Entidades na Modelagem de Dados: identificação, critérios e tipos

O que é uma entidade

Em modelagem de dados, entidade é uma “coisa” do negócio sobre a qual precisamos registrar informações e recuperá-las depois. Em geral, uma entidade representa um conjunto de ocorrências do mesmo tipo (por exemplo, vários Clientes), e cada ocorrência pode ser distinguida das demais por algum identificador (por exemplo, CPF ou um código interno).

Uma forma prática de pensar: se o sistema precisa guardar e consultar dados sobre algo ao longo do tempo, esse “algo” é um forte candidato a entidade.

Critérios para decidir se um termo vira entidade

Nem todo substantivo do requisito vira entidade. Use os critérios abaixo como checklist. Quanto mais “sim”, mais provável que seja entidade.

1) Persistência (precisa ser armazenado?)

Pergunta: “Isso precisa existir no banco e ser consultado depois?”

• Sim: Cliente, Pedido, Produto, Contrato.
• Não: “Total do pedido” (pode ser calculado), “idade” (derivada da data de nascimento), “status exibido na tela” (pode ser regra/derivação).

2) Identidade (consigo distinguir uma ocorrência de outra?)

Pergunta: “Consigo apontar um exemplar específico?”

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• Sim: um Cliente específico, um Pedido específico.
• Cuidado: “Cor” ou “Tamanho” podem não ter identidade própria no contexto (podem ser domínio/atributo), a menos que o negócio gerencie isso como catálogo com regras e histórico.

3) Ciclo de vida (nasce, muda, termina?)

Pergunta: “Isso tem estados e eventos ao longo do tempo?”

• Sim: Assinatura (ativa, suspensa, cancelada), Entrega (em separação, em rota, entregue).
• Não necessariamente: “CEP” (valor), “UF” (valor de domínio).

4) Relevância de negócio (há regras, relatórios, auditoria?)

Pergunta: “O negócio toma decisões com base nisso, audita, reporta, integra?”

• Sim: Categoria de Produto pode virar entidade se houver gestão (ativar/desativar, hierarquia, responsáveis, integrações).
• Não: “Tipo de pagamento” pode ser apenas um conjunto fixo de valores (atributo) se não houver gestão/histórico.

Passo a passo prático para identificar entidades

Passo 1 — Liste os candidatos

Extraia termos que parecem “coisas” do negócio (normalmente substantivos): Cliente, Pedido, Item, Pagamento, Endereço, etc.

Passo 2 — Aplique o checklist (persistência, identidade, ciclo de vida, relevância)

Para cada termo, responda às 4 perguntas. Se falhar em persistência e identidade, dificilmente é entidade (pode ser atributo, valor de domínio ou derivação).

Passo 3 — Determine o tipo de entidade

Classifique como forte, fraca/dependente, associativa ou derivada (quando fizer sentido no seu método).

Passo 4 — Esboce identificação e dependências

Defina como cada ocorrência será identificada (chave natural ou substituta) e se depende de outra entidade para existir/ser identificada.

Passo 5 — Valide com perguntas de negócio

• “Precisamos cadastrar isso separadamente?”
• “Isso aparece em relatórios?”
• “Pode existir sem outra coisa?”
• “Pode mudar ao longo do tempo?”

Tipos de entidades

Entidade forte (independente)

É identificada por uma chave própria e pode existir independentemente de outras entidades.

• Exemplos: Cliente, Produto, Loja, Funcionário.
• Identificação: CPF, matrícula, SKU, ou um ID interno.

CLIENTE(id_cliente, cpf, nome, data_nascimento, email)

Entidade fraca/dependente

Não possui identificação completa sem se apoiar em uma entidade “dona” (identificadora). Normalmente, sua chave inclui a chave da entidade forte + um discriminador (número sequencial, código dentro do contexto do dono).

• Exemplos: Dependente de Funcionário, Parcela de Fatura, Item de Pedido (em muitos modelos), Endereço “do Cliente” quando não é global.

Exemplo (Dependente): um dependente é identificado dentro do contexto de um funcionário.

FUNCIONARIO(id_funcionario, nome, ...)

