Pesquisar conteúdos

Encontre uma trilha ou aula pelo assunto.

Experimente pesquisar por “governança”, “ITIL” ou “planejamento”.

Conteúdo da trilha

Transformação do modelo ER para o modelo relacional

Converta entidades, atributos e relacionamentos em tabelas, chaves e restrições sem perder as regras do modelo conceitual.
Modelo relacional e projeto8 de 2025 min de leitura
Modelo entidade-relacionamento é transformado em relações que preservam identificadores, referências, associação e dependência

Mapear é preservar significado em outra estrutura

O modelo entidade-relacionamento descreve conceitos, atributos, associações, cardinalidades e participação. O modelo relacional precisa representar essas mesmas regras com relações, colunas, chaves e restrições de integridade.

Essa transformação é chamada de mapeamento ER-relacional. Ela não consiste em desenhar uma tabela para cada caixa. Entidades fortes normalmente originam relações; atributos multivalorados e relacionamentos podem originar outras relações; cardinalidades determinam onde ficam FKs e restrições únicas; algumas regras ainda exigem mecanismos adicionais.

O resultado deve permitir reconstruir os fatos do modelo conceitual sem inventar associações e sem depender de convenções invisíveis.

Comece por um inventário de regras

Antes de criar tabelas, registre para cada elemento:

  • entidade, identificadores e atributos;
  • atributos simples, compostos, multivalorados e derivados;
  • cardinalidade mínima e máxima de cada participação;
  • atributos pertencentes ao relacionamento;
  • dependência de existência de entidades fracas;
  • especializações totais ou parciais, disjuntas ou sobrepostas;
  • regras que o diagrama não consegue expressar sozinho.

O inventário evita perder a participação mínima durante uma conversão que olha apenas para 1:N ou N:N.

Entidade forte normalmente origina uma relação

Uma entidade com identificação própria vira, como ponto de partida, uma relação. Seus atributos simples viram colunas e o identificador escolhido vira chave primária.

Entidade: TRILHA
Identificador: id_trilha
Atributos: slug, titulo, situacao, publicada_em

CREATE TABLE trilha (
  id_trilha bigint PRIMARY KEY,
  slug text NOT NULL UNIQUE,
  titulo text NOT NULL,
  situacao text NOT NULL,
  publicada_em timestamptz
);

Cada ocorrência da entidade corresponde a uma tupla. A relação recebe regras adicionais do domínio; a conversão não termina na lista de colunas.

Tipos de atributo pedem decisões diferentes

Atributo simples

Um valor indivisível para os usos do sistema vira uma coluna, como titulo. “Indivisível” depende dos requisitos: se nunca precisamos consultar partes de um código, ele pode permanecer um valor; se rua e cidade têm usos próprios, escondê-las em um texto único atrapalha regras e consultas.

Atributo composto

Um atributo composto é decomposto nas partes relevantes. endereco pode originar logradouro, cidade, estado e codigo_postal. Isso não exige automaticamente uma relação separada. Crie outra relação quando o endereço tiver identidade, repetição, ciclo de vida ou compartilhamento que justifique tratá-lo como fato próprio.

Atributo multivalorado

Uma pessoa pode ter vários telefones. Criar telefone_1, telefone_2 e telefone_3 impõe um limite artificial e produz colunas vazias. Armazenar uma lista numa célula prejudica a estrutura relacional quando cada telefone precisa ser validado ou consultado.

Mapeie o conjunto para uma relação:

CREATE TABLE telefone_estudante (
  id_estudante bigint NOT NULL
    REFERENCES estudante (id_estudante),
  telefone text NOT NULL,
  tipo text,
  PRIMARY KEY (id_estudante, telefone)
);

A PK composta expressa que o mesmo telefone não se repete para o mesmo estudante. Se repetição, histórico ou ordem tiver significado, a identidade deve ser redesenhada.

Atributo derivado

total_concluidas pode ser calculado a partir das matrículas concluídas. Armazená-lo cria a obrigação de sincronizar o valor com sua origem. Em geral, preserve a fonte e derive por consulta, visão ou mecanismo controlado. Materializar pode ser justificável por desempenho, mas exige política explícita de atualização e será uma decisão física, não uma regra automática do mapeamento.

