Avançar para o conteúdo

Modelos de Dados: Normalização e Desnormalização

A definição do modelo de um banco de dados é uma das decisões mais importantes a se considerar. Conhecer os seus dados também é entender sobre modelos de dados.

Escolher entre modelos de dados normalizados ou desnormalizados depende das necessidades específicas do sistema — seja ele projetado para processamento transacional (OLTP) ou analítico (OLAP).

Neste post, exploraremos os modelos normalizados e desnormalizados, as principais diferenças entre eles, suas respectivas vantagens e desvantagens e como desnormalizar uma tabela.

Conheça os bancos de dados mais populares

Importância da escolha do Modelo de Dados

A escolha entre um modelo normalizado e um desnormalizado depende das necessidades específicas do seu sistema.

Compreender as compensações entre normalização e desnormalização é crucial para o design de bancos de dados.

A escolha do modelo vai ajudar a garantir que os objetivos do empreendimento sejam atingidos e que os dados sejam utilizados da maneira mais eficiente e com o menor custo.

Se o seu objetivo é garantir a integridade dos dados e o armazenamento eficiente, um modelo normalizado é a melhor opção.

No entanto, se o seu foco é o desempenho de consultas e relatórios, especialmente em cenários de data warehouse ou business intelligence, a desnormalização pode acelerar significativamente a recuperação de dados, mas com o custo da redundância.

Como criar testes para garantir a Qualidade de Dados




O que é um Modelo de Dados Normalizado?

Um modelo de dados normalizado é uma estrutura de banco de dados na qual os dados são organizados para reduzir a redundância e melhorar a integridade dos dados.

O principal objetivo da normalização é eliminar a redundância de dados, que pode levar a inconsistências e anomalias.

Esse tipo de modelo de dados segue regras de normalização (formas normais) para garantir que cada informação seja armazenada no local mais apropriado.

Em um banco de dados normalizado, os dados relacionados são divididos em várias tabelas, e os relacionamentos entre as tabelas são estabelecidos usando chaves estrangeiras.

Como otimizar a performance de query em banco de dados

Processo de Normalização

  • 1ª Forma Normal (1NF): Garante que cada coluna contenha valores atômicos (indivisíveis) e que cada linha tenha um identificador único.
  • 2ª Forma Normal (2NF): Remove dependências parciais, garantindo que cada atributo não-chave seja totalmente dependente da chave primária.
  • 3ª Forma Normal (3NF): Elimina dependências transitivas. Os atributos não-chave devem depender apenas da chave primária e não de outros atributos não-chave.
  • Leia mais sobre Formas Normais aqui.

O que é um Modelo de Dados Desnormalizado?

Um modelo de dados desnormalizado envolve a combinação de dados que poderiam ser divididos várias tabelas em uma única tabela, resultando em dados redundantes.

Isso geralmente é feito para melhorar o desempenho das consultas, especialmente em ambientes como data warehouse ou business intelligence, onde consultas complexas precisam ser executadas em grandes conjuntos de dados.

Dessa maneira, não é preciso utilizar joins e combinações de tabelas.

Em um banco de dados desnormalizado, os dados podem ser duplicados em várias linhas para evitar a necessidade de múltiplas junções, o que pode levar a um desempenho de leitura mais rápido, mas com o custo de redundância de dados e potencial inconsistência.

Conheça melhores práticas para código SQL




Principais Diferenças entre Modelo de Dados Normalizado e Desnormalizado

CaracterísticaModelo NormalizadoModelo Desnormalizado
RedundânciaMínima redundância: dados estão armazenados na forma mais atômicaAlta redundância: dados se repetem entre as tabelas para evitar a necessidade de joins.
IntegridadeAlta integridade de dados e consistência devido a redução de redundância. Os dados estão definidos em um único local, portanto, há maior segurança quando são atualizados.Menor integridade de dados devido à maior possibilidade de inconsistência quando algum registro é atualizado.
Performance de QueryA query é mais lenta devido a maior necessidade de joins.Como todas as informações estão na mesma tabela, para cada registo, a query é feita mais rápida.
Performance de Gravação/EscritaAs operações de gravação ou escrita de dados são mais rápidas, uma vez que os resgistros aparecem apenas uma vez.As operações de gravação ou escrita de dados são mais lentas pois há duplicação de dados e é necessário atualizar mais registros.
Espaço de ArmazenamentoMenos espaço de armazenamento necessário.Mais espaço de armazenamento necessário devido à redundância.
ManutençãoManutenção simplificada devido a menor redundância.Manutenção dificultada devido ao maior potencial de anomalias durante atualizações.

Características de Modelos Normalizados

