Modelo entidade-relacionamento: entidades, atributos e relacionamentos

Modelar é transformar regras do domínio em uma linguagem verificável

Na aula anterior, comparamos modelos relacionais, de documentos, chave-valor, famílias de colunas e grafos. Antes de implementar qualquer um deles, precisamos compreender o domínio: quais objetos importam, que características precisam ser registradas e quais vínculos são permitidos.

O modelo entidade-relacionamento, ou modelo ER, representa esse entendimento por meio de entidades, atributos, relacionamentos e restrições. Peter Chen apresentou o modelo em 1976 como uma forma de incorporar significado sobre o mundo observado e apoiar o projeto de bancos de dados.

O resultado visual é um diagrama entidade-relacionamento (DER ou ERD). Modelo e diagrama não são exatamente a mesma coisa: o modelo inclui definições e regras; o diagrama é uma representação útil desse conhecimento. Regras complexas podem exigir texto complementar.

Requisitos vêm antes das formas do diagrama

Um bom modelo não começa desenhando retângulos. Ele começa com afirmações verificáveis junto a quem conhece o domínio. Na plataforma de estudos, poderíamos registrar:

• cada trilha possui título, descrição e data de publicação;
• uma trilha é organizada em um ou mais módulos;
• cada módulo pertence a uma única trilha;
• estudantes podem se matricular em várias trilhas;
• uma matrícula registra data e situação;
• um conteúdo pode aparecer em uma sequência de módulo;
• o sistema registra quando um estudante conclui um conteúdo.

Substantivos ajudam a encontrar entidades candidatas; características sugerem atributos; verbos indicam relacionamentos; palavras como “cada”, “pode”, “um” e “vários” revelam restrições. Essa leitura é apenas uma heurística. Nem todo substantivo merece uma entidade, e a decisão final depende do significado e das perguntas do sistema.

Tipo de entidade define; ocorrência individualiza

Uma entidade é algo distinguível sobre o qual o domínio precisa manter informação: uma pessoa, organização, objeto, evento ou conceito. Em uma formulação rigorosa, o diagrama descreve tipos de entidade, como Estudante e Trilha; Ana e a trilha Banco de Dados são ocorrências desses tipos.

Na prática, muitos materiais usam apenas “entidade” para o tipo representado no diagrama. O contexto costuma resolver a diferença, mas separá-los evita frases ambíguas:

Uma boa entidade possui identidade própria no domínio. Trilha faz sentido mesmo sem citar uma tela específica. Já TítuloAzul é apenas um valor ou detalhe de apresentação, não uma entidade do negócio.

Identificadores distinguem ocorrências

Um tipo de entidade precisa de um identificador capaz de distinguir suas ocorrências. Estudante pode possuir id_estudante; Trilha, id_trilha. Um identificador pode ser natural ao domínio, criado pelo sistema ou composto por mais de um atributo.

Nesta etapa conceitual, estamos afirmando a necessidade de identidade. A escolha de chaves primárias, tipos SQL e estratégias de geração pertence ao projeto lógico e físico, aprofundado nas próximas aulas.

Atributos descrevem entidades ou relacionamentos

Um atributo registra uma propriedade relevante. nome pode descrever um estudante; publicada_em, uma trilha; matriculada_em, uma matrícula. O atributo deve ter significado claro, conjunto de valores esperado e, quando necessário, obrigatoriedade e regras.

Algumas classificações ajudam a testar o desenho:

• simples: tratado como uma unidade no modelo, como titulo;
• composto: possui partes relevantes, como endereço dividido em logradouro, cidade e CEP;
• monovalorado: uma ocorrência possui no máximo um valor naquele contexto;
• multivalorado: pode haver vários valores, como diferentes meios de contato;
• derivado: pode ser calculado a partir de outros fatos, como percentual de progresso;
• armazenado: é mantido diretamente, como a data de conclusão;
• identificador: participa da distinção entre ocorrências.