Entidade Estudante transforma atributos simples e partes do endereço em colunas, telefone multivalorado em relação própria e total concluído em valor derivado
A forma conceitual orienta a estrutura, mas o significado decide. Compostos são decompostos; multivalorados ganham relação; derivados podem permanecer calculados.

Entidade fraca incorpora a identidade da proprietária

Uma entidade fraca não possui identificação completa fora de sua proprietária. SECAO numerada apenas dentro de CONTEUDO pode ser identificada por (id_conteudo, numero):

CREATE TABLE secao (
  id_conteudo bigint NOT NULL,
  numero integer NOT NULL CHECK (numero > 0),
  titulo text NOT NULL,
  PRIMARY KEY (id_conteudo, numero),
  FOREIGN KEY (id_conteudo)
    REFERENCES conteudo (id_conteudo)
    ON DELETE CASCADE
);

id_conteudo exerce dois papéis: é FK para a proprietária e parte da PK da entidade fraca. numero é o discriminador parcial. CASCADE só é apropriado porque o exemplo assume que uma seção não existe sem o conteúdo; se o domínio exigir histórico independente, a política muda.

Adicionar um id_secao substituto pode facilitar referências externas, mas não elimina UNIQUE (id_conteudo, numero) quando essa combinação continua sendo uma regra do negócio.

Relacionamento 1:N coloca a FK no lado N

Em TRILHA 1:N MODULO, várias ocorrências de módulo podem pertencer à mesma trilha, mas cada módulo pertence a no máximo uma trilha. A chave da trilha migra para MODULO:

CREATE TABLE modulo (
  id_modulo bigint PRIMARY KEY,
  id_trilha bigint NOT NULL
    REFERENCES trilha (id_trilha),
  titulo text NOT NULL,
  ordem integer NOT NULL,
  UNIQUE (id_trilha, ordem)
);

A participação mínima do módulo define a nulabilidade:

  • 1..1 trilha por módulo → FK NOT NULL;
  • 0..1 trilha por módulo → FK anulável, se ausência for um estado válido.

Se o relacionamento possui atributos, eles normalmente acompanham a FK no lado N. Em FUNCIONARIO N:1 DEPARTAMENTO, uma alocado_em que descreve a alocação pode ficar com o funcionário — desde que exista somente uma alocação atual. Histórico de várias alocações exige uma relação própria.

Relacionamento 1:1 exige escolher o lado da FK

Em 1:1, uma FK pode ficar em qualquer uma das relações, mas as opções não são equivalentes. Prefira o lado com participação total ou aquele cuja existência depende semanticamente do outro.

Suponha que PREFERENCIA seja opcional para ESTUDANTE, mas não possa existir sem ele:

CREATE TABLE preferencia (
  id_preferencia bigint PRIMARY KEY,
  id_estudante bigint NOT NULL UNIQUE
    REFERENCES estudante (id_estudante),
  tema text NOT NULL
);

NOT NULL obriga toda preferência a apontar para estudante; UNIQUE impede duas preferências para o mesmo estudante. Isso materializa ESTUDANTE 1 : 0..1 PREFERENCIA.

Outra opção é usar a FK também como PK de PREFERENCIA, chamada de chave primária compartilhada. Se as duas entidades sempre existem juntas e não possuem ciclos de vida distintos, talvez possam ser uma única relação. A separação deve ter justificativa, não ser reflexo automático do desenho.

Mesmo com FK única, exigir que todo estudante possua preferência não é garantido apenas pela tabela dependente. Essa simetria precisa ser analisada separadamente.

Relacionamento N:N vira uma relação associativa

ESTUDANTE N:N TRILHA não cabe como uma FK isolada em qualquer lado. Crie uma relação para o próprio fato da associação:

CREATE TABLE matricula (
  id_estudante bigint NOT NULL
    REFERENCES estudante (id_estudante),
  id_trilha bigint NOT NULL
    REFERENCES trilha (id_trilha),
  matriculada_em date NOT NULL,
  situacao text NOT NULL,
  PRIMARY KEY (id_estudante, id_trilha)
);

