Questão de Banco de Dados — Modelagem e Mapeamento ER-relacional — FUNDATEC 2025
Banco de Dados›Modelagem e Mapeamento ER-relacional
Código
qa699062
Banca
FUNDATEC
Órgão
PROCERGS
Ano
2025
Cargo
ANC ( )
Um órgão federal modelou a relação Departamento–Servidor como um-para-muitos (1:N): cada Servidor pertence a um único Departamento, e um Departamento pode ter muitos Servidores. Não há histórico de lotações (cada servidor tem no máximo uma lotação vigente) e a relação não possui atributos próprios além das chaves. A título ilustrativo, o desenho esperado é compatível como o seguinte DDL:
CREATE TABLE Departamento (
Id INT PRIMARY KEY,
Nome VARCHAR(100) NOT NULL
-- ...
);
CREATE TABLE Servidor (
Id INT PRIMARY KEY,
Nome VARCHAR(120) NOT NULL,
DepartamentoId INT NOT NULL, -- FK no lado N
CONSTRAINT FK_Servidor_Departamento
FOREIGN KEY (DepartamentoId)
REFERENCES Departamento (Id)
ON UPDATE CASCADE
ON DELETE RESTRICT
);
-- (Índice em Servidor(DepartamentoId) recomendado para joins)
No banco relacional, qual é a implementação usual e correta para esse mapeamento?
ATornar obrigatória uma tabela associativa (por exemplo, DepartamentoServidor), mesmo sem atributos na relação, para “garantir escalabilidade futura”.
BDefinir chave estrangeira nos dois lados (Departamento → Servidor e Servidor → Departamento), assegurando referência circular para maior integridade.
CColocar a chave estrangeira no lado N usando nulidade para refletir opcionalidade e índice para joins eficientes.
DManter, no lado 1, uma coluna com lista de identificadores dos servidores para “evitar joins”.
ECriar uma tabela de junção sem atributos com chave estrangeira opcional, deixando as tabelas principais sem referência direta.
Revelar gabarito e comentário▾
GabaritoC — Colocar a chave estrangeira no lado N usando nulidade para refletir opcionalidade e índice para joins eficientes.
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 de Relacionamento 1:N para o Modelo Relacional
Gabarito: letra C. Em um relacionamento um-para-muitos (1:N), a implementação usual e correta no modelo relacional é colocar a chave estrangeira no lado N (muitos) da relação, que é exatamente o que o DDL ilustrativo do enunciado mostra: a tabela Servidor (lado N) recebe a coluna DepartamentoId como chave estrangeira referenciando a chave primária de Departamento (lado 1). Essa é a regra de mapeamento do modelo Entidade-Relacionamento para o modelo relacional.
O mapeamento de relacionamentos do modelo ER para o modelo relacional segue regras específicas conforme a cardinalidade. Para um relacionamento 1:N, a regra é clara: a chave primária da entidade do lado 1 (um) é adicionada como chave estrangeira na tabela que representa a entidade do lado N (muitos). Isso ocorre porque cada registro do lado N precisa indicar a qual registro do lado 1 ele pertence. No exemplo, cada Servidor (lado N) deve apontar para o seu Departamento (lado 1), e é por isso que a coluna DepartamentoId fica na tabela Servidor. Essa chave estrangeira pode ser NULL se a participação do servidor no relacionamento for opcional (ou seja, se um servidor pode existir sem estar lotado em um departamento), e deve ser NOT NULL se a participação for obrigatória. O DDL do enunciado usa NOT NULL, indicando que todo servidor deve ter um departamento.
A razão pela qual a chave estrangeira fica no lado N é a própria natureza do relacionamento: um departamento pode ter muitos servidores, mas cada servidor pertence a um único departamento. Se colocássemos a chave estrangeira no lado 1 (Departamento), precisaríamos de uma coluna que armazenasse múltiplos valores (os IDs de todos os servidores), o que violaria a primeira forma normal (1FN), que exige que cada coluna contenha um único valor atômico. Portanto, a única forma correta de representar essa relação sem criar uma tabela extra é colocar a referência no lado N. Para relacionamentos N:N (muitos-para-muitos), a regra é diferente: é necessário criar uma tabela associativa (ou tabela de junção) que contenha as chaves estrangeiras de ambas as entidades, pois nenhum dos lados pode armazenar múltiplas referências sem violar a 1FN. Já para relacionamentos 1:1, a chave estrangeira pode ser colocada em qualquer um dos lados, geralmente no lado com participação opcional.
A pegadinha desta questão está em confundir a regra de mapeamento de relacionamentos 1:N com a de N:N. A banca tenta induzir o candidato a criar uma tabela associativa (como se fosse N:N) ou a colocar chaves estrangeiras nos dois lados, o que é desnecessário e incorreto para 1:N. O candidato que não domina a regra de mapeamento pode cair na armadilha de achar que "quanto mais tabelas, mais escalável" ou que "referência circular garante mais integridade", mas ambas as ideias são equivocadas. A regra de ouro é: 1:N → chave estrangeira no lado N; N:N → tabela associativa; 1:1 → chave estrangeira em um dos lados.
Guarde essa distinção de cardinalidade: é exatamente nela que as alternativas se dividem. A alternativa correta é a que aplica a regra de colocar a FK no lado N, com nulidade para opcionalidade e índice para eficiência em joins.
Critério
1:N (gabarito C)
N:N (tabela associativa)
1:1 (FK em um lado)
Onde fica a FK
No lado N (ex.: Servidor.DepartamentoId)
Em tabela de junção separada
Em qualquer um dos lados (geralmente no opcional)
Tabela extra necessária?
Não
Sim
Não
Risco de violar 1FN
Não (FK única por linha)
Não (cada linha da junção tem um par)
Não (FK única por linha)
Exemplo de implementação
Servidor(DepartamentoId) com índice
DepartamentoServidor(DeptId, ServId) com PK composta
Pessoa(PassaporteId) ou Passaporte(PessoaId)
Alternativa A — ❌ Incorreta
Criar uma tabela associativa (DepartamentoServidor) é a solução para relacionamentos N:N, não para 1:N. Para 1:N, a tabela associativa é desnecessária e adiciona complexidade sem benefício, pois a relação não possui atributos próprios e cada servidor pertence a um único departamento. A regra de mapeamento para 1:N é colocar a chave estrangeira no lado N, não criar uma tabela extra.
Alternativa B — ❌ Incorreta
Definir chave estrangeira nos dois lados criaria uma referência circular desnecessária e problemática. No relacionamento 1:N, apenas o lado N precisa da chave estrangeira. Colocar uma FK em Departamento referenciando Servidor não faz sentido, pois um departamento pode ter muitos servidores, e uma única coluna não pode armazenar múltiplos IDs sem violar a 1FN. A integridade referencial é garantida pela FK no lado N, não por referência circular.
Alternativa C — ✅ Correta ⟵ GABARITO
Esta é a implementação usual e correta. A chave estrangeira DepartamentoId é colocada na tabela Servidor (lado N), referenciando a chave primária de Departamento (lado 1). A nulidade da coluna reflete a opcionalidade da participação (se um servidor pode ou não existir sem departamento), e o índice em Servidor(DepartamentoId) é recomendado para otimizar os joins entre as tabelas. O DDL do enunciado ilustra exatamente essa implementação.
Alternativa D — ❌ Incorreta
Manter uma coluna com lista de identificadores no lado 1 viola a Primeira Forma Normal (1FN), que exige que cada coluna contenha um único valor atômico. Uma coluna com múltiplos IDs de servidores tornaria consultas e joins extremamente ineficientes e complexos, além de impossibilitar a aplicação de integridade referencial adequada. A solução correta é a chave estrangeira no lado N.
Alternativa E — ❌ Incorreta
Criar uma tabela de junção sem atributos é a solução para relacionamentos N:N, não para 1:N. Além disso, deixar as tabelas principais sem referência direta quebraria a integridade referencial e tornaria o modelo mais complexo sem necessidade. Para 1:N, a chave estrangeira deve estar no lado N, como na alternativa C.