Questão de Banco de Dados — DER - Diagrama de Entidade e Relacionamento — CESPE / CEBRASPE 2025

Modelagem de dados: relacionamento N:M e entidade associativa

Gabarito: letra B. No relacionamento muitos-para-muitos (N:M) entre MÉDICO e PACIENTE, o relacionamento CONSULTA deve ser transformado em uma entidade associativa (também chamada de entidade de ligação ou tabela de interseção) no modelo físico, pois o modelo relacional não representa diretamente relacionamentos N:M — é necessário criar uma tabela intermediária que armazene as chaves estrangeiras das duas entidades participantes. Essa é a regra clássica de transformação do modelo conceitual (DER) para o modelo lógico/físico (relacional).

O Diagrama Entidade-Relacionamento (DER) é a representação gráfica do Modelo Entidade-Relacionamento (MER), um modelo conceitual que descreve entidades, atributos e relacionamentos de forma independente de tecnologia. Quando o enunciado afirma que "um mesmo médico pode realizar consulta com vários pacientes, sendo possível que o mesmo paciente se consulte com o mesmo médico mais de uma vez", estamos diante de um relacionamento binário N:M (muitos-para-muitos): um médico se relaciona com vários pacientes e um paciente se relaciona com vários médicos.

O problema é que o modelo relacional (modelo lógico, que antecede o físico) não suporta diretamente relacionamentos N:M. Para representar essa cardinalidade, é necessário criar uma nova tabela — a entidade associativa — que terá como chave primária a composição das chaves primárias das duas entidades participantes (ou uma chave própria), e cada uma dessas chaves será também chave estrangeira referenciando as tabelas originais. Essa tabela intermediária é o que permite registrar cada consulta específica entre um médico e um paciente, inclusive as repetidas.

Vamos entender o porquê: se simplesmente adicionássemos um campo MÉDICO na tabela PACIENTE (ou vice-versa), não conseguiríamos representar a situação em que um paciente se consulta com vários médicos, nem as consultas repetidas com o mesmo médico. A entidade associativa resolve exatamente isso: cada linha da tabela CONSULTA representa uma ocorrência específica do relacionamento, podendo inclusive armazenar atributos próprios da consulta (como data, hora, diagnóstico).

A pegadinha desta questão está em confundir a transformação de um relacionamento N:M com a simples adição de campos de chave estrangeira. A banca explora o erro comum de achar que basta colocar a chave de uma entidade na outra, quando na verdade é preciso criar uma tabela própria para o relacionamento. Guarde a regra: relacionamento 1:N → chave estrangeira na entidade do lado "N"; relacionamento N:M → entidade associativa (tabela de ligação).

Alternativa A — ❌ Incorreta

Excluir o relacionamento CONSULTA eliminaria a informação de quais médicos atenderam quais pacientes — uma perda irreparável de dados. O relacionamento N:M não pode simplesmente desaparecer no modelo físico; ele precisa ser materializado em uma tabela. A alternativa contraria o princípio básico da modelagem: todo relacionamento do DER deve ter correspondência no modelo relacional.

Alternativa B — ✅ Correta ⟵ GABARITO

Esta é a transformação correta. O relacionamento N:M entre MÉDICO e PACIENTE deve virar uma entidade associativa (tabela CONSULTA) no modelo físico. Essa tabela terá, no mínimo, os campos MÉDICO (chave estrangeira) e PACIENTE (chave estrangeira), e a combinação desses campos (ou uma chave própria) formará a chave primária. É exatamente o que permite registrar as múltiplas consultas entre os mesmos médico e paciente.

Alternativa C — ❌ Incorreta

Transformar CONSULTA em um campo MÉDICO não faz sentido: o relacionamento não é um atributo de nenhuma das entidades. Além disso, adicionar um campo MÉDICO na tabela PACIENTE (ou vice-versa) só permitiria representar um relacionamento 1:N, não o N:M descrito no enunciado. Um paciente com vários médicos exigiria múltiplos campos ou violaria a primeira forma normal.

Alternativa D — ❌ Incorreta

Transformar CONSULTA em dois campos (MÉDICO e PACIENTE) é uma aproximação, mas incompleta e tecnicamente imprecisa. Esses dois campos, na verdade, são as chaves estrangeiras que compõem a entidade associativa — mas a alternativa não menciona a criação da tabela própria. A entidade associativa não é apenas "dois campos", é uma nova relação (tabela) que os contém. Além disso, sem a tabela, não haveria onde armazenar atributos da própria consulta (data, hora, etc.).

Alternativa E — ❌ Incorreta

Transformar CONSULTA em um campo PACIENTE sofre do mesmo problema da alternativa C, mas no sentido inverso. Adicionar um campo PACIENTE na tabela MÉDICO limitaria o modelo a um relacionamento 1:N (um paciente por médico), contrariando diretamente o enunciado que afirma que um mesmo paciente pode se consultar com o mesmo médico mais de uma vez — o que exige uma estrutura que comporte múltiplas ocorrências.

Gabarito: letra B