Escolar Documentos
Profissional Documentos
Cultura Documentos
0305057
DATA WAREHOUSE
Jaguarina 2006
DATA WAREHOUSE
Monografia apresentada disciplina Trabalho de Concluso de Curso, do Curso de Cincia da Computao da Faculdade de Jaguarina, sob a orientao do Prof. Odair Jacinto da Silva, como exigncia parcial para concluso do curso de graduao.
Jaguarina 2006
Panegassi, Luis Fernando. Data Warehouse. Monografia defendida e aprovada na FAJ em 11 de dezembro de 2006 pela banca examinadora constituda pelos professores:
DEDICATRIA s minhas filhas Audrey Carolina Panegassi e Adrielly Fernanda Panegassi Pelos momentos compartilhados juntos e pela alegria que me proporcionam. A vida se torna muito mais adorvel quando temos inspirao para viv-la.
AGRADECIMENTOS Ao Prof. Odair Jacinto da Silva pela orientao dedicada em todas as fases da realizao deste trabalho. A todos os professores do curso de Cincia da Computao da Faculdade de Jaguarina que tambm contriburam para o meu crescimento pessoal e profissional.
EPGRAFE "O valor das coisas no est no tempo em que elas duram, mas na intensidade com que acontecem. Por isso existem momentos inesquecveis, coisas inexplicveis e pessoas incomparveis". (Fernando Pessoa)
Lista de Siglas
DSS DASD EIS E/S ER ETL IDC I/O ID KDD L4Gs MIS MIT MOLAP MPP OLAP OLTP PCs ROLAP SGBD SAD SQL SMP TI Decision Support Systems Direct Access Storage Device Executive Information Systems Entradas/Sadas Entidade/Relacionamentos Extract, Transform and Load International Data Corporation Imput/Output Identification Knowledge Discovery in Databases Linguagens de quarta gerao Management information systems Massachusetts Institute of Technology Multidimensional On-Line Analytical Processing Matching Pursuit Projection On-Line Analytical Processing On-line Transaction Processing Personal Communications Services Relational On-Line Analytical Processing Sistema de gerenciamento de banco de dados Sistemas de Apoio Deciso Structured Query Language Symmetric Multi-Processing Tecnologia da Informao
Lista de Figuras
Figura 1 Figura 2 Figura 3 Figura 4 Figura 6 Figura 5 Figura 7 Figura 8 Figura 9 Figura 10 Figura 11 Figura 12 Figura 13 Figura 14 Figura 15 Figura 16 Figura 17 Figura 18 Figura 19 Figura 20 Os tipos de consulta Comparao entre Banco de Dados Operacionais e Data Warehouse Nveis de granularidade Arquitetura genrica do Data Warehouse Arquitetura de trs camadas. Arquitetura de duas camadas. Modelo Estrela A dimenso do produto normalizada. Relacional versus Bidimensional Remoo dos dados puramente operacionais. Adio de um elemento de tempo. Introduo de dados derivados Relacionamento entre tabelas no modelo E-R. Incluso de artefatos no data warehouse. Alterao do nvel de granularidade. Unio dos dados de diferentes tabelas Modelo corporativo Selecionando os dados a serem varridos. Introduo intencional de dados redundantes. A tabela de fatos e suas dimenses.
INMON, William H.. Como construir o Data warehouse. 2 ed. New York: Editora Campus, 1997.
RESUMO
O ambiente de dados para suporte aos processos de gerncia e tomada de deciso fundamentalmente diferente do ambiente convencional de processamento de transaes. No corao deste ambiente est a idia do Data Warehouse, integrando e consolidando dados disponveis em diferentes acervos para fins de explorao e anlise, ampliando o contedo informacional destes acervos para atender s expectativas e necessidades de nvel estratgico na empresa. Esta monografia tem por objetivo apresentar o estado da arte da tecnologia de Data Warehouse, introduzindo os principais conceitos na rea e discutindo as diferenas deste ambiente para os ambientes e ferramentas usuais de gerenciamento e tratamento de informaes, alem de mostrar duas formas de extrao de seus dados: a OLAP e o Data Mining, cada uma com suas caractersticas, podendo ser usadas separadamente ou em conjunto para um melhor resultado. Palavras-chave: tomada de deciso, integrando e consolidando dados, tratamento de informaes.
SUMRIO
INTRODUO........................................................................................................................12 CAP. 1 - EVOLUO DOS SISTEMAS DE APOIO DECISO ......................................13 1.1 Histrico ....................................................................................................................13 1.2 O Ambiente projetado ...............................................................................................14 CAP. 2 O QUE DATA WAREHOUSE.............................................................................16 2.1 Histrico ......................................................................................................................16 2.1.1 Origem ..................................................................................................................16 2.2 Definies....................................................................................................................17 2.3 - Caractersticas de um Data Warehouse........................................................................17 2.3.1 - Orientado para reas de interesse ..........................................................................19 2.4 Integrado......................................................................................................................19 2.5 - Variante no tempo ........................................................................................................19 2.6 - No voltil ....................................................................................................................20 2.7 Granularidade ..............................................................................................................20 2.7.1 Nveis duais de granularidade ..............................................................................21 2.8 Metadados....................................................................................................................22 CAP. 3 ARQUITETURA DO DATA WAREHOUSE.........................................................23 3.1 Arquitetura genrica do Data Warehouse....................................................................23 3.2 Outras arquiteturas.......................................................................................................25 3.2.1 Arquitetura de duas camadas................................................................................25 3.2.2 Arquitetura de trs camadas .................................................................................26 CAP. 4 MODELO DE DADOS DO DATA WAREHOUSE ...............................................28 4.1 - A Questo das Dimenses............................................................................................28 4.2 - Esquemas do tipo Estrela e Floco de Neve ..................................................................29 4.2.1 Vantagens do modelo estrela................................................................................31 4.2.2 - Bancos de Dados Multidimensionais ....................................................................32 4.3 Converso do modelo E-R para o modelo do Data Warehouse ..................................32 4.3.1 - Remoo dos dados puramente operacionais........................................................33 4.3.2 - Adio de um elemento de tempo na estrutura da chave ......................................33 4.3.3 - Introduo de dados derivados..............................................................................34 4.3.4 - Transformao de Relacionamentos entre dados em artefatos dos dados ............34 4.3.5 - Acomodao dos diferentes nveis de granularidade ............................................36 4.3.6 - Unio dos dados comuns de diferentes tabelas .....................................................36 4.3.7 - Criao de arrays de dados....................................................................................37 4.4 Data Marts ......................................................................................................................38 CAP. 5 DESENVOLVIMENTO DO DATA WAREHOUSE..............................................39 5.1 - Estratgia Evolucionria ..............................................................................................40 5.2 - Aspectos de Modelagem ..............................................................................................40 5.3 Tcnicas de gerenciamento da quantidade de dados operacionais pesquisados..........41 5.4 Tcnicas para incrementar a performance ...................................................................43 5.5 - Etapas do Desenvolvimento de um Data Warehouse ..................................................46 5.6 Relacional versus multidimensional............................................................................47 5.6.1 - Um ou mais bancos ...............................................................................................48 CAP. 6 CARREGANDO O DATA WAREHOUSE ............................................................50 6.1 Extrao .......................................................................................................................50 6.2 Transformao e filtros................................................................................................51 6.3 - Derivao e Sumarizao .............................................................................................52
CAP. 7 EXTRAINDO INFORMAES DO DATA WAREHOUSE ................................53 7.1 - Ferramentas OLAP.......................................................................................................53 7.1.1 - MOLAP x ROLAP................................................................................................55 7.2 - Ferramentas Data Mining.............................................................................................57 CONCLUSO..........................................................................................................................59 BIBLIOGRAFIA ......................................................................................................................61
INTRODUO
Hoje em dia uma organizao precisa utilizar toda informao disponvel para criar e manter vantagem competitiva. Sai na frente organizao que consegue tomar decises corretas e rpidas. Com esta importante tarefa nas mos, profissionais tomadores de deciso tais como executivos, gerentes e analistas, exigem dos sistemas de suporte deciso DSS (Decision Support Systems) mais recursos para anlise, front-ends que suportem consultas ad hoc, interfaces grficas apropriadas, etc. A idia de Data Warehouse integrar os dados internos e externos de uma organizao em uma estrutura nica permitindo uma melhor utilizao dos dados pelos analistas, gerentes e executivos. Uma vez obtida a integrao, sistemas como OLAP (On-Line Analytical Processing) e Data Mining fornecem mecanismos sofisticados para anlise dos dados. Estudar e conhecer a tecnologia de Data Warehouse pode ajudar os empresrios a descobrir novas formas de competir em uma economia globalizada, trazendo melhores produtos ou servios para o mercado, mais rpido do que os concorrentes, sem aumentar o custo do produto ou do servio. No existem ainda metodologias formais para implementao de um Data Warehouse, ela deve ser adaptada s caractersticas e s expectativas de cada empresa, mas o principal objetivo em todas elas o de descobrir maneiras diferentes de atuar no mercado e quais as mudanas internas que devem ocorrer para atender as novas realidades. Este trabalho tem como objetivo fazer um estudo dos principais conceitos necessrios para o desenvolvimento de um ambiente de Data Warehouse. No captulo I apresentada a evoluo dos sistemas de apoio deciso e o motivo do surgimento da necessidade do Data Warehouse. No captulo II iniciam-se os conceitos sobre o Data Warehouse, mostrando suas caractersticas bsicas. O captulo III mostra as arquiteturas disponveis para construo de Data Warehouses, e no captulo IV os modelos de dados. O captulo V mostra alguns detalhes do desenvolvimento propriamente dito do Data Warehouse. O captulo VI mostra as tcnicas para extrair as informaes dos sistemas existentes e transforma-las adequadamente para o Data Warehouse. E finalmente no captulo VII so apresentadas as tcnicas para extrao e analise dos dados de um Data Warehouse que so: OLAP e Data Mining.
Figura 1 Os tipos de consulta. Nos tipos de consultas as informaes ficam disposio com as seguintes caractersticas: Dados primitivos: baseados em aplicaes, detalhados, podem ser atualizados, exatos em relao ao momento do acesso e so processados repetitivamente.
Dados derivados: baseados em assuntos ou negcios, resumidos, ou refinados, no so atualizados, representam valores de momentos j decorridos ou instantneos e so processados de forma heurstica.
2.1.1 Origem
Segundo Haisten (1999), a origem do Data Warehouse vem dos estudos do MIT (Massachusetts Institute of Technology) nos anos 70 que focavam o desenvolvimento de uma arquitetura tcnica mais eficiente para sistemas de informaes. Pela primeira vez foi feita uma distino entre sistemas operacionais e aplicaes analticas e surgiu o princpio de separar esse dois tipos de processamentos em projetos e armazns de dados diferentes. Para Ballard & Herreman (1998) e Teresko (1999), o conceito de Data Warehouse surgiu no inicio dos anos 80 quando os sistemas gerenciais de banco de dados (SGBD) emergiram como produtos comerciais com facilidades para a computao de apoio a deciso (SAD). Teresko (1999) comenta que Bill Inmon, observou que estes repositrios de informaes poderiam ser organizados em um bem corporativo que ele chamou de Data
Warehouse e por causa disso Inmon considerado o pai do Data Warehouse. No inicio, o Data Warehouse consistia de instantneos, ou subconjuntos dos dados operacionais que eram carregados em banco de dados de apoio a deciso em perodos regulares que costumavam ser semanais ou mensais (Ballard & Herreman, 1998).
2.2 Definies
A definio clssica de Data Warehouse criada por Inmon (1997) a seguinte: Data Warehouse uma coleo de dados orientada por assuntos, integrada, variante no tempo, e no voltil que tem por objetivo dar suporte aos processos de tomada de deciso. Knowles (1996) utiliza um lgica interessante para dizer como o Data Warehouse importante para a empresa: Poder faz dinheiro. Conhecimento poder. Data Warehouse aumenta o conhecimento. Portanto, Data Warehouse faz dinheiro.. Gurovitz (1999) cita um estudo do IDC (International Data Corporation) que coloca o Data Warehouse como a melhor chance para a TI (Tecnologia da Informao) mostrar ao que veio gerando ganhos de tempo e dinheiro com informaes acessveis aos executivos quando e como eles quiserem. Segundo Ralph Kimball (1998), uma autoridade nesse assunto, Data Warehouse o lugar onde as pessoas podem acessar seus dados. J Wang (1998) tem uma definio um pouco mais elaborada quando diz que Data Warehouse o processo pelo qual os dados relacionados de vrios sistemas operacionais so fundidos para proporcionar uma nica e integrada viso de informao de negcios que abrange todas as divises de empresa..
armazenados em sistemas de informaes dedicados a ajudar os profissionais de negcio a tomarem decises mais rpidas e efetivas. Para entender melhor o que um Data Warehouse vamos fazer uma comparao entre ele e os bancos de dados operacionais [DAL99].
Figura 2 Comparao entre Banco de Dados Operacionais e Data Warehouse. O Data Warehouse um banco de dados contendo dados extrados do ambiente de produo da empresa, que foram selecionados e depurados, tendo sido otimizados para processamento de consulta e no para processamento de transaes. Em geral, um Data Warehouse requer a consolidao de outros recursos de dados alm dos armazenados em banco de dados relacionais, incluindo informaes provenientes de planilhas eletrnicas, documentos textuais, etc. importante considerar, no entanto, que um Data Warehouse no contm apenas dados resumidos, podendo conter tambm dados primitivos. desejvel prover ao usurio a capacidade de aprofundar se num determinado tpico, investigando nveis de agregao menores ou mesmo o data primitivo, permitindo tambm a gerao de novas agregaes ou correlaes com outras variveis. Alm do mais, extremamente difcil prever todos os possveis dados resumidos que sero necessrios:
limitar o contedo de um Data Warehouse apenas a dados resumidos significa limitar os usurios apenas s consultas e anlises que eles puderem antecipar frente a seus requisitos atuais, no deixando qualquer flexibilidade para novas necessidades.
2.4 Integrado
Refere-se consistncia de nomes, das unidades das variveis, etc., no sentido de que os dados foram transformados at um estado uniforme. 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. Conforme os dados so trazidos para o Data Warehouse, 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 Data Warehouse.
O tratamento de sries temporais apresenta caractersticas especficas, que adicionam complexidade ao ambiente do Data Warehouse. Processamentos mensais ou anuais so simples, mas dias e meses oferecem dificuldades pelas variaes encontradas no nmero de dias em um ms ou em um ano, ou ainda no incio das semanas dentro de um ms. Alm disso, deve-se considerar que no apenas os dados tm uma caracterstica temporal, mas tambm os metadados, que incluem definies dos itens de dados, rotinas de validao, algoritmos de derivao, etc. Sem a manuteno do histrico dos metadados, as mudanas das regras de negcio que afetam os dados no Data Warehouse so perdidas, invalidando dados histricos.
2.6 - No voltil
Significa que o Data Warehouse permite apenas a carga inicial dos dados e consultas a estes dados. Aps serem integrados e transformados, os dados so carregados em bloco para o Data Warehouse, para que estejam disponveis aos usurios para acesso. No ambiente operacional, ao contrrio, os dados so, em geral, atualizados registro a registro, em mltiplas transaes. Esta volatilidade requer um trabalho considervel para assegurar integridade e consistncia atravs de atividades de rollback, recuperao de falhas, commits e bloqueios. Um Data Warehouse no requer este grau de controle tpico dos sistemas orientados a transaes.
2.7 Granularidade
Granularidade diz respeito ao nvel de detalhe ou de resumo contido nas unidades de dados existentes no Data Warehouse. Quanto maior o nvel de detalhes, menor o nvel de granularidade. O nvel de granularidade afeta diretamente o volume de dados armazenado no Data Warehouse e ao mesmo tempo o tipo de consulta que pode ser respondida. Quando se tem um nvel de granularidade muito alto o espao em disco e o nmero de ndices necessrios se tornam bem menores, porm h uma correspondente diminuio da possibilidade de utilizao dos dados para atender a consultas detalhadas [DAL99]. H, portanto, um bom motivo para a compactao de dados em um Data Warehouse. Quando os dados so compactados ocorre uma economia incomum sobre o total de DASD
utilizado, o nmero de ndices necessrios e os recursos de processador necessrios para o tratamento dos dados. No entanto, h um outro aspecto da compactao de dados que ocorre medida que o nvel de granularidade elevado. medida que o nvel de granularidade se eleva, h uma correspondente diminuio da possibilidade de utilizao dos dados para atender a consultas. J com um nvel mais baixo de granularidade possvel responder a qualquer consulta [INM97]. Devemos lembrar, porm que em um ambiente de Data Warehouse, dificilmente um evento isolado examinado. mais comum ocorrer a utilizao de uma viso de conjunto dos dados.
Baixa granularidade
Alta granularidade
2.8 Metadados
Os metadados so de grande importncia para o processo de controle das operaes em um Data Warehouse. Os metadados so dados acerca dos dados constantes no Data Warehouse. Durante todas as fases do projeto de um Data Warehouse, e tambm aps o incio de sua operacionalizao, metadados devem ser armazenados. Existem no mercado ferramentas prprias para armazenar e gerenciar metadados, dos quais o Sybase Warehouse Control Center e o Prism Warehouse Directory so exemplos. Segundo Inmon (1997), os metadados so informaes sobre o que est aonde no Data Warehouse. Os aspectos sobre os quais os metadados mantm informaes so: A estrutura dos dados, segundo a viso do programador; A estrutura dos dados segundo a viso dos analistas de sistemas de apoio deciso; A fonte de dados que alimenta o Data Warehouse; A transformao sofrida pelos dados no momento de sua migrao para o Data Warehouse; O modelo de dados; O relacionamento entre o modelo de dados e o Data Warehouse; O histrico das extraes de dados.
Camadas de bancos de dados operacionais e fontes externas: composto pelos dados dos sistemas operacionais das empresas e informaes provenientes de fontes externas que sero integradas para compor o Data Warehouse; Camada de acesso informao: Envolve o hardware e o software utilizado para obteno de relatrios, planilhas, grficos e consultas. nesta camada que os usurios finais interagem com o Data Warehouse, utilizando ferramentas de manipulao, anlise e apresentao dos dados, incluindo-se as ferramentas de Data Mining e visualizao; Camada de acesso aos dados: Esta camada faz a ligao entre as ferramentas de acesso informao e os bancos de dados operacionais. Esta camada se comunica com diferentes sistemas de bancos de dados, sistemas de arquivos e fontes sob diferentes protocolos de comunicao, o que se chama acesso universal de dados; Camada de metadados (Dicionrio de dados): Metadados so as informaes que descrevem os dados utilizados pela empresa, isto envolve informaes como descries de registros, comandos de criao de tabelas, diagramas Entidade/Relacionamentos (ER), dados de um dicionrio de dados, etc. necessrio que exista uma grande variedade de metadados no ambiente de Data Warehouse para que ele mantenha sua funcionalidade e os usurios no precisem se preocupar onde residem os dados ou a forma com que esto armazenados; Camada de gerenciamento de processos: a camada responsvel pelo gerenciamento dos processos que contribuem para manter o Data Warehouse atualizado e consistente. Est envolvida com o controle das vrias tarefas que devem ser realizadas para construir e manter as informaes do dicionrio de dados e do Data Warehouse; Camada de transporte: Esta camada gerencia o transporte de informaes pelo ambiente de rede. Inclui a coleta de mensagens e transaes e se encarrega da entrega em locais e tempos determinados. Tambm usada para isolar aplicaes operacionais ou informacionais, do formato real dos dados nas duas extremidades; Camada do Data Warehouse: o Data Warehouse propriamente dito, corresponde aos dados utilizados para obter informaes. s vezes o Data Warehouse pode ser simplesmente uma viso lgica ou virtual dos dados, podendo no envolver o armazenamento dos mesmos ou armazenar dados operacionais e externos para facilitar seu acesso e manuseio.
Figura 5 - Arquitetura de duas camadas. A arquitetura ilustrada na Figura 4 pode ser usada para construir um Data Warehouse em duas camadas que consiste de componentes dos clientes (front end) e componentes do servidor (back end). Esta arquitetura atrativa porque ela utiliza os sistemas existentes bem como os servidores de bancos de dados existentes e requer um investimento mnimo em hardware e software. Entretanto, a arquitetura em duas camadas no escalonvel e no suporta um grande nmero de usurios simultaneamente. Isto estimula o desenvolvimento de estaes clientes muito pesadas, pois muito processamento alocado para processar nestas estaes [DAL99].
Warehouse so otimizados para ter alto desempenho em consultas e anlises, em ingls conhecido como On-line Analytical Processing (OLAP).
Figura 6 Arquitetura de trs camadas. importante reconhecer que no existe uma arquitetura "correta" para Data Warehouse. Para algumas organizaes pode ser atrativo utilizar a arquitetura em duas camadas, por que ela minimiza o custo e a complexidade de construo do Data Warehouse. Para outras que requerem grande performance e escalabilidade, a arquitetura em trs camadas pode ser mais apropriada. No planejamento do Data Warehouse, as organizaes devem examinar as alternativas disponveis de arquiteturas e selecionar aquela que satisfaa os seu requisitos estratgicos e organizacionais [DAL99].
Chamaremos de dimenses as diferentes perspectivas envolvidas, no caso, modelo, loja, fabricante, ms. Estas dimenses usualmente correspondem a campos no numricos em um banco de dados. Consideremos tambm um conjunto de medidas, tal como vendas ou despesas com promoo. Estas medidas correspondem geralmente a campos numricos em um banco de dados. A seguir, avaliam-se agregaes destas medidas segundo s diversas dimenses e as armazenamos para acesso futuro. Por exemplo, calcula-se a mdia de todas as vendas por todos os meses por loja. A forma como estas agregaes so armazenadas pode ser vista em termos de dimenses e coordenadas, dando origem ao termo multidimensional. Intuitivamente, cada eixo no espao multidimensional um campo/coluna de uma tabela relacional e cada ponto um valor correspondente interseo das colunas. Assim, o valor para o campo vendas, correspondente a ms igual a maio e loja igual a Iguatemi um ponto com coordenada [maio, Iguatemi]. Neste caso, ms e loja so duas dimenses e vendas uma medida. Teoricamente, quaisquer dados podem ser considerados multidimensionais. Entretanto, o termo normalmente se refere a dados representando objetos ou eventos que podem ser descritos, e, portanto, classificados por dois ou mais de seus atributos. Estruturas relacionais podem ser usadas para a representao e o armazenamento de dados multidimensionais. Neste caso, as abordagens encontradas incluem desde a adoo de formas especficas de modelagem (os chamados esquemas estrela e floco de neve) at mecanismos sofisticados de indexao.
Este esquema chamado de estrela, por apresentar a tabela de fatos "dominante" no centro do esquema e as tabelas de dimenses nas extremidades. A tabela de fatos ligada s demais tabelas por mltiplas junes, enquanto as tabelas de dimenses se ligam apenas tabela central por uma nica juno. A Figura 7 mostra um exemplo de um modelo tipo estrela.
Figura 7 Modelo Estrela. A tabela de fatos onde as medidas numricas do fato representado esto armazenadas. Cada uma destas medidas tomada segundo a interseo de todas as dimenses. No caso do exemplo, uma consulta tpica selecionaria fatos da figura FATOSVENDAS a partir de valores fornecidos relativos a cada dimenso. Outro tipo de estrutura bastante comum o esquema do tipo floco de neve ou "snowflake", que consiste em uma extenso do esquema estrela onde cada uma das "pontas" da estrela passa a ser o centro de outras estrelas. Isto porque cada tabela de dimenso seria normalizada, "quebrando-se" a tabela original ao longo de hierarquias existentes em seus atributos. No caso do exemplo, a dimenso produto possui uma hierarquia definida onde categoria se divide em marca e marca se divide em produtos (Figura 8). Da mesma forma, a dimenso tempo inclui ano que contem ms e ms que contem dia do ms. Cada um destes relacionamentos geraria uma nova tabela em um esquema floco de neve.
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 [DAL99].
Figura 9 Relacional versus Bidimensional. Alm disso, na representao multidimensional, totais consolidados so facilmente obtidos e armazenados, bastando simplesmente adicionar totais de colunas e fileiras.
maneira de representar o relacionamento entre duas tabelas no Data Warehouse atravs da criao de artefatos. Um artefato de um relacionamento somente a parte do relacionamento que bvia e tangvel no momento do instantneo. Em outras palavras, quando o instantneo feito os dados associados com o relacionamento que so teis e bvios sero colocados no Data Warehouse. O artefato pode incluir chaves estrangeiras e outros dados relevantes, tais como colunas de tabelas associadas, ou este pode incluir somente os dados relevantes, sem incluir as chaves estrangeiras. Como exemplo, consideremos as tabelas e o relacionamento entre estas na Figura 13. Nesta existe um relacionamento entre produto e fornecedor, onde cada produto tem um fornecedor principal. Se fossemos fazer ento um instantneo deste relacionamento, teramos que considerar a informao do fornecedor principal que est relacionado ao produto. Alm disso, outras informaes de artefato relacionadas com o fornecedor deveriam ento ser capturadas. A tabela de produtos no modelo do Data Warehouse ficaria ento como a mostrada na Figura 14 [DAL99].
Como exemplo, consideremos a Figura 16, onde temos as tabelas NOTAS e ITENS DAS NOTAS. Quando estas so colocadas no modelo do Data Warehouse, estas vo para uma mesma tabela. Dessa forma, a juno entre estas tabelas passa a no ser mais necessria quando uma consulta for feita. Neste caso, podemos ver que as trs condies so atendidas: as tabelas compartilham parte da chave, ID da Nota; estas duas tabelas geralmente so usadas juntas; e o padro de insero o mesmo, ou seja, sempre que uma nota inserida seus itens tambm o so [DAL99].
A Figura 17 mostra uma tabela no modelo corporativo com as previses de gasto mensais. Quando esta colocada no modelo do Data Warehouse, os dados so armazenados de forma que cada ms do ano uma ocorrncia no array [DAL99].
e geram pouca demanda sobre o SGBD e sobre o ambiente servidor. Anlises complexas, por sua vez, tpicas de ambientes de suporte deciso, exigem mais de todo o ambiente. Ambientes dinmicos, com necessidades em constante mudana, so mais bem atendidos por uma arquitetura simples e de fcil alterao, ao invs de uma estrutura mais complexa que necessite de reconstruo a cada mudana. A freqncia da necessidade de atualizao tambm determinante: grandes volumes de dados que so atualizados em intervalos regulares favorecem uma arquitetura centralizada.
Os requisitos dos sistemas do ambiente operacional so claramente identificveis a partir das funes a serem executadas pelo sistema. Requisitos de sistemas de suporte deciso so, por sua vez, indeterminados. O objetivo por trs de um Data Warehouse prover dados com qualidade; os requisitos dependem das necessidades de informao individuais de seus usurios. Ao mesmo tempo, os requisitos dos sistemas do ambiente operacional so relativamente estveis ao longo do tempo, enquanto que os dos sistemas de suporte deciso so instveis: dependem das variaes das necessidades de informaes daqueles responsveis pelas tomadas de decises dentro da empresa. No entanto, embora as necessidades por informaes especficas mudem com freqncia, os dados associados no mudam. Imaginando-se que os processos de negcio de uma empresa permaneam relativamente constantes, existe apenas um nmero finito de objetos e eventos com as quais uma organizao est envolvida. Por esta razo, um modelo de dados uma base slida para identificar requisitos para um Data Warehouse. De qualquer forma, um erro pensar que tcnicas de projeto que servem para sistemas convencionais sero adequadas para a construo de um Data Warehouse. Os requisitos para um Data Warehouse no podem ser conhecidos at que ele esteja parcialmente carregado e j em uso. Outra questo interessante a adequao do modelo Entidade-Relacionamento ao tipo de transao de sistemas OLTP (On-line Transaction Processing). O principal objetivo da modelagem, neste caso, eliminar ao mximo, a redundncia, de tal forma que uma transao que promova mudanas no estado do banco de dados, atue o mais pontualmente possvel. Com isso, nas metodologias de projeto usuais, os dados so "fragmentados" por diversas tabelas, o que traz uma considervel complexidade formulao de uma consulta por um usurio final. Por isso, esta abordagem no parece ser a mais adequada para o projeto de um Data Warehouse, onde estruturas mais simples, com menor grau de normalizao devem ser buscadas.
Existem algumas tcnicas que podem ser usadas para limitar a quantidade de dados pesquisados, conforme demonstrado na Figura 18, as tcnicas expostas a seguir devem ser analisadas e deve-se escolher a que melhor represente as necessidades da empresa. [DAL99].
Figura 18 Selecionando os dados a serem varridos. A primeira tcnica consiste em pesquisar dados que apresentem marcas de tempo. Para isso necessrio que as aplicaes registrem o momento da ltima alterao ou atualizao em um registro para que ao ser executada a varredura para o Data Warehouse s sejam examinados os registros que tenham a data de atualizao igual ou maior do que a data da ltima pesquisa. A segunda tcnica utiliza um arquivo de registros de alteraes efetuadas. Este arquivo, tambm chamado arquivo delta. criado por uma aplicao e contm apenas as alteraes efetuadas por esta nos dados operacionais. Quando possvel contar com um arquivo delta o processo de varredura se torna muito eficiente uma vez que os dados que no sofreram alteraes no sero acessados. O problema que poucas aplicaes geram arquivos delta. A terceira tcnica consiste em varrer um arquivo de auditoria ou de log. Basicamente o arquivo de log possui os mesmos dados de um arquivo delta, todavia, h algumas diferenas significativas. Uma delas que por ser o arquivo utilizado para a recuperao dos dados do
banco de dados operacional em uma eventual falha no interessante que se utilize este arquivo com outros propsitos. Outra diferena que os arquivos de log normalmente possuem uma estrutura interna voltada aos objetivos de um sistema e no esto completamente preparados para a recuperao de dados por um Data Warehouse. A quarta tcnica empregada no gerenciamento da quantidade de dados pesquisados durante a extrao para o Data Warehouse consiste em modificar o cdigo da aplicao operacional. Essa pode ser a pior escolha, sobretudo quando o cdigo da aplicao antigo ou complexo. A ltima opo consiste em moldar um arquivo de imagem "anterior" e "posterior". Segundo esta opo, uma cpia do banco de dados tirada no momento da extrao e quando for realizada outra extrao, outra cpia ser tirada. As duas cpias sero comparadas serialmente entre si para que seja detectada a atividade transcorrida neste perodo e ento resgatadas s diferenas entre as duas copias. Esse mtodo pesado, complexo e demanda uma quantidade excessiva de recursos.
unidades de processamento separadas. A anlise a respeito desse conceito vem novamente ao encontro de mesma atribuda ao processamento paralelo: dividir o trabalho. Portanto, podemos chegar mesma concluso, em termos de desvantagem, apresentada no processamento paralelo, ou seja, medida que o nmero de dados aumentar, teremos sempre de buscar maneiras de subdividir o conjunto de dados. Data marts so outra forma de distribuir os dados contidos no Data Warehouse. Os data marts, geralmente, contm dados especficos de uma determinada rea ou departamento. Dessa forma, podemos dizer que os data marts so mini Data Warehouses, armazenados provavelmente em plataformas diferentes. O processo de particionamento melhora o desempenho no resgate de informaes, fazendo uso da segmentao dos dados em reas lgicas diferentes. Recursos sofisticados de indexao so a maneira mais eficiente de reduo de I/O de disco, necessria para resgatar um subconjunto de dados. Com tcnicas avanadas de indexao, a seleo de registros por qualquer critrio executada usando-se poucas leituras do disco. Dessa forma, obtemos, em segundos, selees complexas em enormes bases de dados. Existem vrias formas de indexao. H ndices nativos da estrutura de banco de dados relacionais: primrios, B-tree (rvore B) e hash/hashing. H tambm ndices especializados, independentes da estrutura dos bancos de dados relacionais: invertidos, bitmap, combinados, R-tree (rvores R) e alguns outros especficos para determinadas aplicaes. Uma tcnica relativa a estrutura do Data Warehouse que pode ser utilizada a intercalao de tabelas onde o projetista deve procurar intercalar as tabelas afins em um mesmo local fsico, diminuindo assim a quantidade de E/S (entradas/sadas), tanto em termos de acesso aos dados, como em termos de acessos aos ndices para a localizao dos dados. A melhor estratgia de intercalao de tabelas deve ser defina com base nos tipos de dados e possveis consultas que podem ser realizadas. Outra tcnica importante aplicada especialmente no ambiente de Data Warehouse consiste na introduo intencional de dados redundantes. A Figura 19 mostra um exemplo no qual a introduo deliberada de dados redundantes proporciona um excelente retorno. Na parte superior da Figura 19 o campo descrio est normalizado e no apresenta redundncia. Dessa maneira todos os processos que precisam ver a descrio precisam acessar a tabela bsica. Na parte inferior da Figura 19 o campo descrio foi intencionalmente colocado nas diversas tabelas em que ele precisa ser usado. O problema da replicao de dados somente o aumento do volume do Data Warehouse, j que praticamente no existe a preocupao com atualizaes neste ambiente.
Figura 19 Introduo intencional de dados redundantes. A terceira tcnica que pode ser utilizada para aumentar a velocidade de acesso aos dados chamada de "separao de dados" que consiste em transformar uma tabela normalizada e que apresente probabilidades de acesso muito diferentes em duas tabelas separadas. Para a construo de um Data Warehouse pode ser usada tambm uma tcnica chamada de ndice criativo. Um ndice criativo gerado quando os dados passam do ambiente operacional para o ambiente de Data Warehouse. O ndice criativo gera um perfil de dados de interesse do usurio final, como informaes sobre os produtos mais vendidos, clientes inativos e outras informaes que possam antecipar os interesses da gerencia, como esta antecipao nem sempre possvel necessrio avaliar com cautela sobre quais os dados em que ser aplicada esta tcnica. Por ltimo deve-se esclarecer que a tentativa de reproduzir a integridade referencial no Data Warehouse constitui uma abordagem incorreta pois os dados em um Data Warehouse no so atualizados e representam informaes ao longo do tempo, com isso os relacionamentos no permanecem iguais impossibilitando a criao de relacionamentos.
Recomenda-se que estas definies se faam na ordem acima. Esta metodologia segue a linha topdown, pois comea identificando os grandes processos da empresa. Como exemplo, temos os processos de uma empresa revendedora de produtos: planos de estoque, ordens de compra, inventrio, pedidos de clientes, expedio de pedidos, crditos, etc. Quando os processos estiverem identificados, cria-se uma ou mais tabelas de fatos a partir de cada um deles.
Neste ponto necessrio ento decidir o a um fato individual naquela tabela (esta a granularidade da tabela). Exemplos de granularidade so: uma linha sobre um produto, um perfil de venda dirio do produto, ou um perfil de venda mensal do produto. Aps definir a granularidade da tabela de fatos, o prximo passo definir as dimenses e suas granularidades. Neste exemplo, considera-se a tabela de fatos vendas acumuladas do produto. Uma vez definida a granularidade, as dimenses e suas respectivas granularidades podem ser identificadas. Assim, as dimenses tempo, produto e vendedor so criadas, alm de outras dimenses descritivas como local-de-expedio, local-derecebimento, modo-de-envio. A adio destas dimenses descritivas no altera o nmero de instncias na tabela de fatos. A Figura 20 mostra a tabela de fatos com as dimenses identificadas. Cada dimenso pode ser vista como um ponto de entrada para a tabela de fatos. A escolha das dimenses o ponto chave no projeto. O passo seguinte consiste em detalhar todos as medidas que constaro da tabela de fatos e finalmente completar as tabelas de dimenses. Neste instante, tem-se a estrutura do projeto lgico completa. A partir de ento, passa-se a trabalhar questes relativas ao projeto fsico, avaliando mudanas graduais em dimenses e discutindo-se a incluso de agregaes, minidimenses e dimenses heterogneas.
dados. O desempenho dos sistemas de banco de dados relacionais tradicionais melhor para consultas baseadas em chaves do que consultas baseadas em contedo. Para atender os requisitos deste tipo de transaes, fornecedores de SGBDs relacionais tm adicionado funcionalidades a seus produtos. Estas funcionalidades incluem extenses s estruturas de armazenamento e aos operadores relacionais e esquemas de indexao especializados. Estas tcnicas podem melhorar o desempenho para recuperaes por contedo atravs da pr-juno de tabelas usando ndices ou pelo uso de listas de ndices totalmente invertidas. A maioria das ferramentas de acesso a Data Warehouses explora a natureza multidimensional dos dados. Por isso, estruturar os dados em bancos de dados relacionais tradicionais em esquemas do tipo estrela ou floco de neve tornou-se uma abordagem bastante comum. Estes esquemas podem usar mltiplas tabelas e ponteiros para simular uma estrutura multidimensional. Tambm possvel usar algum outro mecanismo no relacional para armazenar algumas das agregaes pr-calculadas enquanto outras so obtidas dinamicamente. Esta abordagem goza dos benefcios de um mecanismo relacional, tirando vantagem do clculo prvio de algumas agregaes. Normalmente a tabela central de fatos bem grande enquanto as das demais dimenses so bem menores. Por sua vez, bancos de dados multidimensionais permitem manipular diretamente objetos multidimensionais. As dimenses so identificadas ao criar a estrutura do banco, de forma que adicionar uma nova dimenso pode ser trabalhoso. Alguns bancos multidimensionais requerem uma completa recarga do banco quando uma reestruturao ocorre. Portanto, so mais recomendados para ambientes mais estveis onde os requisitos sobre os dados no estejam em constante mudana.
muito pouco provvel que o mesmo projeto de banco de dados multidimensional atenda igualmente bem a questes de tomada de deciso das diversas reas da empresa. Neste caso, um sistema de banco de dados relacional usualmente mais adequado para gerenciar um banco de dados integrado, provendo uma estrutura mais neutra com relao s necessidades de cada rea. Uma soluo freqentemente encontrada a separao do gerenciamento dos dados entre o Data Warehouse relacional integrado da empresa e os seus data marts satlites multidimensionais. Esta alternativa introduz a necessidade de uma estratgia de distribuio de dados que coordene a alimentao de novos dados aos bancos multidimensionais. Uma soluo semelhante adotada no caso em que o Data Warehouse possui diferentes nveis de detalhe: a camada atmica, de maior nvel de detalhe, mantida em formato relacional, enquanto a camada contendo dados resumidos, pode ser mantida em formato multidimensional.
6.1 Extrao
As vrias alternativas para extrao permitem balancear desempenho, restries de tempo e de armazenamento. Por exemplo, se a fonte for um banco de dados on-line, pode-se submeter uma consulta diretamente ao banco para criar os arquivos de extrao. O desempenho das aplicaes ligadas s fontes pode cair consideravelmente se transaes on-
line e as consultas para extrao competirem entre si. Uma soluo alternativa criar uma cpia corrente dos dados das fontes a partir da qual se far ento a extrao. Como desvantagem desta soluo, podemos citar o espao adicional de disco necessrio para armazenar a cpia. Outra alternativa examinar o ciclo de processamento de algumas transaes off-line que atuem nas fontes. Os programas que criam os arquivos de extrao para a carga do Data Warehouse podem ser incorporados a um ponto apropriado deste esquema de processamento. As rotinas de extrao devem ser capazes de isolar somente aqueles dados que foram inseridos e atualizados desde a ltima extrao, este processo conhecido como refresh. A melhor poltica de refresh deve ser avaliada pelo administrador do Data Warehouse, que deve levar em conta caractersticas como as necessidades dos usurios finais, trfego na rede e perodos de menor sobrecarga, tanto das origens dos dados quanto do Data Warehouse, devese considerar que os perodos de sobrecarga podem variar para cada origem de dados [DAL99].
estruturais so os conflitos de domnio de atributo que se caracterizam pelo uso de diferentes tipos de dados para os mesmos campos. Conflitos tpicos de domnio de atributo so: Diferenas de unidades: quando as unidades utilizadas diferem, embora forneam a mesma informao (como distncia em metros ou quilmetros); Diferenas de preciso: quando a preciso escolhida varia de um ambiente para outro (como quando o custo do produto armazenado com duas posies ou com seis posies decimais); Diferenas em cdigos ou expresses: quando o cdigo utilizado difere um do outro (como no caso de sexo representado por M ou F e por 1 e 2); Diferenas de granularidade: quando os critrios associados a uma informao, embora utilizando uma mesma unidade, so distintos (como quando horas trabalhadas) correspondem s horas trabalhadas na semana ou s horas trabalhadas no ms; Diferenas de abstrao: quando a forma de estruturar uma mesma informao segue critrios diferentes (como com endereo armazenado em um atributo nico, ou subdividido em rua e complemento). Depois de identificados os conflitos de modelagem, deve-se criar as regras de mapeamento de representaes equivalentes e de converso para os padres estabelecidos pelo Data Warehouse [DAL99].
A nova tendncia dessas solues a integrao com o ambiente Web, permitindo maior agilidade em consultas estticas e dinmicas. Nesta monografia veremos de forma bsica e separadamente os conceitos das tecnologias OLAP e Data Mining. A diferena bsica entre ferramentas OLAP e Data Mining est na maneira como a explorao dos dados abordada. Com ferramentas OLAP a explorao feita na base da verificao, isto , o analista conhece a questo, elabora uma hiptese e utiliza a ferramenta para confirm-la. Com Data Mining, a questo total ou parcialmente desconhecida e a ferramenta utilizada para a busca de conhecimento.
Nesta tcnica os dados so modelados em uma estrutura dimensional conhecida por cubo. As dimenses do cubo representam os componentes dos negcios da empresa tais como "cliente", "produto", "fornecedor" e "tempo". A clula resultante da interseo das dimenses chamada de medida e geralmente representa dados numricos tais como "unidades vendidas", "lucro" e "total de venda". Alm dos componentes dimenso e medida outro importante aspecto do modelo multidimensional a consolidao dos dados uma vez que para a tarefa de anlise so mais teis e significativas as agregaes (ou sumarizao) dos valores indicativas dos negcios. A expresso Decision Cube refere-se a um conjunto de componentes de suporte deciso, que podem ser utilizados para cruzar tabelas de um banco de dados, gerando diversas vises atravs de planilhas ou grficos. Envolve o clculo, quando da carga do Data Warehouse, de dados que o usurio vir a solicitar, mas que podem ser derivados de outros dados. Quando o usurio solicita os dados, estes j esto devidamente calculados, agregados em um Cubo de Decises [DAL99]. Alm da viso multi-dimensional dos dados da empresa, outras importantes caractersticas dos sistemas OLAP so: Anlise de tendncias. A tecnologia OLAP mais do que uma forma de visualizar a histria dos dados. Deve, tambm, ajudar os usurios a tomar decises sobre o futuro, permitindo a construo de cenrios ("e se...") a partir de suposies e frmulas aplicadas, pelos analistas, aos dados histricos disponveis; Busca automtica (reach-through) de dados mais detalhados que no esto disponveis no servidor OLAP. Detalhes no so normalmente importantes na tarefa de anlise, mas quando necessrios, o servidor OLAP deve ser capaz de busc-los; Dimensionalidade genrica; Operao trans-dimensional. Possibilidade de fazer clculos e manipulao de dados atravs diferentes dimenses; Possibilidade de ver os dados de diferentes pontos de vista (slice and dice), mediante a rotao (pivoting) do cubo e a navegao (drill-up/drill-down) entre os nveis de agregao; Conjunto de funes de anlise e clculos no triviais com os dados.
Existe tambm um conjunto de 12 regras que servem para avaliar as ferramentas OLAP conforme [BIS99]: 1. Viso conceitual multidimensional 2. Transparncia 3. Acessibilidade 4. Desempenho consistente de fornecimento de informaes 5. Arquitetura cliente/servidor 6. Dimensionalidade genrica 7. Manipulao dinmica da matriz esparsa 8. Suporte multiusurio 9. Operaes irrestritas com dimenses cruzadas 10. Manipulao intuitiva dos dados 11. Relatrios flexveis 12. Dimenses e nveis de agregao ilimitados Uma arquitetura OLAP possui trs componentes principais: um modelo de negcios para anlises interativas, implementado numa linguagem grfica que permita diversas vises e nveis de detalhes dos dados; um motor OLAP para processar consultas multidimensionais contra o dado-alvo; e um mecanismo para armazenar os dados a serem analisados. A base de dados usada define se o pacote um ROLAP, que interfaceia com um banco de dados relacional de mercado, ou um MOLAP, que se liga a um servidor OLAP, atravs de um banco de dados multidimensional e dedicado [DAL99].
A maneira de se implementar os arranjos de dados pode variar entre fornecedores de solues MOLAP. Existem as arquiteturas hiper-cubos e multi-cubos. Na arquitetura hipercubo existe um nico cubo onde cada medida referenciada por todas as outras dimenses. Por exemplo, um cubo onde a medida "vendas" referenciada pelas dimenses "produto", "ano", "ms", "estado" e "cidade". Alm da dificuldade em visualizar tal "cubo" (com cinco dimenses!). Outros problemas desta abordagem so a maior necessidade de espao em disco e a existncia de um mecanismo para controlar a esparsidade dos dados que ocorre quando no existe uma medida na interseo das dimenses. Por exemplo, quando um produto no vendido em determinado estado. A grande vantagem a consistncia no tempo de resposta que independente do nmero de dimenses envolvidas na consulta. Na arquitetura multi-cubos uma medida referenciada por dimenses selecionadas. Em um cubo, a medida "vendas" referenciada pelas dimenses "semestre", "estado" e "produto" e em outro cubo, a medida "custo" referenciada pelas dimenses "ms" e "departamento". Esta arquitetura escalvel e utiliza menos espao em disco. A performance melhor em cada cubo individualmente, no entanto, consultas que requerem acesso a mais de um cubo podem exigir processamentos complexos para garantir a consistncia do tempo de resposta. Sistemas ROLAP fornecem anlise multidimensional de dados armazenados em uma base de dados relacional. Atualmente existem duas maneiras de se fazer este trabalho: fazer todo o processamento dos dados no servidor da base de dados. O servidor OLAP gera os comandos SQL em mltiplos passos e as tabelas temporrias necessrias para o processamento das consultas; ou executar comandos SQL para recuperar os dados, mas fazer todo o processamento (incluindo joins e agregaes) no servidor OLAP. Alm das caractersticas bsicas de sistemas OLAP, servidores ROLAP devem tambm: utilizar metadados para descrever o modelo dos dados e para auxiliar na construo das consultas. Desta maneira um analista pode executar suas anlises utilizando seus prprios termos; e criar comandos SQL otimizados para os bancos de dados com o qual trabalha. A principal vantagem de se adotar uma soluo ROLAP reside na utilizao de uma tecnologia estabelecida, de arquitetura aberta e padronizada como a relacional, beneficiando-se da diversidade de plataformas, escalabilidade e paralelismo de hardware (SMP e MPP).
Quando determinados padres de comportamento, como associao de produtos durante um processo de compras, por exemplo, comeam a se repetir com freqncia, as ferramentas Data Mining indicam a presena de oportunidades e "insights" em relao quele pblico consumidor. O diferencial do Data Mining est no fato de que as descobertas de padres de consumo se do por uma lgica de algoritmos com base em uma rede neural de raciocnios. So ferramentas de descobertas matemticas feitas sobre os registros corporativos j processados contra descobertas empricas [POL99].
CONCLUSO
Para concluir, vale dizer que o desenvolvimento de um Data Warehouse constitui um avano em relao as metodologias anteriores, pois apresenta uma sistemtica mais apropriada baseada na realidade dos sistemas existentes nas empresas. Essa metodologia tambm valoriza a experincia da equipe no desenvolvimento de sistemas transacionais, pois as fases que a compem j so largamente utilizadas no desenvolvimento dos mesmos. Tambm importante que a metodologia seja suportada por uma ferramenta de desenvolvimento que aumente a produtividade, simplificando e automatizando tarefas complexas no processo de data warehousing. Isto evidencia algumas questes que merecem uma avaliao mais aprofundada. o caso da metodologia. Considerando diferentes arquiteturas de data warehouse e a explorao detalhada dos nveis conceitual e lgico. 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 gastos de recursos desnecessrios. Como o Data Warehouse no um sistema ou programa, mas sim um ambiente que necessita ser adaptado as necessidades das empresas normal que cada ambiente de Data Warehouse possua caractersticas prprias, inviabilizando seu uso para outros objetivos que no os descritos no incio do projeto. Para a informtica o ambiente de Data Warehouse mostrou ser um desafio aos processos que normalmente so utilizados para desenvolver um software. Um dos desafios conseguir modelar os dados de maneira que todas as informaes estejam disponveis de forma clara e rpida para os usurios que a esto requisitando, outro desafio disponibilizar as informaes sobre os dados (metadados), para que os usurios possam saber quais informaes esto disponveis. Tambm pode ser considerado um desafio aos profissionais de informtica a melhor maneira de extrao dos dados do Data Warehouse, de forma que ele realmente se torne um sistema de apoio a deciso. As duas maneiras estudadas neste trabalho foram a analise multidimensional atravs do OLAP e o Data Mining. OLAP fornece para organizaes um mtodo de acessar, visualizar, e analisar dados corporativos com alta flexibilidade e performance. No mundo globalizado de hoje as
empresas esto enfrentando maior concorrncia e expandindo sua atuao para novos mercados. Portanto, a velocidade com que executivos obtm informaes e tomam decises determina a competitividade de uma empresa e seu sucesso de longo prazo. OLAP apresenta informaes para usurios via um modelo de dados natural e intuitivo. Atravs de um simples estilo de navegao e pesquisa, usurios finais podem rapidamente analisar inmeros cenrios, gerar relatrios "ad-hoc", e descobrir tendncias e fatos relevantes independente do tamanho, complexidade, e fonte dos dados corporativos. De fato, colocar informao em bancos dados corporativos sempre foi mais fcil do que retir-los. Quanto maior e complexa a informao armazenada, mais difcil para retir-la. A tecnologia OLAP acaba com estas dificuldades levando a informao mais prxima ao usurio que dela necessite. Portanto, o OLAP freqentemente utilizado para integrar e disponibilizar informaes gerenciais contidas em bases de dados operacionais, sistemas ERP e CRM, sistemas contbeis, e Data Warehouses. Estas caractersticas tornaram-no uma tecnologia essencial em diversos tipos de aplicaes de suporte deciso e sistemas para executivos. Sobre a ferramenta de Data Mining, obviamente, ainda h muito a se falar sobre o assunto (clustering, redes neurais, mtodos genticos, minerao em textos, roll up/drill down. etc), mas importante notar que em praticamente todos esses casos o que se deseja descobrir padres em volumes de dados. importante ressaltar tambm que o Data Mining no o final da atividade de descoberta de conhecimentos, mas to somente o incio. imprescindvel (ao menos com a tecnologia atual) dispor de analistas capacitados que saibam interagir com os sistemas de forma a conduz-los para uma extrao de pades teis e relevantes. A diferena bsica entre ferramentas OLAP e Data Mining est na maneira como a explorao dos dados abordada. Com as ferramentas OLAP a explorao feita na base da verificao, isto , o analista conhece a questo, elabora uma hiptese e utiliza a ferramenta para confirm-la. Com Data Mining, a questo total ou parcialmente desconhecida e a ferramenta utilizada para a busca de conhecimento. Por fim, importante destacar que este trabalho contribuiu muito para a ampliao dos conhecimentos do autor em relao aos ambientes de suporte a deciso. O que com certeza poder ser aplicado na sua futura vida profissional.
BIBLIOGRAFIA
[BIS99] BISPO, Carlos Alberto F. & CAZARINI, Edson Walmir. Anlises sofisticadas com o On-Line Analytical Processing. Developers Magazine, So Paulo, n.32, p.28-31, abril de 1999. [INM97] INMON, William H.. Como construir o Data Warehouse. 2 ed. New York: Editora Campus, 1997. [PER99] PEREIRA, Max Roberto. Data Warehouse: otimizando seu desempenho.Developers Magazine, So Paulo, n.32, p.22-26, abr de 1999. [PIN99] PINHEIRO, Carlos Andr Reis. Data Mining: obtendo vantagens com seu Data Warehouse. [HAISTEN99], M. Real time data warehouse: the next stage in data warehouse evolution, part 1. DM Review, June 1999. [KIMBALL98], R. Data Warehouse Toolkit. So Paulo: Makron Books, 1998.