DATA WAREHOUSE INTRODUO Informaes importantes em uma organizao, armazenadas em grandes bancos de dados, geralmente heterogneas e distribudas, so pouco

aproveitadas para dar suporte deciso. Tentando minimizar problemas de distribuio e heterogeneidade, no centro deste ambiente est o conceito de Data Warehouse. A tecnologia de Data Warehouse surgiu principalmente devido s dificuldades que muitas organizaes comearam a passar pela quantidade de dados que suas aplicaes estavam gerando e dificuldade de reunir estes dados de forma integrada para uma anlise mais eficiente. A idia, ento, foi reunir em um nico local, somente os dados considerados teis no processo decisrio. Em um exemplo prtico, suponhamos uma empresa de transporte areo. Atravs da tecnologia Data Warehouse pode-se obter a informao sobre qual ms do ano h uma maior procura por vos para o Rio de Janeiro, ou ainda, para qual local os jovens com menos de vinte e cinco anos esto viajando atravs dos meios areos. Tendo em mos essas informaes em tempo hbil em outras palavras, antes da concorrncia os executivos dessa organizao podem dispor mais vos para o Rio de Janeiro no ms de maior procura e, a respeito dos jovens, talvez fosse interessante disponibilizar algum tipo de lazer diferenciado durante a viagem. De posse destas informaes, os executivos/usurios do Data Warehouse dispem de mecanismos que permitem, a partir de seu velho e volumoso banco

de dados, extrair dados que sero de grande utilidade e que daro maior lucratividade a mdio-longo prazo. O nosso exemplo se aplica a empresas privadas, mas o Data Warehouse tambm pode ser aplicada em organizaes governamentais pblicas. Tendo em mos um Data Warehouse, o Secretrio da Sade, por exemplo, pode obter a informao de qual regio da cidade ocorreram mais casos de dengue nos ltimos cinco anos e, em quais meses desses anos, houve uma maior incidncia desse vrus. Os avanos da tecnologia de informao vieram garantir a possibilidade das organizaes manipularem grandes volumes de dados e atingirem um alto ndice de integrao. Dados de todos os departamentos de uma organizao podem estar em uma nica base de dados, integrados, padronizados e resumidos para serem analisados pelos tomadores de decises.

DESENVOLVIMENTO DO PROJETO DE DATA WAREHOUSE EVOLUO DOS SISTEMAS DE APOIO DECISO Segundo Inmon (1997), 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, 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. Examinando a confuso criada pelos arquivos mestres e as enormes quantidades de dados redundantes ligadas a eles, no de admirar que banco de dados seja definido como: uma nica fonte de dados para todo o processamento. (Inmon, 1997).

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, comearam a aparecer. O usurio final passou a controlar diretamente os sistemas e os dados, descobrindo que era possvel utiliza-los 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 SIGs. Hoje conhecidos como SAD, os SIGs consistiam em processamento utilizado para direcionar decises gerenciais.

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 3. Primeiro havia extraes. Depois, extraes das extraes, e, ento, extraes das extraes das extraes, e assim por diante.

Figura 1 - A Teia de Aranha

Devido arquitetura de desenvolvimento espontneo, surgiram problemas com a credibilidade dos dados, a produtividade e a dificuldade de transformar dados puros em informaes. 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. No cerne do ambiente projetado est a percepo de que h fundamentalmente duas espcies de dados dados primitivos e dados derivados. A Tabela 1 mostra algumas das principais diferenas entre dados primitivos e derivados.

Dados primitivos / Dados operacionais Baseado em aplicaes Detalhados Podem ser atualizados So processados repetitivamente Requisitos de processamento conhecidos com antecedncia A performance fundamental Voltados para transao Alta disponibilidade Atendem as necessidades cotidianas Alta taxa de acesso

Dados derivados / dados SAD Baseados em assunto ou negcio Resumidos ou refinados No so atualizados Processados de forma heurstica Requisitos de processamento no so conhecidos com antecedncia. Performance no fundamental Voltados para anlise No necessria alta disponibilidade Atendem as necessidades gerenciais Baixa ou mdia taxa de acesso

Tabela 1 - dados operacionais versus dados derivados