Essas categorias dependem do requisito. nome_completo pode ser simples para uma etiqueta, mas inadequado se o sistema precisa tratar componentes separadamente. idade parece um atributo, porém deriva da data de nascimento e muda com o tempo; armazená-la isoladamente cria risco de divergência.

Um atributo multivalorado pode esconder outro conceito

Se um estudante possui vários telefones e cada telefone tem tipo, preferência, verificação e histórico, “telefones” já não é apenas uma lista de valores. Pode merecer um tipo de entidade próprio, relacionado ao estudante.

Relacionamentos expressam associações com significado

Um relacionamento associa ocorrências de tipos de entidade. Seu nome deve formar uma frase de negócio clara:

• Trilha organiza-se em Módulo;
• Estudante realiza Matrícula;
• Matrícula refere-se a Trilha;
• Estudante conclui Conteúdo.

“Tem” ou “relaciona-se com” pode ser genérico demais. Verbos específicos ajudam a descobrir direções, exceções e regras. Leia também no sentido inverso: “Módulo pertence a Trilha” pode revelar uma obrigatoriedade que “Trilha contém Módulo” deixou implícita.

Grau indica quantos tipos participam

Um relacionamento entre dois tipos é binário. Um relacionamento de um tipo consigo mesmo é recursivo ou unário. Por exemplo, um conteúdo pode ser pré-requisito de outro conteúdo; nomes de papéis como “pré-requisito” e “dependente” evitam confundir as duas pontas.

Relacionamentos ternários e de grau maior também existem. Imagine que um tutor recomende um conteúdo a um estudante em determinada trilha. A recomendação pode depender dos três participantes simultaneamente. Substituir automaticamente essa associação por três relacionamentos binários pode permitir combinações que nunca ocorreram juntas.

Use graus maiores somente quando a regra realmente depender da combinação. Muitas situações ficam mais claras como uma entidade que representa o evento ou acordo.

Cardinalidade combina mínimo e máximo

A cardinalidade declara quantas ocorrências de um tipo podem ou devem se associar a uma ocorrência do outro. É útil expressá-la como um intervalo mínimo..máximo:

• 0..1: nenhuma ou uma;
• 1..1: exatamente uma;
• 0..N: nenhuma, uma ou várias;
• 1..N: uma ou várias.

O máximo distingue relações um para um, um para muitos e muitos para muitos. O mínimo informa participação opcional ou obrigatória. Dizer apenas “um para muitos” perde metade da regra.

Faça a pergunta nos dois sentidos

Para Trilha e Módulo, pergunte:

1. para uma trilha, quantos módulos podem existir? 1..N, se a publicação exige ao menos um;
2. para um módulo, a quantas trilhas ele pode pertencer? 1..1, se não há compartilhamento.

Para Estudante e Trilha, um estudante pode estar em 0..N trilhas e uma trilha pode ter 0..N estudantes. Isso caracteriza máximo muitos dos dois lados. Se uma regra disser que toda trilha publicada precisa de ao menos um estudante, provavelmente há um problema: publicação e matrícula não precisam ocorrer juntas. O mínimo força a equipe a confrontar o ciclo de vida real.

Participação revela dependência de existência

Quando o mínimo é zero, a participação naquele relacionamento é opcional ou parcial. Quando o mínimo é um, é obrigatória ou total.

Um estudante pode existir antes de qualquer matrícula, portanto sua participação em matrícula pode ser opcional. Uma matrícula, porém, não faz sentido sem estudante e trilha: sua participação nessas associações é obrigatória.

Obrigatoriedade não é sinônimo de criação simultânea. Uma regra pode exigir que todo conteúdo publicado pertença a um módulo, mas permitir um rascunho ainda não posicionado. Nesse caso, talvez a cardinalidade dependa do estado. O modelo deve registrar a regra completa em texto ou separar conceitos quando necessário.

