Title: Análise de Dados / Banco de Dados Relacionais
Tags: Análise_de_Dados Resumo
On every note of this deck, unless a note says otherwise:
tldr: - Modelo relacional: dados representados em tabelas (relações) com base em teoria de conjuntos e lógica de predicados; permite consultas declarativas (ex.: SQL).
- Tabelas: relação = conjunto de tuplas (linhas) e atributos (colunas); domínios definem tipos; tuplas sem ordem; valores atômicos e suporte a NULLs; esquema interpreta significado das tuplas.
- Álgebra relacional: operações que produzem relações (σ seleção, π projeção, × produto cartesiano, ⋈ junção, ∪ união, ∩ intersecção, − diferença). Cinco primitivas e duas derivadas.
- Views: tabelas virtuais derivadas de outras tabelas; podem ser consultadas sempre; atualizabilidade depende da view; views materializadas são físicas e melhoram desempenho.
- Índices: estruturas para acelerar consultas; índices primários (clustered) definem ordenação física; secundários (non-clustered) são estruturas separadas; têm custo de manutenção.
- Chaves: superchave (identificação única), chave (superchave mínima), chave composta (mínima com >1 atributo), chaves candidatas, chave primária (escolhida) e substituta (surrogate); restrições: implícitas, explícitas (domínio, entidade, referencial, chave) e semânticas.
- Relacionamentos: 1:1, 1:N, N:M; modelagem das dependências por chaves estrangeiras e cardinalidades.
- Regras de Codd (0–12): princípios que definem um SGBD relacional (representação uniforme, acesso por chave, tratamento de NULL, catálogo relacional, sublinguagem completa como SQL, views atualizáveis, operações de alto nível, independência física/ lógica/ de integridade/ de distribuição e proteção contra subversão por baixo nível).
- Notação IDEF1X: método de modelagem (entidades, atributos, relacionamentos); distingue entidades independentes/dependentes, relacionamentos identificadores vs não identificadores, cardinalidades e obrigatoriedade.
link: https://documentacao.online/estudos/xe47.html
title: Banco de Dados Relacionais

front: (CESPE / CNMP - 2023) Um registro é um conjunto de itens de dados que possuem um conjunto de atributos que pertencem a determinada entidade.
response: Correto
comment: Perfeito! Um registro, em um contexto de banco de dados, é um conjunto de itens de dados que compartilham uma mesma estrutura e representam uma instância de uma entidade específica.
Other fields (not shown on cards):
back: Correto - Perfeito! Um registro, em um contexto de banco de dados, é um conjunto de itens de dados que compartilham uma mesma estrutura e representam uma instância de uma entidade específica.

front: (CESPE / SEPLAN-RR - 2023) No modelo relacional de dados todas as relações necessitam de uma chave primária formada por uma ou mais tuplas que identificam um único registro.
response: Errado
comment: Na verdade, o modelo relacional de dados, cada relação (ou tabela) deve ter uma chave primária, mas essa chave não é necessariamente formada por uma ou mais tuplas. Na verdade, a chave primária é composta por uma ou mais colunas que identificam de forma única cada registro (ou tupla) dentro da relação.
Other fields (not shown on cards):
back: Errado - Na verdade, o modelo relacional de dados, cada relação (ou tabela) deve ter uma chave primária, mas essa chave não é necessariamente formada por uma ou mais tuplas. Na verdade, a chave primária é composta por uma ou mais colunas que identificam de forma única cada registro (ou tupla) dentro da relação.

front: (CESPE / SEPLAN-RR - 2023) No modelo relacional, as estruturas de dados lógicas não são separadas das estruturas de armazenamento físico, o que significa que os administradores de banco de dados não podem gerenciar o armazenamento de dados físicos sem afetar o acesso a esses dados como uma estrutura lógica.
response: Errado
comment: Na verdade, no modelo relacional, as estruturas de dados lógicas são separadas das estruturas de armazenamento físico, o que permite aos administradores de banco de dados gerenciar o armazenamento de dados físicos de forma independente da estrutura lógica dos dados. Essa separação entre a estrutura lógica e a estrutura física permite que os administradores de banco de dados otimizem o armazenamento de dados de acordo com as necessidades do sistema, sem afetar a forma como os dados são acessados e manipulados como uma estrutura lógica.
Other fields (not shown on cards):
back: Errado - Na verdade, no modelo relacional, as estruturas de dados lógicas são separadas das estruturas de armazenamento físico, o que permite aos administradores de banco de dados gerenciar o armazenamento de dados físicos de forma independente da estrutura lógica dos dados. Essa separação entre a estrutura lógica e a estrutura física permite que os administradores de banco de dados otimizem o armazenamento de dados de acordo com as necessidades do sistema, sem afetar a forma como os dados são acessados e manipulados como uma estrutura lógica.

front: (CESPE / TCE-SC - 2022) Em bancos de dados relacionais, o mapeamento do relacionamento não deve seguir a cardinalidade, pois a pluralidade dos tipos de cardinalidade (0, 1 e n) dificulta o mapeamento; ele deve ser realizado com base apenas na chave primária.
response: Errado
comment: Que viagem! O mapeamento de relacionamentos em bancos de dados relacionais deve – sim – considerar a cardinalidade, que é a relação entre as entidades nas tabelas. A cardinalidade é fundamental para definir como as tabelas estão relacionadas. A chave primária é importante, mas sozinha não é suficiente para determinar completamente os relacionamentos – especialmente quando existem associações entre múltiplas entidades. Logo, o mapeamento de relacionamentos deve levar em consideração tanto a chave primária quanto a cardinalidade para garantir a integridade e a precisão das relações entre as tabelas.
Other fields (not shown on cards):
back: Errado - Que viagem! O mapeamento de relacionamentos em bancos de dados relacionais deve – sim – considerar a cardinalidade, que é a relação entre as entidades nas tabelas. A cardinalidade é fundamental para definir como as tabelas estão relacionadas. A chave primária é importante, mas sozinha não é suficiente para determinar completamente os relacionamentos – especialmente quando existem associações entre múltiplas entidades. Logo, o mapeamento de relacionamentos deve levar em consideração tanto a chave primária quanto a cardinalidade para garantir a integridade e a precisão das relações entre as tabelas.

front: (CESPE / FUNPRESP-EXE - 2022) View é uma visualização customizada de uma ou mais tabelas, com seus dados armazenados fisicamente e montada a partir da execução de uma consulta.
response: Errado
comment: Na verdade, uma view é uma tabela virtual, dessa forma seus dados não são armazenados fisicamente, mas sim virtualmente. A exceção é a view materializada, que é armazenada fisicamente, mas a questão trata da view tradicional.
Other fields (not shown on cards):
back: Errado - Na verdade, uma view é uma tabela virtual, dessa forma seus dados não são armazenados fisicamente, mas sim virtualmente. A exceção é a view materializada, que é armazenada fisicamente, mas a questão trata da view tradicional.

front: (CESPE / PC-PB - 2022) Na álgebra relacional, a operação que permite combinar informações de duas relações quaisquer é:
a) o produto cartesiano.
b) a seleção.
c) a projeção.
d) a renomeação.
e) a união.
response: Letra A
comment: O produto cartesiano é a operação binária que produz um resultado que combina as linhas de uma tabela com as linhas de outra tabela.
Other fields (not shown on cards):
back: Letra A - O produto cartesiano é a operação binária que produz um resultado que combina as linhas de uma tabela com as linhas de outra tabela.

front: (CESPE / SEFAZ-AL – 2021) Em um banco de dados relacional, uma chave externa fornece uma relação entre duas tabelas, ou seja, ela é a chave principal de uma tabela e, portanto, aparece como atributo em outra tabela.
response: Correto
comment: Em primeiro lugar, chave externa é um nome alternativo para chave estrangeira, logo ela realmente fornece uma relação entre duas tabelas. Além disso, chave principal é um nome alternativo para chave primária. Dito isso, uma chave estrangeira realmente fornece uma relação entre duas tabelas. Nós sabemos que uma chave estrangeira não será necessariamente chave primária de outra tabela, visto que ela poderá referenciar uma chave candidata. A despeito disso, sabemos que o CESPE ignora essa possibilidade e trata há vários anos que uma chave estrangeira referencia necessariamente a chave primária da tabela referenciada. Logo, é uma jurisprudência da banca – não há como discutir! Apenas para exemplificar, vamos imaginar que tenhamos um relacionamento 1:N entre Pessoa- Carro. Em outras palavras, uma pessoa pode ter vários carros, mas um carro só pode pertencer a uma pessoa em nosso contexto.
Other fields (not shown on cards):
back: Correto - Em primeiro lugar, chave externa é um nome alternativo para chave estrangeira, logo ela realmente fornece uma relação entre duas tabelas. Além disso, chave principal é um nome alternativo para chave primária. Dito isso, uma chave estrangeira realmente fornece uma relação entre duas tabelas. Nós sabemos que uma chave estrangeira não será necessariamente chave primária de outra tabela, visto que ela poderá referenciar uma chave candidata. A despeito disso, sabemos que o CESPE ignora essa possibilidade e trata há vários anos que uma chave estrangeira referencia necessariamente a chave primária da tabela referenciada. Logo, é uma jurisprudência da banca – não há como discutir! Apenas para exemplificar, vamos imaginar que tenhamos um relacionamento 1:N entre Pessoa- Carro. Em outras palavras, uma pessoa pode ter vários carros, mas um carro só pode pertencer a uma pessoa em nosso contexto.

front: (CESPE / ISS-Aracaju – 2021) Em um banco de dados relacional, a condição que garante que valores não possam se repetir dentro da mesma coluna denomina-se:
a) Foregin key.
b) Cláusula unique.
c) Domain restriction.
d) Índice cluster.
e) Reference key.
response: Letra B
comment: A condição que garante que valores não possam se repetir dentro da mesma coluna é a cláusula UNIQUE. Quando uma coluna possui a restrição UNIQUE, garante-se que todos os valores dessa coluna são diferentes entre si (lembrando que toda chave primária é automaticamente UNIQUE).
Other fields (not shown on cards):
back: Letra B - A condição que garante que valores não possam se repetir dentro da mesma coluna é a cláusula UNIQUE. Quando uma coluna possui a restrição UNIQUE, garante-se que todos os valores dessa coluna são diferentes entre si (lembrando que toda chave primária é automaticamente UNIQUE).

front: (CESPE / TCE-SC - 2022) Considere que, no modelo entidade relacionamento mostrado a seguir, IdDoenca, IdPessoa e IdDoencaPessoa sejam respectivamente chaves primárias simples de Doenca, Pessoa e Doenca_Pessoa.
Nesse caso, a modelagem está incorreta, pois, sendo Doenca_Pessoa uma tabela associativa às chaves estrangeiras IdPessoa e IdDoenca, nela contidas, deveriam fazer parte da chave primária de Doenca_Pessoa, uma vez que os relacionamentos #1 e #2 são identificados.
response: Errado
comment: Vamos analisar diversos pontos da questão: ▪ Temos quatro tabelas e suas respectivas chaves primárias: Cidade (idCidade), Pessoa (idPessoa), Doenca (idDoenca) e Doenca_Pessoa (idDoenca_Pessoa); ▪ Temos um relacionamento 1:N entre Pessoa e Cidade, isto é, uma pessoa vem de uma – e somente uma – cidade; e uma cidade possui diversas pessoas; ▪ Pessoa e Doenca possuem um relacionamento N:N, logo é necessário haver uma tabela associativa Doenca_Pessoa para representar a cardinalidade desse relacionamento; ▪ Há um relacionamento 1:N entre Doenca e Doenca_Pessoa (#1) e um relacionamento 1:N entre Pessoa e Doenca_Pessoa (#2); ▪ Um relacionamento identificado ocorre quando uma tabela-filha tem uma chave primária que inclui uma chave estrangeira que faz referência à chave primária da tabela-pai; ▪ A tabela associativa Doenca_Pessoa possui uma chave primária (idDoencaPessoa) e duas chaves estrangeiras (idPessoa e idDoenca); ▪ Logo, a chave primária de Doenca_Pessoa (idDoencaPessoa) não inclui chaves estrangeiras referentes às chaves primárias das tabelas referenciadas (idPessoa e idDoenca); ▪ Para que fossem relacionamentos identificados, a chave primária de Doenca_Pessoa não deveria ser idDoencaPessoa e, sim, uma composição de (idPessoa, idDoenca). ▪ Dessa forma, não temos relacionamentos identificados – razão pela qual a questão foi considerada incorreta. ▪ Essa modelagem poderia conter relacionamentos identificados? Sim, desde que a chave primária de Doenca_Pessoa fosse (idPessoa, idDoenca). Detalhe: o relacionamento identificado seria ideal quando uma mesma pessoa só pode pegar uma mesma doença uma vez (Ex: Catapora); e o relacionamento não identificado quando uma mesma pessoa pode pegar uma mesma doença diversas vezes (Ex: Gripe).
Other fields (not shown on cards):
back: Errado - Vamos analisar diversos pontos da questão: ▪ Temos quatro tabelas e suas respectivas chaves primárias: Cidade (idCidade), Pessoa (idPessoa), Doenca (idDoenca) e Doenca_Pessoa (idDoenca_Pessoa); ▪ Temos um relacionamento 1:N entre Pessoa e Cidade, isto é, uma pessoa vem de uma – e somente uma – cidade; e uma cidade possui diversas pessoas; ▪ Pessoa e Doenca possuem um relacionamento N:N, logo é necessário haver uma tabela associativa Doenca_Pessoa para representar a cardinalidade desse relacionamento; ▪ Há um relacionamento 1:N entre Doenca e Doenca_Pessoa (#1) e um relacionamento 1:N entre Pessoa e Doenca_Pessoa (#2); ▪ Um relacionamento identificado ocorre quando uma tabela-filha tem uma chave primária que inclui uma chave estrangeira que faz referência à chave primária da tabela-pai; ▪ A tabela associativa Doenca_Pessoa possui uma chave primária (idDoencaPessoa) e duas chaves estrangeiras (idPessoa e idDoenca); ▪ Logo, a chave primária de Doenca_Pessoa (idDoencaPessoa) não inclui chaves estrangeiras referentes às chaves primárias das tabelas referenciadas (idPessoa e idDoenca); ▪ Para que fossem relacionamentos identificados, a chave primária de Doenca_Pessoa não deveria ser idDoencaPessoa e, sim, uma composição de (idPessoa, idDoenca). ▪ Dessa forma, não temos relacionamentos identificados – razão pela qual a questão foi considerada incorreta. ▪ Essa modelagem poderia conter relacionamentos identificados? Sim, desde que a chave primária de Doenca_Pessoa fosse (idPessoa, idDoenca). Detalhe: o relacionamento identificado seria ideal quando uma mesma pessoa só pode pegar uma mesma doença uma vez (Ex: Catapora); e o relacionamento não identificado quando uma mesma pessoa pode pegar uma mesma doença diversas vezes (Ex: Gripe).

front: (CESPE / SEFAZ - RS – 2019) Uma das regras de Codd para o modelo relacional consiste:
a) na independência de distribuição.
b) na presença de uma linguagem de programação no SGBD que promova interface com o banco de dados, com a segurança e com a atualização dos dados.
c) na subversão das regras de integridade ou restrições quando utilizada uma linguagem de baixo nível.
d) no não tratamento das atualizações de visões de dados.
e) na dependência de dados físicos (mudança na memória e no método de acesso).
response: Alternativa A
comment: (a) Correto, trata-se da Regra 11; (b) , esse item parece ter relação com a Regra 05, mas essa regra fala de ao menos uma sublinguagem declarativa que promova definição de dados, definição de visualizações, manipulação de dados, restrições de integridade, autorização e controle de transações, logo não vejo relação direta com o que propõe o item; (c) , a Regra 12 trata justamente da não subversão das restrições; (d) , a Regra 06 trata justamente do tratamento de atualizações por meio de visões (views) de dados; (e) , a Regra 08 trata justamente da independência física dos dados.
Other fields (not shown on cards):
back: Alternativa A - (a) Correto, trata-se da Regra 11; (b) , esse item parece ter relação com a Regra 05, mas essa regra fala de ao menos uma sublinguagem declarativa que promova definição de dados, definição de visualizações, manipulação de dados, restrições de integridade, autorização e controle de transações, logo não vejo relação direta com o que propõe o item; (c) , a Regra 12 trata justamente da não subversão das restrições; (d) , a Regra 06 trata justamente do tratamento de atualizações por meio de visões (views) de dados; (e) , a Regra 08 trata justamente da independência física dos dados.

