12

1 INTRODUO Com a evoluo da tecnologia de informao e o crescimento do uso de computadores interconectados, praticamente todas as empresas de mdio e grande porte esto utilizando sistemas informatizados para realizar seus processos mais importantes, o que com o passar do tempo acaba gerando uma enorme quantidade de dados relacionados aos negcios, mas no relacionados entre si. Estes dados armazenados em um ou mais sistemas operacionais de uma empresa so um recurso, mas de modo geral, raramente servem como recurso estratgico no seu estado original. Os sistemas convencionais de informtica no so projetados para gerar e armazenar as informaes estratgicas, o que torna os dados vagos e sem valor para o apoio ao processo de tomada de decises das organizaes. Verifica-se tambm a transio da sociedade industrial para a sociedade da informao e do conhecimento (compreenda-se como a transio do material ao imaterial), no qual o processo produtivo se baseia no ciclo informacional, que se constitui da aquisio, armazenamento, processamento, difuso e utilizao da informao (CARVALHO, 2000). A criao de Data Warehouses vem de encontro s necessidades atuais das grandes empresas que possuem uma quantidade enorme de dados derivados de transaes dirias, pois as corporaes encontram grandes dificuldades na hora de utilizar estes dados para a tomada de decises (OLIVEIRA, 1998). Em termos simples, um Data Warehouse, ou em portugus, armazm de dados, pode ser definido como um banco de dados especializado, o qual integra e gerencia o fluxo de informaes a partir dos bancos de dados corporativos e fonte de dados externa empresa. Um Data Warehouse (DW) construdo para que tais dados possam ser armazenados e acessados de forma que no sejam limitados por tabelas e linhas estritamente relacionais. A funo do DW tornar as informaes corporativas acessveis para o seu entendimento,

gerenciamento e uso. Como o DW est separado dos bancos de dados operacionais, as consultas dos usurios no impactam nestes sistemas, que ficam resguardados de alteraes indevidas ou perdas de dados. No como um

13

software, que pode ser comprado e instalado em todos os computadores da empresa em algumas horas, na realidade sua implantao exige a integrao de vrios produtos e processos. Um DW oferece os fundamentos e os recursos necessrios para um Sistema de Apoio Deciso (SAD) eficiente, fornecendo dados integrados e histricos que servem desde a alta direo, que necessita de informaes mais resumidas, at as gerncias de baixo nvel, onde os dados detalhados ajudam a observar aspectos mais tticos da empresa. Nele, os executivos podem obter de modo imediato respostas para perguntas que normalmente no possuem respostas em seus sistemas operacionais e, com isso, tomar decises com base em fatos, no com intuies ou especulaes. Com o surgimento do DW so necessrios novos mtodos de estruturao de dados e novas tecnologias, tanto para armazenamento, como para recuperao de informaes. A necessidade destes novos mtodos e tecnologias surgiu da constatao, primeiro de que existe uma necessidade de informao no atendida pelos aplicativos comerciais convencionais, que atuam a nvel operacional do negcio, e segundo, pelo fato de que a tecnologia de armazenamento de dados utilizada nestes aplicativos no atende s necessidades detectadas. Graas aos avanos nos bancos de dados relacionais, no processamento paralelo e na tecnologia distribuda, finalmente a tecnologia da informao pode permitir que qualquer organizao elabore um Data Warehouse.

14

2 REVISO BIBLIOGRFICA Foi no final da dcada de 1940 e no incio da dcada de 1950 que atravs de pesquisas operacionais, teorias comportamentais e cientficas de gerncia e controle de processos estatsticos que formaram a base para os sistemas de apoio deciso. O princpio bsico, e ainda , coletar dados operacionais do negcio e reduzi-los de maneira que pudessem ser utilizados para ajudar a entender e modificar o comportamento da empresa. J entre 1960 e 1970 pesquisadores de Harvard e do Massachusetts Institute of Technology (MIT) comearam a utilizar computadores para auxiliar no processo decisrio. Seu uso era limitado a automatizar a gerao de relatrios. Os sistemas eram criados como verdadeiras ilhas de informao: As aplicaes mantinham seus dados independentes e isolados das outras. Os dados comuns entre aplicaes eram redundantes e, na maioria das vezes, inconsistentes. No existiam mtodos de gerenciamento de dados como recurso e nem para o recolhimento dos benefcios resultantes. Foi em 1970 que aconteceu o advento do armazenamento em disco: Diferente do armazenamento em fita magntica, os dados poderiam ser acessados diretamente e o tempo de processamento era bem menor. Nesta poca, surgiu o termo OLTP Processamento Transaes On-Line, para definir o processamento efetuado pelos sistemas de informao transacionais ou operacionais. Estes sistemas de informao so tambm identificados pela expresso Eletronic Data Processing (EDP), e so necessrios para o controle operacional das organizaes. A partir de 1980 que comeou a utilizao de banco de dados relacional para fins de apoio deciso, sendo que os primeiros usos comerciais foram: a consulta ad hoc e gerao de relatrios (INMON, 1997).

15

Sistemas OLTP fornecem agilidade, segurana e eficincia na insero dos dados em banco de dados, porm a maioria deles falha no fornecimento de anlises significativas e levam muito tempo na recuperao de dados gerenciais. Paralelamente ao advento do OLTP, surgiram os Sistemas de Gerenciamento de Banco de Dados (SGBD). Os SGBDS foram softwares criados para fornecer acesso s informaes e atualizao das mesmas, garantindo a segurana e a integridade de um banco de dados (OLIVEIRA, 1998). Seu objetivo era: potencializar o gerenciamento dos dados como recursos; eliminar as redundncias de informaes existentes nos sistemas

desenvolvidos anteriormente.

Pode-se afirmar que nenhum dos objetivos foi atingido totalmente, pois, mesmo usando softwares gerenciadores de banco de dados, as empresas continuaram criando sistemas isolados em termos de compartilhamento de dados comuns. Alm disso, os profissionais de informtica da poca, apesar de serem pessoas competentes, desenvolviam sistemas sem nenhuma viso metodolgica e com uma preocupao extrema na estruturao e reestruturao do hardware das organizaes. Os sistemas de apoio deciso foram utilizados para fabricar informaes baseadas em uma fonte limitada de dados para otimizar processos os quais dependem de decises prticas e inteligentes. No caso de uma nica fonte de dados, talvez este processo no seja difcil. Porm sistemas de apoio deciso tm dificuldade em trabalhar com vrias fontes de dados (SANTOS, 1999). Os sistemas informatizados vm se espalhando pelas empresas nos ltimos anos, o que levou a um excessivo aumento de informaes processadas e uma distribuio maior destas. Estes fatores tornaram mais difceis a tarefa de gerenciar as informaes pelos sistemas de apoio deciso.

16

Tal dificuldade acarretou o desenvolvimento da tecnologia de DW, a qual tem o foco principal no DW. (armazm de dados). Segundo Inmon (1997), Data Warehouse uma coleo de dados orientados por assuntos, integrados, variveis com o tempo e no volteis, para dar suporte ao processo de tomada de deciso; um banco de dados capaz de lidar com um grande nmero de dados com um desempenho satisfatrio. Para Kimball (1998) um conjunto de ferramentas e tcnicas de projeto, que quando aplicadas s necessidades especficas dos usurios e aos bancos de dados especficos permitir que planejem e construam um Data Warehouse. O Data Warehouse faz parte da tecnologia de data warehousing, a qual foi inventada com o propsito de possibilitar que empresas fossem capazes de acessar seus dados de uma maneira rpida e fcil. O Data Warehousing capaz de integrar os dados da empresa, auxiliando os processos de tomada de deciso (SOARES, 1998). O Ambiente de Data Warehouse (ADW) engloba toda esta tecnologia e acaba se tornando um ambiente de apoio deciso. O ambiente relacional possui uma linguagem especfica para a realizao de consultas, chamada de Structured Query Language (SQL), que proporciona a consulta a campos especficos de um banco de dados que atendem a uma condio (KIMBALL, 1998). De acordo com Hackathorn (1993), o objetivo de um Data Warehouse fornecer uma "imagem nica da realidade do negcio". De uma forma geral, sistemas de Data Warehouse compreendem um conjunto de programas que extraem dados do ambiente de dados operacionais da empresa, um banco de dados que os mantm, e sistemas que fornecem estes dados aos seus usurios. Graas aos avanos nos bancos de dados relacionais, no processamento paralelo e na tecnologia distribuda, finalmente, a tecnologia da informao pode permitir que qualquer organizao elabore um Data Warehouse.

17

De acordo com Han e Kamber (2001), um Data Warehouse possibilita que dados sejam modelados e vistos em mltiplas dimenses. Em termos gerais, dimenses so as perspectivas ou entidades sobre as quais a empresa deseja manter informaes. Sistemas de Data Warehouse revitalizam os sistemas da empresa, pois:

permitem que sistemas mais antigos continuem em operao; consolidam dados inconsistentes dos sistemas mais antigos em conjuntos coerentes;

extraem benefcios de novas informaes oriundas das operaes correntes; provm ambiente para o planejamento e arquitetura de novos sistemas de cunho operacional. Possui as seguintes caractersticas (BERSON e SMITH, 1997):

um banco de dados projetado para anlise, que usa dados de vrias aplicaes;

projetado para um pequeno nmero de usurios com interaes longas; usado basicamente para leitura; atualizado periodicamente (principalmente com adio de dados); contm dados atualizados e histricos para fornecer informaes do fluxo do negcio no tempo;

formado por poucas e grandes tabelas; destina-se realizao de consultas que resultam em um conjunto grande de dados e geralmente envolvem leituras de tabelas inteiras e vrios relacionamentos. O Data Warehouse deve ter os seguintes objetivos (KIMBALL,

1998):

18

tornar a informao mais acessvel; tornar a informao mais consistente, ou seja, informao de qualidade em toda a organizao. Os termos usados em uma parte da empresa devem ter o mesmo significado em toda a empresa;

ser uma fonte de informao adaptvel e malevel. Deve ser projetado para mudana constante sem que todo o sistema tenha que ser alterado;

ser uma fonte segura para proteger a informao na empresa. Nos sistemas de apoio de deciso (em que se encaixa o ADW), os

requisitos so difceis de determinar, o que acarreta a necessidade de ferramentas de alta flexibilidade e customizao. Com a finalidade de suprir esta necessidade so empregados os sistemas OLAP (on-line analytical processing). Estes sistemas possibilitam aos usurios de alto nvel navegarem entre os dados do ambiente de produo com maior facilidade (ANZANELLO, 2002). Para que esse contedo, de depsito de dados, criado a partir dos negcios da organizao, auxilie a anlise e permita o acesso s vrias faces das informaes apresentando a realidade da empresa ele deve se tornar um tipo de banco de dados especializado, onde os dados colhidos de diversas fontes devem ser reunidos, de maneira organizada e eficiente. Isso se faz necessrio porque para o processo de construo de um Data Warehouse preciso ter em mente que o conhecimento vir a partir da transformao do dado. Portanto, pode-se dizer que o Data Warehouse um sistema de coleta de dados, junto a vrios sistemas das diversas reas da organizao de modo a agrup-los disponibilizando o acesso desses dados aos usurios (INMON, 1997).

19

2.1 VISO GERAL SOBRE DATA WAREHOUSE 2.1.1 Planejamento de Data Warehouse H vrias formas de se construir um Data Warehouse, mas toda implementao envolve trabalho em quatro reas essenciais: anlise das fontes dos dados; definio da transformao e da integrao dos processos necessrios para aqueles dados; construo do Data Warehouse propriamente dito e disponibilizao das ferramentas que os usurios empregaro para acessar o Data Warehouse e extrair as informaes de que precisam (KIMBALL, 1998). Ferramentas disponveis que possibilitam a extrao e duplicao de dados, drill down (refinamento), transporte, acesso e administrao de grande volume de informaes em banco de dados devem ser consideradas para a gerao de aplicativos necessrios aos usurios finais, bem como para oferecer-lhes maior auto-suficincia na recuperao e tratamento dos dados e sua conseqente transformao em informaes para tomada de deciso. O acesso aos dados e a disponibilizao desses servios tornam-se aspectos importantes na construo do Data Warehouse (KIMBALL, 1998). O acesso ao DW deve satisfazer duas premissas: os dados demandados pelo cliente e como os resultados devem ser apresentados, levando-se em considerao o nvel de detalhe requerido. O acesso s informaes pode ocorrer por muitos caminhos. Os mais comuns so: consultas estruturadas parametrizadas; consultas estruturadas no-parametrizadas; consultas no-estruturadas, nas quais o usurio pode interagir com as ferramentas e construir sua prpria consulta, fazer anlises estatsticas, cruzar informaes etc.