Relacionamentos podem possuir atributos

Considere Estudante matricula-se em Trilha. matriculada_em, situacao e origem não descrevem isoladamente o estudante nem a trilha. Descrevem a associação entre ambos.

Quando um relacionamento possui atributos, identidade própria, ciclo de vida ou participa de outros relacionamentos, ele costuma ser representado como uma entidade associativa. Assim surge Matrícula, ligada a exatamente um estudante e uma trilha.

Esse desenho transforma um muitos-para-muitos conceitual em duas associações um-para-muitos ao redor de um conceito significativo. Não é apenas um truque técnico para tabelas: matrícula é um fato do domínio, com estado e histórico próprios.

Entidades dependentes exigem contexto para existir ou ser identificadas

Uma entidade fraca ou dependente não possui identificação completa sem uma entidade proprietária, conforme a variante de modelagem adotada. Imagine uma Seção numerada apenas dentro de um conteúdo: “seção 2” não identifica uma seção globalmente; precisamos saber de qual conteúdo ela faz parte.

Nesse exemplo, o número é um identificador parcial, e a associação com Conteúdo completa a identidade. A seção também pode ser dependente de existência: removido o conteúdo, ela deixa de fazer sentido naquele domínio.

Nem toda entidade que se relaciona obrigatoriamente com outra é fraca. Se Módulo possui identificador global próprio, ele pode depender da trilha por regra de negócio sem depender dela para ser identificado. Identificação e existência são perguntas relacionadas, mas distintas.

Um modelo integrado torna as regras discutíveis

O diagrama abaixo reúne uma versão conceitual simplificada da plataforma. Ele não pretende registrar todos os metadados editoriais; mostra as decisões necessárias para organizar estudo e progresso.

Leia algumas regras representadas:

• um estudante pode realizar zero ou muitas matrículas; cada matrícula pertence a exatamente um estudante;
• uma trilha pode receber zero ou muitas matrículas; cada matrícula se refere a exatamente uma trilha;
• uma trilha é organizada em um ou mais módulos; cada módulo pertence a exatamente uma trilha;
• um módulo contém um ou mais conteúdos naquela versão simplificada; cada conteúdo aparece em exatamente um módulo;
• um estudante pode possuir zero ou muitas conclusões; cada conclusão identifica exatamente um estudante e um conteúdo.

A regra “cada conteúdo aparece em exatamente um módulo” é uma decisão, não uma verdade universal. Se o Guia Estudos quiser reutilizar uma aula em várias trilhas, o modelo precisará representar a participação do conteúdo em uma sequência como outro conceito, talvez com ordem e obrigatoriedade próprias.

Modelo conceitual não é esquema de tabelas

Um modelo ER procura preservar significado sem se comprometer cedo demais com detalhes de um SGBD. Nomes de tabelas, tipos SQL, chaves estrangeiras, índices e particionamento pertencem a etapas posteriores.

Há ferramentas que chamam de ERD qualquer diagrama de tabelas físicas. Esse uso é comum, mas mistura níveis. Para evitar confusão nesta trilha:

• conceitual: destaca conceitos e regras do domínio;
• lógico: adapta o desenho ao modelo de dados escolhido, ainda sem todos os detalhes do produto;
• físico: define objetos, tipos, restrições e otimizações de uma implementação concreta.

Na próxima etapa, estudaremos o modelo relacional. Depois haverá uma aula específica para transformar o modelo ER em relações, chaves e restrições. Não precisamos inserir chaves estrangeiras no desenho conceitual antes de compreender o que elas representarão.

Um processo prático de modelagem

1. Defina o escopo e o vocabulário

Declare qual processo ou decisão o modelo apoia. Crie um glossário: “trilha”, “módulo”, “conteúdo” e “matrícula” devem ter definições que a equipe reconheça.

2. Colete regras e exemplos