front: (CESPE / APEX-BRASIL – 2021) Não pode ter valor nulo em uma tabela do banco de dados um campo:
a) que seja chave estrangeira.
b) que tenha sido utilizado em um índice.
c) que seja chave primária.
d) que represente uma data de nascimento.
response: Letra C
comment: Todos os outros podem ser nulos, exceto a chave primária. Inclusive a chave estrangeira? Sim, conforme explicado em aula.
Other fields (not shown on cards):
back: Letra C - Todos os outros podem ser nulos, exceto a chave primária. Inclusive a chave estrangeira? Sim, conforme explicado em aula.

front: (CESPE / TCE-RJ – 2021) Superchaves e chaves primárias são utilizadas para diferenciar de maneira única as instâncias de uma entidade, assim como para facilitar o processamento.
response: Correto
comment: Perfeito! Ambas permitem diferenciar de maneira única instâncias de uma entidade, facilitando o processamento (lembrando que uma chave primária é uma superchave mínima). Professor, elas facilitam o processamento? Sim, tente fazer transações sem ter uma chave – o processamento poderá ser bem mais complexo.
Other fields (not shown on cards):
back: Correto - Perfeito! Ambas permitem diferenciar de maneira única instâncias de uma entidade, facilitando o processamento (lembrando que uma chave primária é uma superchave mínima). Professor, elas facilitam o processamento? Sim, tente fazer transações sem ter uma chave – o processamento poderá ser bem mais complexo.

front: CESPE / TCE-RJ – 2021) No modelo relacional de bancos de dados, os elementos ficam armazenados em tabelas bidimensionais simples, contendo linhas (registros) e colunas (campos), e os elementos de um arquivo do banco podem relacionar-se com diversos elementos de outros arquivos.
response: Correto
comment: No modelo relacional, os elementos realmente ficam armazenados em tabelas bidimensionais simples, contendo linhas (registros) e colunas (campos). É importante destacar que – de acordo com Navathe – um arquivo é um termo informal para uma coleção de registros (tabela).
Other fields (not shown on cards):
back: Correto - No modelo relacional, os elementos realmente ficam armazenados em tabelas bidimensionais simples, contendo linhas (registros) e colunas (campos). É importante destacar que – de acordo com Navathe – um arquivo é um termo informal para uma coleção de registros (tabela).

front: CESPE / Polícia Federal – 2021) Se uma tabela de banco de dados tiver 205 atributos, então isso significa que ela tem 205 registros.
response: Errado
comment: Em uma tabela de banco de dados, atributos referem-se às colunas, enquanto registros ou linhas representam as entradas de dados individuais. Logo, uma tabela com 205 atributos significa que ela tem 205 colunas, cada uma podendo conter uma categoria de dado diferente. O número de registros (linhas) na tabela é independente do número de atributos (colunas) e precisa ser determinado separadamente. A quantidade de registros é a quantidade de entradas de dados na tabela, enquanto o número de atributos é a quantidade de diferentes tipos de informação que cada registro pode conter.
Other fields (not shown on cards):
back: Errado - Em uma tabela de banco de dados, atributos referem-se às colunas, enquanto registros ou linhas representam as entradas de dados individuais. Logo, uma tabela com 205 atributos significa que ela tem 205 colunas, cada uma podendo conter uma categoria de dado diferente. O número de registros (linhas) na tabela é independente do número de atributos (colunas) e precisa ser determinado separadamente. A quantidade de registros é a quantidade de entradas de dados na tabela, enquanto o número de atributos é a quantidade de diferentes tipos de informação que cada registro pode conter.

front: (CESPE / Polícia Federal – 2021) Uma hiperchave é uma tupla que permite recuperar uma relação de uma tabela.
response: Errado
comment: O termo "hiperchave" não é comumente usado na literatura padrão de banco de dados. Na teoria de banco de dados, especialmente no modelo relacional, uma “superchave” é um conjunto de atributos (ou colunas) em uma tabela que pode ser usado para identificar de forma única cada tupla (ou linha) na tabela. Ela pode incluir um ou mais atributos que, em combinação, são suficientes para garantir a unicidade de cada registro. Uma chave primária é um tipo especial de superchave, que é minimamente suficiente para garantir a unicidade, ou seja, não contém atributos desnecessários. Em suma: não existe o conceito de hiperchave e não faz sentido “recuperar uma relação de uma tabela” porque uma relação é uma tabela!
Other fields (not shown on cards):
back: Errado - O termo "hiperchave" não é comumente usado na literatura padrão de banco de dados. Na teoria de banco de dados, especialmente no modelo relacional, uma “superchave” é um conjunto de atributos (ou colunas) em uma tabela que pode ser usado para identificar de forma única cada tupla (ou linha) na tabela. Ela pode incluir um ou mais atributos que, em combinação, são suficientes para garantir a unicidade de cada registro. Uma chave primária é um tipo especial de superchave, que é minimamente suficiente para garantir a unicidade, ou seja, não contém atributos desnecessários. Em suma: não existe o conceito de hiperchave e não faz sentido “recuperar uma relação de uma tabela” porque uma relação é uma tabela!

front: (CESPE / ME – 2020) Chaves estrangeiras não podem ser nulas e cada registro na tabela deve possuir uma, e somente uma, chave estrangeira.
response: Errado
comment: Chaves estrangeiras – quando não tiverem restrições explícitas na declaração da coluna – podem receber valores nulos. Essa situação acontece quando temos relacionamentos não obrigatórios. Nestes casos, quando uma instância de uma determinada entidade, não estiver relacionada a uma instância da outra entidade, o valor da chave estrangeira será nulo.
Other fields (not shown on cards):
back: Errado - Chaves estrangeiras – quando não tiverem restrições explícitas na declaração da coluna – podem receber valores nulos. Essa situação acontece quando temos relacionamentos não obrigatórios. Nestes casos, quando uma instância de uma determinada entidade, não estiver relacionada a uma instância da outra entidade, o valor da chave estrangeira será nulo.

front: (CESPE / ME – 2020) Uma view é uma tabela que é atualizada no momento em que uma das tabelas consultadas é atualizada; a view permite consultas ao banco de dados de forma mais rápida quando comparada à utilização de índices.
response: Errado
comment: A questão inverteu os conceitos! Um view índice permite consultas ao banco de dados de forma mais rápida quando comparada à utilização de índices views.
Other fields (not shown on cards):
back: Errado - A questão inverteu os conceitos! Um view índice permite consultas ao banco de dados de forma mais rápida quando comparada à utilização de índices views.

front: (CESPE / ME – 2020) Em um banco de dados relacional, a chave candidata a primária é formada por um ou mais atributos que identificam uma única tupla.
response: Correto
comment: Numa relação com mais de uma chave, temos um conjunto de chaves candidatas a chave primária. Em cada relação, apenas um conjunto de atributos pode ser escolhido como chave primária, sendo que toda chave identifica unicamente cada uma das linhas ou tuplas de uma relação. Logo, em um banco de dados relacional, a chave candidata a primária realmente é formada por um ou mais atributos que identificam uma única tupla.
Other fields (not shown on cards):
back: Correto - Numa relação com mais de uma chave, temos um conjunto de chaves candidatas a chave primária. Em cada relação, apenas um conjunto de atributos pode ser escolhido como chave primária, sendo que toda chave identifica unicamente cada uma das linhas ou tuplas de uma relação. Logo, em um banco de dados relacional, a chave candidata a primária realmente é formada por um ou mais atributos que identificam uma única tupla.

front: (CESPE / ME – 2020) A restrição de integridade referencial exige que os valores que aparecem nos atributos especificados de qualquer tupla na relação referenciadora também apareçam nos atributos de pelo menos uma tupla na relação referenciada.
response: Correto
comment: A restrição de integridade referencial restringe que a chave estrangeira de uma tabela seja inconsistente com a chave candidata da tabela referenciada. Em outras palavras, essa restrição existe para manter a consistência das tuplas entre as relações. Logo, a restrição de integridade referencial realmente exige que os valores que aparecem nos atributos especificados de qualquer tupla na relação referenciadora também apareçam nos atributos de pelo menos uma tupla na relação referenciada.
Other fields (not shown on cards):
back: Correto - A restrição de integridade referencial restringe que a chave estrangeira de uma tabela seja inconsistente com a chave candidata da tabela referenciada. Em outras palavras, essa restrição existe para manter a consistência das tuplas entre as relações. Logo, a restrição de integridade referencial realmente exige que os valores que aparecem nos atributos especificados de qualquer tupla na relação referenciadora também apareçam nos atributos de pelo menos uma tupla na relação referenciada.

front: (CESPE / ME – 2020) Um banco de dados relacional organiza os dados em tabelas e os vincula, com base em campos-chave, e essas relações permitem recuperar e combinar dados de uma ou mais tabelas com uma única consulta.
response: Correto
comment: Bancos de dados relacionais realmente organizam dados em tabelas e esses dados se vinculam entre tabelas por meio de campos/colunas e chaves. Essas relações – de fato – permitem recuperar e combinar dados de uma ou mais tabelas com uma única consulta.
Other fields (not shown on cards):
back: Correto - Bancos de dados relacionais realmente organizam dados em tabelas e esses dados se vinculam entre tabelas por meio de campos/colunas e chaves. Essas relações – de fato – permitem recuperar e combinar dados de uma ou mais tabelas com uma única consulta.

front: (CESPE / ME – 2020) Analise o diagrama IDEF1X (pé de galinha) mostrado a seguir.
Sobre esse diagrama e sua implementação relacional correspondente, assinale a afirmativa correta.
a) A1 em T2 pode ser nulo, independentemente de A2 em T2 ser nulo ou não.
b) A1 em T2 pode ser nulo somente se A2 em T2 for nulo.
c) O relacionamento entre T1 e T2 é “não identificador”.
d) Um registro qualquer de T2 pode não estar relacionado a algum registro de T1.
e) Em T2, A2 e A1, concatenados, constituem um identificador para T2.
response: Letra E
comment: Batendo o olho no diagrama, já podemos identificar diversas características importantes: (1) temos uma linha sólida e, não, tracejada. Logo, temos um relacionamento identificador; (2) T2 é representado como um retângulo com arestas arredondadas, logo se trata de uma entidade dependente; (3) a chave primária de T1 se torna chave estrangeira em T2, logo se trata de um relacionamento um-para-muitos; (4) em T2, a chave estrangeira está na parte de cima da linha divisória de atributos, o que indica que a chave estrangeira (A1) compõe a chave primária da Entidade T2 junto com o atributo A2. (5) Pela notação pé-de-galinha, temos (1,1) do lado esquerdo e (0,N) do lado direito. Dito tudo isso, vamos analisar os itens: (a) Errado, não pode ser nulo em nenhuma hipótese porque A1 compõe a chave primária de T2; (b) Errado, não pode ser nulo em nenhuma hipótese porque A1 compõe a chave primária de T2; (c) Errado, trata-se de um relacionamento identificador – baste ver que temos uma linha sólida e, não, tracejada; (d) Errado, isso significaria que que A1 poderia ser nulo e, conforme já vimos, ele não pode; (e) Correto, ambos compõem a chave primária de T2.
Other fields (not shown on cards):
back: Letra E - Batendo o olho no diagrama, já podemos identificar diversas características importantes: (1) temos uma linha sólida e, não, tracejada. Logo, temos um relacionamento identificador; (2) T2 é representado como um retângulo com arestas arredondadas, logo se trata de uma entidade dependente; (3) a chave primária de T1 se torna chave estrangeira em T2, logo se trata de um relacionamento um-para-muitos; (4) em T2, a chave estrangeira está na parte de cima da linha divisória de atributos, o que indica que a chave estrangeira (A1) compõe a chave primária da Entidade T2 junto com o atributo A2. (5) Pela notação pé-de-galinha, temos (1,1) do lado esquerdo e (0,N) do lado direito. Dito tudo isso, vamos analisar os itens: (a) Errado, não pode ser nulo em nenhuma hipótese porque A1 compõe a chave primária de T2; (b) Errado, não pode ser nulo em nenhuma hipótese porque A1 compõe a chave primária de T2; (c) Errado, trata-se de um relacionamento identificador – baste ver que temos uma linha sólida e, não, tracejada; (d) Errado, isso significaria que que A1 poderia ser nulo e, conforme já vimos, ele não pode; (e) Correto, ambos compõem a chave primária de T2.

front: (CESPE / Polícia Federal – 2018) Situação hipotética: Ao analisar um computador, Marcos encontrou inúmeros emails, vídeos e textos advindos, em sua maioria, de comentários em redes sociais. Descobriu também que havia relação entre vários vídeos e textos encontrados em um diretório específico. Assertiva: Nessa situação, tendo como referência somente essas informações, Marcos poderá inferir que se trata de um grande banco de dados relacional, visto que um diretório é equivalente a uma tabela e cada arquivo de texto é equivalente a uma tupla; além disso, como cada arquivo possui um código único, poderá deduzir que esse código é a chave primária que identifica o arquivo de forma unívoca.
response: Errado
comment: De jeito algum! Um banco de dados relacional trata de dados estruturados em linhas e colunas de tabelas. E-mails, vídeos e textos advindos de comentários em redes sociais – em regra – não são dados estruturados. Além disso, diretório não seria uma tabela e o arquivo de texto não seria uma tupla. E quem disse que cada arquivo possui um código único? Além disso, chaves primárias possuem outras características além de serem unívocas. Enfim... tudo errado!
Other fields (not shown on cards):
back: Errado - De jeito algum! Um banco de dados relacional trata de dados estruturados em linhas e colunas de tabelas. E-mails, vídeos e textos advindos de comentários em redes sociais – em regra – não são dados estruturados. Além disso, diretório não seria uma tabela e o arquivo de texto não seria uma tupla. E quem disse que cada arquivo possui um código único? Além disso, chaves primárias possuem outras características além de serem unívocas. Enfim... tudo errado!

front: (CESPE / FUB – 2018) Álgebra relacional é um conjunto de operações sobre relações, sendo gerada dessas operações uma relação de saída.
response: Correto
comment: Perfeito, perfeito, perfeito! Álgebra relacional é um conjunto de operações sobre relações? Sim. Além disso, lembrem-se que toda operação em uma relação resultará em outra relação como saída. Se você fizer uma seleção, projeção, produto cartesiano, qualquer uma gerará como saída outra relação.
Other fields (not shown on cards):
back: Correto - Perfeito, perfeito, perfeito! Álgebra relacional é um conjunto de operações sobre relações? Sim. Além disso, lembrem-se que toda operação em uma relação resultará em outra relação como saída. Se você fizer uma seleção, projeção, produto cartesiano, qualquer uma gerará como saída outra relação.

