Quando começamos a estudar bancos de dados e a elaborar diagramas entidade-relacionamento (ER), é comum buscarmos boas práticas para garantir a integridade e a consistência dos dados. Nesse contexto, surge a normalização, um conjunto de técnicas que organiza os dados de forma a reduzir redundâncias e evitar inconsistências. Assim, entender a normalização e a desnormalização de banco de dados ajuda a compreender diferentes formas de estruturar e utilizar os dados.
Com o tempo, principalmente ao entrar em cenários de Analytics, podemos encontrar uma abordagem aparentemente oposta: a desnormalização. Por isso, podemos ter a impressão de que existe uma maneira “correta” de estruturar os dados e que a desnormalização representa uma prática ruim.
Na realidade, normalização e desnormalização não são conceitos concorrentes. Pelo contrário, cada abordagem possui vantagens e desvantagens que atendem diferentes necessidades.
O que é Normalização?
Normalizar um banco de dados significa organizar as informações em tabelas relacionadas entre si, reduzindo a redundância e evitando que o mesmo dado precise ser armazenado em diversos lugares.
Para isso, esse processo segue regras conhecidas como formas normais, sendo as mais comuns a Primeira Forma Normal (1FN), Segunda Forma Normal (2FN) e Terceira Forma Normal (3FN).
Além disso, esse tipo de estrutura de dados é especialmente adequado para sistemas OLTP (Online Transaction Processing), que são voltados para as operações do dia a dia de uma organização, como um ERP, CRM ou sistema de vendas. Nesse contexto, esses sistemas trabalham frequentemente com transações rápidas, concorrência e operações de inserção e atualização.
Nesse contexto, a normalização costuma ser bastante adequada, pois a consistência dos dados é fundamental.
Exemplo de sistema normalizado:
Para entender melhor como a normalização funciona na prática, imagine o banco de dados de um cinema. O sistema precisa armazenar informações sobre filmes, diretores, salas, sessões, clientes e ingressos.
Nesse modelo, essas informações são distribuídas entre tabelas que representam diferentes entidades do sistema:
- Filmes: armazena as informações dos filmes que já possuíram sessões no cinema;
- Diretores: mantém os dados dos diretores dos filmes;
- Salas: registra as salas disponíveis no cinema;
- Tipos de Sala: define características da sala como 2D, 3D e IMAX;
- Sessões: relaciona um filme a uma sala e a um horário de exibição;
- Clientes: armazena os dados dos clientes;
- Ingressos: registra as vendas realizadas para cada sessão e cliente.
Além disso, essas tabelas se relacionam por meio de chaves estrangeiras, formando uma estrutura como a apresentada abaixo.
Observe, por exemplo, a relação entre Filmes e Diretores. Em vez de armazenar o nome e a nacionalidade do diretor diretamente em cada registro de filme, a tabela Filmes possui apenas o id_diretor, que referencia o cadastro correspondente em Diretores.
Esse mesmo princípio de relacionamento é aplicado entre as outras tabelas. Na tabela de Ingressos, em vez de armazenar novamente o nome do cliente, o filme, a sala e o horário da sessão em cada ingresso, a tabela mantém os identificadores de cliente e sessão. A partir deles, é possível chegar às demais informações.
A normalização traz uma vantagem crucial para o sistema: evita as anomalias de inserção, atualização e exclusão. Graças a isso, a alteração do e-mail de um cliente ocorre apenas uma vez na tabela Clientes, sem afetar seus ingressos associados. Sem essa padronização, dados como os de um diretor se repetiriam nos registros de filmes, exigindo atualizações em massa que, se falhassem, gerariam inconsistências no banco de dados.
Por outro lado, essa organização tem um custo: para obter determinadas informações, é necessário percorrer várias tabelas por meio de JOINs. Para descobrir, por exemplo, qual diretor é responsável pelo filme de uma determinada sessão, precisamos passar pelas tabelas Sessões, Filmes e Diretores.
Pontos positivos:
- Menor redundância de dados
- Maior integridade e consistência
- Atualizações mais seguras
- Redução de anomalias de inserção, atualização e exclusão
- Estrutura adequada para sistemas com muitas operações de escrita
Pontos negativos:
- Consultas podem exigir vários JOINs entre tabelas
- O modelo pode ser mais complexo para usuários que precisam apenas consultar os dados
- Algumas consultas analíticas podem exigir o processamento de várias tabelas
O que é Desnormalização?
A desnormalização consiste em permitir que determinadas informações sejam armazenadas de forma redundante ou em estruturas menos normalizadas, buscando facilitar o acesso e o consumo dos dados em determinados cenários.
Nesse sentido, uma estrutura de dados desnormalizada atende bem a sistemas OLAP (Online Analytical Processing), que utilizam esses dados para análise e tomada de decisão, como Data Warehouses e ambientes utilizados por ferramentas de Business Intelligence.
Nesses ambientes, é comum realizar consultas que percorrem grandes volumes de dados e combinam informações de diferentes perspectivas. Por isso, como esses sistemas priorizam a leitura e a análise de dados, e não a escrita, estruturas desnormalizadas podem oferecer vantagens.
Além disso, um exemplo bastante comum é a modelagem Star Schema (esquema estrela), na qual uma tabela fato se relaciona diretamente com tabelas de dimensão. Nesse modelo, as dimensões geralmente apresentam uma estrutura mais desnormalizada do que a que encontramos em um modelo transacional.
Exemplo de sistema Desnormalizado
Voltando ao exemplo do cinema, imagine que os dados do sistema transacional sejam carregados para um ambiente de Analytics. Em vez de manter a mesma estrutura normalizada, podemos utilizar um Star Schema, composto por uma tabela fato e diferentes tabelas dimensão.
Nesse modelo, a tabela Fato_Ingressos registra cada ingresso vendido e mantém as informações necessárias para relacioná-lo às dimensões de Dim_Data, Dim_Filme, Dim_Sala, Dim_Sessao e Dim_Cliente.
As dimensões, por sua vez, podem armazenar informações que anteriormente estavam distribuídas entre várias tabelas. Por exemplo, no banco de dados normalizado, para descobrir o diretor de um filme seria necessário consultar Filmes e depois Diretores. No modelo dimensional, informações como o nome do diretor e sua nacionalidade podem estar diretamente na Dim_Filme.
Da mesma forma, informações que antes estavam separadas entre Salas e Tipo_Sala podem estar reunidas na Dim_Sala:
Assim, uma consulta que deseja descobrir “Quanto cada tipo de sala arrecadou?” não precisa percorrer as tabelas Ingressos, Sessões, Salas e Tipo_Sala do sistema transacional. No modelo dimensional, a informação necessária está disponível diretamente na fato e na dimensão correspondente.
Essa estrutura também facilita o consumo por ferramentas de Business Intelligence, permitindo análises como:
- Faturamento por filme
- Quantidade de ingressos vendidos por dia
- Horários com maior número de vendas
Por outro lado, essa simplificação pode aumentar a redundância. O nome de um diretor, por exemplo, pode aparecer em diversas linhas da dimensão Dim_Filme, e milhares ou milhões de registros na Fato_Ingressos podem referenciar as informações de um filme.
Essa redundância intencional faz parte da estratégia de modelagem do ambiente analítico. Como os processos de ETL ou ELT normalmente carregam esses dados, eles centralizam as transformações e as regras de atualização, reduzindo o risco de inconsistências.
Pontos positivos:
- Pode simplificar determinadas consultas
- Reduz a necessidade de percorrer várias tabelas normalizadas
- Facilita o consumo dos dados por ferramentas de BI
- Organiza os dados de acordo com as dimensões utilizadas nas análises
- Pode melhorar a performance de consultas específicas em determinados cenários
Pontos negativos:
- Pode aumentar a redundância de dados
- Pode aumentar o armazenamento necessário
- Alterações na estrutura ou nas regras de negócio podem exigir ajustes nos processos de ETL/ELT
- A redundância precisa ser controlada para evitar inconsistências
Os dois modelos podem conviver
A escolha entre normalização e desnormalização não precisa abranger todo o ambiente de dados de uma organização.
É bastante comum que uma empresa mantenha seus sistemas de origem utilizando modelos normalizados, garantindo a integridade das transações do dia a dia, e posteriormente transforme esses dados em uma estrutura mais adequada para análise.
Essa transformação pode ocorrer em uma camada de ETL ou ELT, responsável por extrair os dados dos sistemas de origem, transformá-los e disponibilizá-los em um ambiente analítico.
Dessa forma, o mesmo dado pode passar por diferentes modelos ao longo da arquitetura de dados, de acordo com a finalidade de cada camada.
Afinal, qual modelo usar?
A principal conclusão é que não existe um modelo universalmente melhor.
A normalização é especialmente importante quando precisamos garantir consistência, integridade e segurança em sistemas transacionais. Já a desnormalização pode ser interessante quando o objetivo principal é facilitar o consumo dos dados e otimizar determinadas consultas analíticas.
Portanto, a pergunta mais importante não é “qual modelo é melhor?”, mas sim: “Qual problema estamos tentando resolver e como vamos utilizar esses dados?”
Até a próxima!
