Questão nº 34
Questão de Tecnologia da Informação · FGV TJ-MS 2024 (nº 34)
João está encarregado de projetar um banco de dados PostgreSQL para gerenciar informações sobre casos jurídicos e advogados, considerando as seguintes especificações:
• a tabela "Caso" armazena informações sobre os casos, incluindo um identificador único “IDCaso” como chave primária;
• a tabela "Advogado" armazena informações sobre os advogados, incluindo um identificador único “IDAdvogado” como chave primária;
• cada caso pode ter vários advogados envolvidos;
• um advogado pode estar envolvido em vários casos.
Nesse contexto, João precisa modelar um relacionamento “muitos-para-muitos” entre "Caso" e "Advogado". Para isso, ele deverá criar uma tabela de associação, denominada "Participacao", utilizando o script SQL:
IDParticipacao INT PRIMARY KEY,
FOREIGN KEY (IDCaso) REFERENCES Caso (IDCaso),
FOREIGN KEY (IDAdvogado) REFERENCES Advogado (IDAdvogado));
IDParticipacao INT PRIMARY KEY,
IDCaso INT,
IDAdvogado INT,
FOREIGN KEY (IDCaso) REFERENCES Caso (IDCaso),
FOREIGN KEY (IDAdvogado) REFERENCES Advogado (IDAdvogado));
IDCaso INT,
IDAdvogado INT,
PRIMARY KEY (IDCaso) REFERENCES Caso (IDCaso),
PRIMARY KEY (IDAdvogado) REFERENCES Advogado (IDAdvogado),
FOREIGN KEY (IDCaso, IDAdvogado));
IDParticipacao INT PRIMARY KEY,
FOREIGN KEY (IDCaso) REFERENCES Caso (IDCaso),
FOREIGN KEY (IDAdvogado) REFERENCES Advogado (IDAdvogado),
UNIQUE (IDCaso, IDAdvogado));
IDCaso INT PRIMARY KEY,
IDAdvogado INT PRIMARY KEY,
FOREIGN KEY (IDCaso) REFERENCES Caso (IDCaso),
FOREIGN KEY (IDAdvogado) REFERENCES Advogado (IDAdvogado));
- ACREATE TABLE Participacao (
- BCREATE TABLE Participacao ( (alternativa correta)
- CCREATE TABLE Participacao (
- DCREATE TABLE Participacao (
- ECREATE TABLE Participacao (
Resposta comentada
Gabarito Alternativa B
Para modelar um relacionamento muitos-para-muitos em bancos de dados relacionais, criamos uma tabela associativa (também chamada de tabela de junção ou ponte). Essa tabela contém as chaves primárias das duas tabelas originais como chaves estrangeiras, estabelecendo a ligação entre os registros.
(A) Incorreta: As colunas `IDCaso` e `IDAdvogado` não foram declaradas na tabela `Participacao` antes de serem referenciadas nas cláusulas `FOREIGN KEY`.
(B) Correta: Esta alternativa define corretamente a tabela `Participacao` com uma chave primária `IDParticipacao`, as colunas `IDCaso` e `IDAdvogado` (que serão as chaves estrangeiras) e as cláusulas `FOREIGN KEY` que as vinculam às tabelas `Caso` e `Advogado`. É uma estrutura sintaticamente válida para uma tabela associativa com uma chave primária substituta (surrogate key).
(C) Incorreta: A sintaxe `PRIMARY KEY (IDCaso) REFERENCES Caso (IDCaso)` está incorreta. A cláusula `PRIMARY KEY` define a chave primária da tabela atual, e a cláusula `REFERENCES` é usada apenas para `FOREIGN KEY`. Além disso, a última cláusula `FOREIGN KEY (IDCaso, IDAdvogado))` está incompleta, faltando a referência à tabela de destino.
(D) Incorreta: Assim como na alternativa A, as colunas `IDCaso` e `IDAdvogado` não foram declaradas na tabela `Participacao` antes de serem referenciadas nas cláusulas `FOREIGN KEY` e `UNIQUE`. Armadilha: Esta opção seria conceitualmente muito boa se as colunas estivessem declaradas, pois a restrição `UNIQUE (IDCaso, IDAdvogado)` garantiria que um advogado não fosse associado ao mesmo caso mais de uma vez, o que é uma prática comum e desejável para relacionamentos muitos-para-muitos. No entanto, o erro de sintaxe a invalida.
(E) Incorreta: Uma tabela só pode ter uma chave primária. A tentativa de declarar `IDCaso INT PRIMARY KEY` e `IDAdvogado INT PRIMARY KEY` separadamente está incorreta. Se a intenção fosse uma chave primária composta, a sintaxe correta seria `PRIMARY KEY (IDCaso, IDAdvogado)`.
Fonte: FGV TJ-MS 2024 Técnico de Nível Superior - Analista de Banco de Dados (Caderno Tipo 1). Reproduzida para fins de estudo.