front: (CESPE / TCE-PE – 2017) Uma visão (view) é derivada de uma ou mais relações e armazena os dados em uma tabela física do banco de dados, visando tornar ágeis as consultas.
response: Errado
comment: Uma view é realmente derivada de uma ou mais relações, no entanto ela é uma tabela virtual que não armazena dados. A questão provavelmente se refere às views materializadas, que são tipos específicos de view que permitem o armazenamento em uma tabela real.
Other fields (not shown on cards):
back: Errado - Uma view é realmente derivada de uma ou mais relações, no entanto ela é uma tabela virtual que não armazena dados. A questão provavelmente se refere às views materializadas, que são tipos específicos de view que permitem o armazenamento em uma tabela real.

front: (CESPE / TCE-PE – 2017) A chave estrangeira (foreign key) é o campo que estabelece o relacionamento entre duas tabelas de bancos distintos, sendo necessariamente chave primária na tabela de um dos bancos.
response: Errado
comment: Opa! A chave estrangeira realmente é o campo que estabelece o relacionamento entre duas tabelas, no entanto essas tabelas devem pertencer ao mesmo banco.
Other fields (not shown on cards):
back: Errado - Opa! A chave estrangeira realmente é o campo que estabelece o relacionamento entre duas tabelas, no entanto essas tabelas devem pertencer ao mesmo banco.

front: (CESPE / TCE-PA – 2016) Em bancos de dados relacionais, chave estrangeira é aquela que permite uma ligação lógica entre duas tabelas — a chave estrangeira de uma tabela se liga logicamente à chave primária de outra tabela.
response: Correto
comment: ATENÇÃO CESPE O CESPE – INFELIZMENTE – TEM ADOTADO O ENTENDIMENTO DE QUE A CHAVE ESTRANGEIRA REFERENCIA A CHAVE PRIMÁRIA (E, NÃO, CANDIDATA) DE OUTRA TABELA (OU DA MESMA TABELA). Perfeito! O entendimento do CESPE é de que a chave estrangeira de uma tabela se liga logicamente à chave primária de outra tabela e, não, à chave candidata.
Other fields (not shown on cards):
back: Correto - ATENÇÃO CESPE O CESPE – INFELIZMENTE – TEM ADOTADO O ENTENDIMENTO DE QUE A CHAVE ESTRANGEIRA REFERENCIA A CHAVE PRIMÁRIA (E, NÃO, CANDIDATA) DE OUTRA TABELA (OU DA MESMA TABELA). Perfeito! O entendimento do CESPE é de que a chave estrangeira de uma tabela se liga logicamente à chave primária de outra tabela e, não, à chave candidata.

front: (CESPE / TCE-SC – 2016) Denomina-se visão uma tabela única derivada de uma ou mais tabelas básicas do banco. Essa tabela existe em forma física e viabiliza operações ilimitadas de atualização e consulta.
response: Errado
comment: Primeiro, ela realmente é uma tabela única derivada de uma ou mais tabelas básicas do banco. No entanto, ela existe em forma virtual o que – via de regra – inviabiliza operações de atualização.
Other fields (not shown on cards):
back: Errado - Primeiro, ela realmente é uma tabela única derivada de uma ou mais tabelas básicas do banco. No entanto, ela existe em forma virtual o que – via de regra – inviabiliza operações de atualização.

front: (CESPE / TCE-SC - 2016) Em bancos de dados relacionais, as tabelas que compartilham um elemento de dado em comum podem ser combinadas para apresentar dados solicitados pelos usuários.
response: Correto
comment: A questão trata de junções! Essas operações utilizam atributos que operam sobre o mesmo domínio presentes em cada uma das tabelas. Esses atributos são utilizados para combinar uma tabela com a outra toda vez que tivermos os mesmos valores em ambas as tabelas.
Other fields (not shown on cards):
back: Correto - A questão trata de junções! Essas operações utilizam atributos que operam sobre o mesmo domínio presentes em cada uma das tabelas. Esses atributos são utilizados para combinar uma tabela com a outra toda vez que tivermos os mesmos valores em ambas as tabelas.

front: (FCC / SEFAZ-AP – 2022) Considere que durante a modelagem de um banco de dados relacional observou-se a existência de duas entidades, Produto e Venda, que se relacionam com cardinalidade muitos-para-muitos, uma vez que em uma venda pode haver vários produtos e um determinado produto pode estar qualificado em várias vendas (no caso, unidades diferentes do mesmo produto). Como os sistemas gerenciadores de banco de dados relacionais existentes não implementam relacionamento muitos-para-muitos, para criar as tabelas referentes às entidades no banco de dados será necessário:
a) estabelecer uma relação de herança, onde a tabela Venda herdará os atributos da tabela Produto.
b) criar uma tabela filha para Produto e uma para Venda e relacionar estas tabelas filhas com cardinalidade um-para-muitos.
c) que a chave primária da tabela Venda apareça como chave estrangeira na tabela Produto e que a chave primária da tabela Produto apareça como chave estrangeira na tabela Venda.
d) criar uma tabela de ligação entre Produto e Venda, onde o relacionamento muitos-para- muitos será dividido em dois relacionamentos um-para-um.
e) criar uma tabela associativa, onde o relacionamento muitos-para-muitos será desmembrado em dois relacionamentos do tipo um-para-muitos.
response: Letra E
comment: Questão clássica! Como sistemas gerenciadores de bancos de dados relacionais não implementam relacionamento muitos-para-muitos, para criar as tabelas referentes às entidades no banco de dados será necessário criar uma terceira tabela – chamada tabela associativa ou tabela de ligação – que conecte as tabelas Produto e Venda de forma que essas duas tabelas tenham uma relação de um-para-muitos com a tabela associativa. Lembrem-se sempre: será necessária uma terceira tabela para representar relacionamentos N:M de tal forma que as tabelas tenham um relacionamento 1:N para com a tabela associativa.
Other fields (not shown on cards):
back: Letra E - Questão clássica! Como sistemas gerenciadores de bancos de dados relacionais não implementam relacionamento muitos-para-muitos, para criar as tabelas referentes às entidades no banco de dados será necessário criar uma terceira tabela – chamada tabela associativa ou tabela de ligação – que conecte as tabelas Produto e Venda de forma que essas duas tabelas tenham uma relação de um-para-muitos com a tabela associativa. Lembrem-se sempre: será necessária uma terceira tabela para representar relacionamentos N:M de tal forma que as tabelas tenham um relacionamento 1:N para com a tabela associativa.

front: (FCC / SEFAZ-AP – 2022) Considere as seguintes tabelas relacionais e seus respectivos campos: Tabela1: CPF-Contribuinte, Nome-Contribuinte, Idade-Contribuinte Tabela2: CNPJ-Contribuinte, RazaoSocial, UF, CPF-Contribuinte CPF-Contribuinte e CNPJ-Contribuinte são definidos como Primary-Key, Unique. O campo:
a) CNPJ-Contribuinte é considerado chave estrangeira na Tabela2.
b) CNPJ-Contribuinte é considerado chave estrangeira na Tabela1.
c) CPF-Contribuinte é considerado chave estrangeira na Tabela2.
d) CPF-Contribuinte não é considerado chave estrangeira na Tabela2 porque é Unique na Tabela1.
e) CPF-Contribuinte é considerado chave estrangeira na Tabela1.
response: Letra C
comment: A Tabela1 possui três atributos e a Tabela2 possui quatro atributos, sendo que os atributos CPF- Contribuinte e CNPJ-Contribuinte são chave primária de suas respectivas tabelas. A questão não deixa explícito em seu código (o que eu considero um problema grave), mas é possível inferir que o atributo CPF-Contribuinte na Tabela2 é uma chave estrangeira que referencia o atributo CPF- Contribuinte na Tabela1. Dito isso, vamos analisar item a item: (a) Errado, é considerado chave primária; (b) Errado, esse campo nem existe na Tabela1; (c) Correto; (d) Errado, ele é considerado chave estrangeira na Tabela2; (e) Errado, é considerado chave primária.
Other fields (not shown on cards):
back: Letra C - A Tabela1 possui três atributos e a Tabela2 possui quatro atributos, sendo que os atributos CPF- Contribuinte e CNPJ-Contribuinte são chave primária de suas respectivas tabelas. A questão não deixa explícito em seu código (o que eu considero um problema grave), mas é possível inferir que o atributo CPF-Contribuinte na Tabela2 é uma chave estrangeira que referencia o atributo CPF- Contribuinte na Tabela1. Dito isso, vamos analisar item a item: (a) Errado, é considerado chave primária; (b) Errado, esse campo nem existe na Tabela1; (c) Correto; (d) Errado, ele é considerado chave estrangeira na Tabela2; (e) Errado, é considerado chave primária.

front: (FCC / SEFAZ-AP – 2022) Considere as seguintes tabelas relacionais e seus respectivos campos: Tabela1: CPF-Contribuinte, Nome-Contribuinte, Idade-Contribuinte Tabela2: CNPJ-Contribuinte, RazaoSocial, UF, CPF-Contribuinte CPF-Contribuinte e CNPJ-Contribuinte são definidos como Primary-Key, Unique. Com base nessas informações, é correto afirmar:
a) A Tabela1 se relaciona com a Tabela2 na ordem de cardinalidade n:1.
b) A Tabela1 não seria uma entidade no Modelo Entidade-Relacionamento porque o CPF- Contribuinte está em duas tabelas.
c) Ambas as tabelas se relacionam em cardinalidade n:m.
d) A Tabela1 se relaciona com a Tabela2 na ordem de cardinalidade 1:n.
e) A Tabela2 e a Tabela1 podem ser unificadas em uma única tabela relacional normalizada.
response: Letra D
comment: Inferindo que CPF-Contribuinte na Tabela2 é chave estrangeira que referencia CPF-Contribuinte da Tabela1, vamos analisar os itens: (a) Errado. Vocês se lembram que a forma de modelar um relacionamento 1:N é inserindo a chave estrangeira para o lado N do relacionamento? Ora, se a chave estrangeira está na Tabela2, então temos um relacionamento 1:N entre Tabela1 e Tabela2. Dito de outra forma, temos um relacionamento N:1 entra Tabela 2 e Tabela1; (b) Errado, isso não impede que a Tabela1 seja uma entidade no MER; (c) Errado, conforme vimos nós temos um relacionamento N:1 entra Tabela 2 e Tabela1. Se o relacionamento fosse N:M, deveria existir uma tabela associativa; (d) Correto; (e) Errado. Seria possível unificá-las em uma única tabela relacional, mas não de forma normalizada. Se você unificá-las, alguns atributos ficarão repetidos, o que fere o princípio da normalização.
Other fields (not shown on cards):
back: Letra D - Inferindo que CPF-Contribuinte na Tabela2 é chave estrangeira que referencia CPF-Contribuinte da Tabela1, vamos analisar os itens: (a) Errado. Vocês se lembram que a forma de modelar um relacionamento 1:N é inserindo a chave estrangeira para o lado N do relacionamento? Ora, se a chave estrangeira está na Tabela2, então temos um relacionamento 1:N entre Tabela1 e Tabela2. Dito de outra forma, temos um relacionamento N:1 entra Tabela 2 e Tabela1; (b) Errado, isso não impede que a Tabela1 seja uma entidade no MER; (c) Errado, conforme vimos nós temos um relacionamento N:1 entra Tabela 2 e Tabela1. Se o relacionamento fosse N:M, deveria existir uma tabela associativa; (d) Correto; (e) Errado. Seria possível unificá-las em uma única tabela relacional, mas não de forma normalizada. Se você unificá-las, alguns atributos ficarão repetidos, o que fere o princípio da normalização.

front: (FCC / TRF4 – 2019) Dentre as regras de Codd que caracterizam Bancos de Dados Relacionais, a regra da Independência de Integridade estipula que as várias formas de integridade relacional de banco de dados:
a) precisam ser definidas na linguagem relacional e armazenadas dentro do catálogo do sistema ou dicionário de dados, e ser totalmente independentes da lógica dos aplicativos.
b) podem ser representadas em tabelas relacionais específicas que se relacionam com as tabelas de cada aplicativo. Quando um aplicativo mudar, a regra de independência muda automaticamente.
c) precisam ser definidas na linguagem de cada aplicativo e armazenadas como tabelas relacionais dentro do banco de cada aplicativo, pois somente desta forma, ao mudar o aplicativo, as regras de integridade mudarão também, automaticamente.
d) podem ser definidas em linguagem natural ou em Shell script e armazenadas no dicionário de dados ou dentro do catálogo do sistema; contudo, não há como garantir que elas sejam totalmente independentes da lógica dos aplicativos na totalidade das situações.
e) devem ser escritas em linguagem hierárquica ou de rede pois, desta forma, tanto a hierarquia das tabelas quanto os links entre elas, como ocorre nos bancos em rede, conduzirão às mudanças automáticas das integridades ao se mudar algum aplicativo.
response: Alternativa A
comment: (a) Correto, trata-se da Regra 10; (b) , isso fere a Regra 10, visto regras de um aplicativo são independentes de regras de restrições de integridade de uma base de dados relacional, logo não são modificadas com alterações em um aplicativo; (c) , mudanças no aplicativo não afetam as regras de integridade; (d) , devem ser escritas em linguagem relacional e devem ser logicamente independentes de aplicativos; (e) , devem ser escritas em linguagem relacional e devem ser logicamente independentes de aplicativos.
Other fields (not shown on cards):
back: Alternativa A - (a) Correto, trata-se da Regra 10; (b) , isso fere a Regra 10, visto regras de um aplicativo são independentes de regras de restrições de integridade de uma base de dados relacional, logo não são modificadas com alterações em um aplicativo; (c) , mudanças no aplicativo não afetam as regras de integridade; (d) , devem ser escritas em linguagem relacional e devem ser logicamente independentes de aplicativos; (e) , devem ser escritas em linguagem relacional e devem ser logicamente independentes de aplicativos.

front: (FCC / SEFAZ - SP – 2009) Considere a seguinte regra de Codd, aplicada aos bancos de dados relacionais: A descrição do banco de dados é representada no nível lógico da mesma forma que os dados ordinários, permitindo que usuários autorizados utilizem a mesma linguagem relacional aplicada aos dados regulares. O sentido dessa regra diz respeito à:
a) formação do catálogo.
b) manipulação, por meio de visões.
c) independência física.
d) independência lógica.
e) independência de distribuição.
response: Letra A
comment: A questão trata da Regra 04 – Catálogo baseado no Modelo Relacional: O catálogo do sistema, que contém a descrição lógica da base de dados, deve ser representado da mesma forma que os dados comuns. Essa descrição do banco de dados é representada no nível lógico da mesma forma que os dados ordinários, permitindo que usuários autorizados utilizem a mesma linguagem relacional aplicada aos dados regulares.
Other fields (not shown on cards):
back: Letra A - A questão trata da Regra 04 – Catálogo baseado no Modelo Relacional: O catálogo do sistema, que contém a descrição lógica da base de dados, deve ser representado da mesma forma que os dados comuns. Essa descrição do banco de dados é representada no nível lógico da mesma forma que os dados ordinários, permitindo que usuários autorizados utilizem a mesma linguagem relacional aplicada aos dados regulares.

front: (FGV / SEAD-AP – 2022) Considere a tabela TABX, implementada num banco de dados relacional com a instância exibida a seguir.
TABX
Excetuada a linha de títulos, assinale o número de linhas produzidas pela execução do comando SQL a seguir.
SELECT DISTINCT A, C FROM TABX
a) 4
b) 3
c) 2
d) 1
e) 0
response: Alternativa B
comment: O DISTINCT é utilizado para retornar apenas valores distintos. Logo, devemos excluir as linhas duplicadas nas colunas A e C
Other fields (not shown on cards):
back: Alternativa B - O DISTINCT é utilizado para retornar apenas valores distintos. Logo, devemos excluir as linhas duplicadas nas colunas A e C

