You are on page 1of 52

CONSTRUINDO UM DATA WAREHOUSE E ANALISANDO SUAS INFORMAES COM DATA MINING E OLAP

Monografia apresentada como exigncia parcial para a obteno do grau de Bacharel em Cincia da Computao pela Faculdade de Cincias Administrativas Valinhos, sob a orientao do Professor Doutor Gilberto Shigueo Nakamiti.

FACULDADES DE VALINHOS FACULDADE DE CINCIAS ADMINISTRATIVAS DE VALINHOS

VALINHOS 1.999

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.

Sumrio
Resumo Sumrio

Introduo Cap. I - Evoluo dos Sistemas de Apoio Deciso 1.1 Histrico 1.2 A teia de aranha 1.3 O Ambiente projetado Cap. II Caractersticas do Data Warehouse 2.1 O Ciclo de vida do desenvolvimento 2.2 - Orientado por temas 2.3 - Integrado 2.4 - Variante no tempo 2.5 - No voltil 2.6 - Granularidade 2.6.1 Nveis duais de granularidade 2.7 Particionamento de dados Cap. III Arquitetura do Data Warehouse 3.1 Arquitetura genrica do data warehouse 3.2 Outras arquiteturas 3.2.1 Arquitetura de duas camadas 3.2.2 Arquitetura de trs camadas Cap. IV Modelo de dados do Data Warehouse 4.1 - A Questo das Dimenses 4.2 - Esquemas do tipo Estrela e Floco de Neve 4.2.1 Vantagens do modelo estrela 4.2.2 - Bancos de Dados Multidimensionais 4.3 Converso do modelo E-R para o modelo do data warehouse

4.3.1 - Remoo dos dados puramente operacionais 4.3.2 - Adio de um elemento de tempo na estrutura da chave 4.3.3 - Introduo de dados derivados 4.3.4 - Transformao de Relacionamentos entre dados em artefatos dos dados 4.3.5 - Acomodao dos diferentes nveis de granularidade 4.3.6 - Unio dos dados comuns de diferentes tabelas 4.3.7 - Criao de arrays de dados 4.3.8 - Separao dos atributos de dados de acordo com sua estabilidade Cap. V Desenvolvimento do Data Warehouse 5.1 - Estratgia Evolucionria 5.2 - Aspectos de Modelagem 5.3 Tcnicas de gerenciamento da quantidade de dados operacionais pesquisados 5.4 Tcnicas para incrementar a performance 5.5 - Etapas do Desenvolvimento de um Data Warehouse 5.6 Relacional versus multidimensional 5.5.1 - Um ou mais bancos Cap. VI Povoando o Data Warehouse 6.1 Extrao 6.2 Transformao e filtros 6.3 - Derivao e Sumarizao Cap. VII Extraindo informaes do Data Warehouse 7.1 - Ferramentas OLAP 7.1.1 - MOLAP x ROLAP 7.2 - Ferramentas Data Mining 7.2.1 - O processo do Data Mining

7.2.2 A tecnologia da rvore 7.2.3 Reteno dos dados 7.2.4 Destilao de padres 7.2.4.1 Semelhana lgica 7.2.4.1.1 Regras 7.2.4.1.1.1 - Regra indutiva 7.2.4.1.1.2 Algoritmos genticos 7.2.4.1.2 rvores de deciso 7.2.4.2 Tabulao cruzada 7.2.4.2.1 - Agentes 7.2.4.2.2 Redes de confiana 7.2.4.3 Aproximaes equacionais 7.2.4.3.1 Redes neurais Concluso Bibliografia

Introduo
Hoje em dia uma organizao precisa utilizar toda informao disponvel para criar e manter vantagem competitiva. Sai na frente a 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 (Decision Support Systems - DSS) 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 tm 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 inicia-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.

Cap. I - Evoluo dos Sistemas de Apoio Deciso


1.1 Histrico
A evoluo dos sistemas de apoio a deciso pode ser dividida em cinco fases entre 1960 e 1980. No incio da dcada de 1960 o mundo da computao consistia na criao de aplicaes individuais que eram executadas sobre arquivos mestres, caracterizadas por programas e relatrios. Aproximadamente em 1965 o crescimento dos arquivos mestres e das fitas magnticas explodiu, surgindo problemas como: a complexidade de manuteno dos programas; a

complexidade do desenvolvimento de novos programas; a quantidade de hardware para manter todos os arquivos mestres e a necessidade de sincronizar dados a serem atualizados. Por volta de 1970, surgiu a tecnologia DASD (direct access storage device), substituindo as fitas magnticas pelo armazenamento em disco. Com o DASD surgiu um novo tipo de software conhecido como SGBD ou sistema de gerenciamento de banco de dados, que tinha o objetivo de tornar o armazenamento e o acesso a dados no DASD mais fceis para o programador. E com o SGBD surgiu a idia de um banco de dados que foi definido como: uma nica fonte de dados para todo o processamento. Aproximadamente em 1975 surgiu o processamento de transaes online. Com o processamento de transaes online de alta performance, o computador pde ser usado para tarefas que antes no eram viveis como controlar sistemas de reservas, sistemas de caixas bancrios, sistemas de controle de produo e outros. At o incio da dcada de 1980, novas tecnologias, como os PCs e as L4Gs (linguagens de quarta gerao), comearam a aparecer. O usurio final passou a controlar diretamente os sistemas e os dados, descobrindo que era possvel utilizar os dados para outros objetivos alm de atender ao processamento de transaes online de alta performance. Foi nesse perodo tambm que se tornou vivel a construo dos MIS (management information systems), hoje conhecidos como SAD eles consistiam em processamento utilizado para direcionar decises gerenciais [INM97].

1.2 A teia de aranha


Aps o advento das transaes online de alta performance, comearam a surgir os programas de extrao. Esses programas varrem arquivos de banco de dados usando alguns critrios, e, ao encontrar esses dados, transporta-os para outro arquivo de banco de dados. Com a difuso do programa de extrao, comeou a formar-se a chamada arquitetura de desenvolvimento espontneo ou teia de aranha, conforme mostrado na Figura 1.1. Primeiro havia extraes. Depois, extraes das extraes, e, ento, extraes das extraes das extraes, e assim por diante.

Figura 1.1 A teia de aranha


Com a arquitetura de desenvolvimento espontneo comearam a surgir alguns problemas conforme [INM97]: Credibilidade dos dados; Ausncia de parmetros de tempo dos dados O diferencial algortmico dos dados Os nveis de extrao O problema dos dados externos Nenhuma fonte de dados comum com a qual comear

Produtividade; Localizar e analisar os dados para o relatrio Compilar os dados para o relatrio Obter recursos humanos de programao/anlise para realizar os pontos citados acima

Impossibilidade de transformar dados em informaes.

1.3 O Ambiente projetado


A arquitetura de desenvolvimento espontneo no era suficiente para atender as necessidades do futuro das empresas, fazendo-se necessrio uma mudana de arquitetura, surgindo o ambiente projetado de data warehouse. Neste ambiente h duas espcies de dados dados primitivos e dados derivados. Dados primitivos - baseados em aplicaes - detalhados - podem ser atualizados - exatos em relao ao momento do acesso - so processados repetitivamente Dados derivados - baseados em assuntos ou negcios - resumidos, ou refinados - no so atualizados - representam valores de momentos j decorridos ou instantneos - processados de forma heurstica