Dados primitivos e dados derivados devem estar fisicamente separados. H uma grande quantidade de diferenas entre dados primitivos e dados derivados. espantoso que a comunidade de processamento de informaes tenha pensado

que dados primitivos e dados derivados pudessem se encaixar em um nico banco de dados (Inmon, 1997). H quatro nveis no ambiente projetado o operacional, a atmico ou Data Warehouse, o departamental e o individual, como representado na Figura 4. 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.

Operacional - Detalhado - Cotidiano - Valores atuais - Alta taxa de acesso - Baseado em aplicaes

Atmico / Data Warehouse

Departamental - Paroquial - Alguns derivados; alguns primitivos - Tpico de departamentos: - contabilidade - marketing - engenharia - produo - Baseado em negcio

Individual - Temporrio - ad hoc - Heurstico - No repetitivo - Baseado em PCs ou estaes de trabalho

- mais granular - Temporal - Integrado - Baseado em negcio - Algum nvel de resumo

Figura 2 - Nveis do Ambiente Projetado

Um importante aspecto do ambiente projetado a integrao dos dados que ocorre ao longo da arquitetura. Se os dados chegarem ao Data Warehouse em um estado no integrado, no podero ser utilizados como base para uma viso

corporativa dos dados. A existncia desta viso um dos fundamentos do ambiente projetado (Kimball, 1998).

O QUE UM DATA WAREHOUSE William H. Inmon foi um dos pioneiros no assunto Data Warehouse. Sua definio a mais objetiva sobre o que um Data Warehouse: uma coleo de dados orientados por assunto, integrado, varivel com o tempo e no-voltil, que tem por objetivo dar suporte aos processos de tomada de deciso (Inmon, 1997). Em outras palavras, um 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. Para Campos (1999), 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 dados primitivos, 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. Para ficar mais clara a concepo de Data Warehouse examina a tabela 2 que contm uma comparao entre as caractersticas dos bancos de dados operacionais com um Data Warehouse.

Bancos de dados Operacionais Objetivo Operaes dirias do negcio Uso Operacional Tipo de processamento OLTP Unidade de trabalho Incluso, alterao, excluso. Nmero de usurios Milhares Tipo de usurio Operadores Interao do usurio Somente pr-definida Caractersticas Condies dos dados Volume Histrico Granularidade Redundncia Estrutura Manuteno desejada Acesso a registros Atualizao Integridade Nmero de ndices Inteno dos ndices Dados operacionais Megabytes gigabytes 60 a 90 dias Detalhados No ocorre Esttica Mnima Dezenas Contnua (tempo real) Transao Poucos/simples Localizar um registro

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 Ocorre Varivel Constante Milhares Peridica (em batch) A cada atualizao Muitos/complexos Aperfeioar consultas

Tabela 2 - Comparao entre banco de dados operacionais e Data Warehouse

O Data Warehouse o alicerce do processamento dos SADs. Em virtude de haver uma nica fonte de dados integrados, e uma vez que os dados apresentam

condies facilitadas de acesso e interpretao, a tarefa do analista de SAD no ambiente Data Warehouse fica incomensuravelmente mais fcil do que no ambiente clssico. CARACTERSTICAS DE UM DATA WAREHOUSE Quatro caractersticas principais regem o conceito de Data Warehouse. 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 (Campos, 1999). 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 inseirdos 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 (Campos, 1999).

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 (Campos, 1999). 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 (Campos, 1999). 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 (Campos, 1999).

USURIOS TPICOS DE UM DATA WAREHOUSE Inmon, Welch e Glassey (1999) identificaram trs usurios tpicos de um Data Warehouse: os fazendeiros, os exploradores e os turistas. A Figura 5 ilustra os tipos de usurios.

Os fazendeiros da organizao colhem informaes a partir de caminhos de acessos conhecidos. Fazendeiros

OLAP

Os turistas da organizao navegam atravs das informaes colhidas pelos fazendeiros. Turistas

Estruturado Organizacional
Exploradores Figura 3 - Usurios do Data Warehouse

Os exploradores da organizao procuram as recompensas desconhecidas e at ento ignoradas que se ocultam por trs dos dados detalhados.

Como regra, os dados estruturados organizacional servem aos usurios fazendeiros e turistas. O dados detalhados servem aos usurios exploradores porque so orientados corporativamente, suportam acesso aleatrio e so

