artigo SQL Magazine 03 - Informação, produtividade e rapidez. Descubra o Data Warehouse !

Transformar dados históricos em conhecimento estratégico é um dos principais objetivos da tecnologia da informação nas organizações. O Data Warehouse (DW) é uma ferramenta que surgiu com esse propósito, trazendo a idéia de centralização das informações, visualização multi-dimensional dos dados e descoberta de padrões de comportamento para dar aos administrador mais agilidade na tomada de decisões. Veja a definição de W.H.Inmon, considerado um guru do assunto:

“Data Warehouse é uma coleção de dados orientada por assuntos, integrada, variante no tempo e não volátil, que tem por objetivo dar suporte aos processos de tomada de decisão.”

O Data Warehouse pode ser aplicado em empresas que possuem informações descentralizadas e com deficiência na organização operacional para totalizações, tornando o processo de decisão bastante árduo. O DW realiza consultas em uma única fonte de dados consolidada, através de um banco de dados preparado para armazenar conhecimentos sobre o negócio da empresa.

Como funciona?

O Data Warehouse é um sistema de suporte a decisão, composto por um conjunto de ferramentas que centralizam, armazenam, gerenciam e extraem informações históricas da empresa, em um formato “mastigado” para o tomador de decisão.

Em geral, o Data Warehouse é armazenado em um banco separado da base de dados operacional. Em sistemas desse tipo, os bancos mantêm dados históricos, gerando um grande volume de dados e consultas complexas. A separação evita a perda de performance no processo operacional da empresa. Por exemplo, imagine um supermercado no horário de pico, com dezenas de caixas registradoras conectadas ao banco de dados transacional e alguém tentando extrair um extenso relatório de análise do comportamento da empresa. Outro ponto é que as bases DW possuem objetivo e estrutura diferentes da base transacional, tornando a criação de um banco de dados exclusivo uma necessidade.

O Data Warehouse é “alimentado” periodicamente com informações da base operacional. Os dados são exibidos para o usuário através de ferramentas de apoio a decisão, como o OLAP (On-Line Analytical Processing) e o Data Mining, que permitem a visualização multi-dimensional do resultado e a projeção de comportamentos, respectivamente.

Arquitetura de um Data Warehouse

O Data Warehouse pode ter uma estrutura centralizada ou distribuída em camadas. No modelo centralizado, o poder de processamento é maior e os processos de busca de informação devem ser otimizados. Veja um exemplo na figura 1:

Figura 1: Exemplo de modelo centralizado

A arquitetura em camadas é mais flexível e permite consultas simultâneas sem muita perda de performance. Na primeira camada disponibilizamos o servidor que atenderá a maior parte das consultas, com baixo volume de dados. Nas demais camadas temos os servidores com volume maior de dados, que atenderão uma quantidade menor de usuários (figura 2).

figura 2. Exemplo de arquitetura em camadas

Data Warehouses em Departamentos

Para diminuir o custo e o tempo total de implantação de um Data Warehouse, podemos dividí-lo em partes menores, distribuídas por departamentos ou áreas de atuação da empresa. A “divisão” de um DW é conhecida como Data Mart.

As diferenças entre Data Mart e Data Warehouse são apenas em relação ao tamanho e ao escopo do problema a ser resolvido. Por ser direcionado a uma área específica da empresa, o planejamento e análise de um Data Mart são mais fáceis de gerenciar.

Existem dois tipos de implementação de Data Marts: top-down e bottom-up. Top-down é quando a empresa cria um Data Warehouse e depois divide-o em Data Marts, gerando pequenos bancos orientados por assunto (ou departamentos). Bottom-up é quando a empresa inicia um Data Mart e expande o projeto para outras áreas.

Por apresentar prazo e custo menores, a implantação bottom-up tem sido muito utilizada pelas empresas. Em média, o tempo de implantação de um Data Mart fica em torno de quatro meses. No Data Warehouse o tempo estimado pode passar de 1 ano.

Etapas de um Data Warehouse (ou Data Mart)

A construção de um DW passa por quatro fases principais:

• Levantamento – Avalia, junto aos tomadores de decisão, os conhecimentos que desejam ser adquiridos. Esta é a fase mais importante.
• Modelagem Multidimensional - Nesta forma de modelagem representamos a idéia central e suas dimensões. Identificamos as questões principais e definimos como os dados serão armazenados.
• ETL (Extract, Transform and Load) – Extração dos dados nos sistemas corporativos e transformação, para carga no Data Warehouse.
• Visualização do Resultado - Ferramentas para interação com o usuário, através de interfaces amigáveis.