Os atributos matriculada_em e situacao pertencem à matrícula, não ao estudante nem à trilha. A PK composta é correta somente se houver no máximo uma matrícula por par. Se rematrícula for permitida, precisamos incluir edição, ocorrência ou outro identificador e preservar a regra apropriada.

Três painéis mostram chave estrangeira única em 1 para 1, chave estrangeira no lado muitos em 1 para N e relação Matrícula com duas referências em N para N
A cardinalidade máxima define a estrutura básica. A participação mínima determina nulabilidade e pode revelar garantias que uma FK isolada não consegue expressar.

Relacionamentos recursivos precisam nomear papéis

Num relacionamento recursivo 1:N, a relação referencia a própria chave:

CREATE TABLE conteudo (
  id_conteudo bigint PRIMARY KEY,
  titulo text NOT NULL,
  id_prerequisito bigint
    REFERENCES conteudo (id_conteudo)
);

Os nomes diferenciam os papéis “conteúdo atual” e “pré-requisito”. A FK impede referência a conteúdo inexistente, mas não impede um conteúdo de apontar para si ou ciclos mais longos. Essas regras excedem a correspondência referencial simples.

Um relacionamento recursivo N:N usa uma associativa com duas FKs para a mesma relação, nomeadas pelos papéis:

DEPENDENCIA(id_conteudo, id_prerequisito)

Relacionamento n-ário não deve ser decomposto às cegas

Um relacionamento ternário afirma um fato sobre três participantes simultaneamente. Imagine: um MENTOR recomenda um CONTEUDO a um ESTUDANTE. A relação correspondente pode ser:

RECOMENDACAO(id_mentor, id_estudante, id_conteudo, recomendada_em)

Ela possui três FKs. A chave depende da regra: o mesmo mentor pode recomendar o mesmo conteúdo ao mesmo estudante mais de uma vez? Há campanhas ou ocorrências distintas?

Substituir a relação ternária por três relações binárias pode inventar combinações que nunca ocorreram. Saber que mentor A conhece estudante B, que A conhece conteúdo C e que B acessa C não prova que A recomendou C a B. Preserve o fato completo, salvo quando regras do domínio demonstrarem uma decomposição sem perda.

Generalização e especialização possuem estratégias

Considere CONTEUDO como supertipo de ARTIGO e VIDEO. Existem três estratégias frequentes.

Uma tabela para toda a hierarquia

CONTEUDO recebe um discriminador tipo e todas as colunas dos subtipos. Evita junções para leitura conjunta, mas produz colunas nulas e exige CHECK para impedir combinações incoerentes, como artigo com URL de vídeo e sem corpo.

Supertipo e uma tabela para cada subtipo

CONTEUDO mantém atributos comuns. ARTIGO.id_conteudo e VIDEO.id_conteudo são simultaneamente PK e FK para o supertipo. A identidade global e referências ao conteúdo ficam naturais; recuperar o subtipo completo exige junção.

Uma tabela para cada tipo concreto

Cada tabela repete atributos comuns. Consultas de um subtipo são diretas, mas evolução, identidade global, unicidade e FKs para “qualquer conteúdo” tornam-se mais difíceis. Essa estratégia funciona melhor quando os tipos são operacionalmente independentes.

Comparação entre uma tabela para toda a hierarquia, uma tabela de supertipo ligada a tabelas de subtipo e uma tabela completa para cada tipo concreto
Não existe estratégia universal para herança. Frequência de consultas conjuntas, nulidade, identidade global, evolução e restrições orientam a escolha.

Totalidade e exclusividade também precisam ser preservadas. Na estratégia supertipo–subtipo, PKs compartilhadas não garantem sozinhas que todo conteúdo esteja em algum subtipo nem que apareça em apenas um quando a especialização é disjunta. O suporte declarativo varia, e regras adicionais podem ser necessárias.

Mapeamento e normalização não são a mesma etapa

O mapeamento traduz elementos conceituais. Isso não prova que todas as relações resultantes estejam livres de redundância ou anomalias. Uma entidade conceitual pode reunir atributos com dependências problemáticas; uma relação associativa pode receber uma chave inadequada.