H quatro nveis no ambiente projetado o operacional, a atmico ou data warehouse, o departamental e o individual. O nvel operacional de dados contm apenas dados primitivos e atende comunidade de processamento de transaes de alta performance. O data warehouse contm dados primitivos que no so atualizados e dados derivados. O nvel departamental de dados praticamente s contm dados derivados. E o nvel individual de dados onde o maior parte das anlises heursticas feito [INM97]. A Figura 1.2 mostra os tipos de consulta para os quais os diferentes nveis de dados podem ser usados.

Figura 1.2 Os tipos de consulta.

Cap. II Caractersticas do Data Warehouse


Para entender melhor o que um data warehouse vamos fazer uma comparao entre ele e os bancos de dados operacionais [DAL99]. Caractersticas Objetivo Uso Tipo de processamento Unidade de trabalho Nmero de usurios Tipo de usurio Interao do usurio Condies dos dados Volume Histrico Granularidade Bancos de dados Operacionais Operaes dirias do negcio Operacional OLTP Incluso, alterao, excluso. Milhares Operadores Somente pr-definida Dados operacionais Megabytes gigabytes 60 a 90 dias Detalhados Data Warehouse Analisar o negcio Informativo OLAP Carga e consulta Centenas Comunidade gerencial Pr-definida e ad-hoc Dados Analticos Gigabytes terabytes 5 a 10 anos Detalhados e resumidos

Redundncia Estrutura Manuteno desejada Acesso a registros Atualizao Integridade Nmero de ndices Inteno dos ndices

No ocorre Esttica Mnima Dezenas Contnua (tempo real) Transao Poucos/simples Localizar um registro

Ocorre Varivel Constante Milhares Peridica (em batch) A cada atualizao Muitos/complexos Aperfeioar consultas

Tabela 1.1 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 contem 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 [CAM99].

2.1 O Ciclo de vida do desenvolvimento


Uma das grandes diferenas entre o nvel operacional de dados e processamento e o nvel de dados e processamento do data warehouse diz respeito aos ciclos de vida de desenvolvimento subjacentes, como ilustrado na Figura 2.1. A Figura 2.1 mostra que o data warehouse funciona segundo um ciclo de vida muito diferente, chamado de CLDS. O SDLC clssico baseado em requisitos. Para desenvolver sistemas, primeiro necessrio entender as necessidades. Depois disso, vm as fases de projeto e desenvolvimento. O CLDS quase o inverso. O CLDS comea pelos dados. Uma vez que os dados estejam sob controle, eles so integrados e, em seguida, testados para que se verifiquem quais distores h neles, se houver alguma. Ento, feita a codificao de programas para os dados. Os resultados dos programas so analisados e, finalmente, os requisitos do sistema so compreendidos [INM97].

Figura 2.1 O ciclo de vida de desenvolvimento 2.2 - Orientado por temas


Refere-se ao fato do data warehouse armazenar informaes sobre temas especficos importantes para o negcio da empresa. Exemplos tpicos de temas so: produtos, atividades, contas, clientes, etc. Em contrapartida, o ambiente operacional organizado por aplicaes funcionais. Por exemplo, em uma organizao bancria, estas aplicaes incluem emprstimos, investimentos e seguros [CAM99]. A principal rea de interesse termina sendo fisicamente implementada como uma srie de tabelas relacionadas inseridas no data warehouse. Por exemplo, uma implementao de cliente pode parecer com a que exibida na Figura 2.2.

Figura 2.2 Organizado por rea de interesse.


Na Figura 2.2, h cinco tabelas relacionadas, cada uma delas tendo sido projetada para implementar uma parte de uma rea de interesse principal. H uma tabela bsica referente a cliente conforme definido de 1985 at 1987. H uma outra referente definio dos dados de cliente entre 1988 e 1990. H uma tabela cumulativa da atividade de cliente referente s atividades ocorridas entre 1986 e 1989. A cada ms um registro de resumo gravado para cada registro de cliente baseado na atividade de cliente do ms. Existem arquivos de atividades detalhados por cliente de 1987 a 1989 e de 1990 a 1991. A definio dos dados contidos nos arquivos difere segundo o respectivo ano [INM97]. Todas as tabelas referentes a um determinado cliente so relacionadas por meio de uma chave comum. No nosso exemplo, a chave cd cliente conecta todos os dados encontrados na rea de interesse cliente. A rea de interesse pode estar dividida em meios diferentes, geralmente

os dados com alta probabilidade de acesso e baixo volume residem em dispositivos de armazenamento de acesso direto (DASD) e os dados que apresentam baixa probabilidade de acesso e grande volume residem em fita magntica.

2.3 - 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 [CAM99].

Figura 2.3 A questo da integrao. 2.4 - Variante no tempo


Refere-se ao fato do dado em um data warehouse referir-se a algum momento especfico, significando que ele no atualizvel, enquanto que o dado de produo atualizado de acordo com mudanas de estado do objeto em questo, refletindo, em geral, o estado do objeto no momento do acesso. Em um data warehouse, a cada ocorrncia de uma mudana, uma nova entrada criada, para marcar esta mudana. 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 [CAM99].

Figura 2.4 A questo da variao em relao ao tempo. 2.5 - 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 [CAM99].

Figura 2.5 A questo da no-volatilidade. 2.6 - 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]. A Figura 2.6 apresenta um exemplo das questes referentes granularidade. No lado esquerdo h um baixo nvel de granularidade. Cada chamada telefnica registrada em detalhe. No lado direito um nvel mais alto de granularidade pode ser visto. Os dados representam as informaes resumidas referentes a um cliente em um ms. 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].

Figura 2.6 Definindo o nvel de granularidade.


Devemos lembrar, porem que em um ambiente de data warehouse, dificilmente um evento isolado examinado. mais comum ocorrer a utilizao de uma viso de conjunto dos dados.

2.6.1 Nveis duais de granularidade


O chamado nvel duplo de granularidade, ilustrado na Figura 2.7, se enquadra nos requisitos da maioria das empresas. Na camada de dados levemente resumidos ficam os dados que fluem do armazenamento operacional e so resumidos na forma de campos apropriados para a utilizao de analistas e gerentes. Na segunda camada, ou nvel de dados histricos, ficam todos os detalhes vindos do ambiente operacional, como h uma verdadeira montanha de dados neste nvel, faz sentido armazenar os dados em um meio alternativo como fitas magnticas. Com a criao de dois nveis de granularidade no nvel detalhado do data warehouse, possvel atender a todos os tipos de consultas, pois a maior parte do processamento analtico dirige-se aos dados levemente resumidos que so compactos e de fcil acesso e para ocasies em que um maior nvel de detalhe deve ser investigado existe o nvel de dados histricos. O acesso aos dados do nvel histrico de granularidade caro, incmodo e complexo, mas caso haja necessidade de alcanar esse nvel de detalhe, l estar ele.

Figura 2.7 Nveis de granularidade. 2.7 Particionamento de dados


O objetivo do particionamento dos dados de detalhe corrente consiste em repartir os dados em unidades fsicas menores. Unidades fsicas menores proporcionam ao pessoal de operao a ao projetista muito mais flexibilidade no gerenciamento dos dados do que proporcionado pelas unidades fsicas maiores. O particionamento de dados ocorre quando dados de uma mesma estrutura so divididos em mais de uma unidade fsica de dados. Alm disso, toda unidade de dados pertence a uma e somente uma partio. H vrios critrios por meio dos quais possvel dividir dados, como por exemplo: [INM97]. Por data Por rea de negcio Por rea geogrfica Por unidade organizacional Por todos os critrios acima

Cap. III Arquitetura do Data Warehouse