Como exemplo, vamos acompanhar os passos para construção de um mini Data Mart de uma concessionária.

Levantamento das informações e identificação das necessidades

Uma rede de concessionárias possui um sistema transacional para controle de vendas. Nas entrevistas realizadas com os gerentes, foram identificadas algumas necessidades de informação:

• Acompanhamento da evolução das vendas e do valor total arrecadado por concessionária;
• Definição das lojas que atraem o maior número de clientes;
• Descoberta do perfil dos clientes;
• Identificação do período do ano que apresenta maior volume de vendas, em relação à loja e ao perfil do cliente.

Modelagem Multidimensional: Fato, Dimensões e Medidas

A representação dos dados em um Data Warehouse é estruturada como um cubo, transmitindo a idéia de múltiplas dimensões. Na figura 3, verificamos as dimensões PRODUTO, TEMPO e GEOGRAFIA. A inclusão de dados no DW passa uma idéia de crescimento na largura, comprimento e profundidade do cubo.

A construção do modelo começa pela definição de uma tabela denominada Fato. Em seguida, definimos seus elementos relacionados, que são tabelas denominadas Dimensão. Na interseção das dimensões são obtidas as Medidas, que são as medições numéricas da tabela Fato.

Veja um exemplo de modelagem multidimensional a seguir: no centro vemos a entidade Fato e nas pontas as Dimensões, ou seja, os elementos que participam de um Fato. Essa representação é conhecida como Esquema Estrela (Star Schema):

Na modelagem, podemos identificar mais de uma tabela Fato. Neste caso, as tabelas podem compartilhar dimensões, mesmo que essas dimensões estejam em Data Marts separados.

Podemos ainda utilizar dimensões normalizadas. Essa variação é denominada esquema “Snowflake” e sua principal vantagem é a economia de espaço, pois o volume de dados armazenado é menor. A principal desvantagem é a perda de performance no processo.

Para identificar as tabelas Fato e Dimensão, devemos responder algumas perguntas:

Qual a ideia central no exemplo da concessionária?

Venda de automóveis

O que está sendo medido?

Quantidade de automóveis vendidos

Valor total das vendas

O que precisamos avaliar sobre essas vendas?

Qual produto (automóvel) foi vendido

Quando (dia, mês, trimestre, ano)

Onde (concessionária, região)

Quem comprou (faixa etária, faixa salarial/renda, sexo)

Seguindo a modelagem multidimensional, os dados serão armazenados da seguinte forma:

Representação no esquema estrela:

Terceiro Passo: ETL (Extract, Transform e Load)

O próximo passo é a transferência e transformação dos dados existentes nos sistemas corporativos para uma base de dados independente, disponível apenas para carga e consulta. Este processo é conhecido como ETL – Extração, Transformação e Carga.

Para efetuar a ETL utilizamos linguagens de programação ou ferramentas específicas, como o Oracle Warehouse Builder (www.oracle.com) ou o Cognos DecisionStream (www.cognos.com) [figura].

Em geral, o processo envolve dois passos: extração e tratamento dos dados do sistema de origem, e carga no sistema destino (Data Warehouse). Uma observação é a possibilidade dos sistemas de origem e destino estarem em plataformas diferentes, exigindo um tratamento específico na transformação dos dados.

O primeiro passo é o desenvolvimento de uma metodologia, selecionando o assunto inicial e as dimensões abordadas. Em seguida, é feita a análise de cada tabela destino separadamente, facilitando o processo de identificação das tabelas e campos de origem. Por último, os dados selecionados são inseridos nas respectivas tabelas fato e dimensão.

Devido ao grande volume de registros, a primeira carga geralmente é feita por etapas, como extração de um lote de registros filtrados por mês ou ano. São executados vários processos de extração e carga sucessivamente, até que todos os dados do banco de origem tenham sido carregados no Data Warehouse. Terminada a fase de importação, é estabelecida a periodicidade de atualização das tabelas.

Quarto Passo: Visualização

Uma das ferramentas utilizadas na recuperação dos dados de um DW é o OLAP, que tem como característica principal a visualização multi-dimensional dos dados. Existem quatro visualizações básicas:

• Drill down
• Drill up ou Roll up
• Slice
• Dice