front: (FGV / SEFAZ-BA – 2022) Com relação aos conceitos de banco de dados relacionais, analise as afirmativas a seguir.
I. Instância do banco se refere à supressão de detalhes da organização e do armazenamento de dados, descartando para um melhor conhecimento desses dados os recursos essenciais.
II. Modelo de dados se refere a uma coleção de conceitos que podem ser utilizados para descrever a estrutura de um banco de dados, oferecendo os meios necessários para alcançar essa abstração.
III. Abstração de dados refere aos conjuntos de dados e metadados e usuários presentes no servidor de dados em um determinado instante.
Está correto o que se afirma em:
a) I, somente.
b) II, somente.
c) III, somente.
d) I e II, somente.
e) I e III, somente.
response: Letra B
comment: (I) Errado, essa é a definição de abstração de dados; (II) Correto; (III) Errado, essa é a definição de instância do banco de dados.
Other fields (not shown on cards):
back: Letra B - (I) Errado, essa é a definição de abstração de dados; (II) Correto; (III) Errado, essa é a definição de instância do banco de dados.

front: (FGV / SEFAZ-AM – 2022) A estrutura de dados usada em índices multiníveis dinâmicos em banco de dados relacionais, que garantem que tais estruturas sempre estejam balanceadas e que o espaço desperdiçado pela exclusão de itens de dados, se houver, nunca se torne excessivo, é denominada:
a) fila.
b) hash.
c) bitmap.
d) árvore B.
e) árvore binária.
response: Letra D
comment: Questão completamente sem noção! A estrutura de dados que utiliza índices multiníveis dinâmicos que permite balanceamento das estruturas é a Árvore B. Ocorre que esse é um assunto extremamente aprofundado, que existe o conhecimento de diversas estruturas de dados mais simples até podermos entender essa estrutura de dado mais complexa. Árvore B é uma estrutura de dados em árvore, auto-balanceada, que armazena dados classificados e permite pesquisas, acesso sequencial, inserções e remoções em tempo logarítmico. Já o Índice em Árvore B é um índice de árvore balanceada possui acesso eficiente para consultas de intervalos. A atualização de uma Árvore B é relativamente eficiente, porém seu desempenho pode se degradar conforme o arquivo aumenta de tamanho. Trata-se de uma estrutura de dados bastante complicada e que não faz sentido cobrar em prova sem que esteja previsto especificamente no edital. Enfim... questão para pular e ser feliz!
Other fields (not shown on cards):
back: Letra D - Questão completamente sem noção! A estrutura de dados que utiliza índices multiníveis dinâmicos que permite balanceamento das estruturas é a Árvore B. Ocorre que esse é um assunto extremamente aprofundado, que existe o conhecimento de diversas estruturas de dados mais simples até podermos entender essa estrutura de dado mais complexa. Árvore B é uma estrutura de dados em árvore, auto-balanceada, que armazena dados classificados e permite pesquisas, acesso sequencial, inserções e remoções em tempo logarítmico. Já o Índice em Árvore B é um índice de árvore balanceada possui acesso eficiente para consultas de intervalos. A atualização de uma Árvore B é relativamente eficiente, porém seu desempenho pode se degradar conforme o arquivo aumenta de tamanho. Trata-se de uma estrutura de dados bastante complicada e que não faz sentido cobrar em prova sem que esteja previsto especificamente no edital. Enfim... questão para pular e ser feliz!

front: (FGV / IBGE - 2017) Na década de 80, Edgar Frank Codd definiu um conjunto de regras para definir o que são bancos de dados relacionais. A opção que NÃO faz parte dessas regras, é:
a) qualquer visualização que teoricamente possa ser atualizada deve ser realizada através do próprio sistema;
b) aplicativos e recursos ad hoc não devem ser afetados logicamente quando os métodos de acesso ou as estruturas de armazenamento físico forem alterados;
c) restrições de integridade necessitam ser especificadas dentro dos programas de aplicação, de modo que mudanças nessas restrições sejam observadas por essas aplicações;
d) todas as informações no banco devem ser representadas logicamente como valores de coluna em linhas dentro das tabelas;
e) os usuários finais e aplicativos não devem conhecer nem serem afetados pela localização dos dados.
response: Alternativa C
comment: (a) Correto, trata-se da Regra 06; (b) Correto, trata-se da Regra 08; (c) , elas não necessitam ser especificadas dentro dos programas de aplicação e eventuais mudanças não precisam ser observadas pela aplicação. Na verdade, elas precisam ser definidas na linguagem relacional e armazenadas dentro do catálogo do sistema – além de ser totalmente independentes da lógica dos aplicativos; (d) Correto, trata-se da Regra 00; (e) Correto, trata-se da Regra 11.
Other fields (not shown on cards):
back: Alternativa C - (a) Correto, trata-se da Regra 06; (b) Correto, trata-se da Regra 08; (c) , elas não necessitam ser especificadas dentro dos programas de aplicação e eventuais mudanças não precisam ser observadas pela aplicação. Na verdade, elas precisam ser definidas na linguagem relacional e armazenadas dentro do catálogo do sistema – além de ser totalmente independentes da lógica dos aplicativos; (d) Correto, trata-se da Regra 00; (e) Correto, trata-se da Regra 11.

front: (FGV / MPE-AL – 2018) Em um banco de dados relacional, um nome da tabela, uma chave primária e um nome de coluna garantem o acesso a:
a) um dado.
b) um SGBD.
c) uma linguagem de consulta.
d) uma partição.
e) uma visão.
response: Letra A
comment: O nome da tabela permite identificar uma tabela específica; uma chave primária de uma tabela específica permite identificar uma linha específica; e um nome de coluna com uma linha específica de uma determinada tabela permite identificar um dado.
Other fields (not shown on cards):
back: Letra A - O nome da tabela permite identificar uma tabela específica; uma chave primária de uma tabela específica permite identificar uma linha específica; e um nome de coluna com uma linha específica de uma determinada tabela permite identificar um dado.

front: (FGV / AL-RO – 2018) No processo de otimização e processamento de consultas em bancos de dados relacionais, a construção da query tree (ou árvore de consulta) é feita com base nas operações da Álgebra Relacional. Assinale a opção que indica as operações primitivas dessa álgebra, ou seja, as operações que não podem ser expressas por combinações das demais operações:
a) Diferença, Divisão, Projeção, Produto, Seleção.
b) Diferença, Projeção, Produto, Seleção, União.
c) Divisão, Interseção, Junção, Produto, Seleção, União.
d) Junção, Projeção, Produto, Seleção, União.
e) Junção, Produto, Projeção, Seleção, União.
response: Letra B
comment: As operações primitivas são aquelas que não podem ser obtidas a partir de outras: seleção, projeção, produto cartesiano, união e diferença. Já as outras são consideradas operações derivadas, porque podem ser obtidas a partir de outras operações.
Other fields (not shown on cards):
back: Letra B - As operações primitivas são aquelas que não podem ser obtidas a partir de outras: seleção, projeção, produto cartesiano, união e diferença. Já as outras são consideradas operações derivadas, porque podem ser obtidas a partir de outras operações.

front: (FGV / AL-RO – 2018) O diagrama IDEF1X exibido a seguir será referenciado na questão seguinte.
Considere o relacionamento estabelecido entre as entidades E1 e E2 no diagrama IDEF1X. Assinale a opção que apresenta a leitura correta que deve ser feita dessa representação.
a) A cada elemento de E1 está associado um e somente um elemento de E2.
b) A cada elemento de E1 estão associados entre 1 e N elementos de E2.
c) A cada elemento de E2 está associado um e somente um elemento de E1.
d) A cada elemento de E2 estão associados entre 1 e N elementos de E1.
e) A cada elemento de E2 podem estar associados zero ou um elemento de E1.
response: Letra C
comment: (a) Errado. Temos um círculo e um pé-de-galinha do lado direito, logo a cada elemento de E1 está associado zero ou vários elementos de E2; (b) Errado, conforme comentário do item anterior; (c) Correto. Temos dois traços do lado esquerdo, logo cada elemento de E2 está associado um e somente um elemento de E1; (d) Errado, conforme comentário do item anterior; (e) Errado, conforme comentário anterior.
Other fields (not shown on cards):
back: Letra C - (a) Errado. Temos um círculo e um pé-de-galinha do lado direito, logo a cada elemento de E1 está associado zero ou vários elementos de E2; (b) Errado, conforme comentário do item anterior; (c) Correto. Temos dois traços do lado esquerdo, logo cada elemento de E2 está associado um e somente um elemento de E1; (d) Errado, conforme comentário do item anterior; (e) Errado, conforme comentário anterior.

front: (FGV / AL-RO – 2018) Na representação de esquemas para bancos de dados relacionais por meio da notação IDEF1X, os relacionamentos podem ser identificadores ou não identificadores. Sobre a consequência do uso de relacionamentos identificadores, assinale a afirmativa correta.
a) Uma tabela não pode participar em mais de um relacionamento identificador.
b) A cardinalidade de um relacionamento identificador deve ser 1:1.
c) A tabela do lado N do relacionamento deve possuir uma chave primária que independa da chave estrangeira decorrente do relacionamento.
d) A chave estrangeira decorrente do relacionamento deve fazer parte da chave primária da tabela.
e) A chave estrangeira decorrente do relacionamento deve permitir a preenchimento com valores nulos.
response: Letra D
comment: (a) Errado, não existe essa limitação; (b) Errado, é possível utilizar outra cardinalidade; (c) Errado, a chave primária do lado N do relacionamento deve possuir uma chave primária composta que depende da chave estrangeira decorrente do relacionamento; (d) Correto, a chave primária da entidade-filha é composta pela chave estrangeira que referencia a chave primária da entidade-pai, além de um identificador; (e) Errado, a chave estrangeira não pode ser nula em um relacionamento identificador porque ela compõe a chave primária da entidade-filha.
Other fields (not shown on cards):
back: Letra D - (a) Errado, não existe essa limitação; (b) Errado, é possível utilizar outra cardinalidade; (c) Errado, a chave primária do lado N do relacionamento deve possuir uma chave primária composta que depende da chave estrangeira decorrente do relacionamento; (d) Correto, a chave primária da entidade-filha é composta pela chave estrangeira que referencia a chave primária da entidade-pai, além de um identificador; (e) Errado, a chave estrangeira não pode ser nula em um relacionamento identificador porque ela compõe a chave primária da entidade-filha.

front: (FGV / AL-RO – 2018) Com relação ao diagrama IDEF1X, considere as afirmativas a seguir sobre um eventual esquema relacional, com tabelas E1 e E2, que implemente aquele diagrama.
I. A coluna A1, de E1, deve permitir valores nulos.
II. A coluna AA de E1 não pode conter repetições de valores não nulos.
III. A coluna A1, de E2, deve permitir valores nulos.
Está correto o que se afirma em
a) I, somente.
b) II, somente.
c) III, somente.
d) I e II, somente.
e) II e III, somente.
response: Letra B
comment: (I) Errado, dado que E1 em A1 é chave primária, logo não pode ser nula; (II) Correto. Notem que E1 está em um auto-relacionamento com cardinalidade (0,1)(0,1). Logo, essa chave estrangeira pode ser nula porque não faz parte da chave primária de E2. No entanto, sua cardinalidade máxima é 1, logo não pode haver repetição de valor não-nulos – ou não tem nenhum valor ou tem apenas um; (III) Errado, essa chave estrangeira não pode ser nula dado que compõe a chave primária de E2
Other fields (not shown on cards):
back: Letra B - (I) Errado, dado que E1 em A1 é chave primária, logo não pode ser nula; (II) Correto. Notem que E1 está em um auto-relacionamento com cardinalidade (0,1)(0,1). Logo, essa chave estrangeira pode ser nula porque não faz parte da chave primária de E2. No entanto, sua cardinalidade máxima é 1, logo não pode haver repetição de valor não-nulos – ou não tem nenhum valor ou tem apenas um; (III) Errado, essa chave estrangeira não pode ser nula dado que compõe a chave primária de E2

front: (FGV / IBGE – 2017) Em relação a banco de dados relacionais, analise as afirmativas abaixo:
I. Uma chave primária identifica um registro de forma única, não podendo eventualmente assumir valor nulo.
II. Uma chave estrangeira não pode apontar para uma chave primária da mesma tabela.
III. Uma chave candidata é aquela que define uma combinação de atributos entre tabelas, mas não pode ser uma chave primária.
Está correto o que se afirma em:
a) I;
b) II;
c) III;
d) I e II;
e) I, II e III.
response: Letra A
comment: (I) Correto, toda chave primária deve identificar um registro univocamente e não pode ser nula; (II) Errado, ela pode – sim – no caso de um autorrelacionamento; (III) Errado, uma chave candidata é uma possível chave primária.
Other fields (not shown on cards):
back: Letra A - (I) Correto, toda chave primária deve identificar um registro univocamente e não pode ser nula; (II) Errado, ela pode – sim – no caso de um autorrelacionamento; (III) Errado, uma chave candidata é uma possível chave primária.

front: (FUNDATEC/PROCERGS/2023) Em um modelo lógico de dados, qual é a diferença entre uma entidade fraca e uma entidade forte?
a) Uma entidade fraca não tem atributos próprios, enquanto uma entidade forte tem.
b) Uma entidade fraca depende de outra entidade, chamada de entidade proprietária, enquanto uma entidade forte é independente.
c) Uma entidade fraca possui um relacionamento muitos para muitos, enquanto uma entidade forte possui um relacionamento um para muitos.
d) Uma entidade fraca não tem uma chave primária, enquanto uma entidade forte tem.
e) Uma entidade fraca pode ser removida sem afetar outras entidades, enquanto uma entidade forte é essencial para o modelo.
response: Alternativa B
comment: Entidades fracas são aquelas dependentes de outras entidades, pois sua chave primária é composta a partir de chaves estrangeiras dessa outra entidade. A alternativa que melhor descreve o conceito é a letra B. (Gabarito: Letra B)
Other fields (not shown on cards):
back: Alternativa B - Entidades fracas são aquelas dependentes de outras entidades, pois sua chave primária é composta a partir de chaves estrangeiras dessa outra entidade. A alternativa que melhor descreve o conceito é a letra B. (Gabarito: Letra B)