completos e histricos. O ambiente OLAP (explicado mais adiante) suporta os usurios fazendeiros porque os dados so personalizados antes de serem enviados ao ambiente OLAP. A fim de personalizar os dados, necessrio saber como os dados sero usados.; os fazendeiros tomam essas decises com base no como os turistas consomem seus produtos. Em outras palavras, fornecimento e demanda aplicam-se arquitetura do Data Warehouse na determinao do que deve ser populado no ambiente OLAP (Inmon, Welch e Glassey, 1999). H diversas excees a essa regra de diferentes usurios. Devido quantidade limitada de dados l encontrados, o grande nmero de ndices e a elegncia da interface, possvel executar exploraes no ambiente OLAP. Contudo, a explorao no nvel OLAP superficial, e encontra uma viso geral e no detalhada. Na maioria das vezes, o ambiente OLAP existe e perfeito para os usurios fazendeiros e turistas, mas no para a comunidade de exploradores.

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. A Figura 6 mostra os principais componentes da arquitetura de um Data Warehouse.

Front End Tools Servidores OLAP

Back End
Fontes Extrao Transformao Carga Refresh DW

Anlise
Consulta Relatrio

BD Data Marts

Data Mining

Administrao e gerenciamento: Repositrio de

Figura 6 - Arquitetura do Data Warehouse

A arquitetura de um Data Warehouse inclui ferramentas para extrair dados de mltiplas bases de dados operacionais e fontes externas; limpar, transformar e integrar estes dados, carreg-los at o Data Warehouse e periodicamente fazer o refresh, isto , propagar as atualizaes ocorridas nas mltiplas base de dados operacionais. Em adio ao Data Warehouse principal, pode haver vrios Data Warehouses departamentais, que so denominados Data Marts. Dados no Data Warehouse e Data Marts so armazenados e gerenciados por um ou mais servidores de Data Warehouse, os quais apresentam vises multidimensionais de dados para uma variedade de ferramentas front end. Finalmente, h um repositrio para armazenar e gerenciar metadados.

FERRAMENTAS BACK END Sistemas de Data Warehouse usam uma variedade de ferramentas para extrao, limpeza de dados, carga e refresh para povoar o banco de dados. Estas ferramentas so chamadas Back End e as principais funes desempenhadas por elas so: Limpeza de dados: J que o Data Warehouse usado para tomada de deciso, importante que os seus dados estejam corretos. Entretanto, uma vez que grandes volumes de dados esto envolvidos, h uma alta probabilidade de erros e anomalias nos dados. Tamanhos inconsistentes de campo, descries

inconsistentes, atribuio inconsistente de valores, entradas erradas e violao de restries de integridade so alguns exemplos onde a limpeza de dados torna-se necessria. Carga: Depois de extrair, limpar e transformar, os dados devem ser carregados para o Data Warehouse. Um pr-processamento adicional pode ser requerido, como por exemplo, checagem de restries de integridade, sumarizao, agregao, dentre outros mais. Tipicamente, batch load usado para este propsito, isto , o processo de carga feito em lotes. A carga do Data Warehouse tem que lidar com volumes de dados muito maiores que os banco de dados operacionais.

Refresh: Fazer o refresh de um Data Warehouse consiste em propagar as atualizaes ocorridas nos banco de dados operacionais para o banco de dados derivado do Data Warehouse. FERRAMENTAS FRONT END Segundo Moraes (1998), o componente front end de um sistema de Data Warehouse o responsvel por fornecer uma soluo de acesso aos dados que atenda as necessidades por informaes dos trabalhadores do conhecimento. As ferramentas front end so utilizadas para anlise, ajudando a interpretar o que ocorreu e a decidir sobre estratgias futuras. Neste tipo de aplicao, somente a operao de consulta se faz necessria. As ferramentas Front End executam: o Seleo do conjunto de dados necessrios; o Clculo e manipulao dos dados; o Apresentao das informaes; Os geradores de consultas e relatrios so considerados a primeira gerao de ferramentas para o acesso a dados, as quais permitem a realizao de consultas ad-hoc. Atualmente, as ferramentas de OLAP so as principais aplicaes de suporte deciso utilizadas em sistemas de Data Warehouse, sendo consideradas a segunda gerao de ferramentas para acesso a dados. Ao