Para ser til o data warehouse deve ser capaz de responder a consultas avanadas de maneira rpida, sem deixar de mostrar detalhes relevantes resposta. Para isso ele deve possuir uma arquitetura que lhe permita coletar, manipular e apresentar os dados de forma eficiente e rpida. Mas construir um data warehouse eficiente, que servir de suporte a decises para a empresa, exige mais do que simplesmente descarregar ou copiar os dados dos sistemas atuais para um banco de dados maior. Deve-se considerar que os dados provenientes de vrios

sistemas podem conter redundncias e diferenas, ento antes de pass-los para o data warehouse necessrio aplicar filtros sobre eles. O estudo de uma arquitetura permite compreender como o data warehouse faz para armazenar, integrar, comunicar, processar e apresentar os dados que os usurios utilizaro em suas decises. Um data warehouse pode variar sua arquitetura conforme o tipo de assunto abordado, pois as necessidades tambm variam de empresa para empresa. possvel definir uma arquitetura genrica onde praticamente todas as camadas necessrias so apresentadas, conforme a arquitetura genrica vista a seguir, ou arquiteturas que utilizam somente algumas das camadas definidas, como as arquiteturas em duas e trs camadas.

3.1 Arquitetura genrica do data warehouse


A seguir descrita uma arquitetura genrica proposta por [DAL99] e ilustrada na Figura 3.1. Esta descrio genrica procura apenas sistematizar papis no ambiente de data warehouse, permitindo que as diferentes abordagens encontradas no mercado atualmente possam ser adaptadas a ela, deve-se considerar que esta arquitetura tem o objetivo de representar a funcionalidade de um data warehouse sendo que vrias camadas propostas podem ser atendidas por um nico componente de software. Esta arquitetura composta pela camada dos dados operacionais e outras fontes de dados que so acessados pela camada de acesso aos dados. As camadas de gerenciamento de processos, transporte e data warehouse formam o centro da arquitetura e so elas as responsveis por manter e distribuir os dados. A camada de acesso informao formada por ferramentas que possibilitam os usurios extrair informaes do data warehouse. Todas as camadas desta arquitetura interagem com o dicionrio de dados (metadados) e com o gerenciador de processos. 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 (E-R), 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 de entreg-las 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 3.1 Arquitetura genrica do data warehouse. 3.2 Outras arquiteturas


3.2.1 Arquitetura de duas camadas
Uma opo de arquitetura para o data warehouse utilizar um computador de alta capacidade como servidor, como mostrado na Figura 3.2. Isto uma incorporao das aplicaes utilizadas pelos usurios (front end) com os componentes do servidor (back end). Aplicaes front end construdas com ferramentas cliente/servidor fornecem uma interface grfica amigvel, suportam funes especficas da empresa, possibilitam o acesso transparente aos dados dos sistemas j existentes e escondem a complexidade e a falta de consistncia dos bancos de dados atuais alm de facilitar a utilizao e a visualizao dos resultados. Os

sistemas operacionais de uma empresa podem estar em uso por 15 ou 20 anos e podem ter altas taxas de redundncia. A redundncia e a falta de consistncia dos dados pode dificultar a administrao da empresa e o acesso aos dados e impede o desenvolvimento de novas aplicaes front end. Uma das maneiras de tratar com esta situao partir de um s sistema e construir uma espcie de "sistema guarda-chuva" que tenha facilidade de acesso aos dados do servidor principal.

Figura 3.2 Arquitetura de duas camadas.


A arquitetura ilustrada na Figura 3.2 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].

3.2.2 Arquitetura de trs camadas


Uma alternativa utilizar a arquitetura de informao em mltiplas camadas, como mostrado na Figura 3.3. Esta arquitetura flexvel suporta um grande nmero de servios integrados, na qual a interface do usurio, as funes de processamento do negcio e as funes de gerenciamento do banco de dados so separadas em processos que podem ser distribudos atravs da arquitetura de informao. A arquitetura em trs camadas amplamente utilizada para data warehouse. Na terceira camada ficam as fontes de dados. Dados e regras de negcio podem ser compartilhados pela organizao, assim como os bancos de dados para o data warehouse, ficam armazenados em servidores de alta velocidade na segunda camada. Na primeira camada ficam as aplicaes de interface com os usurios que devem ser grficas e baseadas em rede.

No ambiente do data warehouse, os servidores de banco de dados e os servidores de aplicaes da segunda camada fornecem um acesso eficiente e veloz aos dados compartilhados. Os dados de um data warehouse so tipicamente estticos, por exemplo, no variam com o tempo e devem ser integrados, de natureza histrica e sumarizados ou agregados para que sejam significantes para os analistas de negcios. Como mostrado na Figura 3.3, dados operacionais e bancos de dados para o data warehouse so freqentemente armazenados em servidores fisicamente separados. Bancos de dados operacionais so otimizados para ter alto desempenho no processamento de transaes on-line, em ingls conhecido como On-line Transaction Processing (OLTP). Bancos de dados para data warehouse so otimizados para ter alto desempenho em consultas e anlises, em ingls conhecido como On-line Analytical Processing (OLAP).

Figura 3.3 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].

Cap. IV Modelo de dados do Data Warehouse

O modelo de dados tem um papel fundamental para o desenvolvimento interativo do data warehouse. Quando os esforos de desenvolvimentos 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. Dentre estes modelos apenas o multidimensional ser apresentado neste trabalho.

4.1 - A Questo das Dimenses


Obter respostas a questes tpicas de anlise dos negcios de uma empresa geralmente requer a visualizao dos dados segundo diferentes perspectivas. Como exemplo, imagine-se uma agncia de automveis que esteja querendo melhorar o desempenho de seu negcio, Para isso, necessita examinar os dados sobre as vendas disponveis na empresa. Uma avaliao deste tipo requer uma viso histrica do volume de vendas sob mltiplas perspectivas, como por exemplo: volume de vendas por modelo, volume de vendas por cor, volume de vendas por fabricante, volume de vendas por perodo de tempo. Uma anlise do volume de vendas utilizando uma ou mais destas perspectivas, permitiria responder questes do tipo: Qual a tendncia em termos de volume de vendas para o ms de dezembro para modelos Volvo Sedan preto? A capacidade de responder a este tipo de questo em tempo hbil o que permite aos gerentes e altos executivos das empresas formular estratgias efetivas, identificar tendncias e melhorar sua habilidade de tomar decises de negcio. O ambiente tradicional de bancos de dados relacional certamente pode atender a este tipo de consulta. No entanto, usurios finais que necessitam de consultas deste tipo via acesso interativo aos bancos de dados, mostram-se seguidamente frustrados por tempos de resposta ruins e pela falta de flexibilidade oferecida por ferramentas de consulta baseadas no SQL. Da a necessidade de utilizar abordagens especficas para atender a estas consultas. Para compreender melhor os conceitos envolvidos, examinemos em maior detalhe o exemplo acima. 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.

4.2 - Esquemas do tipo Estrela e Floco de Neve


Em um esquema do tipo estrela ou "star" as instncias so armazenadas em uma tabela contendo o identificador de instncia, valores das dimenses descritivas para cada instncia, e valores dos fatos, ou medidas, para aquela instncia (tabela de fatos). Alm disso, pelo menos uma tabela usada, para cada dimenso, para armazenar dados sobre a dimenso (tabela de dimenso). No caso mais simples, a tabela de dimenso tem uma linha para cada valor vlido da dimenso. Esses valores correspondem a valores encontrados na coluna referente quela dimenso na tabela de fatos. 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 4.1 mostra um exemplo de um modelo tipo estrela.

