MER: O que é e como aplicar

O MER é a base de um banco de dados bem estruturado, evitando problemas de redundância, inconsistência e falhas de desempenho. Mas antes de abrir qualquer ferramenta de diagrama, existe uma confusão comum que precisa ser resolvida: MER e DER não são a mesma coisa — e entender essa diferença muda a forma como você modela.

Este artigo cobre o conceito completo, do artigo seminal de Peter Chen em 1976 até a aplicação em sistemas reais, passando pelos erros mais comuns, as notações disponíveis e como a modelagem se conecta à normalização e ao banco físico.

O que é MER

O Modelo Entidade Relacionamento (também chamado Modelo ER ou simplesmente MER) é um modelo conceitual utilizado na Engenharia de Software para descrever os objetos envolvidos em um domínio de negócios — suas características e como eles se relacionam entre si.

Foi proposto por Peter Chen em 1976, no artigo seminal “The Entity-Relationship Model: Toward a Unified View of Data”, publicado no ACM Transactions on Database Systems. O objetivo era criar uma forma de representar o mundo real de maneira abstrata, independente de qualquer banco de dados específico, antes de qualquer decisão de implementação.

Em termos práticos: o MER é uma linguagem — um conjunto de conceitos e regras que permitem descrever a estrutura de um banco de dados de forma abstrata. Entidades, atributos e relacionamentos são os elementos dessa linguagem.

O modelo representa de forma abstrata a estrutura que o banco de dados da aplicação terá. Obviamente, o banco de dados final poderá conter outras estruturas que só fazem sentido no contexto relacional, como chaves estrangeiras e tabelas intermediárias — mas o MER existe antes disso, na fase conceitual.

Referência: Peter Chen (1976). The Entity-Relationship Model — Toward a Unified View of Data. ACM Transactions on Database Systems. ACM Digital Library

A diferença entre MER e DER

Essa é a dúvida mais comum — e a resposta precisa ser direta.

MER é a linguagem. Um conjunto de conceitos (entidade, atributo, relacionamento, cardinalidade) que descrevem como modelar dados de forma conceitual. A notação original foi proposta por Peter Chen em 1976.

DER (Diagrama Entidade Relacionamento) é a representação gráfica de um modelo criado com base nos conceitos do MER. O diagrama é o artefato visual — o desenho das caixas, losangos e linhas que você vê em ferramentas como Draw.io, Lucidchart ou MySQL Workbench.

A relação entre os dois: o MER define os conceitos, o DER é uma das formas de representar esses conceitos visualmente.

Uma analogia útil: o MER é como a gramática de um idioma. O DER é um texto escrito com essa gramática. Diferentes autores podem escrever o mesmo conteúdo com estilos diferentes — e é exatamente isso que acontece com as notações.

As principais notações do DER

Após a proposta original de Peter Chen, surgiram outras notações que usam os mesmos conceitos do MER com representações visuais diferentes.

Notação Peter Chen (original): entidades são retângulos, atributos são elipses conectadas às entidades por linhas, relacionamentos são losangos. É a notação didática mais usada em livros e faculdades.

Notação James Martin (pé de galinha): é a notação mais usada na indústria hoje. Elimina as elipses — os atributos ficam listados dentro dos retângulos de entidade. A cardinalidade é representada por símbolos nas extremidades das linhas (o “pé de galinha” indica “muitos”). Ferramentas como MySQL Workbench, Lucidchart e dbdiagram.io usam variações dessa notação.

Notação UML (Unified Modeling Language): os atributos aparecem listados no corpo da entidade, no formato de classes. Comum em projetos que documentam tanto o banco quanto a aplicação no mesmo diagrama.

A diferença entre as notações é o “alfabeto” — a forma de representar os conceitos. Os conceitos subjacentes (entidade, atributo, relacionamento, cardinalidade) são os mesmos em todas.

Resumindo o que o Stack Overflow em Português documenta com precisão: MER é a linguagem que descreve modelos conceituais na notação de Peter Chen. DER é o diagrama — o modelo visual — que pode usar notações diferentes (Peter Chen, James Martin, UML), mas sempre com base nos mesmos conceitos do MER.

Os três elementos fundamentais do MER

1. Entidades

Uma entidade é qualquer objeto ou conceito relevante dentro do domínio que precisa ser armazenado. Podem ser classificadas como:

Entidades físicas: existem no mundo real de forma tangível. Exemplos: Cliente, Produto, Funcionário, Veículo.