front: (CEBRASPE/TJ RJ/2021)
A partir do modelo entidade-relacionamento (MER) anterior, utilizado na modelagem de dados relacional, assinale a opção correta.
a) No modelo em questão, há a presença de dois relacionamentos: Tramitação e Responsável.
b) A entidade COMARCA é um exemplo de entidade fraca.
c) Número, Código e OAB são atributos multivalorados.
d) Um ADVOGADO é responsável por no máximo um PROCESSO, pois contém a cardinalidade (0,1).
e) Um PROCESSO pode tramitar em nenhuma ou em várias COMARCAS, já que apresenta cardinalidade (0,n).
response: Alternativa A
comment: Vamos analisar cada alternativa. a) Certo. De fato, temos dois relacionamentos - Tramitação e Responsável. b) Errado. Entidades fracas apresentam bordas duplas, que não é o caso da entidade Comarca. c) Errado. Eles são atributos identificadores, e não multivalorados. d) Errado. Aqui vocês tem que ter cuidado galera, o relacionamento ADVOGADO → PROCESSO é aquele representado ao lado de PROCESSO, ou seja, (0, n). Ou seja, cada advogado pode ser responsável por nenhum ou inúmeros processos. e) Errado. A mesma coisa que aconteceu na afirmativa anterior, no relacionamento PROCESSO → COMARCAS, a cardinalidade é a representada ao lado de COMARCAS - (1, 1). Ou seja, cada processo pertence a 1 e somente 1 comarca. Cuidado com essa parte da cardinalidade - é algo simples, mas que as bancas pegam muito no pé. (Gabarito: Letra A)
Other fields (not shown on cards):
back: Alternativa A - Vamos analisar cada alternativa. a) Certo. De fato, temos dois relacionamentos - Tramitação e Responsável. b) Errado. Entidades fracas apresentam bordas duplas, que não é o caso da entidade Comarca. c) Errado. Eles são atributos identificadores, e não multivalorados. d) Errado. Aqui vocês tem que ter cuidado galera, o relacionamento ADVOGADO → PROCESSO é aquele representado ao lado de PROCESSO, ou seja, (0, n). Ou seja, cada advogado pode ser responsável por nenhum ou inúmeros processos. e) Errado. A mesma coisa que aconteceu na afirmativa anterior, no relacionamento PROCESSO → COMARCAS, a cardinalidade é a representada ao lado de COMARCAS - (1, 1). Ou seja, cada processo pertence a 1 e somente 1 comarca. Cuidado com essa parte da cardinalidade - é algo simples, mas que as bancas pegam muito no pé. (Gabarito: Letra A)

front: (CEBRASPE/MCON/2022) Considerando o modelo abaixo, no qual IdChefe é chave estrangeira relacionada à chave primária IdEmpregado, ambas em Empregado, julgue o item a seguir, relativos a modelagem de dados e SQL.
De acordo com o relacionamento indicado por #1, Empregado possui vários projetos relacionados a ele, havendo, no mínimo, um Projeto.
response: Errado
comment: Galera esse não é um MER, e sim um diagrama entidade-relacionamento (DER), um pouco mais detalhado, que se situa no nível lógico (veja que detalhamos mais a lógica de cada entidade). Mas a cardinalidade aqui funciona da mesma forma que no MER. O relacionamento #1, que envolve as entidades Projeto e Empregado, nos passa duas informações: • O relacionamento EMPREGADO → PROJETO tem cardinalidade 0 e <, ou seja, (0, n) • O relacionamento PROJETO → EMPREGADO tem cardinalidade | e |, ou seja, (1, 1). Sendo assim, a afirmativa está incorreta - já que um empregado pode ter entre 0 e n projetos, podendo ficar sem projetos associados, ao contrário do que a afirmativa aponta. (Gabarito: Errado)
Other fields (not shown on cards):
back: Errado - Galera esse não é um MER, e sim um diagrama entidade-relacionamento (DER), um pouco mais detalhado, que se situa no nível lógico (veja que detalhamos mais a lógica de cada entidade). Mas a cardinalidade aqui funciona da mesma forma que no MER. O relacionamento #1, que envolve as entidades Projeto e Empregado, nos passa duas informações: • O relacionamento EMPREGADO → PROJETO tem cardinalidade 0 e <, ou seja, (0, n) • O relacionamento PROJETO → EMPREGADO tem cardinalidade | e |, ou seja, (1, 1). Sendo assim, a afirmativa está incorreta - já que um empregado pode ter entre 0 e n projetos, podendo ficar sem projetos associados, ao contrário do que a afirmativa aponta. (Gabarito: Errado)

front: (CEBRASPE/ME/2020) Com relação às informações contidas no modelo conceitual abaixo, julgue o próximo item.
Um PAÍS pode, ou não, tributar um SERVIÇO.
response: Certo
comment: A notação da cardinalidade entre PAÍS e SERVIÇO é (0, n) - o que quer dizer que temos um relacionamento opcional. Então, de fato, um PAÍS pode, ou não, tributar um SERVIÇO. (Gabarito: Certo)
Other fields (not shown on cards):
back: Certo - A notação da cardinalidade entre PAÍS e SERVIÇO é (0, n) - o que quer dizer que temos um relacionamento opcional. Então, de fato, um PAÍS pode, ou não, tributar um SERVIÇO. (Gabarito: Certo)

front: (CEBRASPE/FUB/2023) Acerca de bancos de dados relacionais, julgue o item seguinte. As tabelas que estejam na primeira forma normal (1FN) e que possuam apenas uma coluna como chave primária também estão na segunda forma normal (2FN).
response: Certo
comment: Galera, se uma tabela tiver somente uma coluna, ela não terá dependências parciais - já que, por regra, todo atributo define a si mesmo. Portanto, se ela está na 1FN, ela obrigatoriamente está na 2FN. (Gabarito: Certo)
Other fields (not shown on cards):
back: Certo - Galera, se uma tabela tiver somente uma coluna, ela não terá dependências parciais - já que, por regra, todo atributo define a si mesmo. Portanto, se ela está na 1FN, ela obrigatoriamente está na 2FN. (Gabarito: Certo)

front: (FGV/MPE SC/2023) (FGV/MPE SC/2023) A modelagem de bancos de dados passa pela análise das relações e comportamento dos dados que futuramente constituirão o conteúdo desses bancos. Para bancos de dados relacionais, essa modelagem passa pelo levantamento das dependências funcionais que eventualmente possam ser depreendidas em cada caso. Como um exemplo, considere um banco de dados que armazena a data de nascimento, o CPF (Cadastro de Pessoas Físicas) e a CNH (Carteira Nacional de Habilitação) de um grupo de pessoas, no qual todas possuem CPF e CNH. Dado que no Brasil o CPF e a CNH são individualizados, as dependências funcionais que devem ser consideradas, em conjunto, são:
a) CPF → DataNascimento CNH → DataNascimento CPF → CNH CNH → CPF
b) CPF → DataNascimento DataNascimento → CNH CNH → CPF
c) CPF → DataNascimento DataNascimento → CPF CPF → CNH
d) CPF → CNH CNH → CPF
e) CPF → DataNascimento CNH → DataNascimento
response: Letra A
comment: No banco de dados descrito, o CPF e a CNH são chaves únicas de identificação das pessoas, o que significa que cada pessoa tem apenas um CPF e uma CNH. Portanto, existe uma dependência funcional entre CPF e CNH, e vice-versa. Além disso, cada pessoa tem apenas uma data de nascimento, o que significa que existe uma dependência funcional entre o CPF e a data de nascimento, e também entre a CNH e a data de nascimento. Assim, a opção A é a única que considera todas as dependências funcionais necessárias para modelar corretamente esse banco de dados.
Other fields (not shown on cards):
back: Letra A - No banco de dados descrito, o CPF e a CNH são chaves únicas de identificação das pessoas, o que significa que cada pessoa tem apenas um CPF e uma CNH. Portanto, existe uma dependência funcional entre CPF e CNH, e vice-versa. Além disso, cada pessoa tem apenas uma data de nascimento, o que significa que existe uma dependência funcional entre o CPF e a data de nascimento, e também entre a CNH e a data de nascimento. Assim, a opção A é a única que considera todas as dependências funcionais necessárias para modelar corretamente esse banco de dados.

front: (FCC/TRT 23/2022) Considere que uma organização possui um banco de dados com os registros de cidadãos identificados pelo CPF, endereços residenciais identificados pelo CEP e habilidades profissionais pré-determinadas. Os dados dos cidadãos, além dos pessoais, incluem a situação empregatícia atual que pode ser uma das três: empregado contratado, empregado temporário ou desempregado. O banco completo, então, é formado pelas tabelas de cidadãos (cadastro de pessoas), endereços (tabela de CEP), habilidades (tabela de habilidades), tabela cidadão-habilidade e tabela cidadão-endereço. No modelo entidade-relacionamento normalizado até a 3FN, identifica-se como relacionamento, entidade e atributo, correta e respectivamente,
a) cidadão-habilidade, cidadão e situação empregatícia.
b) cidadão, cidadão-endereço e habilidade.
c) situação empregatícia, cidadão e endereço.
d) habilidade, endereço e cidadão-endereço.
e) cidadão-endereço, situação-empregatícia e habilidade.
response: Letra A
comment: O modelo entidade-relacionamento normalizado até a 3FN permite a identificação das entidades, atributos e relacionamentos presentes no banco de dados. Cidadão-Habilidade representa o relacionamento entre a entidade cidadão e a entidade habilidade, pois um cidadão pode ter várias habilidades e uma habilidade pode ser compartilhada por vários cidadãos. Cidadão é uma entidade, representada por uma tabela que contém seus atributos, incluindo a situação empregatícia – permitindo que marquemos a alternativa A como correta. Sobre as demais alternativas: b) A tabela cidadão-endereço não representa um relacionamento, e sim uma entidade associativa, pois ela é criada para associar o cidadão a um endereço de sua residência. c) A situação empregatícia não é uma entidade, e sim um atributo da entidade cidadão. d) A tabela cidadão-endereço representa uma entidade associativa, e não uma entidade separada. e) A tabela cidadão-endereço não é uma entidade, e sim uma entidade associativa, e a situação empregatícia é um atributo da entidade cidadão. A habilidade é uma entidade e deve estar representada em uma tabela própria.
Other fields (not shown on cards):
back: Letra A - O modelo entidade-relacionamento normalizado até a 3FN permite a identificação das entidades, atributos e relacionamentos presentes no banco de dados. Cidadão-Habilidade representa o relacionamento entre a entidade cidadão e a entidade habilidade, pois um cidadão pode ter várias habilidades e uma habilidade pode ser compartilhada por vários cidadãos. Cidadão é uma entidade, representada por uma tabela que contém seus atributos, incluindo a situação empregatícia – permitindo que marquemos a alternativa A como correta. Sobre as demais alternativas: b) A tabela cidadão-endereço não representa um relacionamento, e sim uma entidade associativa, pois ela é criada para associar o cidadão a um endereço de sua residência. c) A situação empregatícia não é uma entidade, e sim um atributo da entidade cidadão. d) A tabela cidadão-endereço representa uma entidade associativa, e não uma entidade separada. e) A tabela cidadão-endereço não é uma entidade, e sim uma entidade associativa, e a situação empregatícia é um atributo da entidade cidadão. A habilidade é uma entidade e deve estar representada em uma tabela própria.

front: (CEBRASPE/ANP/2022) O diagrama de entidade relacionamento a seguir representa a relação entre colaboradores e sua chefia, em que cada chefe pode ter n colaboradores e cada colaborador pode ter muitos chefes.
response: Errado
comment: A cardinalidade indicada na questão “ter como chefe 1”, indica que cada colaborador tem um, e somente um, chefe – na notação numérica, teríamos a cardinalidade 1:1. Outro detalhe interessante nessa questão é que temos um relacionamento recursivo entre pessoa.
Other fields (not shown on cards):
back: Errado - A cardinalidade indicada na questão “ter como chefe 1”, indica que cada colaborador tem um, e somente um, chefe – na notação numérica, teríamos a cardinalidade 1:1. Outro detalhe interessante nessa questão é que temos um relacionamento recursivo entre pessoa.

front: (FCC/TRT 5/2022) O Modelo Entidade-Relacionamento abaixo deve ser utilizado para responder à questão
Observando o Modelo Entidade-Relacionamento apresentado, é possível concluir corretamente que:
a) O atributo nomeDepartamento é chave estrangeira na entidade Departamento.
b) A entidade Login não tem chave estrangeira nem primária.
c) A cardinalidade do relacionamento entre as entidades Funcionario e Login é um-para-um.
d) O atributo telefoneFuncionario é adequado para ser chave primária na entidade Funcionario.
e) A chave primária da entidade Login é composta, pois emailFuncionario é chave primaria e chave estrangeira ao mesmo tempo
response: Letra C
comment: Vamos analisar alternativa por alternativa: a) Errado. nomeDepartatamento, por estar inserida dentro da entidade Departamento, é sua chave primária, não estrangeira. b) Errado. Login tem chave estrangeira, a chave emailFuncionario, que referencia a entidade Funcionário. Além disso, por somente ter chave estrangeira, a entidade Login é considerada uma entidade fraca. c) Certo. A notação utilizada (pé de galinha) nos aponta que a cardinalidade é, de fato, 1:1. d) Errado. Lembrem que a chave primária deve ser única, e não há nenhuma restrição garantindo que telfoneFuncionario o seja. e) Errado. Para ser uma chave composta, a entidade necessitaria de mais de uma chave – e ela só tem uma, estrangeira.
Other fields (not shown on cards):
back: Letra C - Vamos analisar alternativa por alternativa: a) Errado. nomeDepartatamento, por estar inserida dentro da entidade Departamento, é sua chave primária, não estrangeira. b) Errado. Login tem chave estrangeira, a chave emailFuncionario, que referencia a entidade Funcionário. Além disso, por somente ter chave estrangeira, a entidade Login é considerada uma entidade fraca. c) Certo. A notação utilizada (pé de galinha) nos aponta que a cardinalidade é, de fato, 1:1. d) Errado. Lembrem que a chave primária deve ser única, e não há nenhuma restrição garantindo que telfoneFuncionario o seja. e) Errado. Para ser uma chave composta, a entidade necessitaria de mais de uma chave – e ela só tem uma, estrangeira.

front: (FGV/TCU/2022) Para a questão a seguir, considere uma tabela relacional R, com atributos W, X, Y, Z, e o conjunto de dependências funcionais identificadas para esses atributos.
X → Y
X → Z
Z → X
Z → W
Com referência à tabela R, definida anteriormente, considere o esboço de um comando SQL para a criação da tabela.
create table R (
X int not null,
Y int not null,
W int not null,
Z int not null,
constraint …
) De acordo com as dependências funcionais de R, e com a Forma Normal de Boyce-Codd, a definição correta das chaves (por meio de constraints) aplicáveis e necessárias para essa tabela deveria ser:
a) constraint c1 unique (X)
constraint c2 unique (Z)
b) constraint c1 unique (X, Z)
c) constraint c1 unique (X, Y, W)
d) constraint c1 unique (X, Y, Z)
e) constraint c1 unique (X)
constraint c2 unique (Y)
constraint c3 unique (Z)
response: Letra A
comment: Aqui temos um caso da Forma Normal de Boyce-Codd(FNBC) aplicada à prática. Com elas, temos uma superchave. Nossa superchave será definida pelo conjunto de colunas (X, Y, Z ou W) que definir todas as demais colunas. Para encontrar quais são, vamos às regras de associação apresentadas pelo enunciado: X → Y, X → Z, Z → W, portanto, pela regra da transitividade, temos que X → W. E como Z → X, consequentemente, Z define Y e Z. Assim, temos nossas duas chaves concorrentes: Z e X. Para definir uma restrição de domínio em SQL, usamos o comando CONSTRAINT. É necessário que a atribuição de UNIQUE se dê a cada elemento em separado, não ao conjunto de elementos X e Z (conforme a afirmativa B), pois, nesse caso, o que seria único seria o par de chaves A, B, e não as chaves A e B em si. Portanto, nosso gabarito é a letra A.
Other fields (not shown on cards):
back: Letra A - Aqui temos um caso da Forma Normal de Boyce-Codd(FNBC) aplicada à prática. Com elas, temos uma superchave. Nossa superchave será definida pelo conjunto de colunas (X, Y, Z ou W) que definir todas as demais colunas. Para encontrar quais são, vamos às regras de associação apresentadas pelo enunciado: X → Y, X → Z, Z → W, portanto, pela regra da transitividade, temos que X → W. E como Z → X, consequentemente, Z define Y e Z. Assim, temos nossas duas chaves concorrentes: Z e X. Para definir uma restrição de domínio em SQL, usamos o comando CONSTRAINT. É necessário que a atribuição de UNIQUE se dê a cada elemento em separado, não ao conjunto de elementos X e Z (conforme a afirmativa B), pois, nesse caso, o que seria único seria o par de chaves A, B, e não as chaves A e B em si. Portanto, nosso gabarito é a letra A.