Figura 4.1 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 tabela 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 4.2). Da mesma forma, a dimenso tempo inclui ano que contem ms e ms que contem dia-do-mes. Cada um destes relacionamentos muitospara-1 geraria uma nova tabela em um esquema floco de neve.

Figura 4.2 A dimenso do produto normalizada.


4.2.1 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; 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: o o o 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: o 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 [DAL99].

4.2.2 - Bancos de Dados Multidimensionais


Embora seja vivel utilizar estruturas relacionais na representao de dados multidimensionais, a soluo no ideal. Na Figura 4.3, fcil verificar como uma matriz bidimensional representa mais claramente os dados armazenados na forma relacional tradicional. Na matriz, os valores de vendas esto localizados nas intersees dos eixos X e Y da matriz 3x3. Cada eixo corresponde a uma dimenso, e cada elemento dentro de uma dimenso corresponde a uma posio. Um array agrupa informaes semelhantes em colunas e linhas. Modelo Van Van Van Coupe Coupe Coupe Sedan Sedan Sedan BD Relacional Cor Vendas Azul Vermelha Branca Azul Vermelha Branca Azul Vermelha Branca 6 5 4 3 5 5 4 3 2 Matriz Bidimensional Azul Vermelha Branca 6 3 4 5 5 3 4 5 2

Modelo
Van Coupe Sedan

Figura 4.3 Relacional versus Bidimensional.


Alm disso, na representao multidimensional, totais consolidados so facilmente obtidos e armazenados, bastando simplesmente adicionar totais de colunas e fileiras [CAM99].

4.3 Converso do modelo E-R para o modelo do data warehouse


Para tal, W. H. Inmon fornece ento alguns passos que podem ser seguidos, no se esquecendo de que o fundamental que as decises de transformao devem ser tomadas levando-se em considerao os requisitos especficos da empresa. Os passos bsicos so:

4.3.1 - Remoo dos dados puramente operacionais


A primeira ao consiste em remover os dados que so usados apenas no ambiente operacional, como vemos no exemplo da Figura 4.4. Neste, atributos tais como mensagem,

descrio e status so retirados, pois muito pouco provvel que estes sejam utilizados no processo de tomada de deciso. Neste momento, pode ser que se pense em manter todos os atributos, pois talvez algum destes seja necessrio para alguma deciso especfica. Entretanto, deve-se levar em conta o custo para gerenciar grandes volumes de dados [DAL99].

Figura 4.4 Remoo dos dados puramente operacionais.


4.3.2 - Adio de um elemento de tempo na estrutura da chave
A segunda modificao a ser feita no modelo corporativo adicionar um elemento de tempo a chave das tabelas, se estas j no o tiverem. No exemplo da Figura 4.5, o campo Data_Snapshot foi adicionado como parte da chave. Enquanto no modelo corporativo a chave apenas a identificao do consumidor, no modelo do data warehouse a data do instantneo deve fazer parte da chave, j que com o passar do tempo os dados do consumidor podem se alterar. Esta tcnica apenas uma forma de tirar instantneos dos dados. Outra forma de faz-lo adicionar dois campos do tipo data, um marcando o incio e outro o fim de um determinado intervalo de tempo. Esta tcnica melhor por representar faixas contnuas de tempo ao invs de pontos ou datas especficas [DAL99].

Figura 4.5 Adio de um elemento de tempo.


4.3.3 - Introduo de dados derivados
O prximo passo adicionar dados derivados ao modelo, como mostrado na Figura 4.6, j que por regra geral estes no existem no modelo corporativo. Devem ser adicionados os dados derivados que sero usados habitualmente de forma que estes sejam calculados apenas uma vez. Dessa forma, haver uma reduo no processamento que deve ser feito para acessar os dados derivados ou sumarizados. Outra razo para o armazenamento de dados derivados que uma vez calculados e armazenados, a integridade destes aumenta, uma vez que se torna impossvel a utilizao de diferentes algoritmos para o clculo destes derivados [DAL99].

Figura 4.6 Introduo de dados derivados.


4.3.4 - Transformao de Relacionamentos entre dados em artefatos dos dados
Os relacionamentos encontrados nas modelagens de dados clssicas assumem que h um e somente um valor de negcio no relacionamento. Levando-se em considerao que nos sistemas operacionais o dado estar integro no momento da transao, esta abordagem correta. Entretanto, o data warehouse por sua caracterstica de armazenar dados histricos, tem muitos valores para um dado relacionamento entre duas tabelas. Dessa forma a melhor 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 4.7. 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 4.8 [DAL99].

Figura 4.7 Relacionamento entre tabelas no modelo E-R.

Figura 4.8 Incluso de artefatos no data warehouse.


4.3.5 - Acomodao dos diferentes nveis de granularidade
Dependendo do caso, o nvel de granularidade do sistema transacional pode ser o mesmo do data warehouse ou no. Quando o nvel de granularidade se altera, o modelo do data warehouse deve representar esta mudana, como no exemplo da Figura 4.9. No exemplo, o modelo de dados corporativo mostra dados da atividade de envio de um determinado produto que so armazenadas toda vez que uma entrega feita. Quando este passado para o data warehouse, duas agregaes so feitas, alterando ento a granularidade. Na primeira, o total de entregas agregado mensalmente, fazendo com que a granularidade seja o ms, j na segunda, existe uma agregao das entregas feitas por ms e local de origem, fazendo ento com que a granularidade seja o ms associado ao fornecedor [DAL99].

Figura 4.9 Alterao do nvel de granularidade.


4.3.6 - Unio dos dados comuns de diferentes tabelas
Nesta fase, deve-se considerar a possibilidade de combinar duas ou mais tabelas do modelo corporativo em uma nica tabela do modelo do data warehouse. Para que esta juno possa ser feita, as seguintes condies devem ser verdadeiras: As tabelas compartilham uma chave comum (ou chave parcial); Os dados das diferentes tabelas geralmente so usados juntos; Padro de insero nas tabelas o mesmo.

Como exemplo, consideremos a Figura 4.10, 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].

Figura 4.10 Unio dos dados de diferentes tabelas.


4.3.7 - Criao de arrays de dados
Os dados no modelo corporativo geralmente esto normalizados, onde a existncia de grupos repetitivos no permitida. Entretanto, em algumas situaes no ambiente de data warehouse pode haver grupos repetitivos de dados. As condies para existncia destes so: Quando o nmero de ocorrncias do dado previsvel; Quando a ocorrncia do dado relativamente pequena (em termos de tamanho fsico); Quando as ocorrncias do dado geralmente so usadas juntas; Quando o padro de insero e remoo dos dados estvel;

A Figura 4.11 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].

Figura 4.11 Criao de array de dados.


4.3.8 - Separao dos atributos de dados de acordo com sua estabilidade A prxima atividade de projeto, referente passagem do modelo de dados da empresa para o modelo de dados do data warehouse, consiste em realizar a anlise de "estabilidade". A anlise de estabilidade uma tarefa que consiste em agrupar atributos de dados segundo sua propenso a alteraes. A Figura 4.12 ilustra a anlise de estabilidade de uma tabela de produtos. Neste exemplo possvel perceber que os dados que raramente sofrem alteraes so agrupados com outros dados que apresentam essa mesma caracterstica, dados que s vezes so alterados so agrupados com outros dados que s vezes so alterados e dados que freqentemente so alterados so agrupados com outros dados freqentemente alterados. O resultado final da anlise de estabilidade a criao de grupos de dados que apresentem caractersticas semelhantes [DAL99].