20

O projeto de um banco de dados fundamenta-se em nove pontos bsicos de deciso, direcionados pelas necessidades do usurio e pelos dados disponveis (KIMBALL, 1998), e consistem em: 1. os processos e, portanto, a identidade das tabelas de fatos; 2. a granularidade (nvel de detalhe) de cada tabela de fatos; 3. as dimenses de cada tabela de fatos; 4. os fatos, incluindo fatos pr-calculados; 5. os atributos da dimenso com descries completas e terminologia apropriada; 6. como rastrear dimenses de modificao lenta; 7. os agregados, dimenses heterogneas, mini dimenses, modos de consulta e outras decises de armazenamento fsico; 8. a amplitude de tempo do histrico do banco de dados; 9. os intervalos em que os dados so extrados e carregados no Data Warehouse. Essa metodologia do tipo top-down (de cima para baixo) porque inicia identificando os principais processos da organizao em que os dados sero coletados. A funo do projetista de Data Warehouse iniciar por fontes de dados existentes (idem, 1998). Um Data Warehouse quase sempre requer dados expressos no nvel de maior detalhe de cada dimenso, no porque as consultas queiram ver registros analticos individuais, mas porque as consultas precisam aprofundar-se no banco de dados de maneira precisa (idem, 1998). Segundo Vidal (1999), apesar da aparncia simples, construir e implantar um Data Warehouse um projeto de impacto em qualquer organizao, mas como o objetivo descobrir maneiras diferentes de atuar no ambiente, e que mudanas internas devem ocorrer para atender novas realidades, compreensvel

21

que hajam dificuldades. Os custos envolvidos aumentam a presso por resultados, e para que estes apaream, recomenda-se iniciar com um projeto piloto de escopo e propores reduzidas, mas com um retorno considervel principalmente no que se refere ao financeiro. No existem ainda metodologias formais para implementao de um Data Warehouse (KIMBALL, 1998), mas existem passos importantes que devem ser seguidos:

definio dos Requisitos de Negcio; modelagem do Negcio; definio das Fontes de Dados; construo do Prottipo; avaliao e Arquitetura; construo e Implementao. Por este motivo vlido afirmar que no existe uma metodologia de

Data Warehouse pronta, ela deve ser adaptada s caractersticas e expectativas de cada organizao.

2.1.2 Processamento analtico versus processamento transacional Segundo Barbieri (2001), as corporaes trabalham basicamente com dois tipos de sistemas: Sistemas transacionais OLTP; Sistemas analticos - OLAP. Os sistemas OLTP so utilizados para registrar as operaes cotidianas dentro de uma empresa e so a principal fonte de dados para os sistemas

22

analticos. J os sistemas analticos trabalham apenas com dados estticos, permitindo apenas a leitura dos mesmos. Para implantao do sistema analtico, existe a necessidade de um repositrio prprio, que pode ser um Data Warehouse ou Data Mart, ou at mesmo um banco de dados relacional (INMON, 1997). Segundo Inmon (1997), para criar um sistema analtico, por exemplo, um Business Intelligence (BI), necessrio criar uma nova infra-estrutura tecnolgica com novo repositrio de dados, com a escolha de novas ferramentas OLAP e de extrao carga de transformao dos dados, totalmente separada do sistema transacional para evitar a perca de desempenho nos sistemas, pois se trabalha com um grande volume de dados. Os sistemas transacionais (OLTP) so os sistemas de apoio s operaes da empresa registrando uma a uma cada operao que precisa de registro. Exemplo claro o registro de uma operao de venda de produto, onde os dados do cabealho da nota fiscal e cada item de seu corpo so registrados no banco de dados do sistema de vendas da empresa. Os sistemas de apoio tomada de deciso (OLAP, DSS Decision Support System, EIS Executive Information System, etc.), onde se tem o Data Warehouse como fonte de dados principal, processam os dados dos sistemas transacionais relevantes s anlises que sero necessrias ao processo analtico. Seguindo o exemplo acima, os dados da nota fiscal sero armazenados no Data Warehouse de forma mais agregada e muito diferente da forma original para facilitar o trabalho das ferramentas analticas (OLAP). Os sistemas transacionais so previsveis e suas funes usadas com freqncia regular. Em suas consultas so acessados pequenos volumes de dados, sobretudo dados correntes exibidos por linha (ocorrncia) das tabelas de dados. Por outro lado, as funes dos sistemas analticos tm uso menos freqentes e imprevisveis. Suas consultas acessam grande quantidade de dados, histricos, atuais e previses, exibindo dados derivados complexos e usualmente resumidos (THOMSEN, 1997).

23

Sistemas transacionais so fundamentais na operacionalizao das organizaes e a base de informaes para os sistemas de informao de apoio a deciso. A segunda metade da dcada de 90 assistiu um intenso movimento de implantao de sistemas integrados de gesto. Com certeza este no foi um processo fcil, tendo sido em muitos casos altamente doloroso e desgastante. Apesar das dificuldades o resultado obtido pela imensa maioria das organizaes foi um ambiente de sistemas e dados integrado, que pavimenta o caminho em direo a sistemas de informao que apiem a tomada de deciso de forma integrada em toda organizao.

2.1.3 O problema de integrao dos dados em Data Warehouse Os DSS e EIS possuem funcionalidade e desempenho diferentes dos sistemas de produo da empresa, que recuperam e atualizam um registro por vez, usualmente atendendo a muitos usurios de forma concorrente, exigindo tambm um tempo de resposta imediato. Os DW normalmente lidam com poucos usurios por vez e os requisitos em termos de tempo de resposta podem no ser crticos. No entanto, usualmente lidam com consultas complexas, no antecipadas ou previstas, envolvendo grande quantidade de registros bsicos referentes aos processos operacionais da empresa. Os aplicativos DSS e EIS necessitam dados consistentes, normalmente originrios de mais de um sistema de produo, organizados de forma que favoream serem trabalhados por ferramentas de anlise de dados:

bancos de dados que oferecem recursos para suporte DSS e EIS devem ser capazes de oferecer um bom tempo de resposta para consultas que recuperam grandes conjuntos de dados agregados e histricos;

DSS e EIS usualmente lidam com tendncias, e no com um nico instante de tempo: cada elemento de dado acompanhado do correspondente perodo de tempo a que se refere.

24

A importncia em separar dados que do suporte aos sistemas de carter operacional da empresa, daqueles que do suporte aos processos gerenciais e de suporte deciso que cada tipo de aplicao pode se concentrar naquilo que faz melhor, oferecendo melhor funcionalidade e desempenho para seu caso especfico. Outro aspecto bastante crtico quanto avaliao das ferramentas e da arquitetura a ser implementada. Estes dois itens esto intimamente ligados e ambos dependem principalmente do volume, da fonte e da caracterstica dos dados envolvidos, que inclusive podem ser um fator impeditivo. Se o modelo proposto e o nvel de granularidade identificados refletirem um nmero elevado de dimenses e ocorrncias, a implementao ganhar um obstculo talvez intransponvel, que o excessivo volume de dados. Um fator crtico de sucesso algo que concorre objetiva e diretamente para que os negcios venham a ser bem sucedidos (CORNELLA, 1994). O mtodo dos fatores crticos composto de cinco etapas bsicas:

determinao dos principais objetivos do conjunto da empresa e de suas diferentes unidades, no horizonte de curto, mdio e longo prazo;

identificao do fator crtico de sucesso para cada um dos objetivos relacionados, ou seja, identificao daquilo que deve acontecer sem nenhuma falha para que o objetivo em questo se cumpra;

especificao da informao necessria para poder satisfazer os fatores crticos de sucesso;

especificao de indicadores para avaliar o estado dos fatores crticos de sucesso, ou seja, avaliar se a empresa como um todo, ou uma determinada unidade, est em condies de cumprir os objetivos.

especificao de indicadores para avaliar os efetivos cumprimentos dos objetivos. Assim como qualquer outra parte do ambiente Data Warehouse, o

modelo de dados precisa ser atualizado com o passar do tempo. Alteraes no

25

ambiente operacional requerem a manuteno do modelo de dados, h diversas circunstncias sob as quais o modelo de dados requer gerenciamento (INMON, WELCH e GLASSEY, 1999).

2.1.4 Arquitetura de um Data Warehouse 2.1.4.1 Arquitetura Genrica Uma arquitetura genrica proposta procura apenas sistematizar papis no ambiente de DW, permitindo que as diferentes abordagens encontradas no mercado atualmente possam se enquadrar nesta descrio genrica (ORR, 1998). Estas estruturas esto divididas nas seguintes camadas: Camadas de Bancos de Dados Operacionais: corresponde aos dados das bases de dados operacionais da organizao junto com dados provenientes de outras fontes externas que sero tratados para compor o DW. Camada de Acesso Informao: a camada com a qual os usurios finais interagem. Representa as ferramentas que o usurio utiliza no dia-a-dia, tal como Excel, SAS e outras. Tambm envolve o hardware e software utilizado para obteno de relatrios, planilhas, grficos e outros. A cada dia surgem sistemas mais sofisticados para manipulao, anlise e apresentao dos dados, incluindo-se ferramentas de data-mining e visualizao. Camada de Acesso aos Dados: esta camada responsvel pela ligao entre as ferramentas de acesso informao e os dados operacionais. Esta camada comunica no s com diferentes SGBDs e sistemas de arquivos de um mesmo ambiente como tambm, idealmente, com outras fontes sob diferentes protocolos de comunicao, no que se chama acesso universal de dados. Camada de Metadados (Dicionrios de Dados): metadados so as informaes sobre os dados mantidos pela empresa (descries de registros

26

em um programa COBOL, comandos CREATE do SQL, informao em um Diagrama Entidade-Relacionamento (DER) e dados em um dicionrio de dados so exemplos de metadados). Para poder manter a funcionalidade de um ambiente de DW necessrio ter disponvel uma grande variedade de metadados. Dados sobre as vises dos usurios devem poder ter acesso aos dados de um DW sem que tenha que saber onde residem estes dados ou a forma como esto armazenados. Camada de Gerenciamento de Processo: a camada de gerenciamento de processo est envolvida com o controle das diversas tarefas a serem realizadas pelo responsvel pelo gerenciamento dos processos que contribuem para manter o DW atualizado e consistente. Camada de Transporte ou Middleware: esta camada gerencia o transporte de informaes pelo ambiente de redes. usada para isolar aplicaes, operacionais ou informacionais, do formato real dos dados nas duas extremidades. Tambm inclui a coleta de mensagens a transaes e se encarrega de entreg-las em locais e tempos determinados. Camada do DW: o Datawarehouse propriamente dito corresponde aos dados usados para fins informacionais. Em alguns casos, DW simplesmente uma viso lgica ou virtual dos dados, podendo de fato no envolver o armazenamento destes dados. Em um DW que exista fisicamente, cpias dos dados operacionais e externos so de fato armazenadas, de modo a prover fcil acesso e alta flexibilidade de manipulao. Camada de Gerenciamento de Replicao: Esta camada inclui todos os processos necessrios para selecionar, editar, resumir, combinar e carregar o DW e as correspondentes informaes de acesso a partir das bases operacionais e fontes externas. Normalmente isto envolve programao complexa, mas cada vez mais so disponibilizadas ferramentas para facilitar estes processos. Esta camada pode tambm envolver programas de anlise da qualidade dos dados e filtros que identifiquem padres nos dados operacionais.

27

Figura 1 - Arquitetura em Camadas

2.1.4.2 Arquitetura de Dados Em termos de ambiente fsico de dados, o DW pode ser centralizado em um nico local ou distribudo setorialmente. A primeira alternativa significa consolidar o banco de dados em um DW integrado. Esta abordagem procura maximizar o poder disponvel (INMON, 1997). Uma segunda abordagem, considerada uma arquitetura federativa, distribuindo a informao por funo, com dados financeiros em um servidor, dados de marketing em outro local, e dados de manufatura em um terceiro lugar. Em uma terceira abordagem, considera-se uma arquitetura de DW por camadas, armazenando dados altamente resumidos em um servidor, dados resumidos ao nvel de detalhe intermedirio em um segundo servidor, e os dados mais detalhados (atmicos) em um terceiro servidor. O primeiro servidor atende a maior parte dos pedidos de dados, com um nmero menor de pedidos passando para a camada 2 e de usurios com baixo volume de dados enquanto servidores nas outras camadas esto mais adequados para processar grandes volumes de dados, mas baixo nmero de usurios.