Entidades lógicas: existem como conceito dentro do negócio, não necessariamente como objeto físico. Exemplos: Pedido, Contrato, Matrícula, Transação.

Entidades são representadas por retângulos na notação de Peter Chen e por caixas com nome em negrito nas notações modernas.

Entidades fracas: são entidades que não podem ser identificadas de forma única sem depender de outra entidade. Um Item de Pedido não existe sem o Pedido ao qual pertence. Na notação de Chen, entidades fracas são representadas por retângulos com borda dupla.

2. Atributos

Atributos são as características que descrevem uma entidade. A entidade Produto pode ter os atributos ID_Produto, Nome, Preço, Estoque e Data_Cadastro.

Os atributos se dividem em tipos com comportamentos diferentes:

Simples (atômicos): não podem ser decompostos. Nome, Preço, CPF.

Compostos: podem ser divididos em partes menores com significado próprio. Endereço pode ser decomposto em Rua, Número, Bairro, CEP, Cidade, Estado. A decisão de tratar endereço como atributo composto ou como uma entidade separada depende das regras de negócio.

Derivados: calculados a partir de outros atributos. Idade derivada de Data_Nascimento. Total_Pedido derivado dos itens e preços. Na notação de Chen, são representados por elipses com borda tracejada.

Multivalorados: podem ter mais de um valor para a mesma instância. Telefones de um cliente pode ter celular, fixo e comercial. Requerem tratamento especial — geralmente uma tabela associativa no modelo relacional.

Chaves: primária e estrangeira

Chave primária (PK): atributo ou conjunto de atributos que identifica cada instância de uma entidade de forma única. Não pode se repetir e não pode ser nulo. CPF para Pessoa, ID_Produto para Produto. Na notação de Chen, o atributo chave aparece sublinhado.

Chave estrangeira (FK): atributo em uma entidade que referencia a chave primária de outra entidade. É o mecanismo que implementa os relacionamentos no banco de dados físico. Se Pedido referencia Cliente, o campo ID_Cliente em Pedido é uma chave estrangeira.

A distinção entre chaves naturais (como CPF) e chaves substitutas (surrogate keys, como um ID gerado automaticamente) tem impacto direto na manutenibilidade do sistema. Chaves naturais parecem convenientes mas mudam — CPF pode ser corrigido, e-mail muda. Chaves substitutas (IDs inteiros ou UUIDs) são imutáveis por design.

3. Relacionamentos

Relacionamentos descrevem como as entidades interagem entre si. São representados por losangos (notação de Chen) ou por linhas com símbolos de cardinalidade (notações modernas).

Um relacionamento tem:

Nome: que expressa a ação ou associação (realiza, pertence a, contém)
Cardinalidade: quantas instâncias de cada entidade participam do relacionamento
Participação (opcionalidade): se a participação é total (obrigatória) ou parcial (opcional)

Cardinalidade: o coração da modelagem

A cardinalidade define quantas instâncias de uma entidade podem se relacionar com instâncias de outra. É a restrição de negócio mais importante que o MER captura.

Tipos de cardinalidade

1:1 (um para um): cada instância de A se relaciona com no máximo uma instância de B, e vice-versa. Exemplo: um Funcionário tem exatamente um Crachá, e um Crachá pertence a exatamente um Funcionário. Relacionamentos 1:1 são menos comuns e frequentemente indicam que as entidades poderiam ser unificadas — a menos que existam razões específicas para separá-las (acesso diferente, ciclo de vida diferente).

1:N (um para muitos): uma instância de A pode se relacionar com várias instâncias de B, mas cada instância de B se relaciona com no máximo uma instância de A. Exemplo: um Cliente pode ter muitos Pedidos, mas cada Pedido pertence a um único Cliente. É o tipo mais comum em sistemas relacionais.

N:M (muitos para muitos): uma instância de A pode se relacionar com várias instâncias de B, e uma instância de B pode se relacionar com várias instâncias de A. Exemplo: um Aluno pode estar matriculado em várias Disciplinas, e uma Disciplina pode ter vários Alunos. Relacionamentos N:M não podem ser implementados diretamente no modelo relacional — precisam ser decompostos em uma entidade associativa.

Participação: total vs. parcial

A participação total (ou dependência existencial) indica que toda instância da entidade deve participar do relacionamento. Um Item de Pedido obrigatoriamente pertence a um Pedido — não pode existir de forma independente.

A participação parcial indica que a participação é opcional. Um Funcionário pode ou não ter um Veículo da empresa alocado.

Na notação de Chen, participação total é representada por linha dupla. Nas notações modernas, pelo símbolo de “obrigatório” ou “opcional” na ponta da linha.

