Questão de Banco de Dados — Modelagem de dados — FUNDATEC 2025

Mapeamento de relacionamento 1:N no modelo relacional

Gabarito: letra C. Em um relacionamento um-para-muitos (1:N), a implementação usual e correta no banco relacional é colocar a chave estrangeira no lado N (no caso, na tabela Servidor), permitindo valores nulos para refletir a opcionalidade (um servidor pode ainda não ter departamento) e criando índice sobre essa coluna para acelerar as junções (joins). Essa é a regra clássica de mapeamento de cardinalidades, presente em qualquer livro de modelagem de dados (Elmasri & Navathe, Heuser).

O relacionamento 1:N entre Departamento e Servidor significa que cada Servidor pertence a exatamente um Departamento (ou, se opcional, a no máximo um), e cada Departamento pode ter vários Servidores. No modelo relacional, isso é representado adicionando à tabela do lado N (Servidor) uma coluna que referencia a chave primária da tabela do lado 1 (Departamento). Essa coluna é a chave estrangeira (FK). Ela pode ser definida como NOT NULL (se todo servidor deve ter departamento) ou permitir nulos (se a lotação é opcional). O enunciado diz que "cada servidor tem no máximo uma lotação vigente", o que sugere que pode haver servidor sem lotação, ou seja, a FK deve ser opcional (nullable). Além disso, criar um índice sobre a coluna da chave estrangeira é uma prática recomendada para acelerar as operações de junção (JOIN) entre as tabelas, pois o SGBD pode localizar rapidamente os servidores de um departamento.

A alternativa C captura exatamente isso: "Colocar a chave estrangeira no lado N usando nulidade para refletir opcionalidade e índice para joins eficientes." É a implementação canônica.

Vamos entender por que as demais estão erradas:

• A) Criar uma tabela associativa (tabela de junção) é necessário apenas para relacionamentos muitos-para-muitos (N:M). Para 1:N, ela é desnecessária e adiciona complexidade sem benefício, pois a chave estrangeira no lado N já resolve o mapeamento.

• B) Colocar chave estrangeira nos dois lados criaria uma referência circular e redundante. No lado 1 (Departamento), não faz sentido ter uma FK para Servidor, pois um departamento pode ter muitos servidores; não há como armazenar essa relação em uma única coluna sem violar a 1FN (atributo multivalorado). A integridade referencial é garantida pela FK no lado N, não por referência circular.

• D) Manter uma lista de identificadores de servidores na tabela Departamento viola a primeira forma normal (1FN), que exige atributos atômicos. Além disso, essa abordagem dificulta consultas e manutenção, e não é a forma relacional correta.

• E) Criar uma tabela de junção sem atributos para um relacionamento 1:N é redundante e desnecessária, como na alternativa A. Além disso, deixar as tabelas principais sem referência direta quebraria a integridade referencial e complicaria o acesso aos dados.

A pegadinha da banca está em confundir o mapeamento de 1:N com o de N:M. Muitos candidatos, ao verem a palavra "relação", pensam automaticamente em tabela de junção, mas ela só é necessária para N:M. Para 1:N, a chave estrangeira no lado N é a solução padrão.

Alternativa A — ❌ Incorreta

A tabela associativa (também chamada de tabela de ligação ou junção) é a solução para relacionamentos muitos-para-muitos (N:M), não para 1:N. Em 1:N, a chave estrangeira no lado N já representa o relacionamento sem necessidade de tabela extra. Criar uma tabela associativa sem atributos adicionaria uma camada desnecessária, aumentando a complexidade e o número de joins sem nenhum benefício. A justificativa de "garantir escalabilidade futura" não se sustenta: se no futuro o relacionamento mudar para N:M, aí sim a tabela associativa seria criada, mas não se projeta um banco para um futuro hipotético em detrimento da modelagem correta atual.

Alternativa B — ❌ Incorreta

Definir chave estrangeira nos dois lados criaria uma referência circular e redundante. No lado 1 (Departamento), não é possível armazenar a referência a vários servidores em uma única coluna sem violar a atomicidade (1FN). A integridade referencial é garantida pela chave estrangeira no lado N (Servidor → Departamento), que assegura que todo servidor pertença a um departamento existente. Referência circular não aumenta a integridade; pelo contrário, pode causar problemas de inserção e manutenção (qual inserir primeiro?).

Alternativa C — ✅ Correta ⟵ GABARITO

Esta é a implementação clássica e correta. A chave estrangeira (FK) é adicionada à tabela do lado N (Servidor), referenciando a chave primária da tabela do lado 1 (Departamento). A nulidade da FK reflete a opcionalidade do relacionamento: se um servidor pode ainda não ter departamento, a coluna aceita NULL; se for obrigatório, define-se NOT NULL. Além disso, criar um índice sobre a coluna da FK é uma prática recomendada para acelerar as operações de junção (JOIN), pois o SGBD pode localizar rapidamente os registros relacionados. Essa abordagem é simples, eficiente e respeita as formas normais.

Alternativa D — ❌ Incorreta

Manter uma coluna com lista de identificadores de servidores na tabela Departamento viola a primeira forma normal (1FN), que exige que todos os atributos sejam atômicos (não multivalorados). Uma lista de IDs é um atributo multivalorado, o que impossibilita consultas eficientes e viola os princípios do modelo relacional. Além disso, essa abordagem dificulta a manutenção da integridade referencial e a realização de joins. A forma correta é a chave estrangeira no lado N.

Alternativa E — ❌ Incorreta

Criar uma tabela de junção sem atributos para um relacionamento 1:N é redundante e desnecessária, como na alternativa A. Além disso, deixar as tabelas principais sem referência direta quebraria a integridade referencial e complicaria o acesso aos dados. A tabela de junção só é necessária para relacionamentos N:M. Em 1:N, a chave estrangeira no lado N é a solução padrão e mais eficiente.

Gabarito: letra C