28

Nesta terceira abordagem comum que, alm das camadas do DW propriamente ditas, encontre-se a camada dos dados operacionais, de onde os dados atmicos so coletados. Estes dados atmicos, em geral, sofreram diversos processos de transformao para fins de integrao, consistncia e acuracidade e constituem o que se chama de Operational Data Store (ODS).

2.1.4.3 Arquitetura de Duas Camadas Existe uma arquitetura de implantao de sistemas de DW que consiste em utilizar um computador de alta capacidade como servidor. Este mtodo disponibiliza aplicaes aos usurios finais na forma de ferramentas front-end, que servem para realizar as consultas, em conjunto com os componentes do servidor com ferramentas back-end, que servem para municiar o DW com informaes (INMON, 1997). Esta arquitetura pode ser chamada de "sistema guarda-chuva", pois possui um formato em que o cabo do guarda-chuva representa o servidor principal e as hastes representam os sistemas de consulta a este servidor. Pode ser usada para construir um sistema de DW em duas camadas, o qual possui os componentes dos clientes (front-end) e os componentes do servidor (back-end). Organizaes que podem crescer com a incorporao de outras empresas do mesmo ramo ou ainda de outro ramo de negcio, gradualmente acumulam diversos sistemas de computao legados, cada um com suas incompatibilidades de definies dos dados. Esta redundncia e falta de consistncia dos dados dificulta a administrao das bases de dados, resultando numa dificuldade tambm para desenvolver-se novas aplicaes front end (INMON, 1997). Esta arquitetura conveniente, uma vez que utiliza os sistemas j existentes na empresa bem como os servidores de bancos de dados e requer um pequeno investimento em hardware e software.

29

Um dos grandes problemas que existe neste tipo de arquitetura o fato de no ser permitido o seu escalonamento; o que resulta no aumento do nmero de usurios e numa performance ruim, pelo gargalo existente entre os clientes e o servidor. Estas anomalias podem ocorrer pelo uso de estaes clientes muito lentas e com muitos processos rodando simultaneamente.

2.1.4.4 Arquitetura de Trs Camadas Para tentar solucionar os problemas de performance resultantes do gargalo da arquitetura de duas camadas, existe uma arquitetura de informao em mltiplas camadas. Esta arquitetura bastante flexvel e suporta um grande nmero de servios integrados, onde a interface do usurio (ferramentas front-end), as funes de processamento do negcio e as funes de gerenciamento do Banco de Dados (BD) so separadas em processos, os quais podem ser distribudos atravs da arquitetura de informao. Este tipo de arquitetura em trs camadas bastante utilizado. Na primeira camada ficam as aplicaes de interface com os usurios, que devem ser grficas e baseadas em rede. Dados e regras de negcio podem ser compartilhados pela organizao, assim como o BD para o DW, ficam armazenados em servidores de alta velocidade na segunda camada, a camada central. Na terceira e ltima camada esto localizadas as fontes de dados. Analisando o ambiente do DW, os servidores de BD e os servidores de aplicaes da camada central provem um acesso eficiente e rpido aos dados compartilhados. Com a separao dos servidores em transacional e analtico podese obter um bom desempenho nas consultas e no processamento, sendo que deve haver disponibilidade de equipamentos e recursos satisfatrios de conexo entre os diversos componentes do sistema.

30

2.1.4.5 Arquitetura segundo Chaudhuri Alm de conhecer os componentes envolvidos na construo do DW necessrio compreender os fluxos de dados que ocorrem no sistema. Conforme Hackathorn (1993), o verdadeiro valor de um sistema de DW no est em apenas colecionar dados, mas sim, gerenciar fluxos de dados. Chaudhuri (1997) prope uma arquitetura, conforme o fluxo e a origem dos dados no sistema de DW, esta arquitetura pode ser dividida em:

fontes de dados de onde o DW ir retirar os seus dados de origem; um conjunto de estruturas de dados analticos armazenados: o DW do sistema;

um Sistema Gerenciador de Banco de Dados (SGBD) otimizado para atender os requisitos analticos dos sistemas de DW;

um componente back end: conjunto de aplicaes responsveis por extrair, filtrar, transformar, integrar e carregar os dados de diferentes origens no DW;

um componente front end: conjunto de aplicaes responsveis por disponibilizar aos usurios finais acesso ao DW;

um repositrio para armazenar e gerenciar os metadados do sistema.

31

Figura 2 Arquitetura segundo Chaudhuri

2.1.5 O projeto de um Data Warehouse Para Inmon (1997), existem dois importantes aspectos vinculados construo do Data Warehouse o projeto da interface com os sistemas operacionais e o projeto do Data Warehouse propriamente dito. De certa forma, projeto no uma descrio exata do que acontece durante a construo do Data Warehouse, uma vez que ele construdo de modo heurstico. Inicialmente povoado com alguns dados, ento so usados e minuciosamente examinados pelo analista de DSS. Em seguida, com base no feedback proporcionado pelo usurio final, os dados so modificados e/ou outros dados so adicionados (INMON, 1997). Para Kimball (1998), a primeira etapa do processo a escolha do fato, o processo de negcios a ser analisado. Devem ser definidas as medidas utilizadas nas anlises, o gro da anlise, que representa o menor grau de detalhe.

32

A segunda etapa a definio do gro do processo de negcio. A partir

do gro, so feitas consolidaes que permitem anlises agregadas. O gro o nvel

fundamental de dados que ser analisado (KIMBALL, 1998). Outras anlises so feitas a partir da agregao deste nvel fundamental.

A terceira etapa a definio das dimenses de anlise. A ltima etapa do processo a escolha dos fatos. Os fatos so medidas numricas que permitem a anlise do processo de negcio atravs das dimenses (idem, 1998). Um processo operacional importante apoiado pelos sistemas legados, a partir dos quais os dados podem ser extrados para serem armazenados. Deve-se tambm escolher a granularidade que o nvel atmico dos dados a serem representados na tabela de fatos, que define o tamanho e o custo. Definir cada dimenso e para cada uma os atributos na forma textual e as hierarquias (ANGELO e GIANGRANDE, 1999). Sobre o assunto costuma-se dizer que o projeto de sistemas de DW, cansativo e penoso. Analisando pelo ngulo das gerncias administrativas, muitas vezes pode-se imaginar que, uma vez que a base de dados transacional j est em funcionamento, torna-se automtica a implantao de sistemas de anlise e suporte deciso. Muitas vezes necessria uma completa reavaliao dos sistemas transacionais para que s ento seja possvel modelar um projeto de DW. De certa forma os projetos de sistemas de apoio tomada de deciso no fogem ao modo tradicional de se implementar e implantar sistemas de informao. Deve ser feita uma anlise do sistema como um todo utilizando-se inclusive da realizao de diversas reunies com os gerentes, funcionrios e outros colaboradores envolvidos no tema. Segundo Kimball (1997), os projetos devem ser inicialmente simples e teis para que possam atingir seus objetivos de forma rpida e clara. No desejvel para uma empresa investir uma quantia em dinheiro e tempo de seus funcionrios em um projeto que pode levar meses para ser concludo e que durante o processo de implantao possa terminar por gerar controvrsias e at mesmo problemas para os setores.

33

Aps a definio das informaes e das tabelas que sero utilizadas para compor as dimenses do modelo necessrio integrar estes dados, avaliando as suas fontes quanto disponibilidade dos dados contidos nestas, e verificando a sua qualidade. As diversas maneiras com que as informaes contidas nestas fontes podem ser referenciadas tambm so caractersticas importantes da integrao, alm de uma viso geral dos sistemas que hoje esto em funcionamento na empresa, mais aqueles que j foram retirados de circulao ou migrados para outras plataformas tanto de hardware quanto de software. Aps a concluso de um projeto inicial bem implantado, com certeza surgiro outros projetos a partir de novas idias dos prprios usurios, e tambm dos projetistas, em funo da experincia adquirida durante o projeto do sistema inicial.

2.2 CARACTERSTICAS DE DATA WAREHOUSE As principais caractersticas da tecnologia Data Warehouse so: orientado por temas, integrado, variado no tempo e no voltil. - Orientado por temas: refere-se ao fato do DW armazenar informaes sobre temas especficos importantes para o negcio da empresa. Os dados operacionais ou funcionais so organizados em torno das aplicaes da empresa, executam e registram as transaes rotineiras necessrias para conduzir o negcio. O Data Warehouse baseia-se nos principais assuntos ou negcios da organizao que tenham sido definidos no modelo de dados (INMON, 1997). As diferenas entre os dados operacionais orientados para aplicao e os dados orientados a assunto so: o relacionamento e o fato do Data Warehouse no armazenar dados que sero usados para processamento de DSS, enquanto o dados orientados para aplicao armazenam dados que podem ou no interessar ao analista de DSS (INMON, 1997).

34

- Integrado: Conforme os dados so trazidos para o DW, eles so convertidos para um estado uniforme, ou seja, sexo codificado apenas de uma forma. Da mesma maneira, se um elemento de dado medido em centmetros em uma aplicao, em polegadas em outra, ele ser convertido para uma representao nica ao ser colocado no DW. Por exemplo, considere-se sexo como um elemento de dado. Uma aplicao pode codificar sexo como M/F, outra como 1/0 e uma terceira como H/M. - Variante no tempo: Segundo Singh (2001), variao com o tempo significa que os dados esto associados a um ponto no tempo (ou seja, semestre, ano fiscal e perodo de pagamento). Para Inmon (1997), todos os dados no Data Warehouse so precisos em algum instante no tempo. No ambiente operacional, os dados esto corretos como no momento do acesso. Em virtude dos dados no DW serem corretos como em algum momento no tempo, no exatamente agora, dito que estes dados variam com o tempo (INMON, 1997). No nvel operacional atuam diversos Sistemas de Informaes de Processamento de Transaes (SPT), tambm chamados de Processamento Transacional On-Line (On- Line Transaction Processing - OLTP). J no Data Warehouse o armazenamento uma seqncia de tempo explcita, onde so transferidos instantneos estticos (static snapshots) do OLTP para o DW como uma seqncia de camada de dados, muito semelhante s formaes geolgicas. O Data Warehouse uma seqncia de tempos, e como os gelogos, pode-se escavar as camadas para saber como eram os negcios no passado. Essa tcnica de DW chamada de mudana gradual nos eixos temporais (slowly changing dimensions), considerada a principal tcnica para representar o passado, onde as duas inconsistncias temporais nos bancos de dados OLTP so resolvidas. A primeira, o Data Warehouse no se modifica durante o dia quando os usurios esto fazendo as suas consultas. A segunda, armazenando as informaes cuidadosamente em cada instantneo no DW, pode-se representar todos os pontos de tempo anteriores corretamente (KIMBALL, 1998). - No voltil: significa que o DW permite apenas a carga inicial dos dados e consultas a estes dados, o chamado ambiente load-and-access (carregue-eacesse). Aps serem integrados e transformados, os dados so carregados em bloco para o DW, para que estejam disponveis aos usurios para acesso. No

35

ambiente operacional, ao contrario, os dados so, em geral, atualizados registro a registro, em mltiplas transaes. Essa volatilidade requer um trabalho considervel para assegurar integridade e consistncia atravs de atividades de rollback, recuperao de falhas, commits e bloqueios. Um DW no requer este grau de controle tpico dos sistemas orientados a transaes. Nos ltimos anos, o conceito de DW evoluiu rapidamente de um considervel conjunto de idias relacionadas para uma arquitetura voltada para a extrao de informao especializada e derivada a partir dos dados operacionais da empresa. O estudo de uma arquitetura descreve o ambiente de DW e permite compreender melhor a estrutura geral de armazenamento, integrao, comunicao, processamento e apresentao dos dados que serviro para subsidiar o processo de tomada de deciso nas empresas (OLIVEIRA, 1998).

2.3 COMPONENTES DE UM DATA WAREHOUSE Sob diversos aspectos, o Data Warehouse demanda um conjunto de caractersticas tecnolgicas mais simples do que seus predecessores (INMON, 1997). Para desenvolver um Data Warehouse necessita-se de uma grande variedade de tecnologias. Conhecer essas tecnologias pode ter uma importncia fundamental para auxiliar a gerenciar melhor o processo, traar um plano de investimentos, cronograma de trabalho e medir o sucesso do projeto. Elas consistem em processos de Data Warehousing, tecnologias de software e hardware (INMON, 1997). O processo Data Warehousing consiste basicamente nos seguintes passos: entendimento, coleta, organizao, armazenamento, atualizao e uso das informaes. Esses so os principais pontos de um projeto, por isso vamos tentar compreender essas seis categorias. - Entendimento consiste no modelo e no dicionrio de dados.

