Questão de Banco de Dados — PL-SQL — FUNDATEC 2023

Chaves Estrangeiras e Constraints em SQL

Gabarito: letra D — apenas a afirmação II está correta. A assertiva II está certa porque, ao definir uma chave estrangeira sobre uma única coluna, a constraint de tabela é equivalente à constraint de coluna, pois ambas restringem o mesmo campo. As assertivas I e III estão incorretas: a III não é a mais simples e correta, e a I precisa de uma constraint de tabela para a chave primária composta, pois não é possível defini-la diretamente nos campos.

O problema trata da criação de uma tabela associativa para representar um relacionamento muitos-para-muitos (N:N) entre as tabelas Livro e Autor. Nesse modelo, um livro pode ter vários autores e um autor pode escrever vários livros, o que exige uma tabela intermediária (também chamada de tabela de junção ou tabela associativa) que armazene as chaves estrangeiras de ambas as tabelas. Essa tabela terá uma chave primária composta, formada pela combinação das duas chaves estrangeiras, garantindo que cada par (livro, autor) seja único.

A criação dessa tabela envolve dois conceitos fundamentais do SQL: a definição de chaves estrangeiras (FOREIGN KEY) e a definição de chaves primárias compostas. Uma chave estrangeira pode ser definida de duas formas: como constraint de coluna, diretamente na definição do campo, ou como constraint de tabela, em uma cláusula separada após a definição de todos os campos. Para chaves primárias compostas, a definição como constraint de tabela é obrigatória, pois a sintaxe de constraint de coluna não permite especificar mais de uma coluna.

Na prática, a tabela associativa seria criada com dois campos, um para o código do livro e outro para o código do autor, ambos definidos como chaves estrangeiras referenciando as tabelas Livro e Autor, respectivamente. A chave primária seria a combinação desses dois campos, garantindo que não haja duplicidade de pares. A diferença entre constraint de coluna e constraint de tabela é sutil, mas importante: a constraint de coluna é aplicada a um único campo, enquanto a constraint de tabela pode ser aplicada a um ou mais campos, sendo a única forma de definir chaves primárias ou estrangeiras compostas.

A pegadinha da banca está em confundir a necessidade de constraint de tabela para chaves primárias compostas com a possibilidade de defini-las diretamente nos campos. A sintaxe de constraint de coluna para chave primária (PRIMARY KEY após o tipo do campo) só funciona para chaves de uma única coluna. Para chaves compostas, é obrigatório usar a cláusula PRIMARY KEY (coluna1, coluna2) como constraint de tabela. Guarde essa distinção: é exatamente nela que as assertivas I e III se separam da II.

Assertiva I — ❌ Incorreta

A afirmação de que "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" está errada. A sintaxe de constraint de coluna (PRIMARY KEY após o tipo do campo) não permite especificar mais de uma coluna. Para uma chave primária composta, é obrigatório usar a cláusula PRIMARY KEY (coluna1, coluna2) como constraint de tabela, após a definição de todos os campos. A banca explora a confusão entre a definição de chave primária simples (que pode ser de coluna) e a composta (que exige constraint de tabela).

Assertiva II — ✅ Correta ⟵ GABARITO

A afirmação de que "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" está correta. Quando uma chave estrangeira é definida sobre uma única coluna, a constraint de tabela (FOREIGN KEY (coluna) REFERENCES tabela(coluna)) é funcionalmente equivalente à constraint de coluna (coluna REFERENCES tabela(coluna)), pois ambas restringem o mesmo campo. A diferença é apenas sintática, não semântica. A banca testa o conhecimento de que, para campos simples, as duas formas são equivalentes.

Assertiva III — ❌ Incorreta

A afirmação de que "a assertiva III é mais simples e cria corretamente a tabela que relaciona Livros com Autores" está errada. A assertiva III, embora possa ser mais simples, não cria corretamente a tabela associativa, pois não define a chave primária composta necessária para garantir a unicidade dos pares (livro, autor). Sem essa chave, a tabela permitiria registros duplicados, violando a integridade do relacionamento. A banca explora a tentação de escolher a opção mais curta sem verificar se ela atende a todos os requisitos.

Gabarito: letra D — apenas a assertiva II está correta.