Vantagens de Modelos de Dados Normalizados:

  • Menor risco de anomalias – Evita erros em inserções, atualizações e deleções.
  • Organização lógica – Estrutura mais clara e lógica.
  • Flexibilidade para expansão – Mais fácil adicionar novos relacionamentos.
  • Consulta modular – Mais controle sobre o que está sendo consultado.
  • Segurança por tabela – Pode controlar melhor o acesso a cada pedaço de dado.
  • Redução de redundância – Menos dados duplicados.
  • Melhor consistência – Dados mais coerentes entre tabelas.
  • Melhor integridade – Mais fácil manter integridade referencial.
  • Economia de espaço – Armazena menos dados repetidos.
  • Facilidade de manutenção – Atualizações são feitas em menos lugares.

Desvantagens da Normalização de Modelos de Dados:

  • Consultas mais lentas e complexas: Consultas que exigem dados de várias tabelas podem envolver junções complexas, o que pode reduzir o desempenho, especialmente com conjuntos de dados grandes.
  • Design mais complexo e menos intuitivo: Bancos de dados normalizados podem ser mais desafiadores de projetar e manter, pois os relacionamentos entre as tabelas devem ser cuidadosamente planejados.
  • Mais acessos ao armazenamento: Como os dados estão distribuídos em várias tabelas, a busca dos dados requer vários acessos ao banco de dados, o que pode aumentar o tempo de recuperação.
  • Mais difícil para iniciantes – Estrutura pode parecer confusa no início.
  • Desempenho inferior em BI e sistemas OLAP – Ferramentas de análise e modelos analíticos preferem dados prontos.
  • Mais tabelas para gerenciar – Aumenta a complexidade do banco.
  • Latência nas consultas – Leitura de dados fica mais lenta devido às junções e número de tabelas.




Características de Modelos Desnormalizados

Vantagens da Desnormalização de Modelos de Dados:

  • Desempenho de Consultas Mais Rápido: A desnormalização pode acelerar operações com alto consumo de leitura, reduzindo a necessidade de joins. Isso é especialmente benéfico em data warehouse ou análises, onde as consultas tendem a ser complexas e envolvem grandes conjuntos de dados.
  • Consultas Simplificadas: Como os dados são armazenados juntos em uma ou menos tabelas, as consultas se tornam mais simples de escrever e executar.
  • Otimizado para Relatórios e Dashboards: Modelos desnormalizados são frequentemente usados ​​em ferramentas de relatórios e inteligência de negócios, onde o foco está na leitura de grandes volumes de dados, em vez da consistência transacional.
  • Melhor performance de leitura e redução de latência
  • Modelo mais simples para entender – Estrutura direta, fácil visualização.
  • Mais eficiente para OLAP e análise de dados.
  • Menos necessidade de JOINs – Toda a informação está na mesma tabela
  • Boa para leituras em quantidade – Reduz tempo de carregamento.
  • Melhor performance em cache – Dados prontos podem ser armazenados facilmente.
  • Ideal para bancos NoSQL – Muito usado em modelos não relacionais.

Desvantagens de modelos de Dados Desnormalizados:

  • Redundância de Dados: Modelos desnormalizados frequentemente armazenam dados duplicados, o que leva a requisitos de armazenamento mais elevados.
  • Problemas de Integridade de Dados: Quando os mesmos dados são duplicados em vários locais, pode ser difícil garantir que as atualizações dos dados sejam consistentes. Uma alteração em um local deve ser propagada para todos os registros
  • Atualizações Mais Complexas: Como os dados são duplicados, as atualizações precisam ser feitas em vários locais, aumentando o risco de erros e tornando a manutenção mais complexa.
  • Aumento dos Custos de Armazenamento: Dados redundantes exigem mais espaço em disco, o que pode aumentar o custo de armazenamento.
  • Manutenção mais difícil – Alterações exigem mais cuidado.
  • Propenso a anomalias – Inserções/remoções/atualizações mal feitas causam erros.
  • Menos controle lógico – Pode perder clareza na estrutura.
  • Escalabilidade complicada – Crescer o modelo pode gerar gargalos.
  • Menos integridade referencial – Relações ficam mais soltas.
  • Problemas em sistemas transacionais – Ideal para leitura, mas ruim para escrita frequente.

Como escolher o melhor Modelo de Dados Normalizado ou Desnormalizado

Uma boa regra para escolher o melhor Modelo de Dados Normalizado ou Desnormalizado:

Tipo de SistemaMelhor ModeloPrioridadeExemplo
OLTP (transacional)NormalizadoConsistência e manutençãoSistemas que têm muitas operações de escrita, atualização e deleção, como sistemas de cadastro, ERPs, e-commerce e CRMs.
OLAP (analítico)DesnormalizadoPerformance e leitura rápidaSistemas que focam em leitura rápida de grandes volumes de dados, como relatórios, BI, dashboards, etc.