DEPENDENTE(id_funcionario, seq_dependente, nome, parentesco, data_nascimento)

Nesse caso, (id_funcionario, seq_dependente) identifica unicamente um dependente.

Entidade associativa (para relacionamentos N:N com dados)

Surge quando há um relacionamento muitos-para-muitos e precisamos registrar atributos do relacionamento. Em vez de tentar “colocar lista” em um lado, criamos uma entidade que representa a associação.

• Exemplo: Aluno se matricula em Turma e a matrícula tem data, status, nota.

ALUNO(id_aluno, nome, ...)

TURMA(id_turma, codigo, periodo, ...)

MATRICULA(id_aluno, id_turma, data_matricula, status, nota_final)

MATRICULA é associativa porque representa a ligação entre ALUNO e TURMA e guarda dados próprios.

Entidades derivadas e conceitos derivados

“Derivado” significa que pode ser obtido a partir de outros dados e regras. Em modelagem, isso costuma aparecer como:

• Atributo derivado: não precisa ser armazenado (ex.: idade = hoje − data_nascimento).
• Entidade derivada/visão: um conjunto de dados que pode ser montado por consulta (ex.: “Saldo por Cliente” calculado a partir de lançamentos).

Regra prática: se for derivado, só persista se houver motivo claro (performance, auditoria, congelamento histórico, integrações). Caso contrário, mantenha como cálculo/visão.

Armadilhas comuns (e como evitar)

1) Confundir entidade com atributo

Erro típico: criar entidade para algo que é apenas uma característica simples.

Pergunta de validação: “Eu cadastraria isso separadamente e referenciaria de vários lugares?” Se não, tende a ser atributo.

2) Criar entidades para valores de domínio simples

Erro típico: transformar listas pequenas e estáveis em entidades sem necessidade (ex.: Sexo, Sim/Não, UF) apenas porque “parece organizado”.

• Quando NÃO criar entidade: valores fixos, sem gestão, sem histórico, sem integrações.
• Quando criar entidade (catálogo): quando o domínio é gerenciado (ativar/desativar, descrições, códigos externos, traduções, hierarquias, auditoria).

Exemplo: “Status do pedido” pode ser domínio (atributo) se for fixo e controlado por regra; pode virar entidade/tabela de domínio se houver parametrização por cliente, integrações e auditoria.

3) Misturar processos com dados

Erro típico: tratar ações como entidades: “Cadastro”, “Aprovação”, “Envio”, “Cancelamento”.

• Processos geralmente viram: eventos, estados, registros de log, ou atributos de status/data.
• Dados são as entidades: Pedido, Pagamento, Entrega.

Como separar: se o termo responde “o que é?” (Pedido), tende a ser entidade; se responde “o que acontece?” (Aprovar), tende a ser processo/regra/evento.

4) Entidade “genérica demais”

Ex.: criar uma entidade PESSOA sem clareza se o negócio precisa diferenciar Cliente, Fornecedor, Funcionário, ou se são papéis distintos. Isso pode ser válido, mas só quando os requisitos indicam compartilhamento real de dados e regras. Caso contrário, pode aumentar complexidade e ambiguidade.

Exercícios guiados: identificar entidades a partir de mini-requisitos

Exercício 1 — Loja online (básico)

Mini-requisito: “O sistema registra clientes com nome, email e telefone. Clientes fazem pedidos. Cada pedido possui data e status. Um pedido contém itens, e cada item informa o produto e a quantidade. O total do pedido deve ser exibido.”

Guia:

• Liste candidatos: Cliente, Pedido, Item, Produto, Total, Status.
• Aplique critérios:
• Cliente: persiste? sim. identidade? sim. ciclo de vida? sim. relevância? sim → Entidade forte.
• Pedido: persiste? sim. identidade? sim. ciclo de vida? sim → Entidade forte.
• Produto: persiste? sim. identidade? sim → Entidade forte.
• Item: existe sem Pedido? não. identificado fora do Pedido? geralmente não → Entidade dependente (ou associativa entre Pedido e Produto, dependendo do modelo).
• Total do pedido: derivado de itens e preços → atributo derivado (persistir só se houver motivo).
• Status: domínio/atributo (ou catálogo se parametrizável) → atributo na primeira versão.