36

- Coleta modelo de dados, converso e extrao e uma grande variedade de softwares. - Organizao modelo e transformao de dados, sistema gerenciador de banco de dados e plataforma de SGBD e gerenciador de metadados. - Armazenamento transformao de dados e SGBD. - Atualizao - transformao e carga de dados e SGBD. - Uso das informaes SGBD, OLAP, data mining, LAN/WAN, sistema operacional de rede, internet e intranet, browser, workstation, programadores e sistemas operacionais. No DW no h atualizaes online; h apenas exigncias mnimas de bloqueio; uma interface de teleprocessamento muito bsica suficiente e assim por diante (INMON, 1997). No que concerne ao DW, no apenas a tecnologia bsica e sua eficincia, como tambm os custos de armazenamento e processamento so fatores importantes.

2.4 METADADOS Os metadados compem o centro nervoso do Data Warehouse. Sem eles, o Data Warehouse e seus componentes associados no ambiente projetado so meramente componentes soltos funcionando independentemente e com objetivos separados (INMON, WELCH e GLASSEY, 1999). Os metadados so um elemento crtico no gerenciamento de dados, um dos mais importantes componentes do Data Warehouse. Os metadados contm, no mnimo:

- a localizao e a descrio de um sistema de DW e os componentes de dados;

37

- nomes, definies, estruturas e contedo do Data Warehouse; - regras de transformao e integrao usadas para povoar um Data Warehouse;

- regras de transformao e integrao usadas para entregar dados s ferramentas analticas de usurio final;

- informao de assinatura para o sistema de entrega da informao; - autorizao de segurana, lista de controle de acesso. atravs dos metadados que se alcana uniformidade e coeso

entre os diferentes componentes do ambiente projetado. A infra-estrutura deve ser construda e mantida em diversas plataformas tecnolgicas e diferentes tecnologias de software (INMON, WELCH e GLASSEY, 1999). Os metadados devem ser extrados da tecnologia encontrada em cada ambiente em que so criados, ou ento devem ser criados como parte da infraestrutura de cada ambiente e neles gerenciados interativamente. Para ser capaz de utilizar os objetos de metadados compartilhados que passam de um ambiente a outro, deve haver compatibilidade entre a infra-estrutura de metadados na estao de trabalho e a tecnologia subjacente que reside na estao de trabalho. No h razo para ter metadados em qualquer parte do ambiente projetado se eles no puderem ser uma parte ativa do desenvolvimento ou anlise (idem, 1999). Existem trs camadas de metadados em um Data Warehouse: Metadados operacionais (do nvel das aplicaes): definem a estrutura dos dados mantidos pelos bancos operacionais, usados palas aplicaes de produo da empresa; Metadados centrais do DW: mantidos no catlogo do DW. Distinguem-se por serem orientados por assunto, definindo como os dados transformados devem ser interpretados. Incluem definies de agregados e campos calculados, assim como vises sobre cruzamentos de assuntos;

38

Metadados do nvel do usurio: mapeiam os metadados do DW para conceitos que sejam familiares e adequados aos usurios finais. Metadados adequadamente criados e mantidos so, portanto,

absolutamente essenciais para a operao do Data Warehouse nos casos em que dados externos esto envolvidos (INMON, 1997). A infra-estrutura de metadados para o ambiente projetado complexa e requer implementao de acordo com mltiplas tecnologias. Para ser capaz de utilizar os objetos de metadados compartilhados que passam de um ambiente a outro, deve haver compatibilidade entre a infra-estrutura e a tecnologia subjacente. No h razo para ter metadados em qualquer parte do ambiente projetado se eles no puderem ser uma parte ativa do desenvolvimento ou anlise (INMON, WELCH e GLASSEY, 1999). A iniciativa de criar um padro para o acesso (esse acesso seria, por exemplo, o word conseguir ler essas informaes) de metadados foi tomada porque era necessrio um padro para acessar, compartilhar e gerenciar metadados. Algumas metas iniciais de comum acordo entre os membros:

- criar um API (Application Programming Interface) para os metadados; - permitir a usurios o controle e gerenciar o acesso e a manipulao dos metadados em um nico ambiente;

- permitir a usurios construir ferramentas de configurao que vo de encontro s suas necessidades;

- permitir o uso de ferramentas individuais para satisfazer seu acesso aos metadados especficos;

definir uma troca simples de implementao de infra-estrutura que acelerar a adoo e minimizar a quantidade de informao requerida para as ferramentas existentes;

- criar um processo no apenas para estabelecer e manter a troca de padro, mas tambm para estender e atualizar quando for necessrio.

39

Uma das mais claras tendncias na rea o aumento nos requerimentos para incorporar dados externos no Data Warehouse. Isto necessrio para reduzir custos e aumentar a competitividade e agilidade de negcios. O processo de integrao de dados externos e internos trazem problemas tona:

- formatos de dados inconsistentes; - dados invlidos ou perdidos; - diferentes nveis de integrao; - inconsistncia semntica; - dados desconhecidos ou questionveis quanto qualidade e tempo. Um problema comum num sistema de Data Warehouse a

incapacidade de comunicar o usurio final qual informao reside num Data Warehouse e como ela pode ser acessada. A chave para prover informao necessria so os metadados. Os metadados precisam guardar informao sobre como um warehouse foi desenhado e montado. Os metadados tambm devem estar disponveis a todos os usurios para gui-los num Data Warehouse (INMON, WELCH e GLASSEY, 1999). Os metadados so definidos como dados dos dados. S que a complexidade desses dados no Data Warehouse aumenta muito. Num sistema OLTP gera-se documentos somente sobre o levantamento dos dados, banco de dados e o sistema que alimenta o mesmo. No Data Warehouse alm do banco, gera-se uma documentao muito maior. Alm de falar sobre o levantamento de dados e o banco, ainda se tem o levantamento dos relatrios a serem gerados, de onde vm os dados para alimentar o DW, processos de extrao, tratamento e rotinas de carga dos dados, as regras de negcio da empresa e todas as mudanas que elas podem ter sofrido, e tambm a freqncia de acesso aos dados. Dados sobre desempenho e monitoramento tambm se qualificam como metadados. Os processos que monitoram o ambiente de uma DW (tais como extrao, carga e uso) criam metadados que so usados para determinar como o

40

sistema vem atuando em termos de desempenho. Da mesma forma, dados que identificam questes relativas qualidade dos dados detectados durante os processos de extrao e carga, devem tambm estar disponveis para os usurios, para que estes possam julgar a acuracidade de suas anlises.

2.5 GRANULARIDADE DE DADOS O mais importante aspecto do projeto de um Data Warehouse a questo da granularidade. A granularidade diz respeito ao nvel de detalhe ou de resumo contido nas unidades de dados existentes no Data Warehouse. Quanto mais detalhe, mais baixo o nvel de granularidade. Quanto menos detalhe, mais alto o nvel de granularidade (INMON, 1997). Quando se tem um nvel de granularidade muito alto o espao em disco e o nmero de ndices necessrios, tornam-se bem menores, porm h uma correspondente diminuio da possibilidade de utilizao dos dados para atender a consultas detalhadas. A granularidade de dados tem se mantido como uma questo de projeto. Nos primeiros sistemas operacionais que foram criados, a granularidade era tida como certa. Quando os dados detalhados eram atualizados, era quase certo que eles seriam armazenados no nvel mais baixo de granularidade. No entanto, no ambiente de Data Warehouse, a granularidade no um pressuposto. Os dados altamente resumidos so compactos e devem ser de fcil acesso, pois fornecem informaes estatsticas valiosas para os Sistemas de Informaes Executivas (EIS), enquanto que nos nveis anteriores ficam as informaes destinadas aos Sistemas de Apoio a Deciso (SAD), que trabalham com dados mais analticos procurando analisar as informaes de forma mais ampla (INOMN, 1993). A razo pela qual a granularidade a principal questo de projeto consiste no fato de que ela afeta profundamente o volume de dados que residem no

41

Data Warehouse e, ao mesmo tempo afeta o tipo de consulta que pode ser atendida. O volume de dados contidos no Data Warehouse balanceado de acordo com o nvel de detalhe de uma consulta (INMON, 1997).

2.5.1 Nveis Duais de Granularidade

Na maior parte do tempo, h uma grande demanda por eficincia no armazenamento de dados e no acesso a eles bem como pela possibilidade de analisar dados em maior detalhe (idem, 1997). Quando uma organizao possui grandes quantidades de dados no Data Warehouse, faz sentido pensar em dois (ou mais) nveis de granularidade na parte detalhada do Data Warehouse. Na realidade, a necessidade de existncia de mais de um nvel de granularidade tamanha que a opo do projeto que consiste em nveis duais de granularidade deveria ser o padro para quase todas as empresas. Para Inmon, 1997, no nvel operacional existe uma tremenda

quantidade de informaes adicionais. A maioria desses detalhes necessria para os sistemas em uso. A segunda camada de dados existentes no Data Warehouse o nvel mais baixo de granularidade armazenada no nvel de dados verdadeiramente histricos. Neste nvel, todos os detalhes vindos do ambiente operacional so armazenados (idem, 1997). Em decorrncia dos custos, da eficincia, da facilidade de acesso e da possibilidade de atender a qualquer consulta que possa ser respondida, para a maior parte das empresas, o nvel dual de dados consiste na melhor opo arquitetnica para o nvel detalhado do Data Warehouse. Outra questo importante do projeto de dados contidos no warehouse, depois da granularidade o particionamento. O particionamento de

42

dados diz respeito repartio dos dados em unidades fsicas separadas que podem ser tratadas independentemente. Freqentemente mencionado que se tanto a granularidade quanto o particionamento forem apropriadamente executados, ento quase todos os outros aspectos de projeto e implementao do Data Warehouse brotaro naturalmente (INMON, 1997).

2.5.2 Qualidade dos dados A qualidade dos dados o estado de perfeio, validade, consistncia e preciso que os dados apresentam durante a sua utilizao. Os dados do DW devem ser confiveis, pois daro suporte tomada de decises. Considerando que os dados so um produto de um processo empresarial, podem-se aplicar neles os mesmos princpios do gerenciamento da qualidade total. Assim, necessrio melhorar os processos empresariais que produzem os dados que povoaro o Data Warehouse e adotar diretrizes para administrar os recursos de dados (idem, 1993), como: administradores de dados - orientados aos negcios, enfocam o significado e o uso dos dados; administradores de banco de dados - orientados tecnologia e enfocam confiabilidade, integridade e desempenho das aplicaes; limpeza de dados - extrao dos dados dos bancos de dados fontes, transformao at deix-los com boa qualidade para carreg-los no DW. Inclui: o elementarizao diviso dos dados at atingirem sua forma mais elementar; o padronizao padronizar formatos, abreviaes, entre outros;

43

o verificao de consistncia verificao de erros nos dados; o emparelhamento verificao de duplicidade dos dados; o verificao domstica (householding) - verificar se existem pessoas com o mesmo endereo e sobrenome, por exemplo, o que pode ser til mais tarde; o documentao Documentar os passos anteriores e armazen-los no banco de dados para metadados. Os esforos com a qualidade dos dados no agregam valor aos mesmos, porm aumentam sua confiabilidade e usabilidade, a fim de satisfazer os usurios.

2.5.3 Segurana dos dados Alm de um projeto de segurana para o ambiente de rede da empresa recomendado um projeto especfico de segurana para o Data Warehouse (INMON, 1993): regras de segurana quais usurio tem acesso e/ou podem fazer manutenes de quais tipos de dados; tecnologia de segurana identificao do usurio, liberao de acesso pelo servidor, caminho de acesso, controle de interrupes, acessos remotos rede; administrao da segurana quem controla as regras de segurana, senhas, comunicao dos esquemas de segurana aos usurios. No projeto do Data Warehouse deve constar toda a poltica de segurana, e esta deve ser assinada pelo presidente da empresa para mostrar que os dados so um recurso importante. A correta utilizao dos equipamentos fsicos

44

deve ser enfocada, como tambm a preveno a vrus e a ataques externos de hackers.

2.6 MODELAGEM DE DADO PARA DATA WAREHOUSE O desenvolvimento modelo interativo de do dados Data tem um papel fundamental os para o de

Warehouse.

Quando

esforos