contrrio dos geradores de consultas e relatrios, que apenas permitem uma visualizao esttica dos dados que no podem mais ser manipulados, as aplicaes de OLAP possibilita que a partir de uma resposta se faam outros questionamentos, ou seja, o usurio consegue analisar o porqu dos resultados obtidos. Moraes (1998), compilou a lista abaixo de caractersticas que possuem eficientes ferramentas de Front End. o facilidades para acesso aos dados, manipulao e apresentao; o capacidade de especificar consultas e relatrios com facilidade; o suporte para a indstria de padres de interface, incluindo Microsoft Windows GUI, ODBC, etc. o suporte para o desenvolvimento de interfaces amigveis; o habilidade para acessar a funcionalidade nativa de uma variedade de BD e outras origens de dados; o habilidade para suportar uma variedade de plataformas servidoras e SGBDs.

DATA MARTS Um Data Mart um sistema de suporte a deciso que incorpora um subconjunto de dados da empresa focalizado em funes ou atividades especficas da organizao. Os Data Marts tm propsitos especficos relacionados ao negcio, como medida do impacto de promoes de marketing, medida ou previso de vendas, medida do impacto da introduo de novos produtos, etc. Data Marts podem incorporar dados substanciais, mas eles contm muito menos dados que teria um Data Warehouse desenvolvido para a mesma organizao. Uma vez que Data Marts so focalizados em propsitos especficos do negcio, o planejamento do sistema e a anlise dos requerimentos so mais facilmente gerenciveis, e o projeto, implementao, fase de testes e instalao so bem mais baratos que para um Data Warehouses (Inmon, Welch e Glassey, 1999). Por esse motivo, os Data Marts esto se tornando uma alternativa bastante popular nos ltimos anos. Os projetos de Data Marts devem ser inicialmente simples e teis para que possam atingir seus objetivos de forma rpida e clara. No desejvel para uma empresa investir uma quantia em dinheiro e tempo de seus funcionrios em um projeto que pode levar meses para ser concludo e que durante o processo de implantao possa terminar por gerar controvrsias e at mesmos problemas para os setores (Kimball, 1998).

DATA MINING Data Mining uma ferramenta de extrao de dados. O Data Mining engloba um nmero de diferentes abordagens tcnicas, como clustering (agrupamento), sumarizao de dados, regras de classificao, deteco de anomalias, etc. Data Mining uma categoria de ferramentas de anlise. Em vez de se fazerem perguntas, entrega-se grandes quantidades de dados e pergunta-se se existe algo de interessante (uma tendncia ou um agrupamento, por exemplo). O processo de minerao de dados pode extrair conhecimento que est escondido ou informaes de prognstico do Data Warehouse sem a necessidade de consultas especficas ou requisies. Esse processo de minerao usa tcnicas avanadas como redes neurais, heursticas, descoberta por regra e deteco de desvio. Ao contrrio de relatrios e consultas cujos relacionamentos j se conhece, o trabalho do Data Mining descobrir o que no se sabe que existe no banco de dados. Alguns exemplos de aplicaes de Data Mining: o identificar padres de compra dos clientes; o identificar correlaes escondidas entre diferentes indicadores financeiros; o identificar superfaturamento em grandes obras pblicas.

SISTEMAS GERENCIADORES DE BANCOS DE DADOS SGBDs tm como funo fornecer acesso e manipulao eficientes aos dados armazenados no banco, proteger estes dados contra acessos indevidos e manter sua consistncia e integridade (Moraes, 1998). Os SGBDs em sistemas de Data Warehouse devem suportar processamento analtico on-line (OLAP), ao contrrio do j tradicional processamento de transaes on-line (OLTP). Os SGBDs voltados ao processamento de transaes tm como principal caracterstica dar suporte para atualizaes concorrentes de centenas de usurios. J os SGBDs voltados para sistemas de Data Warehouse devem ser otimizados para o processamento de consultas complexas e ad-hoc. Trs classes de SGDBs devem ser citadas: a) SGBDs relacionais tradicionais: A tecnologia relacional vem sendo amplamente reconhecida como a melhor alternativa para a hospedagem de dados em sistemas de Data Warehouse. Rapidamente, as melhorias dos SGBDs na rea de suporte deciso vm atendendo as necessidades impostas pelo ambiente de Data Warehouse. Isto se deve, principalmente, a dois principais pontos fracos dos SGBDs