Depois da conversão, revise dependências funcionais e formas normais. Não use “veio do ER” como certificado automático de qualidade relacional.

Da mesma forma, índices não fazem parte desta tradução lógica. PKs e restrições podem criar estruturas auxiliares no SGBD, mas escolhas adicionais de índice dependem das consultas e serão analisadas depois.

Um esquema resultante para o Guia Estudos

Após as decisões, uma visão compacta pode ser:

ESTUDANTE(id_estudante PK, nome, email UQ)
TELEFONE_ESTUDANTE(id_estudante PK/FK, telefone PK, tipo)
TRILHA(id_trilha PK, slug UQ, titulo, situacao)
MODULO(id_modulo PK, id_trilha FK, titulo, ordem, UQ(id_trilha, ordem))
CONTEUDO(id_conteudo PK, id_modulo FK, titulo, ordem)
SECAO(id_conteudo PK/FK, numero PK, titulo)
MATRICULA(id_estudante PK/FK, id_trilha PK/FK, matriculada_em, situacao)

Esse esquema registra identidade, composição, ordem local, entidade fraca, atributo multivalorado e associação N:N. Ainda precisamos conferir nulabilidade, ações referenciais, domínios e dependências em cada relação.

Erros comuns

  • criar uma tabela para toda forma do diagrama: atributos e relacionamentos não seguem uma regra única;
  • colocar uma FK no lado 1 de um relacionamento 1:N: isso limita ou inverte o fato representado;
  • guardar vários IDs numa coluna: listas escondem cardinalidade e impedem integridade referencial elementar;
  • mapear N:N com apenas uma FK: uma relação associativa é necessária para representar os pares;
  • perder atributos do relacionamento: data de matrícula não pertence isoladamente a estudante ou trilha;
  • esquecer UNIQUE no 1:1: uma FK comum permite vários filhos para o mesmo pai;
  • ignorar participação mínima: nullable e obrigatório não são detalhes de interface;
  • dar ID substituto à entidade fraca e remover sua unicidade natural: duplicações conceituais tornam-se possíveis;
  • decompor relacionamento ternário em binários sem prova: combinações falsas podem surgir;
  • escolher herança por preferência de framework: identidade, consultas e restrições devem orientar a estratégia;
  • confundir mapeamento com normalização ou projeto físico: são análises relacionadas, mas distintas.

Roteiro de transformação

  1. Congele uma versão revisada do modelo conceitual e seu dicionário.
  2. Mapeie entidades fortes, atributos simples e identificadores.
  3. Decomponha compostos e crie relações para multivalorados.
  4. Mapeie entidades fracas com a chave da proprietária.
  5. Converta 1:N, registrando FK, nulabilidade e atributos do vínculo.
  6. Resolva 1:1 pelo lado de maior dependência e imponha unicidade.
  7. Crie relações associativas para N:N e relacionamentos n-ários.
  8. Trate relacionamentos recursivos com nomes de papéis claros.
  9. Escolha e documente a estratégia de especialização.
  10. Reaplique todas as restrições de domínio, entidade e referência.
  11. Liste regras conceituais ainda não garantidas pelo esquema.
  12. Revise dependências funcionais antes do projeto físico.

O que você deve guardar

Entidades fortes normalmente viram relações; atributos simples viram colunas; multivalorados ganham relações próprias; entidades fracas incorporam a chave da proprietária. Em 1:N, a FK fica no lado N. Em 1:1, a FK recebe unicidade e deve ficar no lado semanticamente adequado. Em N:N e relacionamentos n-ários, uma relação associativa preserva o fato completo.

Cardinalidade máxima define grande parte da estrutura; participação mínima define obrigatoriedade e revela regras adicionais. Generalizações admitem estratégias com custos diferentes. O mapeamento termina somente quando cada regra conceitual foi implementada ou registrada como uma garantia ainda pendente.

Na próxima aula, investigaremos dependências funcionais e normalização para identificar redundâncias e anomalias que o mapeamento, sozinho, não elimina.

Referências