desenvolvimento so baseados em um nico modelo de dados sempre que for necessrio unir estes esforos os nveis de sobreposio de trabalho e desenvolvimento desconexo sero muito baixos, pois todos os componentes do sistema estaro utilizando a mesma estrutura de dados. Existe um grande nmero de enfoques sobre modelagem de dados j desenvolvidos por vrios autores, a maioria deles pode ser usada para construir um Data Warehouse. Os dois modelos com maior utilizao so: 1) o primeiro modelo foi escrito por Kimball e divide a modelagem dos dados em trs partes: modelo empresarial, modelo dimensional e modelo fsico; 2) o segundo modelo apresentado foi escrito por Inmon e divide a modelagem dos dados em trs partes: a modelagem de alto nvel, a modelagem de nvel intermedirio e a modelagem de baixo nvel.

2.6.1 Modelagem Dimensional ou Multidimensional de Ralph Kimball A modelagem dimensional permite ao usurio observar seu banco de dados no formato de um hipercubo contendo duas, trs ou quantas dimenses forem possveis e aplicveis. Esta modelagem proporciona um ganho de tempo na consulta, uma melhor organizao do sistema e principalmente a sua utilizao de forma intuitiva para o usurio. Modelagem dimensional um nome novo para uma tcnica antiga usada para criar banco de dados simples e compreensveis

45

(KIMBALL, 1998). Essa tcnica segue a chamada escola Ralph Kimball, introdutor do conceito do star schema.

Figura 3 - Hipercubo

As tcnicas de modelagem dimensional de um Data Warehouse, se aplicadas corretamente, garantem que o desenho reflita a forma de pensar dos analistas de negcio e gerentes da empresa e possa ser usado eficazmente para atender os seus requisitos de negcio. Alis, este o princpio bsico da modelagem de um Data Warehouse: discutir diretamente com o usurio final sua viso do modelo de negcios e fazer com que esta viso seja refletida na base de informaes (KIMBALL, 1998). O Data Warehouse deve ser desenhado para transpor os limites de cada um dos sistemas transacionais. Ele construdo para responder questes que no esto limitadas s transaes ou aos sistemas individuais, apresentando, desta forma, uma viso integrada e completa dos negcios. Uma das tcnicas utilizadas para se obter um modelo para o Data Warehouse que identifique e represente as informaes importantes para o modelo de negcios a Modelagem Dimensional ou Multidimensional. Quando bem definido, o Modelo Dimensional pode ser uma ajuda de valor incalculvel para as reas de negcio, apoiando e otimizando todo o processo de tomada de decises (idem, 1998). O Modelo Dimensional representa: os indicadores importantes para uma rea de negcios, que so chamados de fatos ou mtricas; os parmetros atravs dos quais estas mtricas so analisadas pelos usurios, que so chamados de dimenses (as dimenses de negcios).

46

O Modelo Dimensional fornece subsdios para que se respondam perguntas como Qual o total de vendas de cadeiras vermelhas em Curitiba no ms de maro? (HARRISON, 1998), permitindo que se analisem os dados atravs da dimenso tempo, ou cor, ou utilizando-se quaisquer dimenses disponveis para efetuar o cruzamento das informaes e obter o resultado desejado. Harrison (1998) ressalta que o modelo dimensional referenciado com freqncia atravs do termo esquema estrela devido organizao de seu projeto lgico de banco de dados. Este modelo combina tabelas de armazenamento de dados histricos em sries temporais, indexados em chaves dimensionais, descritas em tabelas dimensionais correspondentes (HARRISON, 1998). O Modelo Dimensional, segundo Ballard (2006), tem a capacidade de aumentar a visualizao das vrias apresentaes possveis que podem ser configuradas sobre os dados. Afirma, tambm, que o objetivo deste modelo est relacionado anlise de negcios. A principal contribuio da Modelagem Dimensional a

possibilidade de realizao de anlises mais profundas com simplicidade. Alm disso, o Modelo Dimensional permite a navegao e o fcil entendimento das estruturas dos dados (BALLARD, 2006). O Modelo Dimensional composto, basicamente, da tabela de fatos e suas dimenses (tabelas dimensionais). A tabela de fatos contm os dados mais significativos do negcio que est sendo modelado, possui este nome devido ao relacionamento de todas as dimenses com os fatos (mtricas escolhidas para anlise). Conforme Kimball e Ross (2002), um Modelo Dimensional tem sua tabela dimensional sempre acompanhada das tabelas de fatos, sendo que a primeira deve possuir muitas colunas para representar da melhor forma possvel a rea de negcio modelada. As tabelas dimensionais fornecem a informao que ir descrever a condio em que o fato (mtrica) se realizou. Por este motivo, a

47

quantidade de dimenses ligadas tabela de fatos determina a granularidade da informao, ou seja, o fato (mtrica) ser mais detalhado.

2.6.1.1 Tipos de Modelos Dimensionais 2.6.1.1.1 O Modelo Estrela (Star Schema) Um princpio bsico de projeto de dados de fcil implementao a utilizao do modelo estrela, que significa que h muitos campos em cada tabela em vez de muitas tabelas. A noo de uma estrela sugere que as medidas bsicas de acordo com as quais se gerencia os negcios podem ser armazenadas em uma nica tabela a tabela de fatos e que os atributos significativos descrevendo cada dimenso principal dos negcios podem ser armazenados em tabelas, uma por dimenso (INMON, WELCH e GLASSEY, 1999). Modelos Dimensionais tm uma estrutura distinta como mostra a figura abaixo:

Figura 4 Star Schema Modelo Estrela

Duas vantagens so apresentadas por esse tipo de projeto. A primeira o desempenho de consulta aperfeioado, servidores de banco de dados relacionais simplesmente funcionam melhor quando h menos joins por consulta. A segunda vantagem que os usurios compreendem seus negcios quando colocados nesses termos (INMON, WELCH e GLASSEY, 1999).

48

Abaixo segue uma pequena explicao sobre as variaes do Esquema Estrela: Esquema Estrela com mltiplas tabelas fato: acontece quando existem fatos no relacionados tornando possvel existir mais de uma tabela fato ou quando a freqncia de carga dos dados operacionais distinta. Ex. tabela fato de vendas e tabela fato de vendas previstas. Tabelas Associativas: algumas chaves podem ser desdobradas na tabela fato quando existem relacionamentos muitos-para-muitos. Esquema Estrela com Tabelas Externas: nesse esquema uma ou mais tabelas dimenso podem conter uma chave estrangeira que referencia a chave primria de outra tabela dimenso, podendo tambm ser chamada de tabela dimenso secundria. Esquema floco de neve: o esquema floco de neve uma variao do esquema estrela no qual todas as tabelas dimenso so normalizadas na terceira forma normal (3FN). Reduzem a redundncia, mas aumentam a complexidade do esquema e conseqentemente a compreenso por parte dos usurios. Elas dificultam as implementaes de ferramentas de visualizao dos dados. Impossibilitam o uso de esquemas de indexao mais eficientes como o bitmap indexing. Tabela Multi-Estrela: so assim chamadas quando a chave da tabela fato complementada por mais campos que no so dimenses. Constelaes: quando existem mltiplas tabelas fato que compartilham as mesmas dimenses, dizemos que o esquema de constelaes de fatos. Isto acontece quando as medidas nas tabelas fatos possuem diferenas em relao aos eventos geradores. Vantagens do modelo estrela:

O modelo Estrela tem uma arquitetura padro e previsvel. As ferramentas de consulta e interfaces do usurio podem se valer disso para fazer suas interfaces mais amigveis e fazer um processamento mais eficiente.

49

Todas as dimenses do modelo so equivalentes, ou seja, podem ser vistas como pontos de entrada simtricos para a tabela de fatos. As interfaces do usurio so simtricas, as estratgias de consulta so simtricas, e o SQL gerado, baseado no modelo, simtrico. O Modelo Dimensional totalmente flexvel para suportar a incluso

de novos elementos de dados, bem como mudanas que ocorram no projeto. Essa flexibilidade se expressa de vrias formas, dentre as quais temos: Todas as tabelas de fato e dimenses podem ser alteradas simplesmente acrescentando novas colunas a tabelas. Nenhuma ferramenta de consulta ou relatrio precisa ser alterada de forma a acomodar as mudanas. Todas as aplicaes que existiam antes das mudanas continuam rodando sem problemas. Existe um conjunto de abordagens padres para tratamento de situaes comuns no mundo dos negcios. Cada uma destas tem um conjunto bem definido de alternativas que podem ento ser especificamente programadas em geradores de relatrios, ferramentas de consulta e outras interfaces do usurio. Dentre estas situaes temos: Mudanas lentas das dimenses: ocorre quando uma determinada dimenso evolui de forma lenta e assncrona. Produtos heterogneos: quando um negcio, tal como um banco, precisa controlar diferentes linhas de negcio juntas, dentro de um conjunto comum de atributos e fatos, mas ao mesmo tempo esta precisa descrever e medir as linhas individuais de negcio usando medidas incompatveis. Outra vantagem o fato de um nmero cada vez maior de utilitrios administrativos e processo de software serem capazes de gerenciar e usar agregados, que so de suma importncia para a boa performance de respostas em um Data Warehouse.

50

2.6.1.1.2 O Modelo Floco de Neve (Snow Flake) No modelo Floco de Neve as tabelas dimensionais relacionam-se com a tabela de fatos, mas algumas dimenses relacionam-se apenas entre elas, isto ocorre para fins de normalizao das tabelas dimensionais, visando diminuir o espao ocupado por estas tabelas (KIMBALL, 1998).

Figura 5 Snow Flake - Modelo Floco de Neve

No modelo Floco de Neve existem tabelas de dimenses auxiliares que normalizam as tabelas de dimenses principais. Na figura anterior estas tabelas so (Ano, Ms e Dia) que normalizam a Dimenso Tempo, (Categoria, Departamento e Marca) que normalizam a Dimenso Produto e a tabela Meio que normaliza a Dimenso Promoo. Construindo a base de dados desta forma, passa-se a utilizar mais tabelas para representar as mesmas dimenses, mas ocupando um espao em disco menor do que o Modelo Estrela. Este modelo chama-se Floco de Neve, pois cada dimenso se divide em vrias outras tabelas, onde organizadas de certa forma lembram um floco de neve (KIMBALL, 1998).

51

2.6.1.1.3 Tabela de Fatos A tabela de fatos representa as informaes que sero avaliadas, sendo, normalmente, constituda de valores numricos que representam os objetos da anlise, como por exemplo, total de vendas, total de movimentao e mdia de reservas canceladas. Algumas vezes possvel encontrar Tabelas de Fatos sem valores numricos, nesses casos, normalmente, a tabela de fatos empregada para mapear eventos (KIMBALL, 1997). A Tabela de Fatos normalmente grande, apresentando muitos registros. Esta tabela contm as informaes bsicas do nvel de transao do negcio, de interesse particular a uma aplicao. Uma caracterstica importante da Tabela de Fatos a esparsidade, dessa forma, quando no existem valores para um cruzamento de dimenses, no so armazenados zeros. A Tabela de Fatos armazena as medies numricas de interesse para o negcio. Os projetistas devem dar preferncia aos atributos que representem valores perfeitamente aditivos (idem, 1998). Segundo Kimball (1998), os fatos podem ser classificados em transaes individuais, "snapshots" e linhas de itens. As transaes individuais, normalmente, apresentam uma estrutura muito simples, com um campo acumulado que contm o valor da transao. Os fatos "snapshots" representam medidas de atividades extradas em tempo determinado, como, por exemplo, fim do dia ou fim do ms e os fatos do tipo "linhas de itens" so aqueles que representam

exatamente uma linha de item, como, por exemplo, itens de pedido, itens de entrega e itens de aplice de seguro.

52

2.6.1.1.4 Tabela de Dimenso As tabelas dimensionais contm informaes sobre as dimenses dos dados (perodos de tempo, produtos, compradores, organizao, entre outros). As tabelas dimensionais so normalmente projetadas de uma perspectiva centrada no usurio. Em outras palavras as colunas de descrio e de atributos devem conter descries de textos que sejam significativos aos usurios finais e apropriadas para exibio em um relatrio. No boa idia comprometer o projeto de tabela dimensional para economizar espao em disco (TANLER, 1998). Cada tabela dimensional deve incorporar mltiplos campos de atributos contendo textos e cdigos que descrevam melhor a chave. Os campos de atributos so usados para delimitar ou filtrar o contedo da dimenso. As tabelas dimensionais devem ser utilizadas para suportar variados tipos de inquiries, como E se...?? necessrias para o suporte de decises. Alm disso, usar o uso de regras de filtragens matemticas como maior que, menor que e entre. Conseqentemente, a chave das tabelas de dimenso devem apresentar o nvel de detalhe necessrio para dar suporte ao propsito de negcios para o qual o esquema em estrela foi criado. Isso pode ser diferente para mltiplos esquemas em estrela que contm dados similares, mas em combinaes diferentes (INMON, WELCH e GLASSEY, 1999).