front: (FGV/TCE TO/2022) Considere um banco relacional com duas tabelas declaradas como abaixo.
CREATE TABLE T1(A1 int not null UNIQUE,
B1 int not null)
CREATE TABLE T2(A2 int not null UNIQUE,
B2 int,
FOREIGN KEY (B2) references T1(A1))
Para n >= 1, está correto concluir que:
a) cada linha de T1 está relacionada a exatamente 1 linha de T2;
b) cada linha de T1 está relacionada a 0 ou 1 linha de T2;
c) cada linha de T2 está relacionada a exatamente 1 linha de T1;
d) cada linha de T2 está relacionada a 0 ou 1 linha de T1;
e) cada linha de T2 está relacionada a n linhas de T1.
response: Letra D
comment: Essa é uma questão recorrente da FGV e, como ela é um pouco mais complexa, vou ensinar direitinho como vocês podem encontrar a resposta. A sintaxe SQL apresentada cria duas tabelas, uma tabela T1 e outra T2. A tabela T1 tem dois atributos: • A1: uma coluna do tipo INT (números inteiros), que só recebe valores não nulos (not null) e únicos (UNIQUE). Ela é, portanto, uma chave primária. • B1: uma coluna do tipo INT, que só recebe valores não nulos. Já a tabela T2 também possui 2 atributos: • A2: também do tipo INT, que recebe valores não nulos e únicos - a chave primária dessa tabela. • B2: um atributo qualquer, do tipo INT Só que temos um pequeno detalhe - a coluna B2 é uma chave estrangeira na tabela T2, ligada à coluna A1 da tabela T1. Isso define um relacionamento entre as duas tabelas. O grande cerne dessa questão é definir qual a cardinalidade dessa ligação. Então, a princípio, o que temos é isso aqui: T1 T2 A1 (PK) B1 A2 B2 (FK) Para esse tipo de questão, temos dois casos: • A chave estrangeira se liga à chave primária • A chave estrangeira se liga a um atributo qualquer Se a chave estrangeira se ligar à chave primária, já sabemos uma coisa - que a cardinalidade máxima será de 1. A cardinalidade mínima será definida pela própria chave estrangeira. Se tivermos o atributo NOT NULL, a cardinalidade mínima será 1, já que não poderemos ter campos vazios. Se não tivermos esse atributo, a cardinalidade mínima é igual a 0. Já se a chave estrangeira se ligar a um atributo qualquer, a cardinalidade mínima seguirá o mesmo padrão que vimos no caso acima. Porém a cardinalidade máxima é definida pela chave estrangeira - se tivermos o atributo UNIQUE, a cardinalidade máxima será de 1, caso contrário, será ilimitada (n). Então, de forma resumida: • Chave estrangeira ligada a chave primária: o Cardinalidade máxima = 1 o Cardinalidade mínima = ▪ Com o atributo "NOT NULL" = 1 ▪ Sem o atributo "NOT NULL" = 0 • Chave estrangeira ligada a um atributo qualquer: o Cardinalidade mínima = ▪ Com o atributo "NOT NULL" = 1 ▪ Sem o atributo "NOT NULL" = 0 o Cardinalidade máxima = ▪ Com o atributo "UNIQUE" = 1 ▪ Sem o atributo "UNIQUE" = n Na questão em análise, o atributo B2 se liga à coluna A1, que é chave primária na coluna T1. Portanto, já sabemos que a cardinalidade máxima dessa relação será 1. O segundo ponto é analisar a cardinalidade mínima - para isso, verificamos a presença do atributo "NOT NULL". Como não temos esse atributo na construção de B2, podemos afirmar que a cardinalidade mínima é 0. Ficamos, portanto, com a cardinalidade (0, 1) - ou seja, cada linha da tabela T2 irá se relacionar a 0 ou 1 linhas da tabela T1.
Other fields (not shown on cards):
back: Letra D - Essa é uma questão recorrente da FGV e, como ela é um pouco mais complexa, vou ensinar direitinho como vocês podem encontrar a resposta. A sintaxe SQL apresentada cria duas tabelas, uma tabela T1 e outra T2. A tabela T1 tem dois atributos: • A1: uma coluna do tipo INT (números inteiros), que só recebe valores não nulos (not null) e únicos (UNIQUE). Ela é, portanto, uma chave primária. • B1: uma coluna do tipo INT, que só recebe valores não nulos. Já a tabela T2 também possui 2 atributos: • A2: também do tipo INT, que recebe valores não nulos e únicos - a chave primária dessa tabela. • B2: um atributo qualquer, do tipo INT Só que temos um pequeno detalhe - a coluna B2 é uma chave estrangeira na tabela T2, ligada à coluna A1 da tabela T1. Isso define um relacionamento entre as duas tabelas. O grande cerne dessa questão é definir qual a cardinalidade dessa ligação. Então, a princípio, o que temos é isso aqui: T1 T2 A1 (PK) B1 A2 B2 (FK) Para esse tipo de questão, temos dois casos: • A chave estrangeira se liga à chave primária • A chave estrangeira se liga a um atributo qualquer Se a chave estrangeira se ligar à chave primária, já sabemos uma coisa - que a cardinalidade máxima será de 1. A cardinalidade mínima será definida pela própria chave estrangeira. Se tivermos o atributo NOT NULL, a cardinalidade mínima será 1, já que não poderemos ter campos vazios. Se não tivermos esse atributo, a cardinalidade mínima é igual a 0. Já se a chave estrangeira se ligar a um atributo qualquer, a cardinalidade mínima seguirá o mesmo padrão que vimos no caso acima. Porém a cardinalidade máxima é definida pela chave estrangeira - se tivermos o atributo UNIQUE, a cardinalidade máxima será de 1, caso contrário, será ilimitada (n). Então, de forma resumida: • Chave estrangeira ligada a chave primária: o Cardinalidade máxima = 1 o Cardinalidade mínima = ▪ Com o atributo "NOT NULL" = 1 ▪ Sem o atributo "NOT NULL" = 0 • Chave estrangeira ligada a um atributo qualquer: o Cardinalidade mínima = ▪ Com o atributo "NOT NULL" = 1 ▪ Sem o atributo "NOT NULL" = 0 o Cardinalidade máxima = ▪ Com o atributo "UNIQUE" = 1 ▪ Sem o atributo "UNIQUE" = n Na questão em análise, o atributo B2 se liga à coluna A1, que é chave primária na coluna T1. Portanto, já sabemos que a cardinalidade máxima dessa relação será 1. O segundo ponto é analisar a cardinalidade mínima - para isso, verificamos a presença do atributo "NOT NULL". Como não temos esse atributo na construção de B2, podemos afirmar que a cardinalidade mínima é 0. Ficamos, portanto, com a cardinalidade (0, 1) - ou seja, cada linha da tabela T2 irá se relacionar a 0 ou 1 linhas da tabela T1.

front: (FCC/TRT 14/2022) Considere o Modelo Entidade-Relacionamento (MER). Uma entidade desse modelo que só pode ser identificada por meio da associação com uma outra entidade, ou seja, sua chave primária é composta pela chave proveniente dessa outra entidade, concatenada a um identificador de si própria, é classificada como
a) Relação Dependente.
b) Entidade Associativa.
c) Relação por Associação.
d) Entidade Fraca.
e) Entidade subordinada.
response: Letra D
comment: Quando uma entidade é “derivada” de outra – isso é, sua chave primária é composta por uma chave estrangeira, essa entidade é chamada de entidade fraca.
Other fields (not shown on cards):
back: Letra D - Quando uma entidade é “derivada” de outra – isso é, sua chave primária é composta por uma chave estrangeira, essa entidade é chamada de entidade fraca.

front: (FCC/MPE PB/2023) Em um modelo relacional de dados, a restrição de chave serve para garantir que as tuplas de uma relação sejam únicas. Para isso, identifica um conjunto mínimo de atributos que devem ter valores diferentes em todas as tuplas de uma instância da relação. Este conjunto de atributos denomina-se
a) chave estrangeira da relação.
b) chave candidata da relação.
c) chave primária permanente, mas não única.
d) tupla-mãe da relação.
e) tupla-primária da relação.
response: Letra B
comment: A questão nos pede o conceito de chave candidata, que é a chave que tem a capacidade, por ser única e não nula, de se tornar a chave primária de uma tabela.
Other fields (not shown on cards):
back: Letra B - A questão nos pede o conceito de chave candidata, que é a chave que tem a capacidade, por ser única e não nula, de se tornar a chave primária de uma tabela.

front: (FGV/TJ RN/2023) Supondo que no Brasil - todo brasileiro tem um, e somente um, CPF; - alguns brasileiros têm um, mas somente um, passaporte válido; - alguns brasileiros têm uma, mas somente uma, carteira de motorista (CNH) válida. A definição correta desses atributos numa tabela relacional normalizada seria:
a) CPF varchar(11) not null
CNH varchar(9) UNIQUE
Passaporte varchar(9) UNIQUE
b) CPF varchar(11) not null UNIQUE
CNH varchar(9) UNIQUE
Passaporte varchar(9) UNIQUE
c) CPF varchar(11) UNIQUE
CNH varchar(9) not null
Passaporte varchar(9) not null
d) CPF varchar(11) not null
CNH varchar(9) null
Passaporte varchar(9) null
e) CPF varchar(11) null
CNH varchar(9) UNIQUE
Passaporte varchar(9) UNIQUE
response: Letra B
comment: Pelas restrições apresentadas no enunciado, temos o seguinte: • Cada brasileiro tem 1 e somente 1 CPF – portanto, deve ser único (unique) e não nulo (not null) • Alguns brasileiros tem 0:1 passaporte – portanto, deve ser único (unique), mas não precisa ser não nulo (not null). O mesmo é aplicado à CNH. Pelo apresentado acima, está correto o apontado na letra B.
Other fields (not shown on cards):
back: Letra B - Pelas restrições apresentadas no enunciado, temos o seguinte: • Cada brasileiro tem 1 e somente 1 CPF – portanto, deve ser único (unique) e não nulo (not null) • Alguns brasileiros tem 0:1 passaporte – portanto, deve ser único (unique), mas não precisa ser não nulo (not null). O mesmo é aplicado à CNH. Pelo apresentado acima, está correto o apontado na letra B.

front: (FGV/SEFAZ BA/2022) Considerando as restrições do modelo de dados relacionais e os esquemas de bancos de dados relacionais, aquelas que não podem ser expressas diretamente nos modelos de dados e, portanto, devem ser expressas e impostas pelos programas de aplicação, denominam-se restrições
a) inerentes.
b) explicitas.
c) de atributo.
d) semânticas;
e) de domínio.
response: Letra D
comment: Na construção de um banco de dados, temos diferentes restrições inerentes ao modelo. Essas restrições são chamadas de regras semânticas, ou restrições semânticas. Elas são inerentes ao modelo e, portanto, não podem ser expressas (E nem precisam) diretamente no modelo de dados. Essas regras são definidas de acordo com o significado dos dados e são usadas para garantir que apenas dados válidos e corretos sejam armazenados no banco de dados.
Other fields (not shown on cards):
back: Letra D - Na construção de um banco de dados, temos diferentes restrições inerentes ao modelo. Essas restrições são chamadas de regras semânticas, ou restrições semânticas. Elas são inerentes ao modelo e, portanto, não podem ser expressas (E nem precisam) diretamente no modelo de dados. Essas regras são definidas de acordo com o significado dos dados e são usadas para garantir que apenas dados válidos e corretos sejam armazenados no banco de dados.

front: (FGV/SEMSA MANAUS/2022) Para a próxima s questãos, considere do banco de dados relacional happyhour, que contém três tabelas, a saber.
frequencia (cliente, bar)
preferencia (cliente, cerveja)
oferta (bar, cerveja)
A relação frequencia registra o(s) bar(es) que cada cliente frequenta, e tem dois atributos: nome do cliente e nome do bar;
A relação preferencia armazena a(s) cerveja(s) preferida(s) por cada cliente e tem dois atributos: nome do cliente e nome da cerveja;
A relação oferta relaciona a(s) cerveja(s) que cada bar serve, também com dois atributos: nome do bar e nome da cerveja.
É dado que todo cliente frequenta pelos menos um bar, que nem todos os clientes têm preferências, que todo bar oferece pelo menos uma cerveja e que toda cerveja é oferecida pelo menos por um bar. Assinale o esquema correto para a definição de chaves/identificadores para as tabelas do banco de dados happyhour.
a) Em cada tabela, cada coluna é declarada como identificador pela cláusula unique.
b) Em cada tabela, as duas colunas em conjunto formam a primary key.
c) Nenhuma tabela com especificação de identificador ou primary key.
d) Em cada tabela, cada coluna é declarada como identificador pela cláusula unique e declarada como chave estrangeira para as demais tabelas.
e) Em cada tabela, as duas colunas em conjunto formam a primary key e são declaradas, em conjunto, chaves estrangeiras para as demais tabelas.
response: Letra B
comment: A questão quer saber, em suma, qual será nossa chave primária. Percebam que não existe nenhum atributo que, por si só, pode ser considerado chave primária, tendo em vista que eles se repetem em todas as tabelas – cliente está em frequência e preferência, bar está em frequência e oferta, e cerveja está em preferência e bar. Portanto, para identificarmos uma chave corretamente, devemos adotar a forma normal BCFN, criando uma superchave com ambos os atributos da tabela. Sendo assim, está correto o apontamento da afirmativa B. Vamos apontar os erros das demais alternativas: a) Não é possível usar unique, tendo em vista que tanto bar, quanto cerveja e cliente podem se repetir em uma mesma tabela – o que é único é a associação entre ambos. c) Não é possível uma tabela sem chave primária d) Conforme a explicação da afirmativa A, a chave primária é o conjunto das colunas e) Não são chaves estrangeiras, tendo em vista que cada tabela é composta apenas por sua chave primária
Other fields (not shown on cards):
back: Letra B - A questão quer saber, em suma, qual será nossa chave primária. Percebam que não existe nenhum atributo que, por si só, pode ser considerado chave primária, tendo em vista que eles se repetem em todas as tabelas – cliente está em frequência e preferência, bar está em frequência e oferta, e cerveja está em preferência e bar. Portanto, para identificarmos uma chave corretamente, devemos adotar a forma normal BCFN, criando uma superchave com ambos os atributos da tabela. Sendo assim, está correto o apontamento da afirmativa B. Vamos apontar os erros das demais alternativas: a) Não é possível usar unique, tendo em vista que tanto bar, quanto cerveja e cliente podem se repetir em uma mesma tabela – o que é único é a associação entre ambos. c) Não é possível uma tabela sem chave primária d) Conforme a explicação da afirmativa A, a chave primária é o conjunto das colunas e) Não são chaves estrangeiras, tendo em vista que cada tabela é composta apenas por sua chave primária