Figura 4.12 Anlise de estabilidade dos dados

Cap. V Desenvolvimento do Data Warehouse


O sucesso do desenvolvimento de um data warehouse depende fundamentalmente de uma escolha correta da estratgia a ser adotada, de forma que seja adequada s caractersticas e necessidades especficas do ambiente onde ser implementado. Existe uma variedade de abordagens para o desenvolvimento de data warehouses, devendo-se fazer uma escolha fundamentada em pelo menos trs dimenses: escopo do data warehouse (departamental, empresarial, etc), grau de redundncia de dados, tipo de usurio alvo.

O escopo de um data warehouse pode ser to amplo quanto aquele que inclui todo o conjunto de informaes de uma empresa ou to restrito quanto um data warehouse pessoal de um nico gerente. Quanto maior o escopo, mais valor o data warehouse tem para a empresa e mais cara e trabalhosa sua criao e manuteno. Por isso, muitas empresas tendem a comear com um ambiente departamental e s aps obter um retorno de seus usurios expandir seu escopo. Quanto redundncia de dados, h essencialmente trs nveis de redundncia: o data warehouse virtual, o data warehouse centralizado e o data warehouse distribudo. O data warehouse virtual consiste em simplesmente prover os usurios finais com facilidades adequadas para extrao das informaes diretamente dos bancos de produo, no havendo assim redundncia, mas podendo sobrecarregar o ambiente operacional. O data warehouse central constitui-se em um nico banco de dados fsico contendo todos os dados para uma rea funcional especfica, um departamento ou uma empresa, sendo usados onde existe uma necessidade comum de informaes. Um data warehouse central normalmente contm dados oriundos de diversos bancos operacionais, devendo ser carregado e mantido em intervalos regulares. O data warehouse distribudo, como o nome indica, possui seus componentes distribudos por diferentes bancos de dados fsicos, normalmente possuindo uma grau de redundncia alto e por conseqncia, procedimentos mais complexos de carga e manuteno.

Os padres de uso de um data warehouse tambm constituem um fator importante na escolha de alternativas para o ambiente. Relatrios e consultas pr-estruturadas podem satisfazer o usurio final, 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.

5.1 - Estratgia Evolucionria


Data warehouses, em geral, so projetados e carregados passo a passo, seguindo, portanto uma abordagem evolucionria. Os custos de uma implementao "por inteiro", em termos de recursos consumidos e impactos no ambiente operacional da empresa justificam esta estratgia. Muitas empresas iniciam o processo a partir de uma rea especfica da empresa, que normalmente uma rea carente de informao e cujo trabalho seja relevante para os negcios da empresa, criando os chamados data marts (um data warehouse departamental), para depois ir crescendo aos poucos, seguindo uma estratgia "botton-up" ou assunto-porassunto.

Outra alternativa selecionar um grupo de usurios, prover ferramentas adequadas, construir um prottipo do data warehouse, deixando que os usurios experimentem com pequenas amostras de dados. Somente aps a concordncia do grupo quanto aos requisitos e funcionamento, que o data warehouse ser de fato carregado com dados dos sistemas operacionais na empresa e dados externos. Data marts tambm pode ser criados como subconjunto de um data warehouse maior, em busca de autonomia, melhor desempenho e simplicidade de compreenso.

5.2 - Aspectos de Modelagem


A especificao de requisitos do ambiente de suporte deciso associado a um data warehouse fundamentalmente diferente da especificao de requisitos dos sistemas que sustentam os processos usuais do ambiente operacional de uma empresa. 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. 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.

5.3 Tcnicas de gerenciamento da quantidade de dados operacionais pesquisados


Existem algumas tcnicas que podem ser usadas para limitar a quantidade de dados pesquisados, conforme demonstrado na Figura 5.1, as tcnicas expostas a seguir devem ser analisadas e deve-se escolher a que melhor represente as necessidades da empresa.[DAL99].

Figura 5.1 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.

5.4 Tcnicas para incrementar a performance


O grande desafio de um sistema de apoio a deciso que ele possua uma interface amigvel e tempo de resposta satisfatrio. Existem algumas tcnicas que podem ser aplicadas no desenvolvimento de um data warehouse para incrementar sua performance. Essas tecnologias podem ser divididas em duas reas: aquelas que propem solues baseadas em hardware e outras baseadas em software. Algumas destas tcnicas baseadas em software so amplamente utilizadas no ambiente operacional e outras so especficas do ambiente de data warehouse, algumas tcnicas so citadas a seguir, conforme [DAL99] e [PER99]. Uma proposta ao nvel de hardware seria dividir o trabalho entre vrios processadores. Porm, o sistema gerenciador de banco de dados deve ser capaz de dividir seu processamento entre esses processadores. Com o processamento paralelo, a percepo de melhora no desempenho imediata, mas a tendncia, ao longo do tempo, voltarmos ao mesmo ponto, devido ao crescimento constante do data warehouse, atrelado s grandes mudanas que ocorrem freqentemente no mundo dos negcios. A distribuio do data warehouse, por vezes, similar abordagem do processamento paralelo: dividir a base de dados em subconjuntos de dados e coloca-los em 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 5.2 mostra um exemplo no qual a introduo deliberada de dados redundantes proporciona um excelente retorno. Na parte superior da Figura 5.2 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 5.2 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 5.2 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.

5.5 - Etapas do Desenvolvimento de um Data Warehouse


Na verdade, difcil apontar no momento, uma metodologia consolidada e amplamente aceita para o desenvolvimento de data warehouses. O que se v na literatura e nas histrias de sucesso de implementaes em empresas, so propostas no sentido de construir um modelo dimensional a partir do modelo de dados corporativo ou departamental (base dos bancos de dados operacionais da empresa), de forma incremental. De fato, um data warehouse construdo de uma maneira "heurstica", confirmando a estratgia evolucionria discutida no item anterior. De qualquer forma, a metodologia a ser adotada ainda bastante dependente da abordagem escolhida, em termos de ambiente, distribuio, etc. A seguir, apresentamos, a ttulo de exemplo, as etapas sugeridas para um desenvolvimento do tipo estrela. Desenvolver um data warehouse uma questo de casar as necessidades dos seus usurios com a realidade dos dados disponveis. Abaixo podemos analisar um conjunto de nove pontos fundamentais no projeto da estrutura de um data warehouse. So os seguintes os chamados pontos de deciso, que constituem definies a serem feitas e correspondem, de fato, a etapas do projeto: Os processos, e por conseqncia, a identidade das tabelas de fatos; A granularidade de cada tabela de fatos; As dimenses de cada tabela de fatos; Aos fatos, incluindo fatos pr-calculados; Os atributos das dimenses; Como acompanhar mudanas graduais em dimenses; As agregaes, dimenses heterogneas, minidimenses e outras decises de projeto fsico; Durao histrica do banco de dados; A urgncia com que se d a extrao e carga para o data warehouse.

Recomenda-se que estas definies se faam na ordem acima. Esta metodologia segue a linha top-down, 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-de-recebimento, modo-de-envio. A adio destas dimenses descritivas no altera o nmero de instncias na tabela de fatos. A Figura 5.3 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.

Figura 5.3 - A tabela de fatos e suas dimenses. 5.6 Relacional versus multidimensional
Bancos de dados relacionais encontram em sua flexibilidade e potencial para consultas adhoc, um de seus pontos fortes. Bancos de dados relacionais so sabidamente mais flexveis quando so usados com uma estrutura de dados normalizada. Uma tpica consulta OLAP, no entanto, "atravessa" diversas relaes e requer diversas operaes de juno para reunir estes 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.