2.6.2 Modelagem Relacional Denormalizada de Bill Inmon O Modelo Entidade-Relacionamento (MER) um modelo de dados conceitual de alto nvel, cujos conceitos foram projetados para estar o mais prximo possvel da viso que o usurio tem dos dados, no se preocupando em representar como estes dados estaro realmente armazenados. O modelo Entidade

Relacionamento utilizado principalmente durante o processo de projeto de banco de dados (MIORELLI, 2000).

53

Um SGBD, armazena e gerencia dados de forma segura e eficiente, baseado no MER, que trabalha com entidades e relacionamentos. Este modelo no se preocupa com arquitetura ou problemas de desempenho que possam ocorrer, pois sero avaliados quando o modelo for implementado. Para gerar o MER so aplicadas regras conhecidas como Normalizao, que foram criadas para reduzir a redundncia dos dados e melhorar o armazenamento dos mesmos. Cada entidade possui um conjunto particular de propriedades que a descreve chamado atributos. Um atributo pode ser dividido em diversas sub-partes com significado independente entre si, recebendo o nome de atributo composto. Um atributo que no pode ser subdividido chamado de atributo simples ou atmico. Os atributos que podem assumir apenas um determinado valor em uma determinada instncia so denominados atributos simplesmente valorados, enquanto que um atributo que pode assumir diversos valores em uma mesma instncia denominado multi valorado. Um atributo que gerado a partir de outro atributo chamado de atributo derivado. Um atributo pode ter valor nulo, ou seja para determinadas situaes no assumir nenhum valor. Uma restrio muito importante em uma entidade de um determinado tipo a chave. Uma entidade possui um atributo cujos valores so distintos para cada uma individualmente. Este atributo chamado atributo chave e seus valores podem ser utilizados para identificar cada entidade de forma nica. Muitas vezes, uma chave pode ser formada pela composio de dois ou mais atributos. Cada atributo simples de um tipo entidade est associado com um conjunto de valores denominado domnio, que especifica o conjunto de valores que podem ser designados para este determinado atributo para cada entidade. As chaves so atributos com caractersitcas especiais, elas podem representar regras e restries que sero implementadas no banco de dados. As chaves podem ser: - Candidatas: Quando o atributo apresenta as caractersticas de ter um nico valor, que no se repete nas demais linhas da tabela;

54

- Primrias: Dentre as chaves candidatas escolhida uma nica que vai ser a chave nica para a tabela (por tabela s deve existir uma chave primria). As demais chaves candidatas podero se tornar ndices; - Concatenadas: Quando a tabela no tiver nenhum atributo que possa ser chave primria, a combinao de dois ou mais campos desta tabela poder se tornar a chave primria; - Estrangeiras: Utilizada para criar os relacionamentos entre as tabelas. Quando uma tabela tem relacionamento com outra, a ligao entre elas feita pela chave primria que passa a ser atributo na outra tabela. O Modelo Relacional a implementao do modelo fsico de Entidade-Relacionamento onde as entidades so representadas por tabelas que so compostas por colunas (atributos) que descrevem linhas de dados, tambm conhecidas como tuple ou registros. Tabela uma relao que consiste em um conjunto de colunas com um ttulo e um conjunto de linhas. Coluna uma tabela vertical onde so selecionados valores do mesmo domnio. Uma linha composta de uma ou mais colunas (INMON, 1997). Em um banco de dados relacional, todos os dados esto em tabelas. Uma tabela mantm dados relacionados com uma classe particular de objetos (uma entidade). Tabelas so compostas por linhas e colunas. Existe exatamente um contedo de dado em cada coluna de cada linha. Este modelo composto por trs nveis de modelagem: a modelagem de alto nvel, de nvel intermedirio e a de baixo nvel. Cada nvel de modelagem tem seu prprio propsito. Conforme Inmon (1997), h quatro elementos bsicos referentes ao nvel intermedirio: um argumento primrio de dados, um argumento secundrio de dados, um conector que representa os relacionamentos dos dados entre as reas de interesse, tipo de dados. O tratamento das informaes til para que possam ser selecionados os itens que realmente interessam para o projeto do DW. A seleo das informaes feita atravs dos seguintes passos:

55

a) Removendo dados operacionais - Os sistemas transacionais necessitam de uma srie de informaes de controle que no sero teis ao sistema de anlise, as quais devem ser ignoradas durante a carga no DW. Alguns dos dados referentes aos cdigos, numricos ou siglas, que possibilitam um relacionamento otimizado entre as diversas tabelas do sistema transacional, os quais foram criados para a normalizao das tabelas, podem ser substitudos por textos legveis alterando cdigos existentes nas dimenses. Existem tambm informaes operativas que esto sendo

constantemente atualizadas, e portanto dificultam a interpretao dos seus contedos em consultas, uma vez que se encontram incompletas; dentre estas informaes que devem ser descartadas esto os flags, os campos de status, totalizaes parciais de valores em contas ainda no encerradas, no caso de faturamento hospitalar, etc. b) Desnormalizando relacionamentos - O processo de normalizao serve para modelar o DER no sentido de definir entidades que so desmembradas de uma tabela, tais como clientes que possuem uma profisso e moram em uma cidade. No caso dos sistemas de apoio deciso, a caracterstica de organizar as informaes em tabelas distintas relacionadas entre si, pode ser uma desvantagem, pois a complexidade para o tratamento destas informaes que agora esto dispersas em vrias tabelas pode comprometer a performance do sistema. Deve-se ento aplicar um processo inverso ao de normalizao, uma vez que os sistemas de DW devem ser to desnormalizados quanto for possvel (SILVA, 1997). Em sistemas desnormalizados reduzida a necessidade de se utilizar joins na elaborao de consultas; para retirar a normalizao podem ser utilizados merges nas tabelas relacionadas do modelo transacional. Se por um lado perde-se a normalizao, por outro se atinge uma melhor performance nas consultas pelo fato de que a estrutura dos dados foi simplificada. Os seguintes tipos de tabelas devem ser desnormalizados (SILVA, 1997):

56

Tabelas que compartilham uma chave comum ou parcial; Tabelas diferentes nas quais os seus dados so freqentemente utilizados juntos;

Tabelas onde o padro de insero aproximadamente o mesmo.

c) Estabelecendo o tipo padro para os atributos - Os padres dos dados em sistemas de DW normalmente referem-se ao tipo e ao tamanho. Existem campos do tipo data com diversos formatos, dependendo do banco de dados utilizado como fonte de dados. Um determinado sistema pode adotar as datas como uma string no formato AAAAMMDD, com o ano nos caracteres representados pela letra "A", o ms na letra "M" e o dia na letra "D". J outro sistema poderia adotar o formato com as barras de diviso, como AAAA/MM/DD. Um terceiro formato pode ser o numrico, onde a data representada pela soma dos dias desde o ano zero. Como se pode notar no exemplo citado acima, ser necessria a converso dos dados de formato de data para um, e somente um, padro prestabelecido pelos projetistas do sistema de apoio deciso. d) Estabelecendo Valores Default - Pela prpria caracterstica dos sistemas de apoio deciso conterem dados de perodos relativamente grandes de tempo, possvel que alguns dados no estejam definidos em determinados momentos representados nos arquivos de fontes de dados. Caso alguns atributos no possuam valores para carregar no DW, o sistema deve prever valores padro que sero inseridos para suprir a sua falta. Estes valores so chamados default, ou seja, informaes que sero inseridas caso no seja possvel determinar qual o dado relativo ao atributo em questo. Vale ressaltar que podero ser inseridos valores nulos (null) ou zerados para suprir estas faltas. e) Modelando as dimenses - As chaves de entrada das tabelas dos sistemas transacionais raramente so utilizadas em sistemas de apoio deciso. Em casos mais simples apenas inserida uma nova dimenso de tempo, porm nos casos

57

mais complexos existe a necessidade de inserir chaves baseadas em processos de hashing que facilitam o acesso aos dados. Segundo Inmon (1996), deve-se reestruturar as chaves quando:

existe a possibilidade de haver alterao na chave e no desejvel a sua reutilizao;

for necessrio rastrear modificaes nos dados; for necessria a criao de itens que iro descrever outros itens agregados. A reestruturao pode ser feita adicionando-se uma chave de tempo.

Esta tarefa pode no ser to fcil como parece, deve ser feita uma anlise a respeito dos perodos de tempo que sero consultados posteriormente, sendo que uma anlise incompleta poder levar a resultados de consultas insatisfatrios para os usurios finais. interessante notar tambm que as informaes de data no devem ser apenas associadas tabela de fatos (INMON, 1996). Os termos operacionais contidos na base de dados transacional devem, preferencialmente, ser substitudos por outros mais ligados s atividades administrativas ao invs de serem tratados como termos tcnicos da rea-fim da entidade, uma vez que o usurio final ser formado por gerentes e tomadores de deciso.

2.7 DATA MART O Data Mart geralmente descrito como um subconjunto dos dados contidos em um Data Warehouse extrado para um ambiente separado (INOMN, WELCH e GLASSEY, 1999). Data Marts so muito teis quando: os dados devem estar segregados para melhorar o desempenho do sistema do ponto de vista do usurio; existir uma cpia dos dados onde s pessoas com autorizao tm o privilgio de acess-las;

58

em um ambiente corporativo, for importante fortalecer o conceito de propriedade dentro do banco de dados. Segundo Kimball (1998), especialista no assunto, um Data Mart,

tambm

conhecido

como

Warehouse

Departamental,

uma

abordagem

descentralizada do conceito de Data Warehouse. Esses ambientes fisicamente distintos trazem benefcios, mas existe um preo a se pagar. Com a presena de muitos Data Marts pode haver o risco de redundncia. A construo de Data Marts deve ter sempre a preocupao de compartilhamento de dados, tabelas e relatrios em comum entre os departamentos. A dificuldade de evitar a redundncia de dados pode ir contra o paradigma de um Data Warehouse j que a separao fsica em diferentes grupos diminui essa habilidade de organizao. Fica clara a necessidade de preservao da consistncia das informaes presentes nos Data Marts atravs da eliminao de redundncias, pois relatrios em comum no podem possuir valores diferentes. Isto uma caracterstica da maioria dos sistemas transacionais das corporaes e deve ser eliminada com a presena de um DW (KIMBALL, 1998). preciso ter em mente que as diferenas entre Data Mart e Data Warehouse so apenas com relao ao tamanho e ao escopo do problema a ser resolvido. Portanto, as definies dos problemas e os requisitos de dados so essencialmente os mesmos para ambos. Enquanto um Data Mart trata de um problema departamental ou local, um Data Warehouse envolve o esforo de toda a empresa para que o suporte decises atue em todos os nveis da organizao. Sabendo-se as diferenas entre escopo e tamanho, o desenvolvimento de um Data Warehouse requer tempo, dados e investimentos gerenciais muito maiores que um data mart (KIMBALL, 1998). Por muitos anos, todos os sistemas que extraam dados de sistemas legados e os armazenavam de maneira utilizvel para suporte a decises eram chamados de Data Warehouses. Ao longo dos ltimos anos, tem sido feita uma distino entre os Data Warehouses corporativos e os Data Marts departamentais, mesmo que geralmente o conceito ainda continue sendo chamado de Data Warehousing.

59

Os Data Marts atendem s necessidades de unidades especficas de negcios, ao invs das da corporao como um todo. Eles otimizam o fornecimento de informaes de suporte a decises e focam a gerncia sumarizada e/ou dados exemplificativos ao invs do histrico de nveis atomizados. Eles podem ser apropriados e gerenciados por pessoal de fora do departamento de informtica das corporaes. A crescente popularidade desses mal definidos Data Marts em cima da popularidade dos grandes sistemas de Data Warehouses corporativos baseada em bons motivos:

Os Data Marts tm diminudo drasticamente o custo de implementao e manuteno de sistemas de apoio a decises, colocando-os posto ao alcance de um nmero muito maior de corporaes;

eles podem ser prototipados muito mais rapidamente, com alguns pilotos sendo construdos entre 30 e 120 dias e sistemas completos sendo construdos entre 3 e seis meses;