multidimensionais:

inflexibilidade (estrutura de arquivos proprietria) e limitado

volume de dados que podem gerenciar. b) SGBDs multidimensionais (MOLAP):

Em um banco de dados multidimensional, em vez de armazenar registros em tabelas, eles armazenam os dados em matrizes. So projetados com o objetivo de permitir uma eficiente e conveniente armazenagem e recuperao de dados que esto intimamente relacionados. Estes dados so armazenados, visualizados e analisados segundo diferentes dimenses. O grande problema dos SGBDs multidimensinais a sua capacidade de armazenamento ainda limitada para as necessidades de um Data Warehouse. Desta forma, estes produtos so mais utilizados no mercado como gerenciadores de Data Marts. c) SGBDs relacionais especializados para sistemas de Data Warehouse: So otimizados para atender ambientes de somente leitura (read only), onde o processamento eficiente de consultas importantssimo. A idia nestes produtos abandonar os requisitos necessrios ao processamento de transaes (OLTP) e se concentrar nos requisitos necessrios ao OLAP. Desta forma, estes SGBDs fornecem novas tcnicas de otimizao de consultas sobre estruturas do tipo star scheme, utilizam novos mtodos de indexao e interpretam a sintaxe SQL para dar suporte a consultas que so importantes no ambiente de Data Warehouse.

MODELO DE DADOS Obter respostas a questes tpicas de anlise dos negcios de uma empresa geralmente requer a visualizao dos dados segundo diferentes perspectivas. Suponhamos uma grande rede de hotis que deseja melhorar o desempenho de seu negcio. Para isso, necessita examinar os dados sobre as reservas e seus clientes. Uma avaliao deste tipo requer uma viso histrica do volume de reservas informaes sobre seus clientes sob mltiplas perspectivas, como por exemplo: qual a idade mdia de seus clientes, qual o perodo mdio que os mesmos se hospedam no hotel. Uma anlise da idade mdia de seus clientes utilizando uma ou mais destas perspectivas, permitiria responder questes do tipo: Qual a idade mdia dos hspedes na temporada de final de ano? Tendo em mos a resposta para essa questo, a gerncia do hotel poderia investir no marketing para um cliente-alvo mais preciso. 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 frustrados por tempos de resposta ruins e pela falta de flexibilidade oferecida por ferramentas de consulta baseadas no SQL (Kimball, 1998).

Da a necessidade de utilizar abordagens especficas para atender a estas consultas. A mais importante diferena entre sistemas OLTP e Data Warehouse est no modelo de dados. O tradicional modelo Entidade-Relacionamento divide os dados em vrias entidades distintas, cada uma transformada em uma tabela do Banco de Dados OLTP. H algumas observaes a fazer sobre o diagrama entidaderelacionamento. Em primeiro lugar, ele muito simtrico. Todas as tabelas parecem iguais; esses diagramas so difceis de visualizar e memorizar tanto pelo usurio final quanto pelos projetistas (Kimball, 1998). Segundo, quando duas tabelas do diagrama so necessrias para uma consulta, h um nmero imenso de conexes possveis entre as duas tabelas. Em consultas que abrangem muitas tabelas e registros, os diagramas Entidade-Relacionamento tornam-se muito complexos tanto para o usurio entender quanto para o software navegar. Dito isto, pode-se concluir que modelos Entidade-Relacionamento so um desastre para ambientes read only (somente consulta) e no so propcios para serem utilizados como base para o Data Warehouse. A representao dos dados em um Data Warehouse estruturada como um cubo de dados. Essa estrutura chamada modelo dimensional, tambm conhecida como star scheme. Ao contrrio do modelo Entidade-Relacionamento, o modelo dimensional muito assimtrico. H uma tabela dominante no centro do diagrama com mltiplas junes a conectando nas outras tabelas. Cada uma das tabelas

secundrias possui apenas uma juno com a tabela central. A tabela central chamada de tabela de fatos e as outras tabelas de tabelas de dimenso, como mostra a Figura 7:

