Do que trata o artigo

Este artigo mostra técnicas para desconstruir uma forma normalizada de banco de dados de modo a criar um modelo otimizado para consultas e relatórios. É necessário um conhecimento mínimo em modelagem de dados e de Business Intelligence.

Para que serve

Um sistema de Business Intelligence lida normalmente com milhões de registros e aplica cálculos complexos sobre esses registros e de forma agregada. Para que a visualização desses dados seja rápida e eficiente, é preciso que os mesmos sejam modelados de forma desnormalizada.

Em que situação o tema é útil

Business Intelligence é uma das áreas de maior expansão no mercado de tecnologia. Especialistas em arquitetura neste tipo de sistema são cada vez mais requisitados. Não existe como pensar em arquitetura de BI sem conhecer com profundidade as técnicas de desnormalização de banco de dados.

Resumo do DevMan

Este artigo aborda um dos assuntos mais importantes em uma implementação de Business Intelligence e está relacionado à fase de arquitetura de dados de um projeto de BI. Com um exemplo simples e claro, será mostrado como transformar um banco de dados transacional e normalizado em uma estrutura desnormalizada com foco em desempenho na análise de dados complexos.

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.

ID_Usuario

Nome

DataLogins

1

Lou Reed

2010-11-05;2010-11-07

2

Andy Bell

2010-10-27; 2010-11-02;2010-11-15

3

Sonya Madan

2010-05-07

Tabela 1. Tabela tbUsuarios fora da 1FN

ID_Usuario

Nome

1

Lou Reed

2

Andy Bell

3

Sonya Madan

Tabela 2. Tabela tbUsuarios dentro da 1FN

ID_Usuario

DataLogins

1

2010-11-05

1

2010-11-07

2

2010-10-27

2

2010-11-02

2

2010-11-15

...

Quer ler esse conteúdo completo? Tenha acesso completo