os Data Marts tm o escopo mais limitado e so mais identificados com grupos de necessidades dos usurios, o que se traduz em esforo/equipe concentrados. Os departamentos autnomos e as pequenas unidades de negcios

freqentemente preferem construir o seu prprio sistema de apoio a decises via Data Marts. Muitos departamentos de informtica esto vendo a efetividade desta abordagem e esto agora construindo o Data Warehouse por tpico ou um Data Mart por vez, ganhando experincia gradualmente e garantindo o suporte dos fatores-chave de gesto e colhendo benefcios concretos vrias vezes ao ano. Comeando com planos modestos e desenvolvendo-os na medida que se adquire mais conhecimento sobre as fontes de dados e as necessidades dos usurios faz com que as organizaes justifiquem os Data Marts na medida em que progridem (INMON, 1997). Algumas vezes, projetos que comeam como Data Warehouse transformam-se em Data Marts. Quando as organizaes acumulam grandes

60

volumes de dados histricos para suporte deciso que se mostram pouco ou nunca utilizados, elas podem reduzir o armazenamento ou arquivamento de informaes e contrair o seu Data Warehouse para um Data Mart mais focado. Ou elas podem dividir o warehouse em vrios Data Marts, oferecendo tempos de resposta mais rpidos, acesso mais fcil e menos complexidade para os usurios finais.

2.8 DATA MINING o processo de descobrir informaes relevantes, como padres, associaes, mudanas, anomalias e estruturas, em grandes quantidades de dados armazenados em banco de dados, depsitos de dados ou outros repositrios de informao. Devido disponibilidade de enormes quantias de dados em formas eletrnicas, e necessidade iminente de extrair delas informaes e conhecimentos teis a diversas aplicaes, por exemplo na anlise de mercado, administrao empresarial, apoio deciso, e outros, data mining foi popularmente tratado como sinnimo de descoberta de conhecimento em bases de dados (GOLDSCHMIDT e PASSOS, 2005). Talvez a definio mais importante de Data Mining tenha sido elaborada por Usama Fayyad (FAYYAD et al. 1996) como processo no trivial de identificar padres vlidos, potencialmente teis e compreensveis, em um conjunto de dados. Em geral, um processo de descoberta de conhecimento consiste em uma iterao das seguintes etapas: Preparao: o passo onde os dados so preparados para serem apresentados s tcnicas de data mining. Os dados so selecionados (quais os dados que so importantes), purificados (retirar inconsistncias e incompletude dos dados) e pr-processados (reapresent-los de uma maneira adequada para o data mining). Este passo realizado sob a superviso e conhecimento de um especialista, pois o mesmo capaz de definir quais dados so

61

importantes, assim como o que fazer com os dados antes de utiliz-los no Data Mining; Data Mining: onde os dados preparados so processados, ou seja, onde se faz a minerao dos dados propriamente dita. O principal objetivo desse passo transformar os dados de uma maneira que permita a identificao mais fcil de informaes importantes; Anlise de Dados: o resultado do Data Mining avaliado, visando determinar se algum conhecimento adicional foi descoberto, assim como definir a importncia dos fatos gerados. Para esse passo, vrias maneiras de anlise podem ser utilizadas, por exemplo: o resultado do Data Mining pode ser expresso em um grfico, em que a anlise dos dados passa a ser uma anlise do comportamento do grfico. O mtodo tradicional de transformar dados em conhecimento, que depende da anlise manual de dados, est ficando impraticvel em muitos domnios medida que os volumes de dados crescem exponencialmente. A tecnologia atual de banco de dados permite o armazenamento e o acesso aos dados de forma eficiente e barata. Porm, se a origem de dados da rea empresarial, mdica, cientfica ou governamental, o conjunto de dados na forma original tem pouco valor direto. O que de valor o conhecimento que pode ser extrado dos dados e sua utilizao de forma adequada (DINIZ e LOUZADA-NETO, 2000). Descobrir padres teis em dados conhecido em diversas comunidades por nomes diferentes como: extrao de conhecimento, descoberta de informao, colheita de informao, arqueologia de dados e processamento de padro de dados inclusive Data Mining. O termo Data Mining muito usado por estatsticos, pesquisadores de banco de dados e comunidades de negcio GOLDSCHMIDT e PASSOS, 2005). O processo de descoberta de conhecimento em banco de dados interativo e repetitivo, envolvendo vrios passos, conforme descritos a seguir: a) conhecimento do domnio da aplicao - ter conhecimento relevante anterior e as metas da aplicao;

62

b) criao de um banco de dados alvo - selecionar um conjunto de dados ou dar nfase para um subconjunto de variveis ou exemplo de dados nos quais a "descoberta" ser realizada; c) pr-processamento dos dados - fazer operaes bsicas, como remover rudos ou subcamadas se necessrio; coletando informaes necessrias para modelar; decidindo estratgias para manusear dados faltantes e decidindo assuntos como tipos de dados, esquema e mapeamento de valores desconhecidos. Este item prov um resumo conciso e sucinto de uma coleo de dados, com o objetivo de eliminar rudos ou distores; d) reduo de dados - encontrar formas prticas para representar dados. Compreende uma descrio compacta para um subconjunto de dados. Funes mais sofisticadas envolvem regras de resumo, tcnicas de visualizao multivariada e funes de relao entre variveis. Funes de sumarizao so tambm freqentemente utilizadas em mtodos interativos de explorao de anlise de dados e gerao de relatrios; e) escolha da funo - encontrar modelos derivados dos algoritmos; como por exemplo, sumarizao, regresso e classificao; f) encontrar o algoritmo - selecionar mtodos de procura por modelos e decidir quais modelos e parmetros podem ser apropriados; g) minerao de dados - procurar por modelos de interesse numa forma particular de representao ou num conjunto de tais representaes, incluindo regras de classificao ou rvores, regresso, agrupamento, dependncia e anlise linear. A classificao analisa um conjunto de dados de treinamento e constri modelos para cada classe, com base nas caractersticas dos dados. Existem muitos mtodos de classificao desenvolvidos no campo de aprendizagem de mquina, estatstica, redes neuronais e outros. As tcnicas de classificao criam automaticamente um modelo a partir de um conjunto inicial de registros. Esse conjunto chamado de conjunto de treinamento. Os registros do conjunto de treinamento devem pertencer a um pequeno grupo de classes pr-definidas pelos analistas;

63

h) interpretao - visa explicitao do modelo descoberto, removendo modelos redundantes ou irrelevantes e traduzindo os teis em termos compreendidos pelos usurios; i) utilizao das regras descobertas - incorporar este conhecimento no processo. Data Mining uma das ferramentas mais utilizadas para extrao de conhecimento atravs de bancos de dados KDD (Knowledge Discovery in Databases), tanto no meio comercial quanto no meio cientfico (GOLDSCHMIDT e PASSOS, 2005). O termo KDD (Knowledge Discovery in Databases) refere-se ao processo global de descobrimento de conhecimento til em bases de dados. Data Mining um passo particular neste processo-aplicao de algoritmos especficos para extrair padres (modelos) de dados. Os passos adicionais no processo KDD, como preparao de dados, seleo de dados, limpeza de dados, incorporao de conhecimento anterior apropriado e interpretao formal dos resultados de minerao assegura aquele conhecimento til que derivado dos dados. A aplicao cega de mtodos de Data Mining pode ser uma atividade perigosa que conduz descoberta de padres sem sentido (GOLDSCHMIDT e PASSOS, 2005).

Figura 6 - Etapas do processo KDD

O KDD evoluiu e continua evoluindo da interseo de pesquisas em campos como banco de dados, aprendizado de mquinas, reconhecimento de padres, estatsticas, inteligncia artificial, aquisio de conhecimento para sistemas especialistas, visualizao de dados, descoberta cientfica, recuperao de

64

informao e computao de alto-desempenho. Sistemas de software KDD incorporam teorias, algoritmos e mtodos de todos estes campos (ZANUSSO, 2001). As tcnicas de KDD podem ser utilizadas em qualquer domnio de aplicao que contenha razoveis volumes de dados histricos sobre algum assunto. A complexidade do processo de KDD est na dificuldade em perceber e interpretar adequadamente inmeros fatos observveis durante o processo e na dificuldade em conjugar dinamicamente tais interpretaes de forma a decidir que aes devem ser realizadas em cada caso (GOLDSCHMIDT e PASSOS, 2005). Somente a prtica proporciona os meios para desenvolver a intuio muitas vezes necessria coordenao e execuo de aplicaes de KDD, por isso requer um amplo estudo e o domnio sobre a fundamentao terica (envolvendo conceitos, tcnicas e algoritmos) aliada a uma intensa vivncia prtica de diversas experincias reais (GOLDSCHIMDT e PASSOS, 2005).

2.9 ON-LINE ANALYTICAL PROCESSING (OLAP) Partindo dos primrdios da informatizao, quando um sistema que gerava relatrios era a principal fonte de dados residentes na empresa, toda vez que uma anlise necessitasse ser feita, eram necessrios produzir novos relatrios. Estes relatrios tinham que ser produzidos pela rea de informtica e, normalmente, se precisava de muito tempo para ficar pronto. Apresentavam, porm, os seguintes problemas: - Os relatrios eram estticos; - O acmulo de diferentes tipos de relatrios num sistema gerava um problema de manuteno. Ento surgiu o conceito de OLAP (On-Line Analytic Processing). um software cuja tecnologia de construo permite aos analistas de negcios, gerentes e executivos analisar e visualizar dados corporativos de forma rpida,

65

consistente e principalmente interativa. Auxilia o usurio a sintetizar informaes corporativas por meio de vises comparativas e personalizadas, anlises histricas, projees e elaboraes de cenrios (INMON, WELCH e GLASSEY, 1999). A funcionalidade OLAP inicialmente caracterizada pela anlise dinmica e multidimensional dos dados consolidados de uma organizao permitindo que as atividades do usurio final sejam tanto analticas quanto navegacionais Essa tecnologia geralmente implementada em ambiente multiusurio e cliente/servidor, oferecendo assim respostas rpidas s consultas ad-hoc (construo de listagens, interligando a informao disponvel na base de dados conforme as necessidades especficas da empresa, assim como a sua exportao, possibilitando vrias simulaes), no importando o tamanho do banco de dados nem sua complexidade. Hoje em dia, essa tecnologia tambm vem sendo disponibilizada em ambiente Web. Em um modelo de dados OLAP, a informao conceitualmente organizada em cubos que armazenam valores quantitativos ou medidas. As medidas so identificadas por duas ou mais categorias descritivas denominadas dimenses que formam a estrutura de um cubo. Uma dimenso pode ser qualquer viso do negcio que faa sentido para sua anlise, como produto, departamento ou tempo. Este modelo de dados multidimensional simplifica para os usurios o processo de formular pesquisas ou queries complexos, criar relatrios, efetuar anlises comparativas, e visualizar subconjuntos (slice) de maior interesse. Existem diversos operadores OLAP que permitem acessar os dados em modelos multidimensionais (GOLDSCHMIDT e PASSOS, 2005). A seguir encontram-se indicados alguns deles: - Drill up/down utilizado para aumentar ou reduzir o nvel de detalhe da informao acessada; - Slicing utilizado para selecionar as dimenses a serem consideradas na consulta; - Dicing utilizado para limitar o conjunto de valores a ser mostrado, fixando-se algumas dimenses;

66

- Pivoting utilizado para inverter as dimenses entre linhas e colunas; - Data surfing executar uma mesma anlise em outro conjunto de dados. H trs abordagens principais para fornecer capacidades de anlise multidimensional complexa arquitetura de Data Warehouse (INMON, WELCH e GLASSEY, 1999): - gerenciar os dados em um Esquema de Estrela de nvel departamental; - usar ferramenta OLAP verdadeira que possa acessar dados relacionais normalizados; - usar um Banco de Dados multidimensional no nvel departamental. Enquanto a arquitetura de Data Warehouse deve ser independente da tecnologia na qual reside, as arquiteturas de hardware two-tiered e three-tiered fornecem um cenrio til para se discutir as trs abordagens de fornecimento de capacidades OLAP (idem, 1999). Qualquer processamento OLAP que ocorra , em geral, conhecido como OLAP relacional, ou ROLAP, em que uma ferramenta de anlise multidimensional (MDA) no cliente acessa um banco de dados relacional no servidor. Algumas ferramentas MDA tm a habilidade de acessar um banco de dados relacional normalizado adequadamente. Outras ferramentas MDA, contudo, requerem um Esquema em Estrela para facilitar o processamento multidimensional. O Esquema em Estrela pr-processa dados em uma tabela fato central com tabelas dimenso relacionadas (idem, 1999). As chaves nicas de cada tabela de dimenso compem uma chave composta na tabela fato. Os benefcios dessa abordagem so que os dados no Esquema em Estrela so pr-processados em dimenses conhecidas e prcategorizadas com base em um conjunto especfico de necessidades de informaes, tornando mais eficiente o acesso por uma ferramenta MDA no cliente. A desvantagem que o administrador de banco de dados do Data Warehouse deve manter Esquemas em Estrela para cada grupo de necessidades de negcio; alm do fato de que mais objetos de banco de dados significam mais trabalho para o