DIM PRODUTO FATO COMPRAS DIM TEMPO id_tempo dia_do_ms dia_da_semana ms ano id_tempo id_produto id_fornecedor quantidade valor id_produto descrio categoria volume DIM FORNECEDOR id_fornecedor nome endereo descrio

Figura 5 - Star Scheme

A tabela de fatos armazena medies numricas do negcio. Cada uma das medies obtida na interseo de todas as dimenses. Os fatos melhores e mais teis so numricos, valorados (diferentes a cada medida) e aditivos (podem ser adicionados ao longo das dimenses). O motivo para utilizar fatos valorados e aditivos que em praticamente todas as consultas feitas tabela de fatos, so solicitados centenas ou milhares de registros para construir o conjunto de resposta. Esse grande nmero de registros ser compactado em algumas dezenas de linhas para produzir o conjunto de resposta do usurio. A nica forma vivel de compact-los no conjunto de resposta ser adicion-los. Portanto, se as medies forem nmeros e se forem aditivas, pode-se construir facilmente o conjunto de resposta.,

As tabelas dimensionais armazenam as descries textuais das dimenses. Esses atributos textuais so usados como restries e cabealhos de linha no conjunto de resposta. Ao se projetar um banco de dados, pode-se ficar na dvida se um campo de dados ser modelado como um fato ou um atributo. Segundo Kimball (1998), se o dado for numrico e variar continuamente a cada amostragem, ele ser considerado um fato. Do contrrio, se for uma descrio praticamente constante de um item, ser considerada um atributo de dimenso. O Star Scheme tem uma srie de vantagens que so descritas abaixo: o O Star Scheme 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; o 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 O modelo dimensional totalmente flexvel para suportar a incluso de novos elementos de dados, bem como mudanas que ocorram no projeto. Essa flexibilidade se expressa de vrias formas, dentre as quais temos:

Todas as tabelas de fato e dimenses podem ser alteradas simplesmente acrescentando novas colunas a tabelas; Nenhuma ferramenta de consulta ou relatrio precisa ser alterada de forma a acomodar as mudanas; Todas as aplicaes que existiam antes das mudanas continuam rodando sem problemas; o Existe um conjunto de abordagens padres para tratamento de situaes comuns no mundo dos negcios. Cada uma destas tem um conjunto bem definido de alternativas que podem ento ser especificamente programadas em geradores de relatrios, ferramentas de consulta e outras interfaces do usurio. Dentre estas situaes temos: Mudanas lentas das dimenses: ocorre quando uma determinada dimenso evolui de forma lenta e assncrona; Produtos heterogneos: quando um negcio, tal como um banco, precisa controlar diferentes linhas de negcio juntas, dentro de um conjunto comum de atributos e fatos, mas ao mesmo tempo esta precisa descrever e medir as linhas individuais de negcio usando medidas incompatveis; o 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. DESENVOLVIMENTO DE UM 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 fundamentada de Data pelo Warehouses, trs devendo-se fazer uma escolha

em

menos

dimenses:

escopo

(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 prestruturadas 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. 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, 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, o Data Warehouse ser de fato alimentado 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.

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. 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, o modelo de dados uma base slida para identificar requisitos para um Data Warehouse.

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, de forma incremental. De qualquer forma, a metodologia a ser adotada ainda bastante dependente da abordagem escolhida, em termos de ambiente, distribuio, etc. Desenvolver um Data Warehouse uma questo de casar as necessidades dos seus usurios com a realidade dos dados disponveis. Abaixo podemos analisar os chamados pontos de deciso, que constituem definies a serem feitas e correspondem a etapas do projeto: 1. Os processos, e por conseqncia, a identidade das tabelas de fatos; 2. A granularidade de cada tabela de fatos; 3. As dimenses de cada tabela de fatos; 4. Aos fatos, incluindo fatos pr-calculados; 5. Os atributos das dimenses; 6. Como acompanhar mudanas graduais em dimenses;

7. As agregaes, dimenses heterogneas, minidimenses e outras decises de projeto fsico; 8. Durao histrica do banco de dados; 9. A urgncia com que se d a extrao e carga para o Data Warehouse. Esta metodologia segue a linha top-down, pois comea identificando os grandes processos da empresa. EXTRAINDO INFORMAES DE UM DATA WAREHOUSE Existem vrias maneiras de recuperar informaes de um data Warehouse. As formas de extrao mais comuns no mercado hoje so: o Ferramentas de consulta e emisso de relatrios; o EIS (Executive Information Systems); o Ferramentas OLAP; o Ferramentas Data mining. A nova tendncia dessas solues a integrao com o ambiente Web, permitindo maior agilidade em consultas estticas e dinmicas.

A seguir 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.

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...". Os 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 (Bispo e Cazarini, 1999). A modelagem dimensional a tcnica utilizada para se ter uma viso multidimensional 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. Alm da viso multi-dimensional dos dados da empresa, a tecnologia OLAP tem uma srie de outras caractersticas importantes relacionadas abaixo: o 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; o 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; o Dimensionalidade genrica; o Operao trans-dimensional. Possibilidade de fazer clculos e

manipulao de dados atravs diferentes dimenses; o Possibilidade de ver os dados de diferentes pontos de vista (slice and dice), mediante a rotao (pivoting) do cubo e a navegao (drill-up/drilldown) entre os nveis de agregao; o Conjunto de funes de anlise e clculos no triviais com os dados. Segundo Inmon, Welch e Glassey (1999), existe tambm um conjunto de regras que servem para avaliar as ferramentas OLAP): o Viso conceitual multidimensional; o Transparncia; o Acessibilidade;

o Performance de Relatrio consistente; o Arquitetura cliente-servidor; o Dimensionalidade genrica; o Operao dimensional cruzada irrestrita; o Manipulao de dados intuitiva; o Flexibilidade quanto a relatrios; o Dimenso e nveis de agregamentos ilimitados; o Pesquisa de detalhes (drill down); o Atualizao incremental do banco de dados; o Arrays mltiplos; o Seleo de subconjuntos; o Suporte a dados locais. 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.

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 faz 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 "compras" referenciada pelas dimenses "produto", "ano", "mes", "estado" e "cidade". 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. Existem duas maneiras de se fazer este trabalho: o 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; o Ou executar comandos SQL para recuperar os dados, mas fazer todo o processamento (incluindo joins e agregaes) no servidor OLAP. 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. FERRAMENTAS DATA MINING Segundo Pinheiros (1999), nos primrdios do Data Warehouse, o Data Mining era visto como um subconjunto das atividades associadas com o Data Warehouse. Mas atualmente os caminhos do Data warehouse e do Data Mining esto divergindo. Enquanto o Data 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 Data Warehouse. 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 (Campos, 1999). 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 (Pinheiros, 1999). O Data Mining pode ser utilizado com os seguintes objetivos: o Explanatrio: explicar algum evento ou medida observada, tal como porque a venda de sorvetes caiu no Rio de Janeiro;

o 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; o 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. 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.

CARACTERSTICAS DE UM DATA WAREHOUSE BEM-SUCEDIDO O que pode ser feito para criar um ambiente de anlise de dados moderno no qual os usurios possam embarcar numa viagem aleatria e direta? Segundo Inmon, Welch e Glassey (1999) h quatro objetivos-chave que devem ser alcanados para um Data Warehouse ser considerado bem-sucedido. o Fornecer modos melhores e mais rpidos para que os usurios descubram as respostas a questes complexas e imprevisveis.

o Colocar os usurios em contado direto com os dados de que precisam para tomar decises melhores. o Permitir que os usurios tornem-se responsveis pela especificao, criao e gerao repetida dos relatrios e anlises que necessitem. o Contar com uma manuteno apropriada e responsvel dos recursos de dados corporativos. O sistema que satisfaz esses objetivos um sistema de suporte a decises moderno. Os projetos de Data Warehouse obtm sucesso quando os usurios so mais independentes. Data Warehouses bem-sucedidos colocam os usurios no centro do projeto. Quando todos reconhecem isso, uma nova atitude e abordagem so os ingredientes mais bem-sucedidos nessa mistura. As organizaes que entendem esses fatores fundamentais que esto conduzindo a alteraes no paradigma tero sucesso em estabelecer Data Warehouses bem-sucedidos (Inmon, Welch e Glassey, 1999).