DATA WAREHOUSE Data Warehouse
Sumário Conceitos / Autores chave... 3 1. Introdução... 5 2. Características de um Data Warehouse... 6 3. Arquitetura de Data Wirehouse... 8 4. Conclusões... 10 Materiais complementares... 11 Bibliografia... 11
Conceitos / Autores-chave Glossário Data Warehouse Conjunto de tabelas que armazenam os dados dos sistemas de operação (ERPs, tarifadores, etc ) em um modelo multidimensonal, possibilitando a exploração direcionada dos mesmos, melhorando as possibilidades de análises operacionais e gerenciais. Dimensão Conceitualmente são os elementos que participam de um fato, ou assunto de negócio. Cubo Banco de dados multidimensional, geralmente referindo-se a um caso simples de produto, mercado e tempo. Primeiro, oferecem ao 1 projetista uma visão concreta das necessidades e expectativas da comunidade de usuários. As entrevistas criam uma conexão entre as equipes de projetistas do DW e do negócio. Entender o negócio é a moeda de ouro da equipe de projetistas. Essas entrevistas são essenciais ao sucesso do projeto. Database Marketing Conceito lógico de exploração de um data warehouse, onde os dados cadastrais e comportamentais de uma base de dados de clientes são organizados, de forma a favorecer a análise dos acontecimentos do mercado consumidor, prospectar novos clientes e definir possibilidades promocionais para incentivar o consumo. Este modelo de exploração do data warehouse agiliza o desenvolvimento das estratégias de Marketing. Fatos Um fato é uma coleção de itens de dados, composta de dados de medidas e de contexto. Cada fato representa um item, uma transação ou um evento de negócio e é utilizado para analisar o processo de negócio de uma empresa. Pontos Críticos Aspectos relevantes a serem considerados para obter os requisitos de um Data Warehouse Para saber quais informações importantes são necessárias para serem consultadas e analisadas em um data warehouse, devese começar pelas entrevistas com os usuários finais. Estas entrevistas têm duas finalidades. A segunda finalidade das 2 entrevistas permite aos projetistas aumentar o nível de conscientização dos usuários finais quanto à implantação do DW, assim como adequar suas expectativas. Entrevistar o usuário final é sem dúvida uma faca de dois gumes. A equipe de projetistas deve estar preparada para dar continuidade ao projeto, logo após o término das entrevistas, porque o DW estará nas mentes dos usuários (KIMBALL, 2002).
As entrevistas ideais consistem em sessões de uma hora, em que dois ou três projetistas da equipe reúnem-se com um gerente de área e alguns de seus subordinados. As reuniões com muitos participantes de cada departamento são uma perda de tempo. Uma hora de reunião será mais que suficiente para a equipe de DW obter informações iniciais e geralmente é oportuno absorver as principais necessidades do usuário antes de prosseguir com as entrevistas. Em uma organização de grande porte, é aconselhável realizar uma ou duas entrevistas com cada segmento, mesmo que alguns deles não sejam prioritários para o DW. Será especialmente importante incluir tanto o segmento matriz como o filial nas entrevistas principais, além das áreas igualmente importantes. Será melhor não entrevistar todas as equipes de uma determinada área em seqüência, isto é, todas as equipes de marketing, seguidas de todas as equipes de produção e de todas as de vendas. À medida que as entrevistas progridem, os projetistas adquirem maior entendimento do negócio e pode ser útil retornar a um tópico do início do processo, nas últimas entrevistas. O conteúdo das entrevistas finais não deve acrescentar nada de extraordinário às informações coletadas, comprovando dessa forma que todos os aspectos importantes do negócio foram abordados. Caso surjam informações totalmente novas nas etapas finais do processo de entrevistas, então devemos suspeitar de que alguns dos tópicos não foram amplamente cobertos. Deve-se ter cuidado na escolha do usuário que deve ser entrevistado. O mesmo deve ser capaz de responder todas as perguntas sobre o negócio da empresa e especialmente do seu departamento. Importante O segredo de uma boa entrevista é fazer o usuário descrever seu trabalho. Há várias perguntas que resultam em respostas produtivas. A seguir estão algumas delas, mas lembre-se: seja flexível.? Qual a missão do seu grupo/departamento/ divisão? Qual mudança recente na condução do negócio é mais significativa? Como você mede o sucesso em seu grupo? Você consulta os dados diariamente? Você precisa distinguir terças de sábados? Valores acumulados mensais são suficientes para o que você deseja fazer? Finalmente, algumas perguntas sobre urgência: É necessário que os dados de ontem estejam disponíveis hoje? É possível que um grupo precise distinguir terças-feiras de sábados (detalhe dos dados), mas não que os dados de ontem estejam disponíveis hoje (urgência). Quanto tempo, após o fechamento do mês, deve ser gerado o relatório mensal? As respostas a essas perguntas orientarão o projeto do sistema de extração de dados. No final da entrevista, será um bom momento para serem solicitados exemplos de relatórios sobre os temas discutidos. Um processo de entrevista bem sucedido deve resultar num acúmulo de relatórios administrativos.
1. Introdução Devido às constantes mudanças no mercado sócio-econômico e à concorrência acirrada existente entre as empresas, os sistemas de apoio à decisão tornamse elementos decisivos nestas empresas. Além disso, o uso eficiente dos bancos de dados para melhorar a gestão dos negócios e expandir as vendas, tendo o cliente como beneficiário direto, é uma necessidade que se impõe às empresas que queiram se manter competitivas. Normalmente, as bases de dados das empresas possuem uma grande quantidade de dados, e o processo para tomada de decisão sem uma ferramenta adequada, que dê apoio a este processo, torna-se inviável em função do tempo necessário, para acessar esta massa de dados e gerar complexos relatórios. Um caminho utilizado para o apoio ao processo de decisão é empregar uma tecnologia de banco de dados orientada a um Data Warehouse, visto que tão somente um SGBD não é apropriado para trabalhar com grandes quantidades de dados históricos. Os bancos de dados e a teoria de banco de dados estão disponíveis há bastante tempo. As primeiras edições de bancos de dados concentravam-se em um único banco de dados, que atendia a todos os propósitos conhecidos pela comunidade de informática do processamento de transações ao processamento batch (lote) e ao processamento analítico. Na maioria dos casos, o enfoque principal dos primeiros sistemas de banco de dados era o processamento operacional geralmente transacional. Nos últimos anos, surgiu um conceito de banco de dados mais sofisticados um que atende as necessidades operacionais e outro que atende as necessidades informacionais ou analíticas. Até certo ponto, esse conceito mais evoluído de banco de dados se deve ao advento dos PCs, à tecnologia das linguagens de quarta geração, e ao poder de decisão do usuário final. A divisão em banco de dados operacionais e informacionais ocorrem por várias razões: Os dados que atendem às necessidades operacionais são fisicamente diferentes dos dados que atendem às necessidades informacionais ou analíticas. A tecnologia de suporte ao processamento operacional é fundamentalmente, diferente da tecnologia utilizada para prestar suporte a necessidades informacionais ou analíticas. A comunidade de usuários dos dados operacionais é diferente da que é atendida pelos dados informacionais ou analíticos. As características de processamento do ambiente operacional e do ambiente informacional são, fundamentalmente diferentes. Estas são algumas das razões pelas quais a maneira moderna de construir sistemas consiste em separar o processamento e os dados operacionais dos informacionais ou analíticos. Pode-se definir que o processamento informacional ou analítico é o processamento que atende às necessidades dos gerentes durante o processo de tomada de decisões. Geralmente conhecido como sistema de apoio à decisão (SAD), o processamento analítico examina amplos espectros de dados para detectar tendências. Em vez de considerar um ou dois registros de dados (como ocorre no processamento operacional), quando o analista de SAD executa um processamento analítico, muitos registros são acessados. Além disso, o analista de SAD muito raramente atualiza dados. Nos dados operacionais, os dados estão constantemente sendo atualizados no nível de registro individual. No processamento analítico, os registros estão constantemente sendo acessados, e seus conteúdos são agrupados para análise, mas ocorre pouca ou nenhuma alteração dos registros individuais.
2. Características de um Data Warehouse Processamento Analítico No processamento analítico, os requisitos de tempo de resposta são muito atenuados em comparação com o do tradicional processamento operacional. O tempo de resposta analítico alcança de 30 minutos a 24 horas. Os Data warehouses não são construídos de uma única vez, pois eles são projetados e povoados passo a passo, sendo evolucionários. Segundo Inmon (INMON, 1997) Um DW deve ser orientado por assuntos, integrado, variável no tempo e não volátil. A seguir, são apresentadas as principais características de um DW: 2.2 Integração Os dados antes de estarem no banco do DW, geralmente encontram-se armazenados em vários padrões de codificação, isso se deve aos inúmeros sistemas existentes nas empresas, e que eles tenham sido codificados por diferentes analistas. Portanto, os mesmos dados podem estar em formatos diferentes. Para o processamento operacional, tempos de resposta inseridos nessa escala significariam um absoluto desastre. A rede que atende a comunidade analítica é muito menor do que a que atende à comunidade operacional. Normalmente, há muito menos usuários da rede analítica do que da rede operacional. Ao contrário da tecnologia que dá suporte ao ambiente analítico, a tecnologia voltada para o ambiente operacional deve tratar do bloqueio de dados e transações, disputa de dados, e assim por diante. 2.1 Orientação por Assunto O dado é inserido no Data Warehouse decorrente de um ambiente operacional, na grande maioria das vezes. O Data Warehouse é sempre um armazenamento de dados transformados, separados fisicamente do ambiente operacional e da fonte do dado utilizado na aplicação. As diferenças entre aplicações orientadas por processos/funções e as orientadas por assunto estão no conteúdo dos dados e no nível de detalhes dos mesmos. No Data Warehouse são excluídos os dados que não devem ser usados no processo de Suporte a Decisão (DSS), enquanto no ambiente operacional as aplicações contêm dados para satisfazer imediatamente as requisições que podem ou não ser usadas para análise de DSS. Por meio da integração, padronizam-se em uma representação única os dados de todos os sistemas que formarão a base de dados do DW. Por isso, grande parte do trabalho na construção de um DW está na análise dos sistemas operacionais e dos dados que eles contêm. Na figura a seguir é apresentado um ambiente composto de aplicações, definidas como aplicação A, aplicação B e aplicação C. Cada uma destas aplicações pode representar o termo sexo masculino pelo algarismo 0, pela letra M ou H. Da mesma forma, para o sexo feminino, os seguintes caracteres 1, F ou M. Quando da devida integração, realizada de forma automática, desta informação no DW, os dados devem assumir um único padrão. Para o exemplo apresentado, o padrão escolhido foi M e F, para sexo masculino e feminino, respectivamente.
Na figura abaixo são apresentadas as formas de utilização que ocorrem nos Sistema Transacionais e no Data Warehouse. A Diferença dos Dados num Sistema Operacional e no Data Warehouse 2.3 Variação no tempo Em um DW é normal um horizonte de tempo bem superior ao dos sistemas transacionais, ou seja, informações armazenadas, excluídas, atualizadas e consultadas em um período de tempo de segundos. Isso é bastante lógico porque num sistema transacional a finalidade é de fornecer as informações no momento exato, já no Data Warehouse, o principal objetivo é analisar o comportamento das mesmas durante um período de tempo maior. É importante considerar que os dados existentes em um DW são como fotografias (snapshots) e não podem ser atualizados, pois seus dados refletem um estado em um determinado momento do tempo, já nos sistemas operacionais os registros são atualizados constantemente. Este é um dos motivos que fazem com que o DW se torne essencial para uma tomada de decisão, pois é por meio de seus recursos (ferramentas de suporte a análise) que temos a facilidade de verificar os históricos dos principais assuntos. 2.4 Não Volatilidade No Data Warehouse existem somente duas operações, a carga inicial e as consultas dos frontends aos dados. Isso pode ser afirmado porque a maneira como os dados são carregados e tratados é completamente diferente dos sistemas transacionais. Enquanto nesses sistemas temos vários controles e atualizações de registros, em um DW, tem-se somente inserção e consulta de dados. Deve-se considerar que os dados sempre passam por filtros antes de serem inseridos no DW. Uma vez que participam de um ambiente de DW, os dados são dispostos de forma diferente à representação de um sistema transacional. Em outras palavras, a maior parte dos dados é física e radicalmente alterada quando passam a fazer parte do DW. Do ponto de vista de integração, não são mais os mesmos dados do ambiente operacional. À luz destes fatores, a redundância de dados entre os dois ambientes raramente ocorre, resultando em menos de um por cento de duplicações, essa definição é dada por Inmon. As Formas de Atualizações que ocorrem no Sist. Operacional e no DW 2.5 Localização Os dados em um DW podem estar fisicamente armazenados em função de dois conceitos: por meio de uma centralização ou por meio de distribuição. Em um único local, de forma centralizada, o banco de dados supre informação a um DW integrado, e desta forma maximizando o poder de processamento e agilizando a busca dos dados. Esse tipo de armazenamento é utilizado freqüentemente, porém existe a inconveniência de investimentos em hardware para comportar a base de dados muito volumosa, e o poderio de processamento elevado, a fim de atender satisfatoriamente as consultas simultâneas de muitos usuários. Quando o armazenamento é de forma distribuída, fazendo uso de Data Marts, armazenando informações por áreas de interesse. Por exemplo, os dados da gerência financeira num servidor, dados de marketing em outro e dados da contabilidade em um terceiro lugar.
Esta visão tende a ser uma opção interessante para quem precisa de bastante desempenho, pois desta forma minimiza a sobrecarga de um único servidor, e as consultas serão sempre atendidas em tempo satisfatório. 2.6 Particionamento O particionamento dos dados é a repartição dos dados em unidades físicas separadas que podem ser tratadas de forma independente. Dica 2.8 Granularidade Granularidade é o nível de detalhe ou de resumo dos dados existentes num Data Warehouse. Quanto maior for o nível de detalhes, menor será o nível de granularidade. O nível de granularidade afeta diretamente o volume de dados armazenados no DW, e ao mesmo tempo o tipo de consulta e a velocidade de resposta. A figura a seguir apresenta dois tipos diferentes de granularidade. Quando a granularidade e o particionamento forem devidamente executados, os outros aspectos do projeto e implementação ocorrerão de forma natural. 2.7 Credibilidade dos Dados É importante à credibilidade dos dados, como premissa, para o sucesso de qualquer projeto, por exemplo: dados aparentemente simples, como um CEP errado, podem não ter nenhum impacto em uma transação de compra e venda, mas podem influenciar nas informações referentes à cobertura geográfica. É importante também nesta fase procurar sempre evitar dados que não sejam provenientes de fontes seguras, pois estes dados geram relatórios de má qualidade, prejudicando a tomada de decisão e causando altos riscos para a tomada de decisão de um negócio. Níveis de Granularidade 3. Arquitetura de Data Wirehouse Um data warehouse pode armazenar uma grande quantidade de informações, podendo dividi-las em subconjuntos lógicos, chamados data marts. Os data marts focalizam um assunto em específico relativo a empresa (por exemplo, Vendas, Financeiro, Marketing), enquanto um data warehouse tem uma visão mais abrangente, corporativa. As diferenças entre os dois, são: o tamanho e o escopo do problema a ser resolvido. Alguns especialistas preferem, quando da implantação de um data warehouse em uma empresa, começar por áreas específicas (ou seja, implantando data marts em alguns setores da empresa) para por fim, implantar o sistema completo (um data warehouse, a nível de empresa como um todo). Existem grandes diferenças no investimento e no tempo de conclusão do trabalho. Enquanto o custo de implantação de um data mart gira em torno de R$ 100 mil a R$ 1 milhão e leva de 30 a 120 dias para ficar pronto, um data warehouse tem como preço inicial R$ 2 milhões e prazo de 3 a 6 meses para sua conclusão (QUADROS, 2007).
Um Data Warehouse deve ser elaborado conforme as necessidades do usuário, alinhado às suas áreas funcionais na empresa e de acordo com as condições de negócio e as pressões de competitividade. No entanto, são três as arquiteturas mais utilizadas para seu desenvolvimento: Arquitetura Top-down Arquitetura Bottom-up Arquitetura Híbrida Arquitetura Top-Down Esta arquitetura consiste na extração dos dados do DW para os DM s e no seu desenvolvimento. Esse processo inicia-se com a extração, a transformação e a integração das informações dos sistemas utilizados pela empresa e dados externos, para uma área intermediária de preparo dos dados. A partir disso, esses dados são transferidos para o DW. Após essa transferência, os dados são extraídos para os DM s setoriais. A figura ao lado apresenta o modelo da arquitetura Top-Down. Arquitetura Top-Down Arquitetura Bottom-Up O plano arquitetural é um importante fator na elaboração do projeto de um Data Warehouse como ferramenta de comunicação, flexibilidade e planejamento, facilitando o aprendizado e o aumento da produtividade. Para o sucesso na obtenção de um Data Warehouse que atenda as necessidades de informação da Empresa, as sutilezas existentes entre cada uma das abordagens devem ser conhecidas (KIMBALL, 2002). Esta arquitetura consiste na extração dos dados para o DW. Esse processo inicia-se com a extração, a transformação e a integração das informações dos sistemas utilizados pela empresa e dados externos para um ou mais DM s. A partir desses DM s constrói-se o DW incremental para a empresa. Entretanto, devese tomar o cuidado para que esses DM s não se tornem totalmente independentes, causando um problema no carregamento das informações para o DW. A figura ao lado apresenta o modelo da arquitetura Bottom-Up. Importante Arquitetura Bottom-Up Para se construir um DW não basta conhecer a sua arquitetura e níveis de granularidade, deve-se estudar o modelo adequado. Existem modelos do DW tais como o dimensional e multidimensional.
Arquitetura Híbrida Essa abordagem tem como finalidade integrar as abordagens de Top Down e Bottom up, utilizando o que há de melhor nas duas abordagens e tirando proveito da orientação do usuário e da velocidade que existe na abordagem Bottom-up sem prejudicar a integração forçada por um Data Warehouse que existe na abordagem Top-Down. Primeiro todo o Data Warehouse da organização é modelado para posterior implementação de partes desse modelo, representando os assuntos da organização e que serão os Data Marts (HACKNEY, 1998). Uma arquitetura híbrida é apresentada na figura ao lado. Arquitetura Híbrida A elaboração de um data warehouse é uma tarefa que exige conhecimento de modelagem de dados, banco de dados e um profundo conhecimento dos processos de negócio que servirão de base para a construção das tabelas fato e dimensão. 4. Conclusões É importante entender o processo pelo qual deve passar a empresa, durante a elaboração do DW, e para isto a escolha mais adequada quanto à sua arquitetura é fundamental para o sucesso do DW. Neste texto foram apresentados elementos fundamentais para se ter em conta quanto à melhor abordagem a ser praticada durante a etapa de analise dos dados a serem carregados no DW, além disso alguns cuidados quanto a implementa de um DW. 10
Materiais complementares BAPTISTA, E. Um Modelo para Análise Gerencial na Área de Vendas. 2001,108P. Dissertação de Mestrado (Mestrado em Engenharia de Produção) - Universidade Federal de Santa Catarina Santa Catarina, Disponível em: http://teses.eps.ufsc.br/defesa/pdf/4114.pdf Acesso em: 20 de novembro de 2007. NAVARRO, M. c. Tema 127 - ANO III - Nº 27-1996. Ministério da Fazenda, SERPRO. http://www.serpro.gov. br/imprensa/publicacoes/tematec/1996/ttec27/?searchterm=data%20warehouse Acesso em: 20 de novembro de 2007. Bibliografia INMON, William H. Como construir o Data warehouse. 2ª ed. New York: Editora Campus, 1997. KIMBALL, Ralph; ROSS, Margy. The Data Warehouse Toolkit Guia Completo para Modelagem Dimensional. Tradução 2ª. ed., Rio de Janeiro, Campus, 2002. QUADROS, A. A., MUNIZ, D.B., NETO, D.F., FILHO, J.D. Introdução à Banco de Dados Data Warehouse, Departamento de Ciência da Computação, Salvador, 14p, 2007. HACKNEY, Douglas. Data Warehouse Delivery: Who are You? Part I. DM Review Magazine, v.8, n. 2, 1998. 11