Questão de Banco de Dados — Modelo relacional — FGV 2026
Banco de Dados›Modelo relacional
Código
fg133937
Banca
FGV
Órgão
TJ-RJ
Ano
2026
Nível
Superior
Cargo
Analista Judiciário - Tecnologia da Informação - Arquiteto de Dados
O arquiteto de dados Gustavo precisa implementar o modelo lógico do relacionamento entre as entidades Processo e Parte de um sistema do TJRJ. Cada Processo pode ter uma ou mais Parte, e cada Parte pode estar em um ou mais Processo. O modelo lógico que Gustavo deve implementar, garantindo a integridade dos relacionamentos, é:
GabaritoE — Processo: ID_Processo (PK), Numero
Parte: ID_Parte (PK), Nome
Processo_Parte: ID_Processo (FK), ID_Parte (FK), PK composta (ID_Processo, ID_Parte)
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”.
Gabarito: letra E. A representação correta de um relacionamento N:N (muitos-para-muitos) no modelo relacional é feita por meio de uma tabela associativa (tabela de junção) que contém chaves estrangeiras referenciando as chaves primárias das entidades envolvidas, formando uma chave primária composta que garante a unicidade da combinação e a integridade referencial. A alternativa E descreve exatamente essa estrutura: tabelas Processo e Parte independentes e a tabela associativa Processo_Parte com PK composta por ID_Processo e ID_Parte, ambas indicadas como FK.
No modelo relacional, um relacionamento muitos-para-muitos não pode ser representado diretamente com chaves estrangeiras nas tabelas originais, pois isso geraria redundância e violaria a normalização. A solução padrão é criar uma nova relação (tabela) que associe as chaves primárias das duas entidades. A tabela associativa pode ter uma chave primária composta pelas duas chaves estrangeiras (garantindo que cada par seja único) ou uma chave surrogate com uma restrição UNIQUE sobre o par. A alternativa E adota a primeira abordagem, que é a mais direta e comum.
Critério
Alternativa A
Alternativa B
Alternativa C
Alternativa D
Alternativa E (Gabarito)
Tabelas definidas
Apenas Processo_Parte
Processo e Parte
Processo, Parte e Processo_Parte
Processo e Parte
Processo, Parte e Processo_Parte
Chave primária (PK) da tabela associativa
Composta (ID_Processo, ID_Parte)
Inexistente (não há tabela associativa)
Surrogate (ID)
Inexistente (não há tabela associativa)
Composta (ID_Processo, ID_Parte)
Chave estrangeira (FK) na tabela associativa
Não declarada
Inexistente
ID_Processo e ID_Parte (implícitas)
Inexistente
ID_Processo e ID_Parte (explicitamente FK)
Representa N:N corretamente
❌ (faltam entidades base e FK)
❌ (insere FK nas entidades base como parte da PK)
❌ (PK surrogate sem unicidade do par)
❌ (insere FK nas entidades base como parte da PK)
✅ (tabela associativa com PK composta e FK explícitas)
Integridade referencial garantida
❌
❌
❌ (parcial, sem unicidade)
❌
✅
Alternativa A — ❌ Incorreta
Apresenta apenas a tabela associativa Processo_Parte com chave primária composta, mas não define as tabelas Processo e Parte. Além disso, as colunas ID_Processo e ID_Parte não são explicitamente marcadas como chaves estrangeiras, o que compromete a integridade referencial. Faltam as entidades base e a indicação de FK.
Alternativa B — ❌ Incorreta
Insere a chave estrangeira de uma tabela na outra como parte da chave primária: Processo tem ID_Parte como parte da PK, e Parte tem ID_Processo como parte da PK. Isso modela incorretamente um relacionamento muitos-para-muitos e geraria repetição desnecessária de dados (por exemplo, um processo com várias partes teria várias linhas na tabela Processo, cada uma com o mesmo ID_Processo e diferentes ID_Parte, violando a definição de chave primária).
Alternativa C — ❌ Incorreta
Embora crie a tabela associativa, utiliza uma chave primária surrogate (ID) sem garantir a unicidade da combinação (ID_Processo, ID_Parte). Para evitar duplicatas do mesmo par, seria necessário adicionar uma constraint UNIQUE sobre essas duas colunas, o que não está explícito. A alternativa E é mais direta e garante a integridade com a PK composta.
Alternativa D — ❌ Incorreta
Similar à alternativa B, modela o relacionamento de forma invertida, colocando a chave estrangeira como parte da chave primária em cada tabela, o que gera redundância e não representa corretamente um relacionamento N:N.
Alternativa E — ✅ Correta ⟵ GABARITO
Cria as tabelas Processo (com ID_Processo como PK e Numero) e Parte (com ID_Parte como PK e Nome). Em seguida, define a tabela associativa Processo_Parte com chave primária composta por ID_Processo e ID_Parte, ambas explicitamente indicadas como chaves estrangeiras (FK). Essa estrutura garante a integridade referencial (cada FK aponta para uma tupla existente na tabela referenciada) e a unicidade da combinação (não há duas linhas com o mesmo par). É a implementação canônica do relacionamento muitos-para-muitos no modelo relacional.
NÃO CAIA NESSA!
A banca tenta confundir o candidato com modelagens que colocam chaves estrangeiras diretamente nas tabelas principais (alternativas B e D) ou com tabela associativa sem chave estrangeira explícita ou sem garantia de unicidade (A e C). Lembre-se: para um relacionamento N:N, crie uma nova tabela com chave primária composta pelas chaves estrangeiras das entidades envolvidas. Essa é a forma mais direta e segura de garantir a integridade.