5.5.1 - Um ou mais bancos


Embora se discuta o banco de dados de um data warehouse como se fosse um nico repositrio de dados, em grande parte dos casos isto no acontece. Na verdade, os dados podem estar distribudos por mltiplos bancos de dados, inclusive sob diferentes sistemas de gerenciamento de banco de dados. Bancos de dados multidimensionais fornecem uma viso especfica dos dados da empresa. Cada rea pode, no entanto, requerer que a organizao dos dados segundo um array multidimensional seja ditada pela sua viso do negcio, atendendo a suas necessidades. 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.

Cap. VI Povoando o Data Warehouse

A extrao, limpeza, transformao e migrao de dados dos sistemas existentes na empresa para o Data warehouse constituem tarefas crticas para o seu funcionamento efetivo e eficiente. Diversas tcnicas e abordagens tm sido propostas, algumas bastante genricas e outras especialmente voltadas para a manuteno de integridade dos dados num ambiente caracterizado pela derivao e replicao de informaes. Os produtos oferecidos no mercado procuram automatizar processos que teriam de ser feitos manualmente ou utilizando ambientes de programao de mais baixo nvel. De fato, no existe uma ferramenta nica capaz de oferecer suporte aos processos de extrao, limpeza, transformao e migrao dos dados: diferentes ferramentas especializam-se em questes especficas. O grande desafio por trs da alimentao de dados das fontes para o data warehouse no tcnico, mas gerencial. Muitos dos processos envolvidos - como mapeamento, integrao e avaliao de qualidade - ocorrem de fato durante a fase de anlise e projeto do data warehouse. Especialistas afirmam que identificar fontes, definir regras de transformao e detectar e resolver questes de qualidade e integrao consomem cerca de 80 % do tempo de projeto. Infelizmente, no fcil automatizar estas tarefas. Embora algumas ferramentas possam ajudar a detectar problemas na qualidade dos dados e gerar programas de extrao, a maioria das informaes necessria para desenvolver regras de mapeamento e transformao existe apenas na cabea dos analistas e usurios. Fatores que certamente influem na estimativa de tempo para estas tarefas so o nmero de fontes e a qualidade dos metadados mantidos sobre estas fontes. As regras de negcio associadas a cada fonte - tais como validao de domnios, regras de derivao e dependncias entre elementos de dados - so outra fonte de preocupaes. Se estas regras tiverem de ser extradas do cdigo fonte das aplicaes, o tempo para mapeamento e integrao pode dobrar [CAM99].

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 [CAM99]. 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].

6.2 Transformao e filtros


Uma vez que os dados so extrados e colocados na rea de trabalho temporria, estes devem passar por uma srie de tratamentos. O primeiro destes tratamentos refere-se a limpeza ou filtragem dos dados onde o objetivo garantir a integridade dos dados atravs de programas ou rotinas especiais que tentam identificar anomalias e resolv-las, deixando os dados em um estado consistente antes de serem instalados no data warehouse. A correo de erros de digitao, a descoberta de violaes de integridade, a substituio de caracteres desconhecidos, a padronizao de abreviaes, podem ser exemplos de limpeza de dados. O segundo passo colocar os dados em uma forma homognea aplicando uma metodologia de comparao de representaes, que inclua os critrios a serem utilizados na identificao de semelhanas e conflitos de modelagem. Conflitos de modelagem podem ser divididos em: semnticos e estruturais. Conflitos semnticos so todos aqueles envolvendo o nome ou palavra associado s estruturas de modelagem, por exemplo, mesmo nome para diferentes entidades ou diferentes nomes para a mesma entidade. Conflitos estruturais englobam os conflitos relativos s estruturas de modelagem escolhidas, tanto no nvel de estrutura propriamente dito como no nvel de domnios. Os principais tipos de conflito 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].

6.3 - Derivao e Sumarizao


Diferentes alternativas tambm existem para prover suporte a dados. Uma abordagem derivar os dados durante o processo de carga e armazen-los no ambiente relacional

corporativo. Uma alternativa fazer a derivao quando o servidor de replicao distribui os dados para os data warehouses. Ou ento, derivar os dados "on-the-fly" quando o usurio submeter uma consulta ou lanar uma simulao [CAM99].

Cap. VII Extraindo informaes do Data Warehouse


Existem vrias maneiras de recuperar informaes de um data warehouse, as formas de extrao mais comuns no mercado hoje so: Ferramentas de consulta e emisso de relatrios; EIS (Executive Information Systems); Ferramentas OLAP; Ferramentas Data mining.

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.

7.1 - Ferramentas OLAP


OLAP (On-Line Analytical Processing) representa um conjunto de tecnologias projetadas para suportar anlise e consultas ad hoc. Sistemas OLAP ajudam analistas e executivos a sintetizarem informaes sobre a empresa, atravs de comparaes, vises personalizadas, anlise histrica e projeo de dados em vrios cenrios de "e se...". Sistemas OLAP so implementados para ambientes multi-usurio, arquitetura cliente-servidor e oferecem respostas rpidas e consistentes s consultas iterativas executadas pelos analistas, independente do tamanho e complexidade do banco de dados. A caracterstica principal dos sistemas OLAP permitir uma viso conceitual multidimensional dos dados de uma empresa. A viso multi-dimensional muito mais til para os analistas do que a tradicional viso tabular utilizada nos sistemas de processamento de transao. Ela mais natural, fcil e intuitiva, permitindo a viso em diferentes perspectivas dos negcios da empresa e desta maneira tornando o analista um explorador da informao [BIS99]. A modelagem dimensional a tcnica utilizada para se ter uma viso multi-dimensional dos dados. 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 multi-dimensional 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 [TEC99]. 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 [TEC99]: 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]. 7.1.1 - MOLAP x ROLAP Multidimensional OLAP (MOLAP) uma classe de sistemas que permite a execuo de anlises sofisticadas usando como gerenciador de dados um banco de dados multidimensional. Em um banco de dados MOLAP os dados so mantidos em arranjos e indexados de maneira a prover uma tima performance no acesso a qualquer elemento. O indexamento, a antecipao da maneira como os dados sero acessados e o alto grau de agregao dos dados fazem com que sistemas MOLAP tenham uma excelente performance. Alm de serem rpidos, outra grande vantagem destes sistemas o rico e complexo conjunto de funes de anlise que oferecem. 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 hiper-cubo 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", "mes", "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. 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) [TEC99].

7.2 - Ferramentas Data Mining


Nos primrdios do data warehouse, data mining era visto como um subconjunto das atividades associadas com o warehouse. Mas atualmente os caminhos do warehouse e do mining esto divergindo. Enquanto o warehouse pode ser uma boa fonte de dados para minerar, o data mining foi reconhecido como uma tarefa genuna, e no mais como uma colnia do warehouse [PAR99]. Apesar do termo data mining ter se tornado bastante popular nos ltimos anos, existe ainda uma certa confuso quanto sua definio. Data mining (ou minerao de dados) o processo de extrair informao vlida, previamente desconhecida e de mxima abrangncia a partir de grandes bases de dados, usando-as para efetuar decises cruciais. Data mining vai muito alm da simples consulta a uma banco de dados, no sentido de que permite aos usurios explorar e inferir informao til a partir dos dados, descobrindo relacionamentos escondidos no banco de dados. Pode ser considerada uma forma de descobrimento de conhecimento em bancos de dados (KDD - Knowledge Discovery in Databases), rea de pesquisa de bastante evidncia no momento, envolvendo Inteligncia Artificial e Banco de Dados [CAM99]. Um ambiente de apoio tomada de decises, integrando tcnicas de data mining sobre um ambiente de data warehousing, possibilita um grande nmero de aplicaes, que j vm sendo implementadas em diversos segmentos de negcios, como manufatura, automao de pedido de remessas, varejo, gerenciamento de inventrios, financeiro, anlise de risco, transporte, gerenciamento de frotas, telecomunicao, anlise de chamadas, sade, analise de resultados,

markenting, estabelecimento do perfil dos consumidores, seguros, deteco de fraude, dentre outros [PIN99]. Data mining pode ser utilizado com os seguintes objetivos [TEC99]: Explanatrio: explicar algum evento ou medida observada, tal como porque a venda de sorvetes caiu no Rio de Janeiro; Confirmatrio: confirmar uma hiptese. Uma companhia de seguros , por exemplo, pode querer examinar os registros de seus clientes para determinar se famlias de duas rendas tem mais probabilidade de adquirir um plano de sade do que famlias de uma renda; Exploratrio: analisar os dados buscando relacionamentos novos e no previstos. Uma companhia de carto de crdito pode analisar seus registros histricos para determinar que fatores esto associados a pessoas que representam risco para crditos.

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].

7.2.1 - O processo do Data Mining


De uma vista de processo orientado, h trs classes de data mining: descobrimento, modelagem de prognstico e anlise prvia. Descobrimento o processo de examinao em um banco de dados para encontrar padres escondidos sem uma idia ou hiptese pr-determinada sobre o que so esses padres. Em outras palavras, o programa toma a iniciativa de encontrar aquilo que interessa aos padres, sem que o usurio verifique se isto realmente interessa. Em uma grande base de dados, h muitos padres que o usurio pode praticamente nunca imaginar as perguntas certas para as respostas. A soluo lanada aqui a riqueza dos padres que podem ser expressos e descobertos e a qualidade de informao libertada - determinando a fora e a utilidade da tcnica de descoberta. Na modelagem de prognstico, os padres descobertos no banco de dados so usados para prognosticar o futuro. Isto permite ao usurio submeter valores desconhecidos de campos nos registros, e o sistema ir supor os valores desconhecidos baseado em padres previamente descobertos no banco de dados. Enquanto o processo de descobrimento encontra padres em dados, o processo de modelagem de prognstico aplica estes padres para supor valores nos novos itens de dados. A anlise prvia o processo de aplicao dos padres extrados para encontrar anomalias ou elementos de dados raros. Para descobrir os dados raros, ns primeiramente encontramos os

dados que seguem uma norma ou os habituais, ento detectamos aqueles que se desviam dos habituais dentro de um certo limiar. Existem trs tipos de atividade de data mining em um ambiente corporativo: episodic mining, strategic mining e continuous mining. Na atividade episodic mining ns buscamos dados de um fato especfico, tal como uma campanha de marketing direto. Ns podemos tentar entender este conjunto de dados ou us-lo para prognstico em uma nova campanha de marketing. Na atividade strategic mining, ns olhamos um largo conjunto de dados corporativos com a inteno de ganhar um conhecimento global das medidas especficas. Portanto, strategic mining pode responder a perguntas tais como: "De onde vem nosso lucro ?" ou "como fazer para nosso segmento de clientes e produtos se relacionarem?". Na atividade continuous mining ns tentamos entender como o mundo foi modificado em um determinado perodo de tempo e tentar compreender os fatores que influenciaram esta mudana. Neste caso, poderamos perguntar: "como obter padres de venda modificados neste ms?" ou "qual foi a fonte de mudana do consumidor no ltimo quadrimestre?". Continuous mining normalmente aparece e toma lugar uma vez que a strategic mining foi realizada e providenciou uma primeiro entendimento sobre os dados [POL99].

7.2.2 A tecnologia da rvore


A Figura 7.1 mostra a rvore das abordagens do data mining.

Figura 7.1 rvore das abordagens do data mining.


7.2.3 Reteno dos dados

Enquanto na "destilao de padres" ns analisamos dados, extramos padres e deixamos os dados para trs, na reteno os dados so mantidos para posterior combinao. Quando novos dados so apresentados, eles so combinados com o conjunto de dados anterior. Um exemplo bem conhecido de uma aproximao baseada na reteno de dados o mtodo "nearest neighbor" (vizinho prximo). Neste mtodo, o conjunto de dados mantido (geralmente em memria) para a comparao com novos dados. Quando um novo registro est presente, por prognstico, a "distncia" entre ele e os registros semelhantes no conjunto de dados encontrado, e os mais parecidos (ou vizinhos prximos) so identificados. Algumas vezes, precisamos reter apenas um conjunto de "casos tpicos" - podemos selecionar, por exemplo, uma srie de 100 "padres tpicos" como base para comparaes. Isto muitas vezes denominado Case-based Reasoning (traduzindo livremente, poderia ser algo como "caso baseado no raciocnio").

7.2.4 Destilao de padres


Estas tecnologias extraem padres a partir de uma srie de dados e os usam para vrios fins. Naturalmente, as primeiras duas questes aqui so: Que tipos de padres podem ser extrados e como sero representados? Obviamente, os padres necessitam ser expressos dentro de um formalismo e uma linguagem - para os escolhermos, temos trs distintas formas de abordagem: sistema lgico (logic) sistema equacional (equations) classificao cruzada (cross-tabulations)

Cada uma dessas abordagens tm razes histricas, levando-nos distintas origens matemticas.

7.2.4.1 Semelhana lgica


A lgica forma a base da maioria das linguagens escritas, e essencialmente trabalhada pelo lado esquerdo do crebro. Padres expressos em linguagens lgicas so distinguidos por duas principais caractersticas: Os primeiros so legveis e compreensveis enquanto que os outros so excelentes na representao sinuosa de "caixas" e agrupamento de dados. O operador central numa linguagem lgica normalmente uma variao do conhecido comando If / Then. Entretanto, devemos notar que enquanto a forma lgica mais comum a lgica condicional, muitas vezes necessitamos usar outras formas lgicas como uma associao lgica com a regra When / Also. Ainda que as lgicas atribudas e propostas (lgicas condicionais) sejam melhor conhecidas, outras formas de lgica (lgicas de variao e de tendncia, por exemplo) so usadas tambm em anlise dos dados objetos. Sistemas de lgica condicional podem ser separados em dois grupos distintos: rvores de regras e de deciso. Regras condicionais podem ser implementadas por Induo ou Algoritmos Genticos e vrias outras formas de gerar rvores de deciso.

7.2.4.1.1 Regras
Os relacionamentos lgicos so normalmente representados como regras. Simples regras podem expressar relaes condicionais ou de associao. Uma regra condicional um comando na forma: If Condio 1 Then Condio 2 A conexo lgica distinta a partir da lgica condicional, tanto em termos da linguagem da expresso como da estrutura de dados usadas. Anlise por Conexo (ou Anlise por Associao) [Affinity Analysis / Association Analysis] a procura por padres e condies que descrevem vrios itens, como "grupos simultneos" ou "acontecimentos simultneos" [group together / happen together] numa srie de eventos ou transaes. Uma regra de afinidade possui a seguinte forma: When Item_1 Also Item_2. Regras tm a vantagem de serem mais competentes para trabalhar com dados numricos e no-numricos de uma maneira uniforme. Enquanto trabalha com dados numricos, algumas aproximaes valem-se da quebra de campos numricos nos cdigos ou nos valores especificados. Isto pode, efetivamente, remover todas as consideraes numricas dos cdigos - resultando na perda dos padres. Regras podem tambm atuar bem em dados multidimensionais ou OLAP porque eles podem trabalhar com faixas de dados numricos e seus formatos lgicos, permitindo que seus padres possam ser mesclados ao longo de mltiplas dimenses. Regras podem ser vistas tambm como rvores de deciso, mas apesar da semelhana a nvel superficial, tm uma tcnica distinta, diferente. Isto fcil de ver quando consideramos o fato que rvores de deciso no expressam associaes ou padres baseados em atributos. A seguir, duas abordagens para a gerao de regras so colocadas: regra indutiva e algoritmos genticos. Entretanto, estas no so as nicas formas de abordagem do Data mining com regras. Algumas abordagens examinam, atravs de uma pr-computao, cada possibilidade da regra at numa srie de dados que j estavam includas (previstas). Nesses casos, somente uma nica coluna de dados pode ser usada porque o espao lgico imenso. Conseqentemente, no prtico para aplicaes em larga escala.

7.2.4.1.1.1 - Regra indutiva


Regra indutiva o processo de olhar uma srie de dados e, a partir dela, gerar padres. Pelo fato de explorar automaticamente a srie de dados, o sistema indutivo cria hipteses que conduzem a padres. O processo em sua essncia semelhante quilo que um analista humano faria em uma anlise exploratria.

7.2.4.1.1.2 Algoritmos genticos


Algoritmos genticos tambm geram regras dos conjuntos de dados, mas no seguem a induo de protocolo de regras de explorao orientada. Ao contrrio, eles contam com a idia de "mutao" para fazer trocas nos padres at que uma forma apropriada de modelo surja via educao seletiva.

7.2.4.1.2 rvores de deciso


rvores de deciso expressam uma forma simples de lgica condicional. Um sistema de rvore de deciso, simplesmente, divide uma tabela em tabelas menores pela seleo de subconjuntos baseados em valores de um atributo dado. Baseado no modo como a tabela dividida, ns obtemos um algoritmo diferente de rvore de deciso.

7.2.4.2 Tabulao cruzada


Tabulao cruzada uma forma muito bsica e simples de anlise de dados, bem conhecida em estatstica, largamente usada para reportagem. Uma tabulao cruzada de duas dimenses semelhante a uma extenso de papel, com ambos cabealhos de linhas e colunas como valores de atributos. As clulas na extenso de papel representam uma ao agregada, freqentemente o nmero de co-ocorrncias de atributo avalia-se juntos. Muitas tabulaes cruzadas so eficazmente dois equivalentes a um grfico de barras de trs dimenses o qual expe somas totais de co-ocorrncias.

7.2.4.2.1 - Agentes
O termo "agente" usado algumas vezes para referir-se as tabulaes cruzadas que so graficamente mostradas numa rede e permitem algumas conjunes (por exemplo "E" ou "AND"). Neste contexto o termo agente , efetivamente, equivalente ao termo "par de valor do campo".

7.2.4.2.2 Redes de confiana


Redes de Confiana (algumas vezes chamada de redes causais) tambm contam com totais de co-ocorrncia, mas ambas a reproduo grfica e a representao probabilista so levemente diferentes dos agentes. As redes de confiana so freqentemente ilustradas usando uma representao grfica de distribuio probabilistas (derivadas de somas totais). Uma rede de confiana ento em grfico dirigido, consistindo de ns (variveis representadas) e arcos (representando dependncias probabilistas) entre as variveis de ns.

7.2.4.3 Aproximaes equacionais


O mtodo abaixo de expresso padro nestes sistemas a construo de superfcie melhor do que a expresso lgica ou co-ocorrncia de contagens. Tal sistema geralmente utiliza um grupo de equaes para definir uma superfcie dentro de um espao numrico.

As aproximaes equacionais quase sempre requerem que os dados sejam todos numricos. Dados no numricos precisam ser codificados em nmeros (o contrrio do que faz a tabulao cruzada).

7.2.4.3.1 Redes neurais


Redes Neurais so uma classe de modelagem de prognstico que trabalha por ajuste repetido de parmetro. Estruturalmente, uma rede neural consiste em um nmero de elementos interconectados (chamados neurnios) organizados em camadas que aprendem pela modificao da conexo firmemente conectando as camadas. Redes neurais geralmente constroem superfcies equacionais complexas atravs de interaes repetidas, cada hora ajustando os parmetros que definem a superfcie. Depois de muitas repeties, uma superfcie pode ser internamente definida que se aproxima muito dos pontos dentro do grupo de dados. A funo bsica de cada neurnio : (a) avaliar valores de entrada, (b) calcular o total para valores de entrada combinados, (c) compara o total com um valor limiar, (d) determinar o que ser a sada. Enquanto a operao de cada neurnio razoavelmente simples, procedimentos complexos podem ser criados pela conexo de um conjunto de neurnios. Tipicamente, as entradas dos neurnios so ligadas a uma camada intermediria (ou vrias camadas intermedirias) que ento conectada com a camada de sada. Para construir um modelo neural, ns primeiramente "adestramos" a rede em um dataset de treinamento e ento usamos a rede j treinada para fazer predies. Ns podemos, s vezes, monitorar o dataset durante a fase de treinamento para checar seu progresso. Cada neurnio geralmente tem um conjunto de pesos que determina como o neurnio avalia a combinao dos sinais de entrada. A entrada para um neurnio pode ser positiva ou negativa. O aprendizado se faz pela modificao dos pesos usados pelo neurnio em acordo com a classificao de erros que foi feita pela rede como um todo. As entradas so geralmente pesadas e normalizadas para produzir um procedimento suave. Durante a fase de treinamento, a rede estabelece os pesos que determinam o comportamento da camada intermediria. Um termo popular chamado "backpropagation" (propagao realimentada) usado quando os pesos so ajustados baseados nas estimativas feitas pela rede - suposies incorretas reduzem os limites para as conexes apropriadas.

Concluso
A tecnologia de data warehouse mostra-se muito interessante para empresas que possuem grandes volumes de dados gerados e acumulados durante sua existncia e necessitam recuperar estes dados de uma forma que eles possam auxiliar os administradores destas empresas a tomarem decises estratgicas rapidamente e com segurana. 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, de onde vieram, para onde vo, etc. 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. 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, abr de 1999. [CAM99] CAMPOS, Maria Luiza & FILHO, Arnaldo V. Rocha. Data warehouse. Obtida via Internet. Ultimo acesso: 01/09/1999. http://genesis.nce.ufrj.br/dataware/tutorial/indice.html. [DAL99] DALALBA, Adriano. Um estudo sobre Data warehouse. Obtida via internet. Ultimo acesso: 01/09/1999. http://www.geocities.com/siliconvalley/port/5072/. [GRI99] DALFOVO,Oscar & GRIPA, Robson. Data warehouse: usando a tcnica de cubo de deciso. Developers Magazine, So Paulo, n.32, p.12-17, abr de 1999. [INM97] INMON, William H.. Como construir o Data warehouse. 2 ed. New York: Editora Campus, 1997, 388p. [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. Developers Magazine, So Paulo, n.35, p.38-40, jul de 1999. [TEC99] Tecnologias Data warehouse e OLAP. Obtida via internet. Ultimo acesso: 01/09/1999. http://jacques.ic.cti.br/ic/pqps/atps/dw.htm.

You might also like