front: (FGV/DPE RS/2023) Em um Modelo Entidade-Relacionamento (MER), os objetos básicos de um determinado contexto são modelados como entidades. Considere o seguinte contexto de uma empresa imobiliária: “Um cliente aluga um imóvel. Um vendedor vende o imóvel de um cliente. A alocação do funcionário é em um setor. Um cliente tem um imóvel.” No contexto apresentado, o objeto básico que representa uma entidade é:
a) Alocação;
b) Cliente;
c) Aluga;
d) Venda;
e) Tem.
response: Letra B
comment: Para resolver essa questão, precisamos entender que as entidades são representações de objetos do mundo real. Na frase apontada, podemos identificar alguns objetos que se classificam como entidades, por serem "agentes" das relações: • Cliente • Imóvel • Vendedor • Funcionário Todos esses se relacionam entre si de alguma forma. Dos listados, o único que aparece na questão e que, consequentemente, é nosso gabarito, é cliente.
Other fields (not shown on cards):
back: Letra B - Para resolver essa questão, precisamos entender que as entidades são representações de objetos do mundo real. Na frase apontada, podemos identificar alguns objetos que se classificam como entidades, por serem "agentes" das relações: • Cliente • Imóvel • Vendedor • Funcionário Todos esses se relacionam entre si de alguma forma. Dos listados, o único que aparece na questão e que, consequentemente, é nosso gabarito, é cliente.

front: (FGV/DPE RS/2023) Um Modelo Entidade-Relacionamento (MER) é composto basicamente por entidades e seus relacionamentos, assim como por atributos que descrevem suas propriedades. Considere Pessoa como uma entidade que possui diversos dependentes, como: filhos, pai, mãe, enteado etc. Para modelar “Dependentes” como uma propriedade da entidade “Pessoa”, deve-se usar o atributo do tipo:
a) chave;
b) composto;
c) derivado;
d) multivalorado;
e) monovalorado.
response: Letra D
comment: Como você deve ter percebido, "Dependentes" é um atributo que possui múltiplos valores. Mas, seria ele um atributo composto, ou um atributo multivalorado? Sempre que você estiver com essa dúvida, pense da seguinte forma: • Se cada valor do atributo representa uma informação com níveis de abstração diferente → atributo composto. Aqui cada valor terá um significado por si, diferente dos outros valores que compõem o atributo. Por exemplo, um endereço, com Rua, Cidade, Estado etc. • Se cada valor do atributo possui o mesmo nível de abstração → atributo multivalorado. Nesse caso, temos múltiplos valor de mesma "importância" para o atributo. Por exemplo, números de telefone. Na nossa questão, estamos analisando um atributo em que todos os valores possuem o mesmo nível de abstração e, portanto, estamos abordando um atributo multivalorado.
Other fields (not shown on cards):
back: Letra D - Como você deve ter percebido, "Dependentes" é um atributo que possui múltiplos valores. Mas, seria ele um atributo composto, ou um atributo multivalorado? Sempre que você estiver com essa dúvida, pense da seguinte forma: • Se cada valor do atributo representa uma informação com níveis de abstração diferente → atributo composto. Aqui cada valor terá um significado por si, diferente dos outros valores que compõem o atributo. Por exemplo, um endereço, com Rua, Cidade, Estado etc. • Se cada valor do atributo possui o mesmo nível de abstração → atributo multivalorado. Nesse caso, temos múltiplos valor de mesma "importância" para o atributo. Por exemplo, números de telefone. Na nossa questão, estamos analisando um atributo em que todos os valores possuem o mesmo nível de abstração e, portanto, estamos abordando um atributo multivalorado.

front: (CEBRASPE/EMPREL/2023)
Com relação ao modelo entidade-relacionamento (MER) ilustrado na figura precedente, assinale a opção correta.
a) Um treinamento pode ser solicitado por no máximo um cliente.
b) O relacionamento SOLICITA é classificado como ternário.
c) Um cliente pode solicitar vários treinamentos.
d) O modelo está representado de forma incorreta, pois não se admite, em um MER, o uso de atributos em relacionamentos.
e) Na entidade CLIENTE, o atributo Nome é do tipo identificador.
response: Letra C
comment: Vamos analisar cada uma da alternativas. a) Errado. A cardinalidade (0, n) indica que não temos um limite máximo de solicitações b) Errado. Como ele liga apenas duas entidades, é um relacionamento binário. c) Certo. De fato, a cardinalidade (0, n) indica que um cliente pode solicitar nenhum ou vários treinamentos. d) Errado. É admitido o uso de atributos a relacionamentos - porém, idealmente, esse relacionamento deveria ser transformado numa entidade associativa. e) Errado. O atributo identificador é representado por um círculo preenchido. No caso de CLIENTE, o atributo identificador é Código.
Other fields (not shown on cards):
back: Letra C - Vamos analisar cada uma da alternativas. a) Errado. A cardinalidade (0, n) indica que não temos um limite máximo de solicitações b) Errado. Como ele liga apenas duas entidades, é um relacionamento binário. c) Certo. De fato, a cardinalidade (0, n) indica que um cliente pode solicitar nenhum ou vários treinamentos. d) Errado. É admitido o uso de atributos a relacionamentos - porém, idealmente, esse relacionamento deveria ser transformado numa entidade associativa. e) Errado. O atributo identificador é representado por um círculo preenchido. No caso de CLIENTE, o atributo identificador é Código.

front: (VUNESP/DPE SP/2023) Os diagramas entidade-relacionamento representam uma maneira gráfica para a modelagem de bancos de dados relacionais. Um dos símbolos utilizados nesses diagramas é um retângulo desenhado com linhas duplas, que representa um
a) atributo do tipo derivado.
b) atributo de valores múltiplos.
c) conjunto de entidades forte.
d) conjunto de entidades fraco.
e) conjunto de relacionamentos.
response: Letra D
comment: Os objetos representados por retângulos são as entidades. Quando possuímos linhas simples, temos entidades fortes. Quando as linhas são duplas, temos entidades fracas. Mas atenção! É possível adotar também a notação IDEF1X para as entidades - nesse caso, as entidades fracas serão representadas por retângulos de canto arredondado. Veremos uma questão em seguida que aborda esse conhecimento.
Other fields (not shown on cards):
back: Letra D - Os objetos representados por retângulos são as entidades. Quando possuímos linhas simples, temos entidades fortes. Quando as linhas são duplas, temos entidades fracas. Mas atenção! É possível adotar também a notação IDEF1X para as entidades - nesse caso, as entidades fracas serão representadas por retângulos de canto arredondado. Veremos uma questão em seguida que aborda esse conhecimento.

front: (CEBRASPE/EMPREL/2023) Na notação IDEF1X, uma entidade é dependente sempre que sua chave (também conhecida como chave primária) contém a chave completa de pelo menos outra entidade. Nesse contexto, a entidade dependente é representada por
a) retângulos com os cantos vivos (90 graus).
b) retângulos com os cantos arredondados.
c) uma linha pontilhada.
d) linhas rotuladas com um verbo ou uma frase verbal.
e) uma linha dupla.
response: Letra B
comment: Como acabei de falar para vocês, por padrão a notação de uma entidade fraca (que é o que a questão descreve) é feita por retângulos de bordas duplas. Porém, na notação IDEF1X, essas entidades fracas são identificadas através de retângulos com bordas arredondadas.
Other fields (not shown on cards):
back: Letra B - Como acabei de falar para vocês, por padrão a notação de uma entidade fraca (que é o que a questão descreve) é feita por retângulos de bordas duplas. Porém, na notação IDEF1X, essas entidades fracas são identificadas através de retângulos com bordas arredondadas.

front: (CEBRASPE/MPE RO/2023)
Com relação ao modelo entidade-relacionamento (MER) precedente, assinale a opção correta.
a) No modelo apresentado existem duas entidades, cinco atributos e dois relacionamentos.
b) Na entidade PROMOTORIA_JUSTIÇA, o atributo Área de Atuação é do tipo identificador.
c) Em uma entidade COMARCA, deve existir somente uma entidade PROMOTORIA_JUSTIÇA.
d) Uma entidade PROMOTORIA_JUSTIÇA pode estar localizada em várias entidades COMARCA.
e) modelo em questão apresenta erro de construção, pois em um MER não se pode representar atributos com acentuação.
response: Letra D
comment: Vamos às alternativas. a) Errado. Temos, de fato, duas entidades - mas são 6 atributos e 1 relacionamento. b) Errado. O atributo identificador de PROMOTORIA_JUSTIÇA é Código, não Área de Atuação. c) Errado. A cardinalidade (0, n) indica que podemos ter várias promotorias. d) Certo. Novamente, a cardinalidade (0, n) indica que essa possibilidade é verdadeira. e) Errado. O MER é apenas uma representação gráfica, não a implementação final. Na implementação final, a depender do SGBD, devemos evitar acentuações e espaços.
Other fields (not shown on cards):
back: Letra D - Vamos às alternativas. a) Errado. Temos, de fato, duas entidades - mas são 6 atributos e 1 relacionamento. b) Errado. O atributo identificador de PROMOTORIA_JUSTIÇA é Código, não Área de Atuação. c) Errado. A cardinalidade (0, n) indica que podemos ter várias promotorias. d) Certo. Novamente, a cardinalidade (0, n) indica que essa possibilidade é verdadeira. e) Errado. O MER é apenas uma representação gráfica, não a implementação final. Na implementação final, a depender do SGBD, devemos evitar acentuações e espaços.

front: (CEBRASPE/DATAPREV/2023) A respeito de banco de dados, julgue o item a seguir. O modelo entidade relacionamento (MER) representa a estrutura física de um banco de dados relacional.
response: Errado
comment: Cuidado, galera! Essa é uma questão que vocês não podem errar. O MER é uma representação do modelo conceitual, não apontando nada da estrutura física do banco de dados. Incorreta a afirmativa.
Other fields (not shown on cards):
back: Errado - Cuidado, galera! Essa é uma questão que vocês não podem errar. O MER é uma representação do modelo conceitual, não apontando nada da estrutura física do banco de dados. Incorreta a afirmativa.

front: (CEBRASPE/DATAPREV/2023) Com relação a banco de dados, julgue o item a seguir. No MER, a entidade associativa é utilizada para representar um relacionamento entre relacionamentos.
response: Errado
comment: As entidades associativas são criadas quando temos dois relacionamentos muitos-para-muitos (ou seja, (0, n) ou (m, n)) - o que cria uma necessidade de individualização para cada relacionamento, com seus atributos específicos. Elas não são usadas para representar relacionamentos entre relacionamentos - incorreta a afirmativa, portanto.
Other fields (not shown on cards):
back: Errado - As entidades associativas são criadas quando temos dois relacionamentos muitos-para-muitos (ou seja, (0, n) ou (m, n)) - o que cria uma necessidade de individualização para cada relacionamento, com seus atributos específicos. Elas não são usadas para representar relacionamentos entre relacionamentos - incorreta a afirmativa, portanto.

front: (CEBRASPE/DPE RO/2022) Quando um relacionamento entre duas entidades passa a ser tratado também como uma entidade, é gerada uma entidade
a) associativa.
b) por especialização.
c) herança.
d) por generalização.
e) de cardinalidade.
response: Letra A
comment: Quando transformamos um relacionamento em entidade, esse objeto recebe o nome de entidade associativa.
Other fields (not shown on cards):
back: Letra A - Quando transformamos um relacionamento em entidade, esse objeto recebe o nome de entidade associativa.

front: (CESGRANRIO/BASA/2022) No banco de dados de um banco comercial, há uma tabela TRANSFERENCIA onde são registrados a data, a hora, o minuto e o segundo da transferência, além do valor transferido entre duas contas-correntes desse banco. Essa tabela tem, adicionalmente, duas chaves estrangeiras (FKs) que apontam para a tabela CONTA-CORRENTE. Considere que há, no máximo, uma transferência por segundo entre duas contas-correntes. A chave primária (PK) da tabela TRANSFERENCIA (data, hora, minuto, segundo, valor, conta- origem, conta-destino) deve ser formada exatamente
a) pelas duas FKs
b) por todos os atributos
c) pelas duas FKs e a data
d) pela data, hora e minuto
e) por todos os atributos exceto o valor
response: Letra E
comment: A chave da questão está em "Considere que há, no máximo, uma transferência por segundo entre duas contas-correntes". Se vocês analisarem bem, entre duas contas-corrente teremos apenas uma transação por segundo, mas nada impede que tenhamos transações entre outras contas- corrente, ou entre uma mesma conta-corrente e oura. Nesse sentido, para criarmos a chave primária, precisaremos usar todos os valores de tempo (data, hora, minuto e segundo), para identificar de forma única a transação relativamente a uma mesma conta, e os valores da conta-origem e conta-destino, para identificarmos essa transação de forma única em relação a outras contas. Explicando melhor: imagine que temos as contas correntes A, B e C. Podemos ter uma transação A → B às 11:00:01, e uma transação A → C também às 11:00:01. Veja que identificar apenas o segundo da transação não é suficiente, precisamos identificar as entidades envolvidas de forma a criar um identificador único. Sendo assim, usaremos todos os valores, exceto o atributo de valor.
Other fields (not shown on cards):
back: Letra E - A chave da questão está em "Considere que há, no máximo, uma transferência por segundo entre duas contas-correntes". Se vocês analisarem bem, entre duas contas-corrente teremos apenas uma transação por segundo, mas nada impede que tenhamos transações entre outras contas- corrente, ou entre uma mesma conta-corrente e oura. Nesse sentido, para criarmos a chave primária, precisaremos usar todos os valores de tempo (data, hora, minuto e segundo), para identificar de forma única a transação relativamente a uma mesma conta, e os valores da conta-origem e conta-destino, para identificarmos essa transação de forma única em relação a outras contas. Explicando melhor: imagine que temos as contas correntes A, B e C. Podemos ter uma transação A → B às 11:00:01, e uma transação A → C também às 11:00:01. Veja que identificar apenas o segundo da transação não é suficiente, precisamos identificar as entidades envolvidas de forma a criar um identificador único. Sendo assim, usaremos todos os valores, exceto o atributo de valor.

front: (CEBRASPE/PETROBRAS/2022) Acerca de gerência de transações, modelagem entidade relacionamento e abordagem relacional, julgue o item subsecutivo. Considere que, para uma instância da entidade A, existe zero, uma ou muitas instâncias da entidade B; mas para uma instância da entidade B, existe zero ou uma instância da entidade A. Nesse caso, trata-se de um relacionamento 1:n da entidade A para entidade B.
response: Certo
comment: O que a questão está nos dizendo que acontece é isso aqui: Então, no relacionamento A → B, a cardinalidade é (0, n). Acontece que a notação A:B representa a cardinalidade máxima de cada um dos relacionamentos. Temos o relacionamento A → B com cardinalidade (0, n) - sendo a cardinalidade máxima, portanto, n - e o relacionamento B → A, com a cardinalidade (0, 1) - o máximo, aqui, é 1. Assim, como a notação A:B anota a cardinalidade máxima de cada um dos lados, de forma conjunta, teremos um relacionamento 1:n, conforme a questão aponta.
Other fields (not shown on cards):
back: Certo - O que a questão está nos dizendo que acontece é isso aqui: Então, no relacionamento A → B, a cardinalidade é (0, n). Acontece que a notação A:B representa a cardinalidade máxima de cada um dos relacionamentos. Temos o relacionamento A → B com cardinalidade (0, n) - sendo a cardinalidade máxima, portanto, n - e o relacionamento B → A, com a cardinalidade (0, 1) - o máximo, aqui, é 1. Assim, como a notação A:B anota a cardinalidade máxima de cada um dos lados, de forma conjunta, teremos um relacionamento 1:n, conforme a questão aponta.

front: (CEBRASPE/PETROBRAS/2022)
Com referência ao modelo entidade-relacionamento (ER) precedente e à SQL (structured query language), julgue o seguinte item. No modelo ER apresentado, uma PLATAFORMA possui apenas um TIPO e está localizada em apenas um CAMPO.
response: Certo
comment: A cardinalidade apresentada entre PLATAFORMA → CAMPO e PLATAFORMA → TIPO é (1, 1), o que indica que, de fato, só podemos ter um TIPO para cada PLATAFORMA, e cada PLATAFORMA localizada em um único CAMPO.
Other fields (not shown on cards):
back: Certo - A cardinalidade apresentada entre PLATAFORMA → CAMPO e PLATAFORMA → TIPO é (1, 1), o que indica que, de fato, só podemos ter um TIPO para cada PLATAFORMA, e cada PLATAFORMA localizada em um único CAMPO.