Como aplicar o MER na prática: passo a passo

1. Entenda o domínio antes de modelar

Converse com quem conhece o negócio. Leia os requisitos. Faça perguntas específicas: “Um cliente pode ter vários endereços?” “Um produto pode pertencer a mais de uma categoria?” “Um pedido pode ser reaberto após ser finalizado?”

As respostas determinam a cardinalidade, a participação e a estrutura das entidades. Modelar sem entender o negócio resulta em um banco que funciona tecnicamente mas não atende às necessidades reais.

2. Identifique as entidades

Liste os objetos e conceitos que precisam ser armazenados. Em um sistema de e-commerce: Usuário, Produto, Categoria, Pedido, Item_Pedido, Pagamento, Endereço, Avaliação.

Uma dica prática: substantivos nos requisitos geralmente indicam entidades. Verbos geralmente indicam relacionamentos.

Não crie entidades para tudo. Se Status_do_Pedido tem apenas um nome e uma descrição e nunca vai ter relacionamentos próprios, pode ser um atributo de Pedido.

3. Defina os atributos de cada entidade

Para cada entidade, liste seus atributos e identifique:

Qual é a chave primária
Quais atributos são compostos ou multivalorados (e precisarão de tratamento especial)
Quais atributos são derivados (calculados em tempo de consulta, não armazenados)

4. Identifique os relacionamentos

Mapeie como as entidades interagem. Perguntas úteis: “Um [A] pode ter vários [B]?” “Um [B] pode existir sem um [A]?”

Documente cada relacionamento com nome, cardinalidade e participação.

5. Resolva os relacionamentos N:M com entidades associativas

Todo relacionamento muitos-para-muitos precisa de uma entidade intermediária no modelo relacional. O relacionamento entre Aluno e Disciplina vira a entidade Matrícula, que contém ID_Aluno, ID_Disciplina, Data_Matrícula e qualquer outro dado que pertence à relação em si.

Essa entidade associativa frequentemente carrega informações próprias — o Item_Pedido em um e-commerce tem Quantidade e Preço_Unitário, que não pertencem nem ao Pedido nem ao Produto isoladamente, mas à sua intersecção.

6. Desenhe o diagrama

Com entidades, atributos e relacionamentos definidos, crie o DER. Ferramentas recomendadas:

Draw.io / diagrams.net — gratuito, online, exporta para vários formatos
Lucidchart — colaborativo, com templates de ER
MySQL Workbench — faz engenharia direta (modelo para banco) e engenharia reversa (banco para modelo), documentado no Manual do MySQL Workbench, Capítulo 9
dbdiagram.io — define o modelo em texto (DBML) e gera o diagrama automaticamente
BRModelo — popular no Brasil para a notação de Peter Chen, especialmente no ambiente acadêmico

7. Aplique a normalização

Com o diagrama conceitual pronto, valide a estrutura eliminando redundâncias. As três primeiras formas normais cobrem a maioria dos casos práticos:

1NF (Primeira Forma Normal): eliminar grupos repetitivos e garantir que cada atributo contenha valores atômicos. Uma coluna Telefones com múltiplos números separados por vírgula viola a 1NF.

2NF (Segunda Forma Normal): eliminar dependências parciais. Cada atributo não-chave deve depender da chave primária inteira — não de uma parte dela. Aplicável apenas quando a chave primária é composta.

3NF (Terceira Forma Normal): eliminar dependências transitivas. Um atributo não-chave não deve depender de outro atributo não-chave. Se CEP determina Cidade, e Cidade está na tabela Cliente, há dependência transitiva — Cidade deveria estar em uma tabela de CEP.

A normalização reduz redundância e inconsistência, mas tem custo em performance de leitura — consultas que precisam de mais JOINs são mais lentas. Em sistemas com volume alto de leitura, uma desnormalização controlada e intencional pode ser justificada. O guia de design de banco de dados relacional da DEV Community detalha os três tipos de integridade (de entidade, referencial e de domínio) e quando considerar trade-offs entre normalização e performance.

O MER em sistemas reais

E-commerce com WooCommerce

O banco de dados do WooCommerce tem mais de 35 tabelas altamente normalizadas. A entidade central é wp_posts — que armazena não só posts de blog mas também produtos, pedidos e páginas. Os pedidos ficam em wp_posts com post_type shop_order, e os metadados do pedido em wp_postmeta. A estrutura demonstra integridade referencial em escala: produtos, pedidos, taxas e inventários precisam estar sincronizados para que não existam anomalias financeiras.

