Questão de Banco de Dados — Modelagem de dados — FGV 2025
Banco de Dados›Modelagem de dados
Código
fg116123
Banca
FGV
Órgão
MPU
Ano
2025
Nível
Superior
Cargo
Analista do - Perito em Tecnologia da Informação e Comunicação
Para desenvolver o sistema de controle de processos, o analista Pedro levantou as seguintes regras de negócio:• todo Juiz pode ter nenhum, um ou diversos Processos; e• todo Processo deve ter um e apenas um Juiz.O modelo de dados que representa essas regras de negócio é:
A
B
C
D
E
Revelar gabarito e comentário▾
GabaritoC — [imagem]
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”.
Modelagem de Dados: Relacionamentos e Cardinalidade
Gabarito: letra C. A regra de negócio estabelece um relacionamento de {{um-para-muitos}} (1:N) entre Juiz e Processo, onde um Juiz pode ter diversos processos (cardinalidade máxima N) ou nenhum (cardinalidade mínima 0), enquanto cada Processo deve ter obrigatoriamente um e apenas um Juiz (cardinalidade mínima 1 e máxima 1). A alternativa C representa corretamente essa estrutura em um modelo lógico relacional, utilizando a {{chave estrangeira}} (FK) na tabela 'Processo' para referenciar a 'JuizID', garantindo a integridade referencial exigida pela regra de que todo processo precisa de um juiz.
Alternativa A — ❌ Incorreta
O diagrama apresenta uma cardinalidade de muitos-para-muitos (N:N) em ambos os lados, o que não reflete a restrição de que cada processo deve ter um único juiz. Além disso, não utiliza chaves estrangeiras para implementar o relacionamento.
Alternativa B — ❌ Incorreta
O diagrama sugere um relacionamento opcional em ambos os lados (0:N para 0:N), o que contradiz a regra de que todo processo deve ter obrigatoriamente um juiz.
Alternativa C — ✅ Correta ⟵ GABARITO
Esta alternativa modela corretamente a restrição: o símbolo de 'pé de galinha' no lado de 'Processo' indica a cardinalidade 'muitos', enquanto a barra vertical no lado de 'Juiz' indica a obrigatoriedade (1). A inclusão da JuizID como FK na tabela 'Processo' é a forma padrão de implementar esse relacionamento 1:N no modelo relacional.
Alternativa D — ❌ Incorreta
O diagrama inverte a lógica de dependência, colocando a chave estrangeira de forma inadequada e sugerindo uma cardinalidade que não atende aos requisitos de obrigatoriedade do processo.
Alternativa E — ❌ Incorreta
O diagrama coloca a chave estrangeira na tabela 'Juiz', o que violaria a regra de negócio, pois um juiz não pode armazenar o ID de um processo em sua própria tabela para representar um relacionamento 1:N (isso limitaria o juiz a um único processo ou exigiria múltiplas colunas).
PEGA ESSA DICA!
Em modelagem relacional, para implementar um relacionamento 1:N, a chave primária da entidade 'um' (Juiz) deve ser migrada como chave estrangeira para a entidade 'muitos' (Processo). A obrigatoriedade (cardinalidade mínima 1) é garantida pela restrição de não nulo (NOT NULL) na coluna da chave estrangeira.
