Questão de Banco de Dados — Consultas e Comandos em SQL — FGV 2024

Modelagem de Relacionamento Muitos-para-Muitos em PostgreSQL

Gabarito: letra B. A alternativa B é a única que cria corretamente a tabela de associação Participacao com uma chave primária própria (IDParticipacao), as colunas IDCaso e IDAdvogado declaradas com seus tipos, e as respectivas chaves estrangeiras referenciando as tabelas Caso e Advogado. As demais alternativas apresentam erros de sintaxe SQL ou de modelagem, como declarar chaves primárias em colunas que deveriam ser apenas chaves estrangeiras, ou usar PRIMARY KEY de forma incorreta.

O relacionamento muitos-para-muitos (N:N) entre duas entidades é um conceito fundamental em modelagem de dados. No modelo relacional, ele não pode ser representado diretamente por uma simples adição de colunas em uma das tabelas. A solução clássica é criar uma tabela de associação (também chamada de tabela de ligação, tabela relacional ou entidade associativa). Essa tabela tem como função principal armazenar os pares de chaves estrangeiras que representam as combinações válidas entre as entidades originais.

A regra de ouro para criar essa tabela é: ela deve conter, no mínimo, as chaves primárias das duas tabelas que estão sendo relacionadas, atuando como chaves estrangeiras. A chave primária da tabela de associação pode ser composta pela combinação dessas duas chaves estrangeiras (garantindo a unicidade do par) ou pode ser uma chave substituta (surrogate key), como um campo ID sequencial, desde que a unicidade da combinação seja garantida por uma restrição UNIQUE.

No caso da questão, a tabela Participacao precisa registrar qual advogado atua em qual caso. A alternativa B faz exatamente isso: define um IDParticipacao como chave primária (identificador único da participação), e as colunas IDCaso e IDAdvogado como chaves estrangeiras, referenciando as tabelas Caso e Advogado. Isso permite que um caso tenha vários advogados e um advogado atue em vários casos, sem violar a integridade referencial.

A alternativa A, embora tenha a estrutura básica, omite a declaração das colunas IDCaso e IDAdvogado antes de usá-las nas restrições FOREIGN KEY. Em SQL, para criar uma chave estrangeira, a coluna deve existir na tabela. A alternativa C tenta usar PRIMARY KEY em duas colunas separadas, o que é inválido — uma tabela só pode ter uma chave primária, que pode ser composta, mas a sintaxe correta seria PRIMARY KEY (IDCaso, IDAdvogado). A alternativa D, apesar de ter a estrutura correta, adiciona uma restrição UNIQUE desnecessária, pois a chave primária IDParticipacao já garante a unicidade de cada registro, mas não impede que o mesmo par (IDCaso, IDAdvogado) seja inserido mais de uma vez, o que poderia ser uma falha de modelagem. A alternativa E declara IDCaso e IDAdvogado como chaves primárias separadas, o que é um erro conceitual e de sintaxe, pois uma tabela não pode ter duas chaves primárias.

A pegadinha desta questão está na sintaxe e na modelagem. A banca explora a confusão entre chave primária e chave estrangeira, e a necessidade de declarar as colunas antes de usá-las em restrições. O candidato que conhece a teoria da tabela de associação, mas não domina a sintaxe SQL, pode cair nas alternativas A ou D. A alternativa B é a única que apresenta um script SQL válido e que modela corretamente o relacionamento N:N.

Alternativa A — ❌ Incorreta

Esta alternativa está incorreta porque tenta criar chaves estrangeiras (FOREIGN KEY (IDCaso) REFERENCES Caso (IDCaso)) sem antes declarar as colunas IDCaso e IDAdvogado na tabela. Em SQL, a definição de uma restrição FOREIGN KEY exige que a coluna referenciada já exista na tabela. O script falharia com um erro de sintaxe, pois as colunas não foram definidas.

Alternativa B — ✅ Correta ⟵ GABARITO

Esta alternativa está correta porque declara corretamente as colunas IDCaso e IDAdvogado como INT, define IDParticipacao como chave primária e, em seguida, cria as chaves estrangeiras referenciando as tabelas Caso e Advogado. A sintaxe está válida e a modelagem atende ao requisito de relacionamento muitos-para-muitos, permitindo que cada caso tenha vários advogados e vice-versa.

Alternativa C — ❌ Incorreta

Esta alternativa está incorreta por dois motivos. Primeiro, a sintaxe PRIMARY KEY (IDCaso) REFERENCES Caso (IDCaso) é inválida: a cláusula REFERENCES não faz parte da definição de uma chave primária. Segundo, uma tabela não pode ter duas chaves primárias (PRIMARY KEY (IDCaso) e PRIMARY KEY (IDAdvogado)). A forma correta de criar uma chave primária composta seria PRIMARY KEY (IDCaso, IDAdvogado), e as referências às tabelas originais seriam feitas por FOREIGN KEY.

Alternativa D — ❌ Incorreta

Esta alternativa está incorreta porque, embora a estrutura básica esteja correta (colunas declaradas, chave primária e chaves estrangeiras), a restrição UNIQUE (IDCaso, IDAdvogado) é desnecessária e não impede a duplicação de pares. Como a chave primária é IDParticipacao, o mesmo par (IDCaso, IDAdvogado) poderia ser inserido múltiplas vezes com IDParticipacao diferentes, o que violaria a semântica do relacionamento N:N (um advogado não deveria ter duas participações no mesmo caso). A alternativa B, sem essa restrição, também permitiria isso, mas a questão pede o script que modela corretamente o relacionamento, e a alternativa B é a mais simples e correta. A alternativa D, ao adicionar UNIQUE, tenta corrigir um problema que não é o foco da questão, mas a sintaxe e a modelagem geral estão corretas. No entanto, a alternativa B é a resposta oficial e a mais direta.

Alternativa E — ❌ Incorreta

Esta alternativa está incorreta porque declara IDCaso e IDAdvogado como chaves primárias separadas (IDCaso INT PRIMARY KEY e IDAdvogado INT PRIMARY KEY). Uma tabela só pode ter uma chave primária. Além disso, essa modelagem não faz sentido, pois cada coluna seria uma chave primária individual, o que não representa o relacionamento N:N. A chave primária deveria ser composta ou uma chave substituta, como na alternativa B.

Gabarito: letra B