Desnormalização de Banco de Dados - Artigo Revista .Net Magazine 83

Até o final da década de 1990 observou-se uma explosão de projetos que visavam implementar sistemas de gestão nas empresas. Hoje, apesar de existente, é cada vez mais raro uma empresa que não possui nenhum software que gerencie suas transações. O problema é que esse tipo de sistema é projetado para armazenar as operações do dia-a-dia da empresa e possui uma modelagem compatível com esta finalidade. Com a adoção destes inúmeros softwares, as empresas acumularam no decorrer destes anos uma grande quantidade de dados, mas ainda estão começando a entender como extrair todo o potencial de informação contido em seus repositórios.

Os relatórios gerenciais que as empresas possuem podem responder muitas das perguntas do dia-a-dia, como “quais foram minhas vendas nos últimos meses?” ou “Quais clientes compram mais?”, mas quando tem-se perguntas como “Quando devo renovar o estoque?” ou “Quais produtos com melhor retorno de vendas versus marketing?”, os relatórios tradicionais mostram-se na maioria das vezes ineficientes. Não que eles não sejam capazes de responder a tais perguntas, mas que para cada novo questionamento deste tipo, existe um esforço imenso de profissionais de TI que demoram dias para produzir os resultados esperados.

É para responder a este tipo de pergunta de forma ágil e precisa que existem os sistemas de Business Intelligence, ou simplesmente BI. Entretanto, o objetivo deste artigo não é abordar este assunto. O que se deseja aqui é mostrar como modelar uma estrutura de dados que dê apoio a este tipo de sistema, tendo como base o modelo estrutural do sistema transacional existente na empresa.

Importante dizer que o modelo de dados desnormalizado não veio substituir o tradicional modelo normalizado. Ambos estão corretos, mas cada um é indicado a um caso específico. Quando fala-se de um sistema transacional (OLTP ou Online Transaction Processing), significa-nos referir a um sistema responsável pelas operações do dia-a-dia de uma empresa, como estoque, contas a pagar, contas a receber, contabilidade, RH, etc. Neste tipo de software o importante é ter um banco de dados normalizado, pois como se lida com poucos registros ao mesmo tempo, o mais importante é que os dados sejam manipulados de forma eficiente.

Quando o foco do sistema é a análise dos dados existentes, tem-se um sistema analítico (OLAP ou Online Analytical Processing). Neste tipo de software, a complexidade dos cálculos é maior, assim como a quantidade de registros. Um OLAP apenas lê dados mantidos por um OLTP, não alterando esses dados. Sendo assim, a forma normalizada não faz muito sentido neste tipo de sistema. Ao contrário, o que importa aqui é a velocidade de retorno das fórmulas matemáticas. Para tanto, armazena-se no banco de dados OLAP tantos cálculos quanto possível. Assim sendo, trata-se de um banco de dados não normalizado.

Antes de iniciar o aprendizado das técnicas de desnormalização, é preciso entender o que vem a ser um banco de dados normalizado.

Banco de Dados Normalizado

Quando a estrutura de um banco de dados relacional é pensada, existem regras que devem ser seguidas com o objetivo de evitar redundâncias e ocupar o menor espaço possível em disco. Essas regras são chamadas de Formas Normais e são descritas como 1FN, 2FN e 3FN (ou NF – Normal Form – na denominação em inglês).

A Primeira Forma Normal (1FN) diz que uma tabela está normalizada se todos os seus campos e valores contiverem apenas valores básicos, ou atômicos. Ou seja, um campo não pode conter valores múltiplos. Na Tabela 1 nota-se um exemplo de uma tabela fora desta regra. Note que o campo DataLogins contém uma lista com as datas de login do usuário. O correto é que este campo contenha apenas um valor e não uma lista de valores. As Tabelas 2 e 3 mostram a forma correta de corrigir esse problema, quebrando tbUsuarios em duas entidades.

Tabela 1. Tabela tbUsuarios fora da 1FN

Tabela 2. Tabela tbUsuarios dentro da 1FN