Resumo TI Banco de Dados: Desnormalização Orientada a Desempenho

Do resumo sobre anomalias até o de preservação de dependências, a trilha inteira caminhou numa direção: eliminar redundância. Chegou a hora de virar essa lógica de cabeça para baixo. A desnormalização reintroduz redundância de propósito, aceitando o risco das anomalias já estudadas em troca de consultas mais rápidas — uma decisão de projeto, não um erro de quem “esqueceu” a teoria.

Neste resumo, você vai entender por que um esquema totalmente normalizado tem custo de leitura, conhecer as técnicas mais comuns de desnormalização, entender o preço que se paga por cada uma e saber em que cenários essa troca vale a pena.

🔄 O que é desnormalização

Desnormalizar é violar deliberadamente uma forma normal já alcançada, reintroduzindo redundância para evitar JOINs em consultas frequentes. Não é “não ter normalizado” — pressupõe que o esquema já passou pela normalização, e que alguém decidiu, de forma consciente e documentada, desfazer parte dela em troca de desempenho de leitura.

⏱️ Por que normalizar custa caro na leitura

Cada forma normal aplicada tende a dividir uma tabela em mais tabelas menores. Isso elimina redundância, mas qualquer consulta que precise reconstituir a informação original precisa fazer JOIN entre elas — e JOIN é, entre as operações relacionais, uma das mais caras computacionalmente, especialmente com tabelas grandes ou quando vários JOINs se encadeiam numa mesma consulta. Em sistemas com leitura muito mais frequente que escrita, esse custo se paga a cada consulta, muitas vezes por segundo.

🧰 Técnicas comuns de desnormalização

• Coluna redundante: copiar um atributo de uma tabela relacionada para evitar o JOIN — por exemplo, guardar o nome do cliente diretamente na tabela de pedidos, além de manter a referência ao cliente_id;
• Coluna derivada (calculada e armazenada): guardar o resultado de um cálculo em vez de recalculá-lo a cada consulta — por exemplo, um campo total_pedido na tabela de pedidos, em vez de somar os itens toda vez que o pedido é exibido;
• Tabela de resumo (pré-agregação): manter uma tabela separada só com totais já calculados — por exemplo, uma tabela de vendas diárias por produto, evitando agregar milhões de linhas de transação a cada relatório;
• Fusão de tabelas: reverter uma decomposição feita para 2FN ou 3FN quando, na prática, as duas tabelas são sempre consultadas juntas, nunca separadamente.

🔧 O preço: as mesmas anomalias voltam, em graus diferentes

Desnormalizar reintroduz, em graus diferentes, o mesmo risco de anomalias visto no início desta seção da trilha. Colunas redundantes e derivadas expõem sobretudo a anomalia de atualização — a cópia pode ficar dessincronizada do valor de origem: se o nome de um cliente muda, é preciso atualizar todos os pedidos que guardam essa cópia redundante, e esquecer um deles deixa o banco inconsistente. Já a fusão de tabelas pode reintroduzir as três anomalias por completo, recriando a mistura de entidades do exemplo Funcionario/Departamento visto anteriormente. Por isso, a desnormalização exige um mecanismo explícito de sincronização: triggers no banco, rotinas em lote (batch jobs) ou disciplina na camada de aplicação para manter as cópias redundantes atualizadas. Sem esse mecanismo, a desnormalização não é uma otimização — é um bug de consistência esperando para acontecer.

✅ Quando vale a pena

A desnormalização costuma valer a pena em cenários analíticos (OLAP), de leitura muito mais frequente que escrita: relatórios, painéis analíticos, data warehouses, APIs de alto tráfego com poucas atualizações. Em sistemas transacionais (OLTP), com escritas frequentes e exigência forte de consistência — como um sistema bancário processando transferências —, o custo de manter cópias redundantes sincronizadas costuma superar o ganho de leitura, e a normalização plena continua sendo a escolha mais segura.

⚠️ Pegadinhas comuns

• Desnormalização não é ausência de projeto: é uma decisão tomada depois de normalizar, com base em padrão de acesso real, nunca um atalho para pular a modelagem;
• Nem toda redundância é desnormalização: cache de aplicação, réplicas de leitura e índices não são desnormalização — a redundância aqui é especificamente dentro do próprio modelo relacional, em colunas ou tabelas;
• A banca pode pedir para você reconhecer quando NÃO desnormalizar: sistemas com escrita intensa e forte exigência de consistência (ex.: sistemas financeiros) são o cenário clássico onde desnormalizar é contraindicado;
• Toda desnormalização deveria vir acompanhada de um mecanismo de sincronização — uma questão que descreve colunas redundantes sem mencionar como elas são mantidas consistentes está descrevendo um risco, não uma boa prática.

🎯 Dica Final para a Prova

Ao ver um cenário com colunas ou tabelas redundantes na prova, primeiro identifique qual das quatro técnicas está em jogo (coluna redundante, coluna derivada, tabela de resumo ou fusão de tabelas). Depois, verifique se o enunciado é de leitura intensiva (a favor da desnormalização) ou escrita intensiva com exigência de consistência forte (contra).

✓ Desnormalizar é a técnica mais direta desse trade-off, mas está longe de ser a única ferramenta de desempenho disponível. O próximo resumo amplia a discussão para um framework mais completo de decisão entre normalização e performance, situando a desnormalização ao lado de outras estratégias.

📍Gostou do conteúdo? Deixe um comentário, compartilhe e continue acompanhando o Dicionário do Concurseiro para mais Resumos de TI – Banco de Dados. Aqui você encontra explicações claras, atualizadas e com foco total no que cai em prova!

👉 Leia também no Dicionário do Concurseiro: Resumo TI Banco de Dados: Trade-offs entre Normalização e Performance

📘 Desnormalizar é trocar consistência automática por velocidade de leitura — uma troca válida, desde que seja uma decisão documentada e sincronizada por um mecanismo explícito. Continue estudando!