front: (CEBRASPE/PETROBRAS/2022)
Com referência ao modelo entidade-relacionamento (ER) precedente e à SQL (structured query language), julgue o seguinte item. Para que o modelo ER atenda aos padrões de modelagem de dados, o atributo CAPACIDADE_PRODUTIVA deve ser representado na entidade TIPO e não na entidade PLATAFORMA, conforme apresentado no diagrama.
response: Errado
comment: Galera, a CAPACIDADE_PRODUTIVA é inerente à plataforma, e não ao tipo de plataforma que ela é. Portanto, devemos manter esse atributo em PLATAFORMA, não em TIPO. Portanto, incorreta a afirmativa.
Other fields (not shown on cards):
back: Errado - Galera, a CAPACIDADE_PRODUTIVA é inerente à plataforma, e não ao tipo de plataforma que ela é. Portanto, devemos manter esse atributo em PLATAFORMA, não em TIPO. Portanto, incorreta a afirmativa.

front: (CEBRASPE/PGE RJ/2022) Julgue o item subsecutivo, a respeito da normalização de dados e da SQL (ANSI). A normalização não visa obter um modelo entidade-relacionamento (MER); seu objetivo consiste em, a partir do MER, eliminar redundâncias de dados que possam estar contidas no modelo.
response: Errado
comment: De fato, a normalização não visa obter um MER, e sim eliminar redundâncias. Mas perceba que não conseguimos identificar a redundância já no MER, pois ele é um esquema do nível externo, um modelo conceitual. Precisamos ter dados mais concretos para verificar a redundância e aí sim poderemos partir para a normalização.
Other fields (not shown on cards):
back: Errado - De fato, a normalização não visa obter um MER, e sim eliminar redundâncias. Mas perceba que não conseguimos identificar a redundância já no MER, pois ele é um esquema do nível externo, um modelo conceitual. Precisamos ter dados mais concretos para verificar a redundância e aí sim poderemos partir para a normalização.

front: (CEBRASPE/SECONT ES/2022) Julgue o item a seguir, a respeito de modelagem de dados. A restrição de disjunção específica que as subclasses da especialização devem ser conjuntos disjuntos, isto é, uma entidade pode ser membro de, no máximo, uma das subclasses da especialização.
response: Correto
comment: Perfeito, galera! Na disjunção específica, cada uma das subclasses da especialização é exclusiva - isso é, só podemos especializar a entidade em uma delas derivadas, de forma exclusiva.
Other fields (not shown on cards):
back: Correto - Perfeito, galera! Na disjunção específica, cada uma das subclasses da especialização é exclusiva - isso é, só podemos especializar a entidade em uma delas derivadas, de forma exclusiva.

front: (VUNESP/PRES. PRUDENTE/2022) O modelo entidade-relacionamento, utilizado no desenvolvimento de bancos de dados relacionais, possui a propriedade de que
a) um conjunto de entidades não pode possuir, simultaneamente, atributos simples e compostos.
b) um mesmo modelo entidade-relacionamento não admite dois tipos diferentes de cardinalidade (por exemplo, um para muitos e muitos para muitos).
c) um conjunto de relacionamentos sempre envolve dois conjuntos de entidades em sua formação.
d) os conjuntos de relacionamentos não podem possuir atributos descritivos próprios.
e) os conjuntos de entidades podem representar tanto objetos físicos (como veículos), quanto abstratos (como contas bancárias).
response: Letra E
comment: Vamos analisar cada alternativa. a) Errado. Não temos essa restrição no MER. b) Errado. Novamente, não temos essa restrição. Podemos ter várias cardinalidades num mesmo MER - o que não podemos é ter várias cardinalidades para um mesmo relacionamento. c) Errado. Podemos ter uma, duas, três ou mais entidades num relacionamento. d) Errado. Podemos ter relacionamentos com atributos e, quando for relevante, elevar esses relacionamentos ao patamar de entidades associativas, funcionando como uma entidade. e) Certo. As entidades representam, de fato, tanto objetos tangíveis, concretos, quanto objetos abstratos, intangíveis.
Other fields (not shown on cards):
back: Letra E - Vamos analisar cada alternativa. a) Errado. Não temos essa restrição no MER. b) Errado. Novamente, não temos essa restrição. Podemos ter várias cardinalidades num mesmo MER - o que não podemos é ter várias cardinalidades para um mesmo relacionamento. c) Errado. Podemos ter uma, duas, três ou mais entidades num relacionamento. d) Errado. Podemos ter relacionamentos com atributos e, quando for relevante, elevar esses relacionamentos ao patamar de entidades associativas, funcionando como uma entidade. e) Certo. As entidades representam, de fato, tanto objetos tangíveis, concretos, quanto objetos abstratos, intangíveis.

front: (CEBRASPE/BANRISUL/2022) A respeito de banco de dados, julgue o item subsequente. No modelo entidade × relacionamento, os atributos determinantes identificam um valor específico na tabela, podendo existir mais de um valor simultaneamente.
response: Errado
comment: Não, não. Os atributos determinantes determinam um valor que identifica de forma inequívoca cada registro da tabela e, portanto, não podendo existir mais de uma valor igual simultaneamente.
Other fields (not shown on cards):
back: Errado - Não, não. Os atributos determinantes determinam um valor que identifica de forma inequívoca cada registro da tabela e, portanto, não podendo existir mais de uma valor igual simultaneamente.

front: (FCC/TRT 14/2022) No Modelo Entidade-Relacionamento − MER, considere a hipótese de uma entidade denominada Cidadão que necessita ser modelada sob dois aspectos: Pessoa Física ou Pessoa Jurídica, cada um deles com atributos específicos. Em relação à entidade Cidadão, cada um desses aspectos é
a) um auto relacionamento.
b) um atributo multivalorado.
c) um relacionamento de grau três.
d) uma especialização.
e) uma entidade associativa.
response: Letra D
comment: A questão está nos apontando a seguinte situação: Trata-se, portanto, de uma especialização.
Other fields (not shown on cards):
back: Letra D - A questão está nos apontando a seguinte situação: Trata-se, portanto, de uma especialização.

front: (CEBRASPE/ISS ARACAJU/2021) O modelo entidade-relacionamento não permite estabelecer relacionamentos entre relacionamentos, apenas entre entidades. Para atender a situações em que seja necessário associar uma entidade com a ocorrência de um relacionamento, utiliza-se
a) dado temporal.
b) cardinalidade 1:N.
c) atributo multivalorado.
d) tabela especializada.
e) entidade associativa.
response: Letra E
comment: A questão descreve a ocorrência das entidades associativas. Elas podem surgir em dois casos: • Relacionamentos entre entidades do tipo m:n (ou seja, (0,n) de cada um dos lados), o que gera uma necessidade de identificar e dar atributos aos relacionamentos • Relacionamentos que ligam outros relacionamentos No caso da questão, como precisamos criar associações entre relacionamentos, usamos essas entidades associativas.
Other fields (not shown on cards):
back: Letra E - A questão descreve a ocorrência das entidades associativas. Elas podem surgir em dois casos: • Relacionamentos entre entidades do tipo m:n (ou seja, (0,n) de cada um dos lados), o que gera uma necessidade de identificar e dar atributos aos relacionamentos • Relacionamentos que ligam outros relacionamentos No caso da questão, como precisamos criar associações entre relacionamentos, usamos essas entidades associativas.

front: (FCC/DETRAN AP/2022) Considere a entidade Motorista identificada pelo CPF. Dependendo da categoria, essa mesma entidade pode ter atributos distintos, ou seja, um motorista da categoria A pode ter atributos unicamente pertencentes a ele como, por exemplo, a pontuação obtida no exame psicotécnico, enquanto um motorista da categoria B pode não ter esse atributo. Para solucionar essa distinção em um Modelo Entidade-Relacionamento (MER), um analista projetou essa entidade como
a) entidade forte com entidades associativas distintas.
b) superclasse com subclasses por tipo de categoria.
c) entidade múltipla com subclasses por tipo de categoria.
d) subclasse com superclasse por tipo de categoria.
e) entidade fraca com subclasses por tipo de categoria.
response: Letra B
comment: Temos um problema apontado - cada motorista terá atributos diferentes conforme o tipo de CNH que ele possui. Para solucionarmos esse problema, já que não conseguimos alterar isso diretamente na entidade MOTORISTA, podemos tratá-la como uma superclasse, e criar especializações separadas por tipo de categoria, cada uma com suas propriedades. A alternativa que traz essa abordagem é a letra B.
Other fields (not shown on cards):
back: Letra B - Temos um problema apontado - cada motorista terá atributos diferentes conforme o tipo de CNH que ele possui. Para solucionarmos esse problema, já que não conseguimos alterar isso diretamente na entidade MOTORISTA, podemos tratá-la como uma superclasse, e criar especializações separadas por tipo de categoria, cada uma com suas propriedades. A alternativa que traz essa abordagem é a letra B.

front: (FCC/TRT 5/2022) Considere os seguintes requisitos aplicáveis a um Modelo Entidade × Relacionamento:
I. Tribunal se relaciona com Funcionário.
II. Os funcionários só podem pertencer a um dado tribunal.
III. Um tribunal tem muitos funcionários.
IV. Os funcionários podem ter ou não dependentes.
V. Um tribunal é reconhecido unicamente por seu código e tem vários dados associados a esse código.
VI. Um funcionário é reconhecido unicamente por seu registro funcional e tem vários dados associados a esse registro. Ao observar os requisitos do modelo, um técnico definiu, corretamente, que
a) o relacionamento entre tribunal e funcionário é de grau binário, cardinalidade 1:N no sentido tribunal-funcionário e que funcionário se relaciona com uma entidade fraca denominada Dependente.
b) o atributo identificador de Tribunal é composto por código concatenado com registro funcional visando a unicidade de chave e que funcionário tem como atributos multivalorados na 3FN a relação de todos os seus dependentes, quando couber.
c) o relacionamento entre tribunal e funcionário é de grau unário, cardinalidade N:1 no sentido tribunal-funcionário e que funcionário se relaciona com uma entidade-associativa denominada Dependente.
d) o atributo identificador de Tribunal é composto por registro funcional e como chave estrangeira o código, visando a unicidade de registro e que funcionário tem como atributos multivalorados na 3FN a relação de todos os seus dependentes, quando couber, complementados unitariamente com o código do tribunal.
e) o relacionamento entre tribunal e funcionário é de grau ternário em razão da existência de uma entidade Dependente relacionada a funcionário, cardinalidade 1:N no sentido tribunal- funcionário e que funcionário se relaciona com uma entidade opcional denominada Dependente.
response: Letra A
comment: Antes de resolver a questão, vamos traduzir os 6 itens para um MER. Vai ficar mais fácil de vocês visualizarem. Para não ficar apertado, vou colocar o diagrama na próxima página. Com o modelo apresentado, vamos à questão. a) Certo. A afirmativa descreve corretamente o que acontece. b) Errado. O atributo identificador de TRIBUNAL é apenas Código, sem concatenação. TRIBUNAL FUNCIONÁRIO (1, 1) (1, n) DEPENDENTE (0, n) Códig o Registro c) Errado. O relacionamento liga duas entidades, então é um relacionamento binário. Além disso, a cardinalidade é (1, n) no sentido TRIBUNAL → FUNCIONÁRIO. Por último, DEPENDENTE é uma entidade fraca, não uma entidade associativa. d) Errado. Como vimos na letra B, o atributo identificador de TRIBUNAL é apenas Código. Além disso, não temos como falar de normalização e formais normais num MER. e) Errado. O erro está no grau do relacionamento, que é binário, o restante está correto.
Other fields (not shown on cards):
back: Letra A - Antes de resolver a questão, vamos traduzir os 6 itens para um MER. Vai ficar mais fácil de vocês visualizarem. Para não ficar apertado, vou colocar o diagrama na próxima página. Com o modelo apresentado, vamos à questão. a) Certo. A afirmativa descreve corretamente o que acontece. b) Errado. O atributo identificador de TRIBUNAL é apenas Código, sem concatenação. TRIBUNAL FUNCIONÁRIO (1, 1) (1, n) DEPENDENTE (0, n) Códig o Registro c) Errado. O relacionamento liga duas entidades, então é um relacionamento binário. Além disso, a cardinalidade é (1, n) no sentido TRIBUNAL → FUNCIONÁRIO. Por último, DEPENDENTE é uma entidade fraca, não uma entidade associativa. d) Errado. Como vimos na letra B, o atributo identificador de TRIBUNAL é apenas Código. Além disso, não temos como falar de normalização e formais normais num MER. e) Errado. O erro está no grau do relacionamento, que é binário, o restante está correto.

front: (VUNESP/PREF. PIRACICABA/2022) No modelo entidade-relacionamento, as entidades possuem atributos, sendo certo que um atributo de uma entidade que tem seus valores determinados ou calculados a partir de outros atributos contidos no modelo, denomina- -se atributo
a) múltiplo.
b) dominante.
c) derivado.
d) distribuído.
e) restritivo.
response: Letra C
comment: Quando um atributo tem seu valor determinado a partir de outro, temos o que chamamos de atributos derivados. O principal tipo de atributo derivado é a idade - pense que, a cada ano, teríamos que atualizar a idade de todos registados no banco de dados. Para resolver esse problema, usamos um atributo derivado, calculado a partir da diferença entre a data atual e a data de nascimento.
Other fields (not shown on cards):
back: Letra C - Quando um atributo tem seu valor determinado a partir de outro, temos o que chamamos de atributos derivados. O principal tipo de atributo derivado é a idade - pense que, a cada ano, teríamos que atualizar a idade de todos registados no banco de dados. Para resolver esse problema, usamos um atributo derivado, calculado a partir da diferença entre a data atual e a data de nascimento.

front: (CEBRASPE/TCE RJ/2021) Julgue o item que se segue, a respeito de bancos de dados relacionais. Os relacionamentos entre os elementos de um sistema podem ser expressos por meio de diagramas como o modelo entidade-relacionamento (MER), que permite organizar o sistema de banco de dados em entidades, atributos, relacionamentos e associações.
response: Correto
comment: Perfeito! Lembrem-se do nosso esquema: Só um adendo, a questão cita associações. As associações são criadas pelos relacionamentos, então acaba sendo um pouco redundante aparecer na afirmativa - mas não a torna errada.
Other fields (not shown on cards):
back: Correto - Perfeito! Lembrem-se do nosso esquema: Só um adendo, a questão cita associações. As associações são criadas pelos relacionamentos, então acaba sendo um pouco redundante aparecer na afirmativa - mas não a torna errada.

front: (CEBRASPE/AGENTE PF/2021) No que diz respeito a modelagem conceitual, julgue o item que se seguem. No modelo de entidade-relacionamento, entidade normalmente representa um objeto do mundo real.
response: Correto
comment: Isso mesmo, galera. As entidades representam objetos do mundo real, sejam objetos tangíveis, como pessoas, sejam objetos intangíveis, como contas de banco, órgãos públicos, entre outros. Então, correta a afirmativa.
Other fields (not shown on cards):
back: Correto - Isso mesmo, galera. As entidades representam objetos do mundo real, sejam objetos tangíveis, como pessoas, sejam objetos intangíveis, como contas de banco, órgãos públicos, entre outros. Então, correta a afirmativa.