Fonte: Estrutura e Diagrama do Banco de Dados WooCommerce

WordPress e seu modelo de dados

O WordPress usa 12 tabelas principais, documentadas no WordPress Codex — Database Description. As tabelas wp_posts e wp_users são o núcleo, com wp_postmeta e wp_usermeta para dados extensíveis via chave-valor. É um exemplo de como uma modelagem relativamente simples pode escalar para suportar desde blogs pessoais até portais de grande porte — e também de como a flexibilidade do modelo EAV (Entity-Attribute-Value) tem custo em performance de consulta.

NoSQL e quando o MER não se aplica

O MER foi projetado para bancos de dados relacionais. Em bancos NoSQL orientados a documentos (MongoDB) ou a larga escala (Apache Cassandra), o paradigma é diferente.

O guia de design do Apache Cassandra explica o contraste diretamente: enquanto o RDBMS foca no modelo de dados e na normalização, o Cassandra usa um design orientado a consultas (query-first) — você modela a partir das consultas que precisa executar, não da estrutura natural dos dados. Isso incentiva a desnormalização intencional para ganho de performance em larga escala.

Entender o MER é fundamental mesmo para trabalhar com NoSQL: você precisa compreender o que está intencionalmente abandonando, e por quê.

Erros comuns na modelagem MER/DER

1. Confundir entidade com atributo

O erro mais frequente. Colocar Endereço como atributo simples de Cliente quando endereço tem múltiplos campos próprios (rua, número, CEP, cidade) e pode ter cardinalidade variada (cliente com vários endereços de entrega). A regra prática: se o dado tem subestrutura própria ou pode se repetir, considere torná-lo uma entidade.

2. Não definir chaves primárias para todas as entidades

Toda entidade precisa de um identificador único. A ausência de chave primária clara impossibilita a implementação correta de chaves estrangeiras e integridade referencial.

3. Deixar relacionamentos N:M sem entidade associativa

No modelo relacional, relacionamentos muitos-para-muitos precisam obrigatoriamente de uma tabela intermediária. Tentar implementar N:M diretamente resulta em redundância e perda de integridade.

4. Cardinalidade e participação mal definidas

Não especificar se a participação é total ou parcial, ou definir a cardinalidade errada, leva a um modelo que não captura as regras reais do negócio. Um relacionamento definido como 1:N quando deveria ser N:M vai gerar problemas que só aparecem quando o sistema estiver em uso.

5. Ignorar as regras de negócio

Modelar apenas com base na estrutura dos dados, sem considerar as restrições e processos da empresa. Resultado: um banco tecnicamente correto que não atende o negócio.

6. Atributos multivalorados não tratados

Atributos que podem ter múltiplos valores (telefones, tags, categorias) precisam de tabelas associativas no banco relacional. Armazenar múltiplos valores em um único campo viola a 1NF e impossibilita buscas eficientes.

7. Não normalizar ou normalizar demais

Falta de normalização gera redundância e inconsistência. Excesso de normalização gera consultas com muitos JOINs que prejudicam performance. O equilíbrio depende do perfil do sistema: leitura intensiva favorece alguma desnormalização, escrita intensiva favorece normalização mais rígida.

8. Não validar o modelo com quem conhece o negócio

O modelo conceitual deve ser revisado com analistas, usuários e stakeholders antes de ir para o modelo lógico. Erros descobertos no papel são baratos. Erros descobertos em produção são caros.

MER e IA: o estado atual

Ferramentas de inteligência artificial estão sendo integradas ao processo de modelagem, principalmente em quatro formas:

Geração de esboço inicial: você descreve o sistema em linguagem natural e a IA propõe uma estrutura inicial de entidades, atributos e relacionamentos. Útil para acelerar o início da modelagem, mas sempre requer revisão técnica — a IA não conhece as regras de negócio específicas.

Validação de modelos: você fornece o modelo e pede identificação de inconsistências, dependências circulares ou violações de normalização.

Conversão MER para modelo relacional: a IA pode auxiliar na tradução do modelo conceitual para SQL DDL (CREATE TABLE), economizando trabalho mecânico.

Documentação: geração de descrições para entidades, atributos e relacionamentos a partir do diagrama.

A IA é uma ferramenta de produtividade nesse contexto — não substitui o entendimento do domínio nem o julgamento técnico sobre cardinalidade, normalização e trade-offs de performance.

Ferramentas para criar o DER

Ferramenta	Tipo	Notação	Destaques
Draw.io / diagrams.net	Online, gratuito	Chen, Martin, UML	Exporta SVG, PNG, XML
Lucidchart	Online, freemium	Martin, UML	Colaborativo, templates
MySQL Workbench	Desktop, gratuito	EER (estendido)	Engenharia direta e reversa
dbdiagram.io	Online, gratuito	Martin	Define modelo em texto (DBML)
BRModelo	Online, gratuito	Peter Chen	Muito usado no Brasil academicamente
ERwin Data Modeler	Desktop, pago	Martin, IDEF1X	Enterprise, engenharia reversa avançada

Perguntas frequentes

Qual a diferença entre MER e DER?

MER é a linguagem — o conjunto de conceitos (entidade, atributo, relacionamento, cardinalidade) para descrever modelos de banco de dados de forma conceitual, proposto por Peter Chen em 1976. DER é o diagrama — a representação gráfica de um modelo criado com os conceitos do MER. O DER pode usar diferentes notações (Peter Chen, James Martin, UML), mas os conceitos subjacentes vêm do MER.

O MER é a mesma coisa que o modelo relacional?

Não. O MER é um modelo conceitual — independente de tecnologia. O modelo relacional (tabelas, linhas, colunas, SQL) é um modelo lógico de implementação. O MER vem antes: você modela conceitualmente com MER/DER, depois traduz para o modelo relacional, e só então implementa no banco físico (MySQL, PostgreSQL, SQL Server).

Quando usar entidade associativa em vez de relacionamento N:M?

Sempre que o relacionamento muitos-para-muitos tiver atributos próprios, ele deve ser modelado como entidade associativa. Se Matrícula tem Data_Início, Nota e Status, esses dados pertencem ao relacionamento em si — não ao Aluno nem à Disciplina. Mesmo sem atributos próprios, no modelo relacional o N:M sempre vira uma tabela intermediária.

O que é cardinalidade mínima e máxima?

A cardinalidade máxima indica o número máximo de instâncias que podem participar do relacionamento (1 ou N). A cardinalidade mínima (participação) indica o número mínimo — 0 (participação parcial, opcional) ou 1 (participação total, obrigatória). A notação (min, max) captura as duas: (0,1), (1,1), (0,N), (1,N) são as combinações possíveis.

Preciso sempre normalizar até a 3NF?

Não existe uma regra absoluta. A normalização até 3NF é adequada para a maioria dos sistemas transacionais. Sistemas analíticos (data warehouses) frequentemente usam modelos desnormalizados (como o modelo estrela) para otimizar consultas de leitura. A chave é entender o trade-off: normalização reduz redundância e facilita escrita, desnormalização acelera leitura.

Como o MER se aplica a bancos NoSQL?

O MER foi projetado para bancos relacionais. Em NoSQL, o design segue outros princípios — em bancos orientados a documentos, você modela pensando em como os dados serão acessados juntos, não em como normalizar. Mesmo assim, entender o MER é valioso: você precisa compreender o que está intencionalmente abandonando ao escolher NoSQL, e por quê esse trade-off faz sentido para o seu caso.

Conclusão

O MER é o ponto de partida correto para qualquer projeto de banco de dados — não porque é obrigatório, mas porque modelar conceitualmente antes de implementar evita os erros mais caros: estruturas que precisam ser reestruturadas em produção, relacionamentos mal definidos que geram anomalias de dados, e decisões de design que não escalam.

Dominar o MER é entender como representar o mundo real em estruturas de dados antes de escrever uma linha de SQL. Isso vale tanto para quem projeta bancos relacionais quanto para quem decide quando e por que um NoSQL faz mais sentido.

Referências

Peter Chen (1976). The Entity-Relationship Model — Toward a Unified View of Data. ACM Transactions on Database Systems. ACM Digital Library
Song & Froehlich. A Practical Guide to Entity-Relationship Diagrams. Drexel University (referência acadêmica).
MySQL Documentation. MySQL Workbench — Data Modeling (Capítulo 9). dev.mysql.com
Apache Cassandra. RDBMS Design vs. Cassandra Design. cassandra.apache.org
WordPress Codex. Database Description. codex.wordpress.org
WooCommerce Database. WooCommerce Database Structure and Diagram. databasesample.com
OWASP. Insecure Direct Object Reference (IDOR). owasp.org
DEV Community. Mastering Relational Database Design. dev.to
Stack Overflow em Português. Qual a diferença entre MER e DER? pt.stackoverflow.com
IESDE. Modelagem de Banco de Dados (material didático).