Questão de Banco de Dados — Modelagem de dados — FUNDATEC 2025
Banco de Dados›Modelagem de dados
Código
qg474970
Banca
FUNDATEC
Órgão
PROCERGS
Ano
2025
Nível
Superior
Cargo
Analista em Computação/Ênfase em Programação de Sistemas na Tecnologia Microsoft
No cadastro corporativo, todo Empregado deve pertencer a exatamente um Departamento, e um Departamento pode existir sem Empregados. A relação não possui atributos próprios (sem histórico de lotações, sem datas). Na conversão para o modelo relacional, qual mapeamento expressa corretamenteacardinalidade e a obrigatoriedade descritas?
ACriar em Departamento uma coluna EmpregadoId com FK (chave estrangeira) e UNIQUE para "garantir um para muitos", evitando tabelas extras e facilitando consultas diretas.
BIntroduzir uma tabela associativa DepartamentoEmpregado com PK (chave primária) composta (DepartamentoId, EmpregadoId) mesmo sem atributos, e ativar ON DELETE CASCADE em ambos os lados para simplificar a manutenção.
CArmazenar, em Departamento, uma lista/JSON de IDs de empregados (com índice específico do SGBD), pois bancos modernos suportam JSON sem comprometer normalização.
DIncluir em Empregado uma FK obrigatória (DepartamentoId NOT NULL) referenciando a PK de Departamento, com índice na FK para joins e política de exclusão adequada.
EDefinir FKs recíprocas (uma em Empregado e outra em Departamento) e usar triggers para mantê-las em sincronia, assegurando a integridade nos dois sentidos.
Revelar gabarito e comentário▾
GabaritoD — Incluir em Empregado uma FK obrigatória (DepartamentoId NOT NULL) referenciando a PK de Departamento, com índice na FK para joins e política de exclusão adequada.
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”.
Mapeamento Relacional: Cardinalidade 1:N com Obrigatoriedade
Gabarito: letra D. No relacionamento entre Departamento (1) e Empregado (N), em que todo empregado deve pertencer a exatamente um departamento e um departamento pode existir sem empregados, a chave estrangeira deve ser inserida na tabela do lado N (Empregado) com restrição NOT NULL, referenciando a chave primária de Departamento. Essa é a técnica padrão do modelo relacional para representar uma relação 1:N com participação total do lado N.
A banca testa o conhecimento do mapeamento de cardinalidades e obrigatoriedades. O erro comum é inverter a direção da FK ou criar estruturas desnecessárias, como tabela associativa ou atributo multivalorado.
Mapeamento 1:N
1FK no lado N (Empregado)
NOT NULL (participação total)
Índice na FK
Política de exclusão adequada
2Erros comuns
FK no lado 1 (vira 1:1)
Tabela associativa (vira N:N)
Atributo multivalorado (viola 1FN)
FKs recíprocas (vira 1:1)
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Criar em Departamento uma coluna EmpregadoId com FK e UNIQUE. Essa abordagem forçaria uma relação 1:1, pois a restrição UNIQUE no lado Departamento impede que mais de um empregado se associe ao mesmo departamento. Além disso, a FK deveria estar no lado N, não no lado 1.
Alternativa B — ❌ Incorreta
Introduzir tabela associativa DepartamentoEmpregado com PK composta (DepartamentoId, EmpregadoId). Isso modela uma relação N:N (muitos-para-muitos), quando a cardinalidade exigida é 1:N. Não há atributos próprios, portanto a tabela associativa seria redundante.
Alternativa C — ❌ Incorreta
Armazenar em Departamento uma lista/JSON de IDs de empregados. Isso viola a 1ª Forma Normal (atributo não atômico) e não é uma abordagem relacional adequada. Bancos modernos até suportam JSON, mas o modelo relacional convencional exige normalização.
Alternativa D — ✅ Correta ⟵ GABARITO
Incluir em Empregado uma FK obrigatória (DepartamentoId NOT NULL) referenciando a PK de Departamento. A obrigatoriedade NOT NULL garante que todo empregado esteja vinculado a um departamento (participação total do lado N). O índice na FK otimiza junções, e a política de exclusão (ex.: RESTRICT ou CASCADE) deve ser definida conforme a regra de negócio (evitar exclusão de departamento com empregados, se for o caso).
Alternativa E — ❌ Incorreta
Definir FKs recíprocas e usar triggers para sincronia. Isso implementaria uma relação 1:1 (cada departamento só poderia ter um empregado, pois a FK em Departamento teria que ser UNIQUE para um único valor). Além disso, triggers são desnecessários para manter a integridade referencial; a própria FK já garante.
NÃO CAIA NESSA!
O candidato pode confundir o lado onde colocar a chave estrangeira. Em um relacionamento 1:N, a FK sempre fica na tabela do lado N (Empregado), e não na do lado 1 (Departamento). A alternativa A inverte essa posição, o que transforma a cardinalidade em 1:1. Outro erro comum é criar tabela associativa mesmo para 1:N (alternativa B) ou usar JSON (alternativa C).