Resposta esperada (uma possibilidade):

CLIENTE(id_cliente, nome, email, telefone)

PEDIDO(id_pedido, id_cliente, data_pedido, status)

PRODUTO(id_produto, nome, preco_atual)

ITEM_PEDIDO(id_pedido, seq_item, id_produto, quantidade, preco_unitario)

Observação: preco_unitario no item é comum para congelar o preço no momento da compra (não é derivado do preço atual).

Exercício 2 — Clínica (atenção a processos)

Mini-requisito: “Pacientes agendam consultas com médicos. Uma consulta tem data/hora e pode ser cancelada. O sistema registra o motivo do cancelamento e quem cancelou (paciente ou clínica). Após a consulta, pode haver prescrição de medicamentos.”

Guia:

• Candidatos: Paciente, Consulta, Médico, Cancelamento, Motivo, Prescrição, Medicamento.
• Paciente e Médico: entidades fortes.
• Consulta: entidade forte (tem identidade e ciclo de vida).
• Cancelamento: cuidado: é processo/evento. Pergunte: precisa ser registrado como ocorrência própria? Aqui há motivo e autor do cancelamento. Pode ser:
• Opção A: atributos em Consulta (status, data_cancelamento, motivo_cancelamento, cancelado_por).
• Opção B: entidade CANCELAMENTO_CONSULTA se houver múltiplos cancelamentos/reagendamentos, auditoria detalhada, histórico de tentativas.
• Prescrição: se precisa ser consultada depois e tem itens, vira entidade (forte ou dependente da consulta).
• Medicamento: entidade forte (catálogo) se for gerenciado; caso contrário, pode ser texto na prescrição (menos recomendado).

Exercício 3 — RH (entidade fraca/dependente)

Mini-requisito: “Funcionários podem cadastrar dependentes para plano de saúde. Cada dependente tem nome, data de nascimento e grau de parentesco. O dependente não existe no sistema sem um funcionário.”

Guia:

• Candidatos: Funcionário, Dependente, Plano de saúde, Parentesco.
• Funcionário: entidade forte.
• Dependente: persiste? sim. identidade própria global? não; depende do funcionário. ciclo de vida? sim → entidade fraca/dependente.
• Parentesco: geralmente domínio (atributo) com valores como “filho”, “cônjuge”. Vira catálogo se houver gestão/integração.

Resposta esperada:

FUNCIONARIO(id_funcionario, nome, ...)

DEPENDENTE(id_funcionario, seq_dependente, nome, data_nascimento, parentesco)

Exercício 4 — Marketplace (entidade associativa)

Mini-requisito: “Vendedores anunciam produtos. Um mesmo produto pode ser anunciado por vários vendedores com preços e prazos diferentes. O sistema deve mostrar o histórico de alterações de preço por anúncio.”

Guia:

• Candidatos: Vendedor, Produto, Anúncio, Preço, Prazo, Histórico.
• Vendedor e Produto: entidades fortes.
• Anúncio: representa a associação Vendedor–Produto com atributos próprios (preço, prazo) → entidade associativa.
• Histórico de preço: persiste e tem ciclo de vida (várias alterações) → entidade dependente do Anúncio (ou entidade forte se houver regras próprias e reuso, o que é menos comum).

Resposta esperada (uma possibilidade):

VENDEDOR(id_vendedor, nome, ...)

PRODUTO(id_produto, nome, ...)

ANUNCIO(id_anuncio, id_vendedor, id_produto, prazo_envio_dias, ativo)

HIST_PRECO_ANUNCIO(id_anuncio, data_inicio_vigencia, preco)

Checklist rápido (para usar durante a modelagem)

• Se não precisa persistir, provavelmente não é entidade.
• Se não tem identidade distinguível, provavelmente não é entidade (ou é dependente).
• Se depende de outra para existir/ser identificada, considere entidade fraca/dependente.
• Se representa N:N com atributos próprios, considere entidade associativa.
• Se é cálculo, trate como derivado (atributo/visão) e só persista com justificativa.
• Se é ação/verbo, provavelmente é processo/evento, não entidade.