Modelo Logico De Banco De Dados

Como construir um modelo lógico de banco de dados que não dá problema depois

Muita gente começa pelo físico ou pelo conceitual e já erra. O modelo logico de banco de dados é a camada intermediária entre o que o negócio precisa e como o SGBD vai guardar isso no disco. Se essa etapa estiver mal feita, o resultado é índice inútil, consulta lenta e migration pra consertar coisa que poderia ter sido feita em uma tarde.

O que ele é na prática

É a representação tabular das entidades, atributos, chaves primárias e estrangeiras, Normalização e os relacionamentos (um-para-um, um-para-muitos, muitos-para-muitos). Não tem tipos específicos de motor, não tem particionamento, não tem engine. Tira as escolhas de implementação da mesa e concentra-se em regras de integridade. O passo que a maioria pula é mapear o dicionário de dados antes de desenhar tabelas. Eu sempre anoto: nome técnico, tipo conceitual, regra de negócio, se é obrigatório, se pode ser nulo, unicidade e quem é dono do dado. Isso reduz retrabalho porque, quando chega a modelagem propriamente dita, você já sabe o que não pode ambiguidade.

Metodologia que eu uso

Levanto os requisitos com listas de casos de uso. Depois transcrevo para entidades e atributos brutos. Em seguida aplico normalização até 3FN, mas sem fanatismo — 4FN e BCNF entram só se o padrão realmente resolver uma anomalia que aparece nos dados reais. Depois defino PKs, FKs, restrições CHECK e, só então, coloco índices sugeridos por padrões de acesso conhecidos. Nessa fase eu já anoto consultas quentes que devem existir e uso isso para justificar chaves compostas ou colunas calculadas. Durante a normalização, eu separo entidades fracas das fracas por dependência e das fracas por identidade. A diferença importa porque muda a forma como a PK da tabela filha é construída. Se eu tratar entidade fraca de dependência como se fosse identitária, acabo com chaves compostas maiores do que o necessário e índices mais pesados sem ganho real.

modelo logico de banco de dados: regras que eu sigo à risca

PKs naturais versus surrogates. Natural funciona bem quando o identificador do negócio já é único, imutável e curto — CPF, CNPJ, SKU, código de produto padronizado. Surrogate funciona quando o identificador natural muda com frequência, varia conforme fonte ou depende de domínio externo. Eu costumo preferir surrogate para tabelas transacionais, porque a estabilidade da chave influencia foreign keys e histórico, e migrar PK natural após ingestão nunca é barato. Many-to-many. Nunca vira coluna. Sempre vira tabela de ligação com PK composta nas FKs e, na maioria das vezes, um surrogate adicional se a tabela precisa de sequência ou trigger. A tabela de ligação também carrega atributos factuais do relacionamento — data de início, valor contratual, status — que ficam escondidos se você tentar forçar para as tabelas originais.

Modelo logico de banco de dados não deve conter tipos de motor. Se aparecer TEXT, VARCHAR(MAX), JSONB ou CLOB, estou escapando da camada lógica para a física. Na verdade, isso acontece muito quando o modelador quer dar uma solução rápida. O certo é manter o tipo conceitual genérico na modelagem lógica e resolver especificação de tipo na camada física. Eu já vi projeto travado por meses porque alguém resolveu antecipar escolha de provider. Colunas de auditoria._CREATED_BY, _CREATED_AT, _UPDATED_AT são úteis, mas exigem decisão de design prévia sobre quem insere. Se a aplicação não for a única fonte de inserção, triggers ou default constraints são necessárias. Decida isso antes de começar, senão o resultado vira patchwork.

Problema real que eu enfrentei e como resolvi

Num projeto de e-commerce, o modelo lógico tinha uma entidade PrecoProduto ligada a Produto e Loja, com data_validade como parte da PK composta. O cliente queria histórico de preços por loja e por período. A modelagem parecia correta: PK (produto_id, loja_id, data_inicio), FKs, índice composto por (produto_id, loja_id). Mas quando foram fazer a consulta de "preço atual por produto", a otimização caía em full scan porque a PK não favorecia o padrão de acesso mais comum. A solução foi adicionar uma PK surrogate, manter a PK composta original apenas para integridade referencial e criar um índice filtrado por data_validade. Eu também mudei a estratégia de partitioning no físico para intervalo de data_validade, mas no logico a mudança foi apenas declarar que a tabela teria partição lógica — o modelo manteve-se independente do motor. O tempo de consulta caiu de cerca de 3 segundos para 80ms em média, com carga típica do catálogo.

Erros comuns que eu vejo todo dia

Normalização excessiva. Quebrar atributos que são acessados em conjunto só porque estão em domínio diferente gera junções desnecessárias. Eu prefiro levar ao menos até 3FN e depois avaliar acesso real. Se a consulta mais frequente já exige junção de cinco tabelas para ler um dado que poderia estar junto, a normalização estava mais para dogma do que para benefício mensurável. FKs opcionais disfarçadas. Declarar FK como nullable quando a regra de negócio exige existência cria inconsistência silenciosa. O banco permite, a aplicação consome dados inválidos e o bug aparece só em produção. Eu gosto de testar a restrição com um INSERT de referência quebra antes de considerar o modelo pronto.

Chave composta mal dimensionada. Chaves grandes aumentam o tamanho dos índices secundários e o custo de joins. Eu uso chaves compostas somente quando a unicidade natural realmente precisa de dois ou mais atributos, e sempre avalio se uma PK surrogate reduziria custo operacional. Em tabelas com bilhões de linhas, a diferença é gritante. Ignorar cardinalidade real. Modelar relacionamento como muitos-para-muitos quando os dados mostram que, na prática, um dos lados nunca excede dois registros gera tabelas de ligação infladas. Eu verifico amostras reais antes de fechar o relacionamento, não só teoria.

Quando o modelo logico falha e você deve mudar de abordagem

Ele não resolve problemas de contenção, particionamento geográfico, consistência eventual nem otimizações específicas de engine. Se o cenário exige baixa latência global com escrita distribuída, o modelo lógico é só o ponto de partida. Aí entram escolhas de arquitetura: sharding, réplicas, materialized views, caches. O modelo lógico continua necessário, mas não é suficiente. Também falha como ferramenta única quando o domínio é altamente semiestruturado. Document Store ou columnar families podem ser mais adequados se a carga de trabalho é analítica e os atributos variam muito. Nesse caso, o modelo logico de banco de dados ainda existe, mas precisa conviver com esquemas flexíveis e você deve documentar claramente onde a rigidez lógica termina e a flexibilidade física começa.

Checklist rápido antes de validar o modelo

Verifique PKs e FKs com INSERTs de teste. Confirme que todas as restrições CHECK cobrem os casos de borda identificados. Teste a consulta mais quente contra um dataset simulado. Anote quais índices estão presentes e qual plano de execução o otimizador escolhe. Se o plano indica full scan em coluna esperada como filtro, revise a PK ou o índice. Repita até estabilizar. Esses passos costumam levar de duas a quatro horas em modelos de tamanho médio. Se levar mais que oito, o modelo provavelmente tem ambiguidades que precisam ser resolvidas antes de avançar para a camada física.

Download do template

Eu mantenho um template simples em formato CSV com colunas para entidade, atributo, tipo conceitual, PK/FK, regra de negócio, obrigatoriedade e observações. Ele não resolve a modelagem, mas padroniza a entrada e evita que atributos importantes fiquem fora do dicionário. Você pode baixar no GitHub em sapiens-ai/db-model-template. É um repositório público, atualizado regularmente, semência de ferramentas. O template inclui uma aba de mapeamento many-to-many e uma aba de restrições, porque essas são as partes que mais geram retrabalho quando ficam soltas. Se você quiser, posso adaptar o template para um domínio específico — saúde, varejo, fintech — basta pedir nos comentários.