Drill down e Drill up movimentam as visões ao longo das hierarquias, enquanto Slice e Dice são operações de navegação apenas. A aplicação dessas quatro visões sobre um modelo-multidimensional cria uma visão no formato de cubo, conhecida como Decision Cube. Na caixa “Visões OLAP” você pode conferir alguns exemplos.

Drill down: visão detalhada

Drill up: visão sumarizada

“Girando o cubo” , temos um exemplo da visão Dice.

No exemplo Slice, o cubo é “fatiado”, apresentando apenas dos dados.

Mineração de Dados

Além do OLAP, o Data Warehouse trabalha com o conceito de ferramentas para mineração de dados (Data Mining). Esses aplicativos utilizam técnicas para reconhecer padrões nos dados do DW, disponibilizando ao administrador “projeções” comportamentais. Normalmente, esses padrões estão “escondidos” nas informações históricas, sendo praticamente impossíveis de serem descobertos por ferramentas de consulta tradicionais. Os sistemas de Data Mining utilizam técnicas avançadas, como inteligência artificial, para mineração desses padrões.

Existem vários cases clássicos de sucesso no uso deste conceito. Um deles pertence a uma empresa americana de venda de roupas por catálogo. Após a aplicação de um Data Mining sobre a base histórica, descobriu-se diversos padrões de compra, como o caso de uma gravata que era mais vendida quando um tipo de calça e sapatos estavam disponíveis no mesmo catálogo, em um determinado período do ano. A partir da descoberta desses padrões, a empresa explorou esses nichos, aumentando sua lucratividade.

O objetivo da Unimed Londrina era maximizar a gestão dos custos com prestadores de serviço e cooperados. O obstáculo era a falta de confiabilidade em relatórios gerenciais e a demanda reprimida de informações estratégicas.

Estas deficiências criavam entraves para a identificação de padrões de comportamento dos geradores do custo, como as doenças mais onerosas, que demandam mais consultas, exames, internações e cirurgias. Era difícil acompanhar o progresso sazonal dos custos (por exemplo, o índice de aumento de gripe durante o inverno) ou mesmo identificar a utilização indiscriminada dos usuários do plano, bem como solicitações indiscriminadas de exames por parte dos prestadores de serviço.

Além disso, a Unimed precisava de agilidade para atender as solicitações e as freqüentes mudanças exigidas pela Agência Nacional de Saúde, que regula a operação de planos de saúde.

A construção de um Data Warehouse foi iniciada por um Data Mart na área de custos concentrando informações de doenças, procedimentos (consultas, exames, internações, cirurgias) e atendimento realizado pelos prestadores de serviços credenciados (hospitais, clínicas e laboratórios) e médicos cooperados.

Assim, foi criado o Datamed, voltado para a área de gestão de custos. O principal usuário é a controladoria que assessora a diretoria executiva, fornecendo informações estratégicas para tomada de decisões, através de relatórios e gráficos.

O Oracle foi escolhido para armazenar os dados do DataMart. O Oracle Designer foi utilizado para a modelagem de dados, implementação e manutenção do banco, e o Oracle Discoverer para processos OLAP (On-line Analytical Processing). Os principais benefícios adquiridos foram:

• Eficiência na resposta para questões contingenciais geradas pelo mercado concorrente e órgãos reguladores;
• Informações estratégicas para melhoria da gestão de custos;
• Identificação de necessidades para novos planos.

Hoje, o Data Warehouse é uma realidade na Unimed Londrina, permitindo a empresa tomar decisões estratégicas mais rapidamente.

De acordo comAndré Portella,Diretor da CommitConsultores, desenvolvedora do DataMed, o Exemplo de ferramenta ETL seria como na imagem a seguir, que trata do Cognos DecisionStream:

Conclusão

Antes de um Data Warehouse virar a solução para a falta de informações gerenciais na empresa, é preciso avaliar se os “sistemas da casa” podem atender as necessidades atuais, já que os projetos de DW são caros e demoram para ser implantados.

Os custos de um Data Warehouse são muitos, mas as vantagens, apesar de reais, podem ser menos perceptíveis. Como quantificar o acesso rápido a dados e relatórios confiáveis? O retorno do investimento de um Data Warehouse será medido através do uso que os administradores derem às informações obtidas.

Em resumo, não adianta ter um “armazém cheio” se o administrador não souber transformar a informação em conhecimento e canalizá-lo em ações. Mais importante do que a tecnologia é um perfeito entendimento do negócio, do que está sendo feito e do que é preciso, para que o ganho de produtividade deixe de ser apenas uma promessa.