DATA WAREHOUSING Data Warehousing
Sumário Conceitos / Autores chave... 3 1. Introdução... 3 2. Modelos de Data Warehouse... 4 3. Processo de Extração, Transformação e Carga de Dados... 6 4. Data Mart versus Data Warehouse... 8 5. Conclusões... 9 6. Atividades... 9 Materiais complementares... 10 Bibliografia... 10 Curso - Data Warehousing
Conceitos / Autores-chave Glossário Business Intelligence Conjunto de conceitos e metodologias que, fazendo uso de acontecimentos (fatos) e sistemas baseados nos mesmos, apóia a tomada de decisões em negócios. OLAP uma mesma informação de diferentes formas pode ajudar na tomada exata de uma decisão. Ferramentas OLAP nos auxiliam nessa função. Data Mining (ou mineração de dados) é o processo de extrair informação válida, previamente desconhecida e de máxima abrangência a partir de grandes bases de dados, usando-as para efetuar decisões cruciais. Pontos Críticos Diferença entre Data Warehouse e Data Warehousing Data Warehousing (DWing) é o processo de desenvolvimento de um Data Warehouse (DW) adequado à análise de negócios e ao apoio à tomada de decisões gerenciais e estratégicas. Esta tecnologia é a base, sobre a qual se monta a Inteligência de Negócios (Business Intelligence ou BI) das empresas. Um data warehouse (ou armazém de dados, ou depósito de dados) é um sistema de computação utilizado para armazenar informações relativas às atividades de uma organização em bancos de dados, de forma consolidada. O desenho da base de dados favorece os relatórios, a análise de grandes volumes de dados e a obtenção de informações estratégicas que podem facilitar a tomada de decisão. 1. Introdução A elaboração de um Data Warehouse requer muito tempo, envolve custos e muito esforço gerencial. Muitas empresas iniciam o tratamento de suas necessidades focadas em um DW por meio de interesses de pequenos grupos dentro da organização, caracterizando o contexto de um data mart. Um data mart é um pequeno data warehouse que fornece suporte à decisão de um pequeno grupo de pessoas ou interessados nos processos de negócio deste grupo. A idéia básica, sugerida por fornecedores de data warehouse é que se deve pensar grande, mas começar de forma pequena e organizada. Um projeto de DW não pode ser uma idéia imediatista, ela deve ser construída de forma gradual ao longo do tempo. É importante ter em mente que a diferença entre um data mart e um data warehouse é apenas o tamanho e o escopo do problema a ser solucionado. Portanto, os problemas e os requisitos são essencialmente os mesmos para ambos. Curso - Data Warehousing
2. Modelos de Data Warehouse O Modelo multidimensional pode ser de dois tipos: O Modelo Estrela e o Modelo Floco de Neve, sendo mais usado o Estrela. 2.1 O modelo estrela (Star Schema) Este modelo é chamado de estrela porque a tabela fato fica ao centro, cercada das tabelas dimensionais, assemelhando-se a uma estrela. Mas o ponto forte a fixar é que as dimensões não são normalizadas e não existe relacionamento entre as mesmas, conforme é apresentado na figura abaixo. Representação de um modelo estrela Esta forma de disponibilizar as tabelas é conhecida como modelo estrela devido a sua disposição no modelo físico, que consiste de uma tabela central, a tabela fato, e as demais tabelas dimensões, em suas extremidades. Na tabela fato existe uma chave estrangeira que se associa a uma chave primária na tabela dimensão, deste modo todas as dimensões ficam associadas à tabela fato. Na figura a seguir é mostrado um exemplo de dimensões com seus papéis, associadas a uma tabela fato. Tabela Fato (Vendas) e tabelas Dimensões (Tempo, Vendedor, Cliente e Produto) 2.2 O modelo Floco de Neve (Snow Flake) No modelo Floco as tabelas dimensionais relacionam-se com a tabela fato, mas algumas dimensões relacionam-se apenas entre elas, isto ocorre para fins de normalização das tabelas dimensionais. Este modelo chama-se floco de neve, pois cada dimensão se divide em várias outras tabelas, que organizadas de certa forma, lembra um floco de neve. O modelo de dados multidimensional é usualmente similar a uma estrela. Um fato está no centro da estrela e as dimensões ao seu redor, formando as pontas dessa estrela. O modelo floco de neves é o resultado da decomposição de uma ou mais dimensões que possuem hierarquias entre seus membros O modelo floco de neve consiste de uma extensão do modelo estrela, onde cada uma das pontas da estrela pode vir a ser o centro de outras estrelas. Cada tabela dimensão uma vez normalizadas, seria convertido em tabelas compostas de hierarquias em função de seus atributos. Considerando possíveis complexidades hierárquicas, aconselha-se aos projetistas a resistirem à tentação de transformar esquemas estrela em floco de neve; devido ao impacto da complexidade deste tipo de estrutura sobre o usuário final, e tratando-se de ganho de espaço de armazenamento o resultado é pouco relevante. Na figura abaixo apresenta-se um exemplo de floco de neves. Modelo floco de neve Curso - Data Warehousing
2.3 Roteiro de Modelagem A seguir é apresentado um roteiro de modelagem multidimensional. Estes passos são fundamentais para a elaboração de um Data Warehouse. Identificar as necessidades do negócio. Definir os fatos. Definir as dimensões. Definir as medidas. Identificar os atributos das dimensões e das hierarquias. Definir a granularidade de cada tabela fato. Verificar o nível de detalhamento das dimensões. Definir a duração do Data Mart (previsão do histórico). Definir a freqüência com que os dados devem ser extraídos e carregados no DW. A definição de freqüência de ETL deve obedecer a critérios que levem em consideração os seguintes aspectos: - O encerramento das atividades em um período relativo ao grau de informação do Data Marts. - A determinação de que não existirão mais modificações de uma base de dados nas fontes relativas ao período em questão. 2.4 Erros na implantação de um DW O Data Warehousing Institute (SINGH, 2001) aponta os dez erros mais comuns na implantação de um DW: 1. Começar o projeto com o tipo errado de patrocínio. 2. Gerar expectativas que não possam ser satisfeitas, frustrando os executivos quando da utilização do DW. 3. Dizer: Isto vai ajudar os gerentes a tomar decisões melhores e outras informações politicamente ingênuas. 4. Carregar o DW com informações só porque estavam disponíveis. 5. Falhar no objetivo de acrescentar valor ao dado por meio de mecanismos de desnormatização, categorização e navegação assistida. 6. Escolher um gerente que seja voltado para a tecnologia e não para o usuário. 7. Focalizar em dados tradicionais internos orientados para o registro e ignorar o valor potencial de dados textuais, imagem, som, vídeo e dados externos. 8. Fornecer dados com definições confusas e sobrepostas. 9. Acreditar nas promessas de desempenho, capacidade e escalabilidade dos vendedores de produtos. 10. Usar o DW como justificativa para modelagem de dados e uso de ferramentas case. Definir o modelo de dados do DW. Escolher uma ferramenta case para realizar a modelagem multidimensional (Ex. ERWIN). Elaborar a modelagem multidimensional. Verificar a consistência e eficiência do modelo de DW. Curso - Data Warehousing
3. Processo de extração, transformação e carga de dados Esta etapa é uma das fases mais críticas de um Data Warehouse, pois envolve a fase de movimentação dos dados. A mesma se dá basicamente em três passos: extração, transformação e carga dos dados. Esses são os mais trabalhosos, complexos e também muito detalhados, embora tenhamos várias ferramentas (falaremos mais abaixo) que nos auxiliam na execução desse trabalho. O primeiro passo a ser tomado no processo de ETL é simplesmente a definição das fontes de dados e a extração deles. As origens deles podem ser várias e também em diferentes formatos, onde poderemos encontrar desde os sistemas transacionais das empresas, até planilhas, flat files (arquivos de textos), dados que vêm do grande porte e também arquivos do tipo DBF, do antigo Clipper ou Dbase. Definidas as fontes, partimos para o segundo passo que consiste em transformar e limpar esses dados. Mas, afinal de contas, o que é isso? Bem vamos descrever de uma forma bem simples: quando obtemos os dados de uma fonte, que na maioria das vezes é desconhecida nossa, e foi concebida há muito tempo atrás, os mesmos possuem muito lixo e há muita inconsistência. Por exemplo. Quando um vendedor de linhas telefônicas for executar uma venda, ou inscrição, ele está preocupado em vender, e não está preocupado com a qualidade dos dados que está inserindo na base. Então, se por acaso, o cliente não tiver o número do CPF à mão, ele cadastra um número qualquer, desde que o sistema aceite. Um dos mais utilizados é o 999999999-99. Agora imagine se um diretor de uma companhia telefônica consultar o seu Data Warehouse (DW) para ver quais são os seus maiores clientes, e aparecer em primeiro lugar o cliente que tem o CPF 999999999-99? Seria no mínimo estranho. Por isso, nessa fase do DW, fazemos a limpeza desses dados, para haver compatibilidade entre eles. Além da limpeza, temos de fazer na maioria das vezes uma transformação, pois os dados provêm de vários sistemas, e por isso, geralmente uma mesma informação tem diferentes formatos. Por exemplo: em alguns sistemas a informação sobre o sexo do cliente pode estar armazenada no formato: M para Masculino e F para Feminino, porém em algum outro sistema está guardado como H para Masculino e M para Feminino; e assim sucessivamente. Quando levamos esses dados para o DW, deve-se ter uma padronização deles, ou seja, quando o usuário for consultar o DW, ele não pode ver informações iguais em formatos diferentes; então, quando fazemos o processo de ETL, transformamos esses dados e deixamos num formato uniforme sugerido pelo próprio usuário. No DW, teremos somente M e F, fato esse que facilitará a análise dos dados que serão recuperados pela ferramenta OLAP (KIMBALL, 2002). A seguir são apresentados alguns dos fatores que devem ser analisados antes de começar a fase de extração dos dados (SINGH, 2001, OLIVEIRA, 2004): A extração de dados do ambiente operacional para o ambiente de data warehouse demanda uma mudança na tecnologia. Os dados são transferidos de bancos de dados hierárquicos, tal como o adabas, ou de bases do grande porte, como o DB2, para uma nova tecnologia de SGBD para Data Warehouse, tal como o IQ da Sybase, Red Brick da Informix, Essbase ou o DB2 para DW; Curso - Data Warehousing 6
A seleção de dados do ambiente operacional pode ser muito complexa, pois muitas vezes é necessário selecionar vários campos de um sistema transacional para compor um único campo no data warehouse; Outro fator que deve ser levado em conta é que dificilmente há o modelo de dados dos sistemas antigos, e se existem não estão documentados; Os dados são reformatados. Por exemplo: um campo data do sistema operacional do tipo DD/MM/AAAA pode ser passado para o outro sistema do tipo ano e mês como AAAA/ MM; Quando há vários arquivos de entrada, a escolha das chaves deve ser feita antes que os arquivos sejam intercalados. Isso significa que se diferentes estruturas de chaves são usadas nos diferentes arquivos de entrada, então se deve optar por apenas uma dessas estruturas; Os arquivos devem ser gerados obedecendo à mesma ordem das colunas estipuladas no ambiente de data warehouse; Pode haver vários resultados. Dados podem ser produzidos em diferentes níveis de resumo pelo mesmo programa de criação do data warehouse; Valores default devem ser fornecidos. Às vezes pode existir um campo no data warehouse que não possui fonte de dados, então a solução é definir um valor padrão para estes campos. Importante O data warehouse espelha as informações históricas necessárias, enquanto o ambiente operacional focaliza as informações pontuais correntes. A parte de carga dos dados também possui uma enorme complexidade, e os seguintes fatores devem ser levados em conta: A parte de Integridade dos dados. No momento da carga é necessário checar os campos que são chaves estrangeiras com suas respectivas tabelas para certificar-se de que os dados existentes na tabela da chave estrangeira estão de acordo com a tabela da chave primária; Se a tabela deve receber uma carga incremental ou a carga por cima dos dados. A carga incremental normalmente é feita para tabelas fato e a carga por cima dos dados é feita em tabelas dimensões onde o analista terá que deletar os dados existentes e incluí-los novamente. Mas, em alguns casos, poderá acontecer que as tabelas de dimensões tenham de manter o histórico, então o mesmo deverá ser mantido; Apesar de existirem ferramentas de ETL como o DTS (Data Transformation Service), Data Stage, ETI, Acta e Sagent, ainda têm-se a necessidade de criar rotinas de carga para atender determinadas situações que poderão ocorrer. As ferramentas de ETL mais utilizadas no mercado são o Data Stage da Ardent, agora adquirido pela Informix, o ETI da IBM, Sagent da própria Sagent, Informática Power Conect da Informática e o DTS da Microsoft. Todos têm os seus diferenciais e cada um poderá ser utilizado dependendo do caso de cada empresa. Algumas ferramentas têm a curva de aprendizado mais suave, outras um pouco mais íngreme, mas em certos casos mesmo sendo uma ferramenta de difícil aprendizado exigindo maiores investimentos em pessoal, serão compensados com o desempenho e flexibilidade da mesma. Há outras ferramentas que têm custo zero de aquisição, pois, vem embutida junto com um SGBD (Sistema Gerenciador de Banco de Dados), mas, em contrapartida são bastante limitadas no tocante à extração de dados e exigem uma maior codificação dos processos de ETL, em relação às outras. O que vale dizer é que uma ferramenta de ETL tem grande valia, principalmente se os sistemas OLTP (transacionais) são muitos, pois ela é uma poderosa fonte de geração de metadados, e que contribuirão muito para a produtividade da sua equipe, porém devese tomar muito cuidado ao escolhê-la. Seja minucioso, teste o máximo de ferramentas que puder e veja qual é a mais adequada ao seu caso, pois elas exigem um alto investimento, tanto em capacitação, quanto na própria aquisição. Em alguns casos é interessante o auxílio de profissionais externos para a escolha. O fato verdadeiro é que os benefícios serão bastante vistosos e a produtividade aumentará consideravelmente. Curso - Data Warehousing 7
4. Data Mart versus Data Warehouse Por muitos anos, todos os sistemas que extraíam dados de sistemas legados e os armazenavam, de maneira utilizável para suporte à decisão, eram chamados data warehouses. Ao longo dos últimos anos, uma distinção tem sido feita entre os data warehouses corporativos e os departamentais data marts, mesmo que, geralmente, o conceito ainda continue sendo chamado de data warehousing. Debates na indústria em geral indicam que aproximadamente 70 a 80 por cento de todos os data warehouses, atualmente em produção, são, de fato, data marts. Na Conferência de fevereiro do Meta Group/DCI 1997 Data Warehouse World Conference, observou-se que o foco dos departamentos de informática tem se transferido da justificação do custo de implementação de data warehouses para a entrega de aplicações de data marts. Os data marts atendem às necessidades de unidades específicas de negócio, ao invés de atender às da corporação inteira. Eles otimizam a entrega de informação de suporte à decisão e se focam na gerência sumarizada e/ou dados exemplificativos ao invés do histórico de níveis atomizados. Eles podem ser apropriados e gerenciados por pessoal fora do departamento de informática das corporações. A crescente popularidade desses mal definidos data marts em cima da popularidade dos grandes sistemas de data warehouses corporativos é baseada em muitos bons motivos: Os data marts têm diminuído drasticamente o custo de implementação e manutenção de sistemas de apoio à decisão e os têm posto ao alcance de um número muito maior de corporações; Eles podem ser prototipados muito mais rápido, com alguns pilotos sendo construídos entre 30 e 120 dias e sistemas completos sendo construídos entre 3 e seis meses; Os data marts têm o escopo mais limitado e são mais identificados com grupos de necessidades dos usuários, o que se traduz em esforço/time concentrado. Os departamentos autônomos e as pequenas unidades de negócio freqüentemente preferem construir o seu próprio sistema de apoio à decisão, via data marts. Muitos departamentos de informática estão vendo a efetividade desta abordagem e estão construindo agora o data warehouse por assunto ou um data mart por vez; ganhando experiência gradualmente e garantindo o suporte dos fatores chave de gerenciamento e vendo, então, benefícios concretos muitas vezes ao ano. Começando com planos modestos e os desenvolvendo à medida que se adquire mais conhecimento sobre as fontes de dados e às necessidades dos usuários, faz com que as organizações justifiquem os data marts enquanto progridem. Algumas vezes, projetos que começam como data warehouses se transformam em data marts. Quando as organizações acumulam grandes volumes de dados históricos para suporte à decisão que se mostram pouco ou nunca utilizados, elas podem reduzir o armazenamento ou arquivamento de informação e contrair o seu data warehouse em um data mart mais focado. Ou, elas podem dividir o warehouse em vários data marts, oferecendo tempo de resposta mais rápido, acesso mais fácil e menos complexidade para os usuários finais. Tanto um Data Warehouse quanto um Data Mart são sistemas orientados a consultas, sobre os quais se produzem processos batch com elevada carga de dados e baixa freqüência. Ambos, data mart e data warehouse, são consultados mediante ferramentas OLAP (On Line Analytical Processing) que oferecem uma visão multidimensional da informação (DALLORA, 2004). Curso - Data Warehousing 8
5. Conclusões A escolha de um data mart ou de um data warehouse é diretamente proporcional à necessidade da empresa e de seus processos de negócio. No entanto, se faz necessário o uso da extração de dados de fontes que em princípio devam ser confiáveis, pois este é o ponto de partida para a carga de dados no banco de dados. A transformação dos dados é o passo seguinte, que deve ser feito de tal forma, que mantenha a qualidade dos dados em questão para então proceder com a devida carga no banco de dados. O processo ETL é fundamental para a manutenção do banco de dados, e deve ser atualizado para adequar-se aos novos processos de negócio que são adotados pela empresa, visto que estes processos geralmente ocorrem em função do dinamismo decorrente do mercado. 6. Atividade Introdução O objetivo desta atividade é mostrar um exemplo prático de implantação de data warehouse; e verificar a habilidade do aluno em identificar os conceitos estudados e as vantagens obtidas pela organização que implantou o data warehouse. Processo Depois de ler e analisar o artigo intitulado Vantagens Obtidas com a Utilização da Implantação do Data Warehouse: Um Estudo de Caso na Unimed de Francisco Beltrão (<Artigo_ Unimed_Unidade7.pdf>), realizar as seguintes atividades: 1. Defina os seguintes termos: data warehouse e data mart. 2. Comente sobre as vantagens obtidas pela Unimed depois de implantar um data warehouse. 3. Quais são os requisitos que uma organização deve cumprir para obter bons resultados com a implantação de um data warehouse? 4. Elabore uma análise crítica do artigo, comentando seu parecer sobre o estudo de caso analisado. Curso - Data Warehousing 9
Materiais complementares INMON, William H.. Como construir o Data warehouse. 2ª ed. New York: Editora Campus, 1997. MACHADO, Felipe Nery Rodrigues. Tecnologia e Projeto de Data Warehouse. 1ª Edição. São Paulo: Editora Érica, 2004, 318p. QUADROS, A. A., MUNIZ, D.B., NETO, D.F., FILHO, J.D. Introdução ao Banco de Dados Data Warehouse, Departamento de Ciência da Computação, Salvador, 14p. HACKNEY, Douglas. Data Warehouse Delivery: Who are You? Part I. DM Review Magazine, v.8, n. 2, 1998. Bibliografia DALLORA. M., GOES, W. M., ROSA, N. A., CORABOLANTE, F. J., SANTOS, F. G., Proposta de utilização de um Data Mart no centro cirúrgico do HCFMRP-USP, ix Congresso Brasileiro de Informática em Saúde, CBIS 2004, Ribeirão Preto, 2004. KIMBALL, Ralph; ROSS, Margy. The Data Warehouse Toolkit Guia Completo para Modelagem Dimensional. Tradução da 2ª. ed. Rio de Janeiro, Campus, 2002 SINGH, H. S. Data Warehouse: conceitos, tecnologias, implantação e gerenciamento. Makron Books, 2001. OLIVEIRA, A. G., DENISE, F. G. Mineração da Base de Dados de um Processo Seletivo Universitário, INFOCOMP, Revista de Ciência da Computação, vol. 3, n.2, nov. 2004. Curso - Data Warehousing 10