Registre frases, casos reais, exceções e estados. Pergunte o que pode existir sem outra coisa, o que se repete e o que muda ao longo do tempo.

3. Identifique tipos de entidade e ocorrências de teste

Proponha candidatos e teste com exemplos concretos. Se duas ocorrências não podem ser distinguidas, o identificador ainda está incompleto.

4. Adicione atributos relevantes

Inclua somente o necessário para compreender identidade e regras. Um diagrama conceitual sobrecarregado com todos os campos perde legibilidade.

5. Nomeie relacionamentos com verbos

Leia cada associação nos dois sentidos. Evite linhas sem semântica e registre papéis quando o mesmo tipo participa mais de uma vez.

6. Defina mínimo e máximo

Não aceite apenas 1:N. Pergunte se zero é permitido e em qual estado. Use exemplos que deveriam ser válidos e inválidos.

7. Encontre atributos de relacionamento e dependências

Datas, situações e quantidades podem revelar entidades associativas. Identificadores locais podem revelar entidades fracas.

8. Valide por cenários

Tente representar:

• um estudante sem matrícula;
• uma trilha recém-publicada;
• duas matrículas do mesmo estudante na mesma trilha;
• um conteúdo reutilizado em outra trilha;
• uma conclusão revogada ou refeita.

O modelo não precisa aceitar todos esses cenários, mas deve rejeitá-los ou permiti-los conscientemente.

Erros comuns

• copiar a tela: componentes visuais mudam e não definem o domínio;
• tratar valores como entidades: cor do card e percentual isolado não possuem necessariamente identidade própria;
• usar nomes genéricos nos relacionamentos: “tem” esconde o significado e dificulta a leitura inversa;
• registrar somente o máximo: 1:N não diz se a participação é opcional;
• adivinhar obrigatoriedade: mínimos devem vir de regras e estados reais;
• colocar atributo no lado errado: data da matrícula pertence à associação, não ao estudante nem à trilha;
• resolver muitos-para-muitos sem compreender o fato: uma entidade associativa deve representar um conceito, não apenas satisfazer uma ferramenta;
• confundir dependência com fraqueza: uma entidade pode ter participação obrigatória e ainda possuir identidade própria;
• misturar modelo conceitual e físico: tipos SQL e índices precoces desviam a discussão do significado;
• produzir um diagrama sem glossário: formas não substituem definições e regras textuais.

O que você deve guardar

O modelo ER transforma requisitos em entidades, atributos, relacionamentos e restrições. Tipos de entidade descrevem categorias; ocorrências representam indivíduos; identificadores distinguem ocorrências. Atributos registram propriedades relevantes, enquanto relacionamentos expressam associações com significado.

Cardinalidade deve combinar mínimo e máximo. O mínimo revela opcionalidade ou obrigatoriedade; o máximo diferencia um e muitos. Relacionamentos com atributos e ciclo de vida podem se tornar entidades associativas. Entidades fracas dependem de contexto para identidade ou existência, conforme a notação adotada.

A próxima aula iniciará o módulo de projeto relacional, mostrando como relações, tuplas, atributos e domínios representam fatos. Depois, veja o mapeamento completo do modelo ER para relações, chaves e restrições.

Referências

• Chen, Peter P. — The Entity-Relationship Model: Toward a Unified View of Data. ACM Transactions on Database Systems, 1976. Acesso em 29 ago. 2026.
• ACM, IEEE-CS e AAAI — CS2023: Data Management Core. Acesso em 29 ago. 2026.
• NIST — FIPS PUB 184: Integration Definition for Information Modeling (IDEF1X). Acesso em 29 ago. 2026.
• Oracle — Data Modeler Tutorial: Modeling for a Small Database. Acesso em 29 ago. 2026.
• IBM — What is an Entity Relationship Diagram?. Acesso em 29 ago. 2026.
• Mermaid — Entity Relationship Diagrams. Acesso em 29 ago. 2026.