67

administrador de banco de dados, os Esquemas em Estrela em particular podem requerer muito processamento para serem descarregados, carregados e mantidos (INMON, WELCH e GLASSEY, 1999). Assim como todos os aspectos do gerenciamento do Data Warehouse, o gerenciamento das capacidades de OLAP deve ser conduzido pelas necessidades de negcios quanto a informao, e no por uma ou um conjunto de tecnologias. Uma abordagem baseada em tecnologia ir restringir a capacidades de satisfazer efetivamente as necessidades por informao dos usurios de OLAP medida que as mesmas evolurem com o passar do tempo. O fundamental , porm, que uma abordagem para o fornecimento de OLAP possa ser substituda em algum ponto do futuro; e essa alterao pode trazer diferentes ferramentas, produtos ou tecnologias (idem, 1999).

68

3 Estudo de Caso Visando um melhor entendimento dos conceitos estudados no captulo anterior, foi realizado uma modelagem de um DW simples, utilizando-se o Modelo Esquema de Estrela (Star Schema).

3.1 Escopo O escopo deste estudo, de uma empresa comercial, com pedidos de venda, faturamento de nota fiscal e contas a receber. O movimento utilizado foi do perodo de 01/01/2007 a 30/09/2008. Ser apresentado um DER, para

entendimento dos leitores, e depois, um diagrama com o modelo do DW. Apresentar-se-a tambm algumas telas com o resultado das pesquisas realizadas, utilizou-se o SGBD Oracle 10xe, para a criao do DW e realizado um procedimento de carga de dados, que em situao de produo, poder ser executado diariamente, seguindo padres para que no haja duplicidade de dados.

69

3.2 DER Diagrama Entidade-Relacionamento

Figura 7 DER PARCIAL DAS TABELAS DO SISTEMA DE PRODUO

70

3.3 Esquema de Estrela

Figura 8 DIAGRAMA EM ESQUEMA DE ESTRELA DO DW

71

3.4 Implementao parcial do Estudo de Caso Neste estudo de caso, faremos algumas perguntas para que a resposta seja dada pelo nosso DW. Qual o valor de vendas por consultor em um perodo, neste perodo, quem foi o representante que efetuou a maior venda e qual o valor?
select unique v.id_gerente, v.id_representante, g.representante as gerente, r.representante, sum(v.vl_total_nf) over (partition by v.id_gerente) as total_venda, sum(v.vl_total_nf) over (partition by v.id_representante) as maior_venda vw_nota v, dim_representantes g, dim_representantes r g.id_representante = v.id_gerente r.id_representante = v.id_representante v.data between '01/02/2007' and '31/10/2008' v.id_gerente = 136 by v.id_representante;

from where and and and order

Listagem 1 CDIGO SQL EXECUTADO PARA PESQUISA 1.

Figura 9 RESULTADO DA PESQUISA 1.

72

Qual o valor de vendas de um dos representantes em um perodo, separado por cliente, informando o total de vendas, quantidade de pedidos, o valor mdio dos pedidos, o total de descontos que o cliente teve e o percentual de desconto.

select unique v.id_cliente, c.cliente, sum(v.vl_total_nf) over (partition by v.id_cliente) as total_venda_cliente, count(1) over (partition by v.id_cliente) as qtdade_pedidos, round(sum(v.vl_total_nf) over (partition by v.id_cliente) / count(1) over (partition by v.id_cliente),2) as media_pedido, sum(v.vl_total_desconto) over (partition by v.id_cliente) as total_desconto, round(((sum(v.vl_total_desconto) over (partition by v.id_cliente) / sum(v.vl_total_nf) over (partition by v.id_cliente))*100),4) as pc_desc vw_nota v, dim_cliente c v.id_cliente = c.id_cliente v.data between '01/02/2007' and '31/10/2008' v.id_representante = 133 by v.id_cliente;

from where and and order

Listagem 2 CDIGO SQL EXECUTADO PARA PESQUISA 2.

Figura 9 RESULTADO DA PESQUISA 2.

73

Ranking de produtos vendidos por dia com mais de 40 unidades.

SELECT P.DS_PRODUTO, V.VENDA_DIA, DENSE_RANK() OVER (PARTITION BY DATA ORDER BY VENDA_DIA DESC) AS "RANK" FROM VW_VENDA_PRODUTO V, DIM_PRODUTO P WHERE V.DATA BETWEEN '03/02/2007' AND '03/02/2007' AND P.ID_PRODUTO = V.ID_PRODUTO AND V.VENDA_DIA >= 40;

Listagem 3 CDIGO SQL EXECUTADO PARA PESQUISA 3.

Figura 9 RESULTADO DA PESQUISA 3.

74

Curva ABC de classificao dos produtos.

SELECT P.DS_PRODUTO, V.VENDA_DIA, NTILE(4) OVER (ORDER BY VENDA_DIA DESC) AS "RANK" FROM VW_VENDA_PRODUTO V, DIM_PRODUTO P WHERE V.DATA BETWEEN '03/02/2007' AND '03/02/2007' AND P.ID_PRODUTO = V.ID_PRODUTO AND V.VENDA_DIA >= 40

Listagem 4 CDIGO SQL EXECUTADO PARA PESQUISA 4.

Figura 9 RESULTADO DA PESQUISA 4.

75

4 CONCLUSO A anlise de grandes quantidades de dados pelo homem invivel sem o auxlio de ferramentas computacionais apropriadas. Portanto, torna-se imprescindvel o desenvolvimento de ferramentas que auxiliem, de forma automtica e inteligente, a tarefa de interpretar e relacionar esses dados para que se possa desenvolver e selecionar tticas de ao em cada contexto de aplicao. A tecnologia de Data Warehouse mostra-se interessante para empresas que possuem grandes volumes de dados gerados e acumulados durante sua existncia e necessitam recuperar estes dados de forma que possam auxiliar na tomada de decises estratgicas, de forma rpida e segura. Apesar de possuir uma arquitetura relativamente simples, os processos de extrao, filtragem, carga e recuperao dos dados so bastante complexos, exigindo que pessoas altamente capacitadas faam parte do projeto, para que os objetivos sejam atingidos no menor espao de tempo possvel e sem o gasto de recursos desnecessrios. Como o Data Warehouse no um sistema ou programa, mas sim um ambiente que necessita ser adaptado s necessidades, muitas vezes especficas, os custos envolvidos no projeto podem a princpio no serem justificveis o que pode levar concluso de que melhor comear o projeto com um escopo menor, definindo-se Data Marts departamentais e depois integr-los em um nico Data Warehouse quando os objetivos iniciais j tiverem sido alcanados. Mas faz-se necessrio uma comparao das diversas ferramentas existentes para o acesso aos dados do Data Warehouse, comparando sua funcionalidade e necessidades de armazenamento, alm de diferenciar seus atributos e suas caractersticas. Dessa forma, na construo de um Data Warehouse necessrio definir os elementos envolvidos com o processo de desenvolvimento de tal sistema, em termos de tipo, funes e interaes, o qual faz uso de diversas tecnologias para o gerenciamento do conhecimento dentro de uma organizao, visando tornar a empresa mais competitiva e inteligente.

76

Este estudo contribui para os trabalhos relacionados rea escificamente em se tratando de DW, campo de pesquisa vasto e carente de aprofundamentos. A presente pesquisa, deforma nenhuma esgota o assunto estudado, podendo, para tanto constituir-se em instrumento a ser utilizado futuramente para outros estudos na rea de SGBD.

77

REFERNCIAS ANGELO, Claudio Felisoni de; GIANGRANDE, Relacionamento no Varejo. So Paulo: Atlas, 1999. Vera. Marketing de

ANZANELLO, C. A. OLAP Conceitos e Utilizao. Trabalho de concluso de curso. Instituto de Informtica, Universidade Federal do Rio Grande do Sul, Porto Alegre, RS, 2002. BARBIERI, Carlos. BI Business Intelligence modelagem e tecnologia. Rio de Janeiro: Axcel Books do Brasil, 2001. CARVALHO, Ana Amlia Amorim. A Abordagem da Complexidade: dos princpios gerais sua implementao na Teoria da Flexibilidade Cognitiva e na Instruo Ancorada. In Manuel Alte da Veiga e Justino Magalhes (orgs), Homenagem ao Prof. Dr. Jos Ribeiro Dias, CEEP, Universidade do Minho, 2000. CHAUDHURI, S. An Overview of Data Warehousing and OLAP Technology. Conferncia Internacional SIGMOD Record, 1997. CORNELLA, Alfons. Los Recursos de Informacin: ventaja competitive de las empresas. Madrid: McGraw-hill Interamericana Espaa S/A, 1994. __________. Information System Arquiteture: Development in 90s. New York: John Wiley & Sons, 1993. __________. Information System Arquiteture: Development in 90s. New York: John Wiley & Sons, 1993. DINIZ, C. A. R.; LOUZADA-NETO, F. Data Mining: Uma introduo. Departamento de estatstica UFSCAR, So Carlos, 2000. FAYYAD, U. et al. From Data Mining to Knowledge Discovery: an overview. AAAI Press, 1996. GOLDSCHMIDT, Ronaldo; PASSOS, Emmanuel. Data Mining um guia prtico. Rio de Janeiro: Campus, 2005. HACKATHORN, R. D. Enterprise Database Connectivity: the key to enterprise aplications on the desktop. New York: John Wiley & Sons, 1993. HAN, J.; KAMBER, M. Data Mining. New York: Morgan Kaufmann Publishers, 2001. HARRISON, T. Intranet Data Warehouse. So Paulo: Berkeley, 1998.

78

HTTP://www.datawarehouse.inf.br HTTP://www.dwbrasil.com.br INMON, W. H. Como Construir o Data Warehouse. Rio de Janeiro: Campus, 1997. __________. Information System Architeture: development in 90s. New York: John Wiley & Sons, 1993. __________. Building the Data Warehouse. New York: John Wiley & Sons, 1996. INMON, W. H.; WELCH, J. D.; GLASSEY, Katherine. Gerenciando Data Warehouse. So Paulo: Makron Books, 1999. KIMBALL, Ralph. Data Warehouse Toolkit. So Paulo: Makron Books, 1998. KIMBALL, Ralph; ROSS, Margy. Data Warehouse Toolkit. Nova York: John Wiley & Sons, 2002. MIORELLI, S. H. Proposta de um roteiro para projetar um Data Warehouse. 2000. Disponvel em: http://www.utp.br. OLIVEIRA, Adelize Generini de. Data Warehouse conceitos e solues. Florianpolis: Advanced, 1998. ORR, Ken. Data Warehousing Technology. The Ken Orr Institute, 1998. Disponvel em: http://www.kenorrinst.com. SANTOS. K. M. Um estudo sobre Data Warehouse atravs de uma experincia prtica. Pontifcia Universidade Catlica do Rio Grande do Sul, Porto alegre, RS, 1999. SILVA, Nelson Peres da. Anlise e Estruturas de Sistemas de Informao. So Paulo: Erica, 1997. SINGH, Harry S. Data Warehouse: conceitos, tecnologias, implantao e gerenciamento. So Paulo: Makron Books, 2001. SOARES, V. J. A. Modelagem Incremental no Ambiente de Data Warehouse. Dissertao (Mestrado em informtica) Ncleo de Computao e Eletrnica, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 1998. STANISLAV, Vohnik. Dimension Modeling: In enviroment. Nova York: IBM Corporation, Mar. 2006. a Business Intelligence

79

THOMSEN, E. OLAP Solutions: building multidimensional information systems. New York: John Wiley & Sons, Inc., 1997. VIDAL, Antonio Geraldo da Rocha. Datawarehousing Conceitos Bsicos. Abril 1999. Disponvel em: http://www.datawarehousing.pdf. ZANUSSO, M. Data http://www.dct.ufms.br. Mining. DCT UFMS, 2001. Disponvel em: