Resumo TI Banco de Dados: Mapeamento do Modelo Conceitual para Lógico Relacional

Todo o vocabulário conceitual construído nesta trilha — entidades, atributos, chaves, relacionamentos, especializações, agregação — só vira banco de dados de verdade quando é traduzido em tabelas. Esse processo tem nome e regras formais: mapeamento do modelo conceitual (EER) para o modelo lógico relacional, e é justamente aqui que se fecham várias pontas deixadas em aberto propositalmente nos resumos anteriores.

Neste resumo, você vai ver a regra de mapeamento para entidades fortes e fracas, atributos compostos e multivalorados, os tipos de relacionamento (1:1, 1:N, N:N e ternário) e as estratégias para especialização, categoria e agregação.

🏛️ Entidade forte → tabela

A regra-base: cada entidade forte vira uma tabela; cada atributo simples vira uma coluna; a chave primária escolhida vira a PK da tabela. É o caso mais direto do mapeamento, sem nenhuma decisão de projeto adicional.

🧩 Entidade fraca → tabela com chave composta

Uma entidade fraca também vira tabela própria, mas sua chave primária não é só a chave parcial: é a combinação da chave parcial com a FK que referencia a chave primária da entidade proprietária. Se Dependente é entidade fraca de Funcionário, a tabela Dependente tem uma coluna id_funcionario (FK para Funcionário) e uma coluna com a chave parcial (ex.: nome), e a PK da tabela é a combinação das duas.

🧱 Atributos compostos e multivalorados

Atributo composto não gera coluna própria — apenas seus componentes viram colunas (Endereço vira Logradouro, Número, Bairro, Cidade, CEP, direto na tabela da entidade). Atributo multivalorado, como já adiantado no resumo sobre tipos de atributo, exige uma tabela própria, com uma FK para a entidade original e uma coluna para o valor do atributo — cada valor ocupa uma linha própria nessa tabela, nunca uma coluna própria — porque nenhuma célula de tabela relacional aceita mais de um valor, sob pena de violar a 1ª Forma Normal.

🔗 Mapeamento por tipo de relacionamento

• 1:1: a chave estrangeira pode ir em qualquer um dos dois lados — a escolha recai, na prática, sobre o lado com participação total (para minimizar valores nulos na FK) ou sobre o lado consultado com mais frequência;
• 1:N: a chave estrangeira sempre vai no lado “N” — o lado que pode se repetir várias vezes recebe a referência para o lado único;
• N:N: exige uma tabela associativa própria, contendo as chaves estrangeiras das duas entidades participantes (juntas formando a PK composta da tabela associativa) e os eventuais atributos do relacionamento — como a Nota de um Aluno numa Disciplina;
• Ternário ou n-ário: segue a mesma lógica do N:N, com uma tabela associativa contendo a FK de cada uma das entidades participantes.

A participação, como visto no resumo específico sobre o tema, determina se a coluna de FK é NOT NULL (participação total do lado que carrega a FK) ou aceita nulo (participação parcial).

🧬 Mapeamento de especialização e generalização

Existem três estratégias clássicas, cada uma com um trade-off diferente:

• Tabela por superclasse + tabela por subclasse: a superclasse vira uma tabela com os atributos comuns; cada subclasse vira outra tabela, contendo só os atributos exclusivos dela, com a PK compartilhada funcionando também como FK para a tabela da superclasse. É a estratégia mais fiel ao modelo conceitual e a mais indicada quando a especialização é sobreposta ou parcial;
• Uma tabela por subclasse, sem tabela para a superclasse: cada subclasse recebe uma tabela com os atributos comuns duplicados mais os exclusivos. Só funciona sem perda de dado quando a especialização é total — caso contrário, as ocorrências da superclasse sem subclasse ficam sem tabela nenhuma; se, além disso, for sobreposta, ainda há duplicação de atributos comuns entre as tabelas das subclasses que compartilham a mesma instância;
• Uma única tabela para toda a hierarquia: reúne todos os atributos (comuns e de todas as subclasses) numa tabela só, com uma coluna discriminadora de tipo indicando a qual subclasse cada linha pertence. Simplifica consultas, mas gera muitas colunas com valor nulo para linhas de subclasses que não usam aquele atributo.

🔀 Categoria e agregação

A categoria (tipo união), vista no resumo anterior, costuma virar uma tabela própria, identificada pela chave substituta discutida naquele resumo, com uma FK opcional em cada tabela de superclasse de origem apontando para essa nova tabela. A agregação não exige uma estratégia exclusiva: como o relacionamento agregado (ex.: Atua, entre Funcionário e Projeto) já vira uma tabela associativa por ser N:N, o relacionamento externo (Supervisiona) é resolvido tratando essa tabela associativa como se fosse uma entidade comum — adiciona-se, dentro dela, uma FK extra apontando para a chave do Funcionário-gerente, aplicando a mesma regra de que o lado “N” (o gerente pode supervisionar várias ocorrências de Atua) é quem recebe a referência.

⚠️ Pegadinhas comuns

• A FK do relacionamento 1:N nunca vai no lado “1”: colocar a chave estrangeira no lado errado é o erro mais cobrado nesse tema — sempre no lado que pode ter várias ocorrências associadas a uma só do outro lado;
• Atributo multivalorado não vira várias colunas na mesma tabela (como Telefone1, Telefone2, Telefone3): essa prática viola a 1ª Forma Normal e limita artificialmente a quantidade de valores — a solução correta é sempre uma tabela própria;
• A estratégia “uma tabela para toda a hierarquia” não é sempre a melhor: é comum a prova cobrar justamente o trade-off entre as três estratégias de especialização, não uma “resposta certa única”;
• Entidade fraca nunca tem PK só com a chave parcial: esquecer de incluir a FK da entidade proprietária na chave primária da tabela é um erro clássico de mapeamento.

🎯 Dica Final para a Prova

Memorize a regra de ouro do mapeamento de relacionamentos: “a chave estrangeira sempre migra para o lado de cardinalidade N” — em 1:N, vai só para o “N”; em N:N, os dois lados são “N” entre si, por isso precisam de uma tabela associativa nova para carregar as duas FKs. E lembre-se de que toda decisão de mapeamento de especialização é sempre um trade-off entre fidelidade ao modelo, simplicidade de consulta e quantidade de valores nulos.

✓ Agora que você sabe transformar qualquer modelo conceitual em tabelas relacionais, o próximo passo é revisar, de forma consolidada, os erros mais frequentes cometidos em todo esse processo de modelagem — e como evitá-los.

📍Gostou do conteúdo? Deixe um comentário, compartilhe e continue acompanhando o Dicionário do Concurseiro para mais Resumos de TI – Banco de Dados. Aqui você encontra explicações claras, atualizadas e com foco total no que cai em prova!

👉 Leia também no Dicionário do Concurseiro: Resumo TI Banco de Dados: Erros Frequentes de Modelagem e Como Evitá-los

📘 Mapear corretamente é o momento em que a modelagem conceitual mostra se realmente foi bem feita — cada decisão errada de chave estrangeira ou de estratégia de especialização se propaga diretamente para o desempenho e a integridade do banco. Continue estudando!