O Que São Entidades Em Um Mapa Conceitual Lógico

O que são entidades e por que elas quebram modelagens

Entidades são os objetos ou conceitos do domínio que você decide preservar como elementos distintos em um modelo. Em um mapa conceitual lógico, isso significa classes abstratas de dados com identidade própria, atributos que as descrevem e relações com outras entidades. Nada mais, nada menos. A confusão começa quando as pessoas tratam entidades como "coisas que existem" de forma vaga. Elas precisam ter identificação unívoca. Se não há forma de distinguir uma instância da outra, você não tem uma entidade — tem um atributo mal disposto ou um conceito que precisa ser decomposto.

o que são entidades em um mapa conceitual lógico

No contexto de modelagem conceitual lógica, entidades são representações abstratas de fenômenos do domínio que o sistema precisa registrar e relacionar. Elas ocupam o nível intermediário entre a visão puramente textual dos requisitos e a estrutura física final. Cada entidade mapeia para uma tabela no modelo relacional posterior, cada atributo vira coluna, e cada relacionamento vira chave estrangeira ou tabela de junção. O mapa conceitual lógico é exatamente esse contrato de responsabilidade antes da implementação. Aqui vai algo que raramente aparece em material introdutório: a maioria das pessoas não sabe onde traçar a linha entre entidade e atributo porque nunca parou para questionar a granularidade. A regra prática que eu uso é simples. Se um dado precisa de suas próprias características, histórico ou se pode se relacionar com múltiplas outras coisas no modelo, ele é entidade. Se existe apenas para descrever algo maior e não faz sentido, é atributo. Eu tenho um caso concreto que ilustra isso. Montava um modelo para um sistema de gestão de contratos de manutenção predial. No início, tratei "equipe de manutenção" como um atributo da entidade "contrato". O problema apareceu quando precisei rastrear quais técnicos haviam estado em cada atendimento e com que frequência. Aquele atributo precisava de histórico, qualificação, disponibilidade. Transformei em entidade própria chamada "tecnico" e gerei um relacionamento N para M com "contrato" via uma entidade associativa chamada "atendimento". O modelo ganhou complexidade, mas a informação que eu realmente precisava passou a existir no diagrama.

Outro erro comum é criar entidades que só existem para evitar campos repetidos. Isso se chama entidade fantasma. Eu já vi modelos onde "cidade" virava entidade só porque "estado" também existia. O resultado era um relacionamento binário desnecessário que só servia para segurar um código estrangeiro. Cidades não precisam de entidade própria nesse contexto. Elas podem viver como atributo composto ou como tabela de códigos normalizada se o volume realmente justificar. A decisão deve vir da frequência de consulta, não do medo de redundância.

Como identificar entidades na prática

O processo mais direto é ler os requisitos e extrair substantivos. Não o último passo, mas um ponto de partida útil. Depois vem a filtragem. Cada substantivo precisa passar por três testes: identificação, comportamento relacional e necessidade de persistência. Identificação significa que existe um campo ou conjunto de campos que torna cada instância única. Sem isso, a entidade não funciona. Comportamento relacional exige que o conceito se conecte a outros elementos do domínio de forma significativa. Necessidade de persistência quer dizer que o dado precisa sobreviver além de uma única operação do sistema. Quando dois ou mais substantivos parecem competindo pela mesma entidade, a solução geralmente é decomposição. "Cliente pessoa fisica" e "cliente pessoa juridica" quase sempre pedem para virar subclasses com atributos diferentes, não uma entidade monolítica cheios de campos nulos. Nulos no modelo conceitual lógico são sinal de que algo ainda não foi refinado.

Entidades fracas merecem atenção separada. Elas existem porque sua identidade depende de outra entidade. Um "detalhe de nota fiscal" não se sustenta sozinho sem a "nota fiscal". No mapa conceitual lógico, entidades fracas são desenhadas com dupla borda e seu relacionamento de identidade recebe seta especial. No modelo relacional, elas viram tabela com chave primária composta pela chave da entidade forte mais seus próprios identificadores. Não trate entidades fracas como entidades normais com campos adicionais. A diferença de identidade afeta diretamente como e joins vão se comportar depois.

Relacionamentos e a parte que mais trava

Entidades sem relacionamentos são apenas listas. O valor do mapa conceitual lógico está nos vínculos. Cada relacionamento tem cardinalidade, opcionalidade e, em alguns casos, uma restrição de negócio que dita como os dados são inseridos e consultados. Cardinalidade um para muitos é o padrão. Isso não significa que tudo seja um para muitos. Relacionamento muitos para muitos existe e precisa ser representado explicitamente no modelo conceitual lógico. Ele vira entidade associativa na fase física. Ignorar isso gera chaves compostas mal distribuídas ou dados duplicados. Opcionalidade é onde a maioria dos modelos erra. Um relacionamento obrigatório versus opcional muda completamente como as constraints são aplicadas no banco. Se um pedido pode existir sem cliente identificado em certos cenários de venda, marcar o relacionamento como obrigatório vai gerar inserts falhos. Eu resolvi isso tratando "cliente" como opcional no primeiro estágio e adicionando uma regra de negócio que obrigar a vinculação antes da faturamento, não no momento da criação do pedido. O modelo conceitual reflecte a flexibilidade real do processo.

Atributos também merecem classificação. Chave primária, chave estrangeira, atributo simples, composto, multivalorado e derivado. Atributos multivalorados, como "telefones" de uma pessoa, precisam sair da entidade e virar tabela separada no modelo lógico. Atributos derivados, como "idade" calculada a partir de "data de nascimento", podem permanecer no conceitual como indicação, mas não devem ser persistidos no físico. Manter dados deriváveis armazena informação duas vezes e quebra a consistência na primeira atualização esquecida.

Erros que custam refatoração

O erro mais caro que eu vi acontecer foi tratar "status" como entidade. Sistema tinha "status_pedido" como classe própria com relacionamento para "pedido". O resultado era uma tabela de status com dez linhas fixas, constraints de foreign key em toda parte e uma manutenção insuportável quando Precisaram adicionar um novo estado ao fluxo. Status não é entidade. É um atributo enumerado com restrições de domínio. Eu redefini como enum ou tabela de lookup simples, removi o relacionamento e o modelo ficou mais legível e mais rápido em consultas. Outro problema recorrente é overengenharia de generalização. Herança não é solução para tudo. Subtipos fazem sentido quando há atributos específicos ou relacionamentos exclusivos por categoria. Se todas as subclasses compartilham os mesmos campos e relações, você só criou trabalho extra. A generalização no mapa conceitual lógico deve refletir diferença real no domínio, não vontade de parecer sofisticado. Há ainda o caso das entidades que existem só porque o requisito pedia. "Registro de auditoria" virou entidade em três projetos que participei. Em todos eles, a solução correta era uma tabela de log genérica com polimorfismo por tipo de operação. Entidade própria generica demais é entidade que ninguém mantém.

Limitações do modelo conceitual lógico

Ele não resolve performance. O mapa conceitual lógico é abstrato. Indexação, partição, cache, sharding não aparecem nele. Quem espera que um bom diagrama elimine queries lentas está enganado. Também não captura regras de negócio dinâmicas. Regras que mudam conforme o usuário, região ou período precisam de documentação complementar. O modelo mostra estrutura, não comportamento. Finalmente, a tradução para o modelo físico nem sempre é trivial. Entidades com hierarquias complexas de herança viram tabelas com JOINs pesados ou strategies de table per subclass que nem todo DBA gosta. Às vezes a solução mais pragmática é abandonar a generalização no conceitual e tratar diferenças como colunas discriminadoras no físico. Isso depende da equipe e do DBMS. Não existe resposta única.

Quando confiar e quando mudar de abordagem

Mapa conceitual lógico funciona bem para sistemas com domínio estável e bem compreendido. Quando o escopo muda constantemente, como em produtos em estágio inicial com hipóteses não validadas, gastar tempo refinando entidades pode ser perda de tempo. Nesses casos, um modelo mais leve ou até mesmo um protótipo funcional entrega valor mais rápido. Se o time não tem padrão definido de notação, escolham UML ou Chen e sigam até o fim. Misturar estilos no mesmo diagrama gera ambiguidade que só aparece na hora da implementação. Preferência pessoal não importa. Consistência importa. O que resta é prática. Desenhe, questione cada entidade, teste contra casos reais, revise quando algo não encaixar. O modelo é documento vivo, não entregável final. A qualidade dele se mede por quantas surpresas ele evitou durante a codificação, não por quantas linhas tem no diagrama.