Como fazer a desnormalização de uma tabela

A desnormalização envolve a introdução intencional de redundância em um banco de dados. O objetivo é tornar a recuperação de dados mais rápida, reduzindo a necessidade de junções.

Veja como fazer a desnormalização de uma tabela a seguir:

1. Identifique as consultas que você precisa otimizar:

Comece entendendo quais consultas ou relatórios são mais importantes para o negócio e precisam ser otimizados.

Identifique as tabelas e os campos envolvidos nessas consultas.

Decida quais campos de cada tabela são necessários na tabela desnormalizada.

Por exemplo, se você estiver trabalhando com um banco de dados de e-commerce, talvez queira desnormalizar os dados de produtos e vendas em uma única tabela para agilizar os relatórios de vendas.

2. Combine dados de várias tabelas em uma só

Em uma estrutura desnormalizada, você pode combinar os dados de várias tabelas em uma.

Por exemplo, em vez de ter tabelas separadas de Produto, Cliente e Vendas, você pode combiná-las em uma única tabela “Sales_Report”.

Crie uma nova tabela que armazenará os dados desnormalizados. Essa tabela conterá os campos necessários das diferentes tabelas de origem.

A nova tabela pode incluir colunas extras que armazenam dados que foram calculados anteriormente ou recuperados de outros locais.

Se você estiver combinando dados de Produto e Vendas, sua nova tabela pode ser:

ID_VendaNome_ProdutoNome_ClienteDataQuantidadePreçoVendas_Totais
101MesaMaria12/04/202525001000
102CadeiraPedro12/04/20254100400

3. Introduzir Redundância (Onde Necessário)

Garanta que os dados usados ​​com frequência nas consultas sejam incluídos e repetidos quando necessário.

Por exemplo, se várias transações de vendas estiverem relacionadas ao mesmo produto, o Product_Name poderá aparecer várias vezes.

4. Garantir a consistência entre dados redundantes

Embora os dados sejam duplicados, é necessário ter um processo em vigor para garantir que as atualizações de quaisquer dados redundantes sejam refletidas corretamente na tabela.

5. Teste e otimização

Após criar a tabela desnormalizada, execute consultas para garantir que o desempenho tenha melhorado e que a tabela esteja fornecendo os resultados esperados.




Como fazer a normalização de uma tabela

Normalizar uma tabela tem o objetivo de focar em limpar redundâncias e garantir integridade dos dados.

Veja como fazer a normalização de uma tabela a seguir:


1. Identificar os dados e a tabela não normalizada (forma zero)

Encontre as tabelas com valores duplicados e dados agrupados em colunas únicas (como listas de itens).

Exemplo:

PedidoIDClienteProdutosQuantidades
1AnaArroz, Feijão1, 2
2JoãoMacarrão3
3AnaArroz, Macarrão, Feijão2, 1, 1

2. Primeira Forma Normal (1FN) — Valor Atômico

Separe as listas em registros separados. Cada campo deve conter apenas um valor atômico (sem listas ou conjuntos).

PedidoIDClienteProdutoQuantidade
1AnaArroz1
1AnaFeijão2
2JoãoMacarrão3
3AnaArroz2
3AnaMacarrão1
3AnaFeijão1

3. Segunda Forma Normal (2FN) — Remover dependências parciais

Crie uma chave primária ou chave primária composta. Remova colunas que dependem apenas de parte da chave primária. Divida a tabela em duas ou mais para separar informações.

Por exemplo, se PedidoID + Produto é a chave composta, mas “Cliente” depende só do PedidoID, separe:

Tabela Pedido:

PedidoIDCliente
1Ana
2João
3Ana

Tabela ItensPedido:

PedidoIDProdutoQuantidade
1Arroz1
1Feijão2
2Macarrão3
3Arroz2
3Macarrão1
3Feijão1

4. Terceira Forma Normal (3FN) — Remover dependências transitivas

Elimine atributos que dependem de outros atributos não-chave, mas não da chave primária.

Se a tabela tivesse Cliente → Endereço, separe isso em uma tabela de cliente.

Tabela Cliente:

ClienteIDNomeEndereço
1AnaRua A
2JoãoAv. Central, 123

Tabela Pedido atualizada:

PedidoIDClienteID
11
22
31

5. Checagem e ajustes finais

Verifique se:

  • Cada tabela tem uma única função/entidade.
  • Não há dados repetidos desnecessariamente.
  • As chaves estrangeiras estão corretamente usadas.




Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *