Questão de Banco de Dados — Consultas e Comandos em SQL — FUNDATEC 2023
Banco de Dados›Consultas e Comandos em SQL
Código
qa537839
Banca
FUNDATEC
Órgão
PROCERGS
Ano
2023
Cargo
ANC ( )
Considere os seguintes comandos:
CREATE TABLE Livro( CodLivro NUMBER(6) PRIMARY KEY, Titulo VARCHAR2(50) NOT NULL, Paginas NUMBER(4) NOT NULL, Edicao NUMBER(2) NOT NULL, ISBN NUMBER(11), CodEditora NUMBER(4) NOT NULL REFERENCES Editora(CodEditora) )
CREATE TABLE Autor( CodAutor NUMBER(5) PRIMARY KEY, nome VARCHAR2(50) NOT NULL, )
Agora analise as três assertivas a seguir para criação de tabela que relaciona a tabela livro com a tabela autor, de forma que um livro pode ter diversos autores e um autor pode escrever diversos livros:
I. CREATE TABLE LivroAutor( CodLivro NUMBER(6) NOT NULL REFERENCES Livro (CodLivro), CodAutor NUMBER(5) NOT NULL REFERENCES Autor (CodAutor), CONSTRAINT LA_PK PRIMARY KEY (CodLivro, CodAutor) )
II. CREATE TABLE LivroAutor( CodLivro NUMBER(6) NOT NULL, CodAutor NUMBER(5) NOT NULL, CONSTRAINT LA_PK PRIMARY KEY (CodLivro, CodAutor), CONSTRAINT LA_FK_LIVRO FOREIGN KEY (CodLivro) REFERENCES Livro (CodLivro), CONSTRAINT LA_FK_AUTOR FOREIGN KEY (CodAutor) REFERENCES Autor (CodAutor) )
III. CREATE TABLE LivroAutor( CodLivro NUMBER(6) NOT NULL PRIMARY KEY REFERENCES Livro (CodLivro), CodAutor NUMBER(5) NOT NULL PRIMARY KEY REFERENCES Autor (CodAutor) )
Sobre as assertivas acima, analise as seguintes afirmações:
I. A assertiva III é mais simples e cria corretamente a tabela que relaciona Livros com Autores.
II. A assertiva II define constraints de tabela para as chaves estrangeiras que, nesse caso, são correspondentes às constraints de coluna, pois são definidas sobre um campo simples.
III. A assertiva I não precisaria definir uma constraint de tabela para a chave primária, pois é possível definir uma chave primária composta diretamente nos campos.
Quais afirmações estão corretas?
ATodas estão corretas.
BTodas estão incorretas.
CApenas I está correta.
DApenas II está correta.
EApenas III está correta.
Revelar gabarito e comentário▾
GabaritoD — Apenas II está correta.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Chaves primárias e estrangeiras em SQL: modelando a relação N:N
Gabarito: letra D. Apenas a afirmação II está correta: a assertiva II define corretamente as chaves estrangeiras como constraints de tabela, o que é válido e equivalente à definição em nível de coluna para campos simples. A assertiva I está incorreta porque, embora crie a chave primária composta corretamente, a afirmação III sobre ela está errada — não é possível definir uma chave primária composta diretamente nos campos, é obrigatório usar uma constraint de tabela. A assertiva III está incorreta porque define duas chaves primárias separadas, uma em cada coluna, o que não cria a chave composta necessária para a relação N:N.
O problema central aqui é entender como o SQL modela uma relação muitos-para-muitos (N:N) entre duas tabelas. No modelo relacional, uma relação N:N não pode ser representada diretamente com uma chave estrangeira em uma das tabelas — seria necessário duplicar dados. A solução clássica é criar uma tabela de associação (ou tabela de ligação), que contém as chaves estrangeiras para as duas tabelas originais e tem como chave primária a combinação dessas duas chaves (chave primária composta). É exatamente isso que as três assertivas tentam fazer, mas apenas uma delas (a II) está sintaticamente correta e semanticamente adequada.
Vamos analisar cada assertiva em detalhe:
Assertiva I: Cria a tabela LivroAutor com as duas colunas NOT NULL, cada uma com REFERENCES direto na coluna (constraint de coluna), e define a chave primária composta via CONSTRAINT de tabela. Isso está correto — a chave primária composta precisa ser definida como constraint de tabela, pois envolve duas colunas. As chaves estrangeiras em nível de coluna são válidas para campos simples. Portanto, a assertiva I é uma forma correta de criar a tabela de associação.
Assertiva II: Cria a tabela LivroAutor com as duas colunas NOT NULL, e define tanto a chave primária composta quanto as duas chaves estrangeiras como constraints de tabela. Isso também está correto — é a forma mais explícita e completa. As constraints de tabela para chaves estrangeiras são equivalentes às de coluna quando o campo é simples, como afirma a afirmação II.
Assertiva III: Cria a tabela LivroAutor com cada coluna tendo PRIMARY KEY individualmente. Isso está incorreto — define duas chaves primárias separadas, o que não é permitido em SQL (uma tabela só pode ter uma chave primária) e não cria a chave composta necessária para a relação N:N. Além disso, a afirmação I diz que a assertiva III é mais simples e correta, o que é falso.
Agora, analisando as afirmações:
Afirmação I: "A assertiva III é mais simples e cria corretamente a tabela que relaciona Livros com Autores." — Incorreta. A assertiva III está errada, pois define duas chaves primárias separadas, não uma chave composta. A relação N:N exige que a combinação (CodLivro, CodAutor) seja a chave primária, não cada coluna individualmente.
Afirmação II: "A assertiva II define constraints de tabela para as chaves estrangeiras que, nesse caso, são correspondentes às constraints de coluna, pois são definidas sobre um campo simples." — Correta. A assertiva II usa CONSTRAINT ... FOREIGN KEY ... REFERENCES, que é a sintaxe de constraint de tabela. Como cada chave estrangeira referencia uma única coluna, ela é equivalente à constraint de coluna (REFERENCES direto na coluna). A afirmação está tecnicamente precisa.
Afirmação III: "A assertiva I não precisaria definir uma constraint de tabela para a chave primária, pois é possível definir uma chave primária composta diretamente nos campos." — Incorreta. Não é possível definir uma chave primária composta diretamente nos campos (em nível de coluna). A sintaxe PRIMARY KEY em nível de coluna só aceita uma coluna. Para uma chave composta, é obrigatório usar CONSTRAINT ... PRIMARY KEY (col1, col2) em nível de tabela. Portanto, a assertiva I precisa sim da constraint de tabela.
Alternativa A — ❌ Incorreta
Afirma que todas as afirmações estão corretas. Como as afirmações I e III são incorretas, esta alternativa está errada.
Alternativa B — ❌ Incorreta
Afirma que todas as afirmações estão incorretas. Como a afirmação II é correta, esta alternativa está errada.
Alternativa C — ❌ Incorreta
Afirma que apenas a afirmação I está correta. Como a afirmação I é incorreta e a II é correta, esta alternativa está errada.
Alternativa D — ✅ Correta ⟵ GABARITO
Afirma que apenas a afirmação II está correta. Isso é verdade: a assertiva II define corretamente as chaves estrangeiras como constraints de tabela, equivalentes às de coluna para campos simples. As afirmações I e III são incorretas pelos motivos expostos.
Alternativa E — ❌ Incorreta
Afirma que apenas a afirmação III está correta. Como a afirmação III é incorreta e a II é correta, esta alternativa está errada.
NÃO CAIA NESSA!
A banca explora a confusão entre chave primária composta e chaves primárias individuais. Na assertiva III, cada coluna tem PRIMARY KEY, o que parece criar uma chave composta, mas na verdade define duas chaves primárias separadas — o que é inválido e não atende à relação N:N. Além disso, a afirmação III tenta convencer que a chave composta pode ser definida em nível de coluna, o que é falso.
PEGA ESSA DICA!
Para modelar uma relação N:N, lembre-se: a tabela de associação deve ter uma chave primária composta (constraint de tabela) e duas chaves estrangeiras. A chave primária composta sempre exige CONSTRAINT ... PRIMARY KEY (col1, col2) em nível de tabela — nunca em nível de coluna. Já as chaves estrangeiras podem ser definidas tanto em nível de coluna (REFERENCES direto) quanto em nível de tabela (CONSTRAINT ... FOREIGN KEY), sendo equivalentes para campos simples.
Gabarito: letra D — apenas a afirmação II está correta.