CONSTRUINDO UM DATA WAREHOUSE E ANALISANDO SUAS INFORMAÇÕES COM DATA MINING E OLAP

 

 Monografia apresentada como exigência parcial para a obtenção do grau de Bacharel em Ciência da Computação pela Faculdade de Ciências Administrativas Valinhos, sob a

orientação do Professor Doutor Gilberto Shigueo Nakamiti.

 

FACULDADES DE VALINHOS

 FACULDADE DE CIÊNCIAS ADMINISTRATIVAS DE VALINHOS

 

VALINHOS 1.999

Resumo 

O ambiente de dados para suporte aos processos de gerência e tomada de decisão é fundamentalmente diferente do ambiente convencional de processamento de transações.

No coração deste ambiente está a idéia do data warehouse, integrando e consolidando dados disponíveis em diferentes acervos para fins de exploração e análise, ampliando o conteúdo informacional destes acervos para atender às expectativas e necessidades de nível estratégico 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 diferenças deste ambiente para os ambientes e ferramentas usuais de gerenciamento e tratamento de informações, alem de mostrar duas formas de extração de seus dados: a OLAP e o data mining, cada uma com suas características, podendo ser usadas separadamente ou em conjunto para um melhor resultado.

SumárioResumo

Sumário

Introdução

Cap. I - Evolução dos Sistemas de Apoio à Decisão

1.1 – Histórico

1.2 – A teia de aranha

1.3 – O Ambiente projetado

Cap. II – Características 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 - Não volátil

2.6 - Granularidade

2.6.1 – Níveis duais de granularidade

2.7 – Particionamento de dados

Cap. III – Arquitetura do Data Warehouse

3.1 – Arquitetura genérica do data warehouse

3.2 – Outras arquiteturas

3.2.1 – Arquitetura de duas camadas

3.2.2 – Arquitetura de três camadas

Cap. IV – Modelo de dados do Data Warehouse

4.1 - A Questão das Dimensões

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 – Conversão do modelo E-R para o modelo do data warehouse

4.3.1 - Remoção dos dados puramente operacionais

4.3.2 - Adição de um elemento de tempo na estrutura da chave

4.3.3 - Introdução de dados derivados

4.3.4 - Transformação de Relacionamentos entre dados em artefatos dos dados

4.3.5 - Acomodação dos diferentes níveis de granularidade

4.3.6 - União dos dados comuns de diferentes tabelas

4.3.7 - Criação de arrays de dados

4.3.8 - Separação dos atributos de dados de acordo com sua estabilidade

Cap. V – Desenvolvimento do Data Warehouse

5.1 - Estratégia Evolucionária

5.2 - Aspectos de Modelagem

5.3 – Técnicas de gerenciamento da quantidade de dados operacionais pesquisados

5.4 – Técnicas 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 – Extração

6.2 – Transformação e filtros

6.3 - Derivação e Sumarização

Cap. VII – Extraindo informações 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 – Retenção dos dados

7.2.4 – Destilação de padrões

7.2.4.1 – Semelhança lógica

7.2.4.1.1 – Regras

7.2.4.1.1.1 - Regra indutiva

7.2.4.1.1.2 – Algoritmos genéticos

7.2.4.1.2 – Árvores de decisão

7.2.4.2 – Tabulação cruzada

7.2.4.2.1 - Agentes

7.2.4.2.2 – Redes de confiança

7.2.4.3 – Aproximações equacionais

7.2.4.3.1 – Redes neurais

Conclusão

Bibliografia

IntroduçãoHoje em dia uma organização precisa utilizar toda informação disponível para criar e manter vantagem competitiva. Sai na frente a organização que consegue tomar decisões corretas e rápidas. Com esta importante tarefa nas mãos, profissionais tomadores de decisão tais como executivos, gerentes e analistas, exigem dos sistemas de suporte à decisão (Decision Support Systems - DSS) mais recursos para análise, front-ends que suportem consultas ad hoc, interfaces gráficas apropriadas, etc.

A idéia de data warehouse é integrar os dados internos e externos de uma organização em uma estrutura única permitindo uma melhor utilização dos dados pelos analistas, gerentes e executivos. Uma vez obtida a integração, sistemas como OLAP (On-Line Analytical Processing) e data mining fornecem mecanismos sofisticados para análise dos dados.

Estudar e conhecer a tecnologia de data warehouse pode ajudar os empresários a descobrir novas formas de competir em uma economia globalizada, trazendo melhores produtos ou serviços para o mercado, mais rápido do que os concorrentes, sem aumentar o custo do produto ou do serviço. Não existem ainda metodologias formais para implementação de um data warehouse, ela deve ser adaptada às características 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 mudanças internas que devem ocorrer para atender as novas realidades.

Este trabalho têm como objetivo fazer um estudo dos principais conceitos necessários para o desenvolvimento de um ambiente de data warehouse. No capítulo I é apresentada a evolução dos sistemas de apoio à decisão e o motivo do surgimento da necessidade do data warehouse. No capítulo II inicia-se os conceitos sobre o data warehouse, mostrando suas características básicas. O capítulo III mostra as arquiteturas disponíveis para construção de data warehouses, e no capítulo IV os modelos de dados. O capítulo V mostra alguns detalhes do desenvolvimento propriamente dito do data warehouse. O capítulo VI mostra as técnicas para extrair as informações dos sistemas existentes e transforma-las adequadamente para o data warehouse. E finalmente no capítulo VII são apresentadas as técnicas para extração e analise dos dados de um data warehouse que são: OLAP e data mining.

Cap. I - Evolução dos Sistemas de Apoio à Decisão1.1 – Histórico

A evolução dos sistemas de apoio a decisão pode ser dividida em cinco fases entre 1960 e 1980. No início da década de 1960 o mundo da computação consistia na criação de aplicações individuais que eram executadas sobre arquivos mestres, caracterizadas por programas e relatórios.

Aproximadamente em 1965 o crescimento dos arquivos mestres e das fitas magnéticas explodiu, surgindo problemas como: a complexidade de manutenção 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 magnéticas 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 fáceis para o programador. E com o SGBD surgiu a idéia 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 transações online. Com o processamento de transações online de alta performance, o computador pôde ser usado para tarefas que antes não eram viáveis como controlar sistemas de reservas, sistemas de caixas bancários, sistemas de controle de produção e outros.

Até o início da década de 1980, novas tecnologias, como os PCs e as L4Gs (linguagens de quarta geração), começaram a aparecer. O usuário final passou a controlar diretamente os sistemas e os dados, descobrindo que era possível utilizar os dados para outros objetivos além de atender ao processamento de transações online de alta performance. Foi nesse período também que se tornou viável a construção dos MIS (management information systems), hoje conhecidos como SAD eles consistiam em processamento utilizado para direcionar decisões gerenciais [INM97].

1.2 – A teia de aranha

Após o advento das transações online de alta performance, começaram a surgir os programas de “extração”. Esses programas varrem arquivos de banco de dados usando alguns critérios, e, ao encontrar esses dados, transporta-os para outro arquivo de banco de dados.

Com a difusão do programa de extração, começou a formar-se a chamada “arquitetura de desenvolvimento espontâneo” ou “teia de aranha”, conforme mostrado na Figura 1.1. Primeiro havia extrações. Depois, extrações das extrações, e, então, extrações das extrações das extrações, e assim por diante.

Figura 1.1 – A teia de aranha

Com a arquitetura de desenvolvimento espontâneo começaram a surgir alguns problemas conforme [INM97]:

     Credibilidade dos dados;

        Ausência de parâmetros de tempo dos dados

        O diferencial algorítmico dos dados

        Os níveis de extração

        O problema dos dados externos

        Nenhuma fonte de dados comum com a qual começar

     Produtividade;

        Localizar e analisar os dados para o relatório

        Compilar os dados para o relatório

        Obter recursos humanos de programação/análise para realizar os pontos citados acima

     Impossibilidade de transformar dados em informações.

1.3 – O Ambiente projetado

A arquitetura de desenvolvimento espontâneo não era suficiente para atender as necessidades do futuro das empresas, fazendo-se necessário uma mudança de arquitetura, surgindo o ambiente projetado de data warehouse.

Neste ambiente há duas espécies de dados – dados primitivos e dados derivados.

Dados primitivos Dados derivados

- baseados em aplicações - baseados em assuntos ou negócios

- detalhados - resumidos, ou refinados

- podem ser atualizados - não são atualizados

- exatos em relação ao momento do acesso - representam valores de momentos já decorridos ou instantâneos

- são processados repetitivamente - processados de forma heurística

Há quatro níveis no ambiente projetado – o operacional, a atômico ou data warehouse, o departamental e o individual. O nível operacional de dados contém apenas dados primitivos e atende à comunidade de processamento de transações de alta performance. O data warehouse contém dados primitivos que não são atualizados e dados derivados. O nível departamental de dados praticamente só contém dados derivados. E o nível individual de dados é onde o maior parte das análises heurísticas é feito [INM97]. A Figura 1.2 mostra os tipos de consulta para os quais os diferentes níveis de dados podem ser usados.

Figura 1.2 – Os tipos de consulta.

Cap. II – Características do Data WarehousePara entender melhor o que é um data warehouse vamos fazer uma comparação entre ele e os bancos de dados operacionais [DAL99].

CaracterísticasBancos de dados

OperacionaisData Warehouse

Objetivo Operações diárias do negócio Analisar o negócioUso Operacional InformativoTipo de processamento OLTP OLAPUnidade de trabalho Inclusão, alteração, exclusão. Carga e consultaNúmero de usuários Milhares CentenasTipo de usuário Operadores Comunidade gerencialInteração do usuário Somente pré-definida Pré-definida e ad-hoc     Condições dos dados Dados operacionais Dados AnalíticosVolume Megabytes – gigabytes Gigabytes – terabytesHistórico 60 a 90 dias 5 a 10 anos

Granularidade Detalhados Detalhados e resumidosRedundância Não ocorre Ocorre     Estrutura Estática VariávelManutenção desejada Mínima ConstanteAcesso a registros Dezenas MilharesAtualização Contínua (tempo real) Periódica (em batch)Integridade Transação A cada atualizaçãoNúmero de índices Poucos/simples Muitos/complexosIntenção dos índices Localizar um registro Aperfeiçoar consultas

Tabela 1.1 – Comparação entre Banco de Dados Operacionais e Data Warehouse.

O data warehouse é um banco de dados contendo dados extraídos do ambiente de produção da empresa, que foram selecionados e depurados, tendo sido otimizados para processamento de consulta e não para processamento de transações. Em geral, um data warehouse requer a consolidação de outros recursos de dados além dos armazenados em banco de dados relacionais, incluindo informações provenientes de planilhas eletrônicas, documentos textuais, etc.

É importante considerar, no entanto, que um data warehouse não contem apenas dados resumidos, podendo conter também dados primitivos. É desejável prover ao usuário a capacidade de aprofundar-se num determinado tópico, investigando níveis de agregação menores ou mesmo o data primitivo, permitindo também a geração de novas agregações ou correlações com outras variáveis. Além do mais, é extremamente difícil prever todos os possíveis dados resumidos que serão necessários: limitar o conteúdo de um data warehouse apenas a dados resumidos significa limitar os usuários apenas às consultas e análises que eles puderem antecipar frente a seus requisitos atuais, não deixando qualquer flexibilidade para novas necessidades [CAM99].

2.1 – O Ciclo de vida do desenvolvimento

Uma das grandes diferenças entre o nível operacional de dados e processamento e o nível 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 clássico é baseado em requisitos. Para desenvolver sistemas, primeiro é necessário entender as necessidades. Depois disso, vêm as fases de projeto e desenvolvimento. O CLDS é quase o inverso. O CLDS começa pelos dados. Uma vez que os dados estejam sob controle, eles são integrados e, em seguida, testados para que se verifiquem quais distorções há neles, se houver alguma. Então, é feita a codificação de programas para os dados. Os resultados dos programas são analisados e, finalmente, os requisitos do sistema são compreendidos [INM97].

Figura 2.1 – O ciclo de vida de desenvolvimento

2.2 - Orientado por temas

Refere-se ao fato do data warehouse armazenar informações sobre temas específicos importantes para o negócio da empresa. Exemplos típicos de temas são: produtos, atividades, contas, clientes, etc. Em contrapartida, o ambiente operacional é organizado por aplicações funcionais. Por exemplo, em uma organização bancária, estas aplicações incluem empréstimos, investimentos e seguros [CAM99].

A principal área de interesse termina sendo fisicamente implementada como uma série de tabelas relacionadas inseridas no data warehouse. Por exemplo, uma implementação 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 básica referente a cliente conforme definido de 1985 até 1987. Há uma outra referente à definição 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 mês um registro de resumo é gravado para cada registro de cliente baseado na atividade de cliente do mês. Existem arquivos de atividades detalhados por cliente de 1987 a 1989 e de 1990 a 1991. A definição dos dados contidos nos arquivos difere segundo o respectivo ano [INM97].

Todas as tabelas referentes a um determinado cliente são relacionadas por meio de uma chave comum. No nosso exemplo, a chave cód 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 magnética.

2.3 - Integrado

Refere-se à consistência de nomes, das unidades das variáveis, etc., no sentido de que os dados foram transformados até um estado uniforme. Por exemplo, considere-se sexo como um elemento de dado. Uma aplicação pode codificar sexo como M/F, outra como 1/0 e uma terceira como H/M. Conforme os dados são trazidos para o data warehouse, eles são convertidos para um estado uniforme, ou seja, sexo é codificado apenas de uma forma. Da mesma maneira, se um elemento de dado é medido em centímetros em uma aplicação, em polegadas em outra, ele será convertido para uma representação única ao ser colocado no data warehouse [CAM99].

Figura 2.3 – A questão da integração.

2.4 - Variante no tempo

Refere-se ao fato do dado em um data warehouse referir-se a algum momento específico, significando que ele não é atualizável, enquanto que o dado de produção é atualizado de acordo com mudanças de estado do objeto em questão, refletindo, em geral, o estado do objeto no momento do acesso. Em um data warehouse, a cada ocorrência de uma mudança, uma nova entrada é criada, para marcar esta mudança.

O tratamento de séries temporais apresenta características específicas, que adicionam complexidade ao ambiente do data warehouse. Processamentos mensais ou anuais são

simples, mas dias e meses oferecem dificuldades pelas variações encontradas no número de dias em um mês ou em um ano, ou ainda no início das semanas dentro de um mês. Além disso, deve-se considerar que não apenas os dados têm uma característica temporal, mas também os metadados, que incluem definições dos itens de dados, rotinas de validação, algoritmos de derivação, etc. Sem a manutenção do histórico dos metadados, as mudanças das regras de negócio que afetam os dados no data warehouse são perdidas, invalidando dados históricos [CAM99].

Figura 2.4 – A questão da variação em relação ao tempo.

2.5 - Não volátil

Significa que o data warehouse permite apenas a carga inicial dos dados e consultas a estes dados. Após serem integrados e transformados, os dados são carregados em bloco para o data warehouse, para que estejam disponíveis aos usuários para acesso. No ambiente operacional, ao contrário, os dados são, em geral, atualizados registro a registro, em múltiplas transações. Esta volatilidade requer um trabalho considerável para assegurar integridade e consistência através de atividades de rollback, recuperação de falhas, commits e bloqueios. Um data warehouse não requer este grau de controle típico dos sistemas orientados a transações [CAM99].

Figura 2.5 – A questão da não-volatilidade.

2.6 - Granularidade

Granularidade diz respeito ao nível de detalhe ou de resumo contido nas unidades de dados existentes no data warehouse. Quanto maior o nível de detalhes, menor o nível de granularidade. O nível 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 nível de granularidade muito alto o espaço em disco e o número de índices necessários se tornam bem menores, porém há uma correspondente diminuição da possibilidade de utilização dos dados para atender a consultas detalhadas [DAL99].

A Figura 2.6 apresenta um exemplo das questões referentes à granularidade. No lado esquerdo há um baixo nível de granularidade. Cada chamada telefônica é registrada em detalhe. No lado direito um nível mais alto de granularidade pode ser visto. Os dados representam as informações resumidas referentes a um cliente em um mês.

Há, portanto, um bom motivo para a compactação de dados em um data warehouse. Quando os dados são compactados ocorre uma economia incomum sobre o total de DASD utilizado, o número de índices necessários e os recursos de processador necessários para o tratamento dos dados.

No entanto, há um outro aspecto da compactação de dados que ocorre à medida que o nível de granularidade é elevado. À medida que o nível de granularidade se eleva, há uma correspondente diminuição da possibilidade de utilização dos dados para atender a consultas. Já com um nível mais baixo de granularidade é possível responder a qualquer consulta [INM97].

Figura 2.6 – Definindo o nível de granularidade.

 Devemos lembrar, porem que em um ambiente de data warehouse, dificilmente um evento isolado é examinado. É mais comum ocorrer a utilização de uma visão de conjunto dos dados.

2.6.1 – Níveis duais de granularidade

O chamado nível 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 são resumidos na forma de campos apropriados para a utilização de analistas e gerentes. Na segunda camada, ou nível de dados históricos, ficam todos os detalhes vindos do ambiente operacional, como há uma verdadeira montanha de dados neste nível, faz sentido armazenar os dados em um meio alternativo como fitas magnéticas.

Com a criação de dois níveis de granularidade no nível detalhado do data warehouse, é possível atender a todos os tipos de consultas, pois a maior parte do processamento analítico dirige-se aos dados levemente resumidos que são compactos e de fácil acesso e para ocasiões em que um maior nível de detalhe deve ser investigado existe o nível de dados históricos. O acesso aos dados do nível histórico de granularidade é caro, incômodo e complexo, mas caso haja necessidade de alcançar esse nível de detalhe, lá estará ele.

Figura 2.7 – Níveis de granularidade.

2.7 – Particionamento de dados

O objetivo do particionamento dos dados de detalhe corrente consiste em repartir os dados em unidades físicas menores. Unidades físicas menores proporcionam ao pessoal de operação a ao projetista muito mais flexibilidade no gerenciamento dos dados do que é proporcionado pelas unidades físicas maiores.

O particionamento de dados ocorre quando dados de uma mesma estrutura são divididos em mais de uma unidade física de dados. Além disso, toda unidade de dados pertence a uma e somente uma partição. Há vários critérios por meio dos quais é possível dividir dados, como por exemplo: [INM97].

        Por data

        Por área de negócio

        Por área geográfica

        Por unidade organizacional

        Por todos os critérios acima

Cap. III – Arquitetura do Data WarehousePara ser útil o data warehouse deve ser capaz de responder a consultas avançadas de maneira rápida, 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 rápida. Mas construir um data warehouse eficiente, que servirá de suporte a decisões 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 vários

sistemas podem conter redundâncias e diferenças, então antes de passá-los para o data warehouse é necessário 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 usuários utilizarão em suas decisões. Um data warehouse pode variar sua arquitetura conforme o tipo de assunto abordado, pois as necessidades também variam de empresa para empresa. É possível definir uma arquitetura genérica onde praticamente todas as camadas necessárias são apresentadas, conforme a arquitetura genérica vista a seguir, ou arquiteturas que utilizam somente algumas das camadas definidas, como as arquiteturas em duas e três camadas.

3.1 – Arquitetura genérica do data warehouse

A seguir é descrita uma arquitetura genérica proposta por [DAL99] e ilustrada na Figura 3.1. Esta descrição genérica procura apenas sistematizar papéis 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 várias 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 são acessados pela camada de acesso aos dados. As camadas de gerenciamento de processos, transporte e data warehouse formam o centro da arquitetura e são elas as responsáveis por manter e distribuir os dados. A camada de acesso à informação é formada por ferramentas que possibilitam os usuários extrair informações do data warehouse. Todas as camadas desta arquitetura interagem com o dicionário 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 informações provenientes de fontes externas que serão integradas para compor o data warehouse;

        Camada de acesso à informação: Envolve o hardware e o software utilizado para obtenção de relatórios, planilhas, gráficos e consultas. É nesta camada que os usuários finais interagem com o data warehouse, utilizando ferramentas de manipulação, análise e apresentação dos dados, incluindo-se as ferramentas de data-mining e visualização;

        Camada de acesso aos dados: Esta camada faz a ligação entre as ferramentas de acesso à informação 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 comunicação, o que se chama acesso universal de dados;

        Camada de metadados (Dicionário de dados): Metadados são as informações que descrevem os dados utilizados pela empresa, isto envolve informações como descrições de registros, comandos de criação de tabelas, diagramas Entidade/Relacionamentos (E-R), dados de um dicionário de dados, etc. É necessário que exista uma grande variedade de metadados no ambiente de data

warehouse para que ele mantenha sua funcionalidade e os usuários não precisem se preocupar onde residem os dados ou a forma com que estão armazenados;

        Camada de gerenciamento de processos: É a camada responsável pelo gerenciamento dos processos que contribuem para manter o data warehouse atualizado e consistente. Está envolvida com o controle das várias tarefas que devem ser realizadas para construir e manter as informações do dicionário de dados e do data warehouse;

        Camada de transporte: Esta camada gerencia o transporte de informações pelo ambiente de rede. Inclui a coleta de mensagens e transações e se encarrega de entregá-las em locais e tempos determinados. Também é usada para isolar aplicações 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 informações. Às vezes o data warehouse pode ser simplesmente uma visão lógica ou virtual dos dados, podendo não envolver o armazenamento dos mesmos ou armazenar dados operacionais e externos para facilitar seu acesso e manuseio.

Figura 3.1 – Arquitetura genérica do data warehouse.

3.2 – Outras arquiteturas

3.2.1 – Arquitetura de duas camadas

Uma opção de arquitetura para o data warehouse é utilizar um computador de alta capacidade como servidor, como mostrado na Figura 3.2. Isto é uma incorporação das aplicações utilizadas pelos usuários (front end) com os componentes do servidor (back end). Aplicações front end construídas com ferramentas cliente/servidor fornecem uma interface gráfica amigável, suportam funções específicas da empresa, possibilitam o acesso transparente aos dados dos sistemas já existentes e escondem a complexidade e a falta de consistência dos bancos de dados atuais além de facilitar a utilização e a visualização dos resultados. Os

sistemas operacionais de uma empresa podem estar em uso por 15 ou 20 anos e podem ter altas taxas de redundância. A redundância e a falta de consistência dos dados pode dificultar a administração da empresa e o acesso aos dados e impede o desenvolvimento de novas aplicações front end. Uma das maneiras de tratar com esta situação é partir de um só sistema e construir uma espécie 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 mínimo em hardware e software. Entretanto, a arquitetura em duas camadas não é escalonável e não suporta um grande número de usuários simultaneamente. Isto estimula o desenvolvimento de estações clientes muito pesadas, pois muito processamento é alocado para processar nestas estações [DAL99].

3.2.2 – Arquitetura de três camadas

Uma alternativa é utilizar a arquitetura de informação em múltiplas camadas, como mostrado na Figura 3.3. Esta arquitetura flexível suporta um grande número de serviços integrados, na qual a interface do usuário, as funções de processamento do negócio e as funções de gerenciamento do banco de dados são separadas em processos que podem ser distribuídos através da arquitetura de informação.

A arquitetura em três camadas é amplamente utilizada para data warehouse. Na terceira camada ficam as fontes de dados. Dados e regras de negócio podem ser compartilhados pela organização, 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 aplicações de interface com os usuários que devem ser gráficas e baseadas em rede.

No ambiente do data warehouse, os servidores de banco de dados e os servidores de aplicações da segunda camada fornecem um acesso eficiente e veloz aos dados compartilhados. Os dados de um data warehouse são tipicamente estáticos, por exemplo, não variam com o tempo e devem ser integrados, de natureza histórica e sumarizados ou agregados para que sejam significantes para os analistas de negócios. Como mostrado na Figura 3.3, dados operacionais e bancos de dados para o data warehouse são freqüentemente armazenados em servidores fisicamente separados. Bancos de dados operacionais são otimizados para ter alto desempenho no processamento de transações on-line, em inglês conhecido como On-line Transaction Processing (OLTP). Bancos de dados para data warehouse são otimizados para ter alto desempenho em consultas e análises, em inglês conhecido como On-line Analytical Processing (OLAP).

Figura 3.3 – Arquitetura de três camadas.

É importante reconhecer que não existe uma arquitetura "correta" para data warehouse. Para algumas organizações pode ser atrativo utilizar a arquitetura em duas camadas, por que ela minimiza o custo e a complexidade de construção do data warehouse. Para outras que requerem grande performance e escalabilidade, a arquitetura em três camadas pode ser mais apropriada. No planejamento do data warehouse, as organizações devem examinar as alternativas disponíveis de arquiteturas e selecionar aquela que satisfaça os seu requisitos estratégicos 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 esforços de desenvolvimentos são baseados em um único modelo de dados sempre que for necessário unir estes esforços os níveis de sobreposição de trabalho e desenvolvimento desconexo serão muito baixos, pois todos os componentes do sistema estarão utilizando a mesma estrutura de dados.

Existe um grande número de enfoques sobre modelagem de dados já desenvolvidos por vários 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 Questão das Dimensões

Obter respostas a questões típicas de análise dos negócios de uma empresa geralmente requer a visualização dos dados segundo diferentes perspectivas. Como exemplo, imagine-se uma agência de automóveis que esteja querendo melhorar o desempenho de seu negócio, Para isso, necessita examinar os dados sobre as vendas disponíveis na empresa. Uma avaliação deste tipo requer uma visão histórica do volume de vendas sob múltiplas perspectivas, como por exemplo: volume de vendas por modelo, volume de vendas por cor, volume de vendas por fabricante, volume de vendas por período de tempo. Uma análise do volume de vendas utilizando uma ou mais destas perspectivas, permitiria responder questões do tipo:

Qual a tendência em termos de volume de vendas para o mês de dezembro para modelos Volvo Sedan preto?

A capacidade de responder a este tipo de questão em tempo hábil é o que permite aos gerentes e altos executivos das empresas formular estratégias efetivas, identificar tendências e melhorar sua habilidade de tomar decisões de negócio. O ambiente tradicional de bancos de dados relacional certamente pode atender a este tipo de consulta. No entanto, usuários 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 específicas para atender a estas consultas.

Para compreender melhor os conceitos envolvidos, examinemos em maior detalhe o exemplo acima. Chamaremos de dimensões as diferentes perspectivas envolvidas, no caso, modelo, loja, fabricante, mês. Estas “dimensões” usualmente correspondem a campos não numéricos em um banco de dados. Consideremos também um conjunto de “medidas”, tal como vendas ou despesas com promoção. Estas medidas correspondem geralmente a campos numéricos em um banco de dados. A seguir, avaliam-se agregações destas medidas segundo às diversas dimensões e as armazenamos para acesso futuro. Por exemplo, calcula-se a média de todas as vendas por todos os meses por loja. A forma como estas agregações são armazenadas pode ser vista em termos de dimensões e coordenadas, dando origem ao termo multidimensional.

Intuitivamente, cada eixo no espaço multidimensional é um campo/coluna de uma tabela relacional e cada ponto um valor correspondente à interseção das colunas. Assim, o valor para o campo vendas, correspondente a mês igual a maio e loja igual a Iguatemi é um ponto com coordenada [maio, Iguatemi]. Neste caso, mês e loja são duas dimensões 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 representação e o armazenamento de dados multidimensionais. Neste caso, as abordagens encontradas incluem desde a adoção de formas específicas de modelagem (os chamados esquemas estrela e floco de neve) até mecanismos sofisticados de indexação.

4.2 - Esquemas do tipo Estrela e Floco de Neve

Em um esquema do tipo estrela ou "star" as instâncias são armazenadas em uma tabela contendo o identificador de instância, valores das dimensões descritivas para cada instância, e valores dos fatos, ou medidas, para aquela instância (tabela de fatos). Além disso, pelo menos uma tabela é usada, para cada dimensão, para armazenar dados sobre a dimensão (tabela de dimensão). No caso mais simples, a tabela de dimensão tem uma linha para cada valor válido da dimensão. Esses valores correspondem a valores encontrados na coluna referente àquela dimensão na tabela de fatos.

Este esquema é chamado de estrela, por apresentar a tabela de fatos "dominante" no centro do esquema e as tabelas de dimensões nas extremidades. A tabela de fatos é ligada às demais tabelas por múltiplas junções, enquanto as tabelas de dimensões se ligam apenas à tabela central por uma única junção. A Figura 4.1 mostra um exemplo de um modelo tipo estrela.

Figura 4.1 – Modelo Estrela.

A tabela de fatos é onde as medidas numéricas do fato representado estão armazenadas. Cada uma destas medidas é tomada segundo a interseção de todas as dimensões. No caso do exemplo, uma consulta típica selecionaria fatos da tabela FATOSVENDAS a partir de valores fornecidos relativos a cada dimensão.

Outro tipo de estrutura bastante comum é o esquema do tipo floco de neve ou "snowflake", que consiste em uma extensão do esquema estrela onde cada uma das "pontas" da estrela passa a ser o centro de outras estrelas. Isto porque cada tabela de dimensão seria normalizada,

"quebrando-se" a tabela original ao longo de hierarquias existentes em seus atributos. No caso do exemplo, a dimensão produto possui uma hierarquia definida onde categoria se divide em marca e marca se divide em produtos (Figura 4.2). Da mesma forma, a dimensão tempo inclui ano que contem mês e mês que contem dia-do-mes. Cada um destes relacionamentos muitos-para-1 geraria uma nova tabela em um esquema floco de neve.

Figura 4.2 – A dimensão do produto normalizada.

4.2.1 – Vantagens do modelo estrela

        O modelo Estrela tem uma arquitetura padrão e previsível. As ferramentas de consulta e interfaces do usuário podem se valer disso para fazer suas interfaces mais amigáveis e fazer um processamento mais eficiente;

        Todas as dimensões do modelo são equivalentes, ou seja, podem ser vistas como pontos de entrada simétricos para a tabela de fatos. As interfaces do usuário são simétricas, as estratégias de consulta são simétricas, e o SQL gerado, baseado no modelo, é simétrico;

        O modelo dimensional é totalmente flexível para suportar a inclusão de novos elementos de dados, bem como mudanças que ocorram no projeto. Essa flexibilidade se expressa de várias formas, dentre as quais temos:

o       Todas as tabelas de fato e dimensões podem ser alteradas simplesmente acrescentando novas colunas a tabelas;

o       Nenhuma ferramenta de consulta ou relatório precisa ser alterada de forma a acomodar as mudanças;

o       Todas as aplicações que existiam antes das mudanças continuam rodando sem problemas;

        Existe um conjunto de abordagens padrões para tratamento de situações comuns no mundo dos negócios. Cada uma destas tem um conjunto bem definido de alternativas que podem então ser especificamente programadas em geradores de relatórios, ferramentas de consulta e outras interfaces do usuário. Dentre estas situações temos:

o       Mudanças lentas das dimensões: ocorre quando uma determinada dimensão evolui de forma lenta e assíncrona;

o       Produtos heterogêneos: quando um negócio, tal como um banco, precisa controlar diferentes linhas de negócio juntas, dentro de um conjunto comum de atributos e fatos, mas ao mesmo tempo esta precisa descrever e medir as linhas individuais de negócio usando medidas incompatíveis;

        Outra vantagem é o fato de um número cada vez maior de utilitários administrativos e processo de software serem capazes de gerenciar e usar agregados, que são de suma importância para a boa performance de respostas em um data warehouse [DAL99].

4.2.2 - Bancos de Dados Multidimensionais

Embora seja viável utilizar estruturas relacionais na representação de dados multidimensionais, a solução não é ideal. Na Figura 4.3, é fácil verificar como uma matriz bidimensional representa mais claramente os dados armazenados na forma relacional tradicional. Na matriz, os valores de vendas estão localizados nas interseções dos eixos X e Y da matriz 3x3. Cada eixo corresponde a uma dimensão, e cada elemento dentro de uma dimensão corresponde a uma posição. Um array agrupa informações semelhantes em colunas e linhas.

BD Relacional   Matriz BidimensionalModelo Cor Vendas  

ModeloAzul Vermelha Branca

Van Azul 6   Van 6 5 4Van Vermelha 5   Coupe 3 5 5Van Branca 4   Sedan 4 3 2

Coupe Azul 3          Coupe Vermelha 5          Coupe Branca 5          Sedan Azul 4          Sedan Vermelha 3          Sedan Branca 2          

Figura 4.3 – Relacional versus Bidimensional.

Além disso, na representação multidimensional, totais consolidados são facilmente obtidos e armazenados, bastando simplesmente adicionar totais de colunas e fileiras [CAM99].

4.3 – Conversão do modelo E-R para o modelo do data warehouse

Para tal, W. H. Inmon fornece então alguns passos que podem ser seguidos, não se esquecendo de que o fundamental é que as decisões de transformação devem ser tomadas levando-se em consideração os requisitos específicos da empresa. Os passos básicos são:

4.3.1 - Remoção dos dados puramente operacionais

A primeira ação consiste em remover os dados que são usados apenas no ambiente operacional, como vemos no exemplo da Figura 4.4. Neste, atributos tais como mensagem,

descrição e status são retirados, pois é muito pouco provável que estes sejam utilizados no processo de tomada de decisão.

Neste momento, pode ser que se pense em manter todos os atributos, pois talvez algum destes seja necessário para alguma decisão específica. Entretanto, deve-se levar em conta o custo para gerenciar grandes volumes de dados [DAL99].

Figura 4.4 – Remoção dos dados puramente operacionais.

4.3.2 - Adição de um elemento de tempo na estrutura da chave

A segunda modificação a ser feita no modelo corporativo é adicionar um elemento de tempo a chave das tabelas, se estas já não 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 identificação do consumidor, no modelo do data warehouse a data do instantâneo deve fazer parte da chave, já que com o passar do tempo os dados do consumidor podem se alterar. Esta técnica é apenas uma forma de tirar instantâneos dos dados.

Outra forma de fazê-lo é adicionar dois campos do tipo data, um marcando o início e outro o fim de um determinado intervalo de tempo. Esta técnica é melhor por representar faixas contínuas de tempo ao invés de pontos ou datas específicas [DAL99].

Figura 4.5 – Adição de um elemento de tempo.

4.3.3 - Introdução de dados derivados

O próximo passo é adicionar dados derivados ao modelo, como mostrado na Figura 4.6, já que por regra geral estes não existem no modelo corporativo. Devem ser adicionados os dados derivados que serão usados habitualmente de forma que estes sejam calculados apenas uma vez. Dessa forma, haverá uma redução no processamento que deve ser feito para acessar os dados derivados ou sumarizados.

Outra razão para o armazenamento de dados derivados é que uma vez calculados e armazenados, a integridade destes aumenta, uma vez que se torna impossível a utilização de diferentes algoritmos para o cálculo destes derivados [DAL99].

Figura 4.6 – Introdução de dados derivados.

4.3.4 - Transformação de Relacionamentos entre dados em artefatos dos dados

Os relacionamentos encontrados nas modelagens de dados clássicas assumem que há um e somente um valor de negócio no relacionamento. Levando-se em consideração que nos sistemas operacionais o dado estar integro no momento da transação, esta abordagem é correta. Entretanto, o data warehouse por sua característica de armazenar dados históricos, 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 é através da criação de artefatos.

Um artefato de um relacionamento é somente a parte do relacionamento que é óbvia e tangível no momento do instantâneo. Em outras palavras, quando o instantâneo é feito os dados associados com o relacionamento que são úteis e óbvios serão 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 então um instantâneo deste relacionamento, teríamos que considerar a informação do fornecedor principal que está relacionado ao produto. Além disso, outras informações de artefato relacionadas com o fornecedor deveriam

então ser capturadas. A tabela de produtos no modelo do data warehouse ficaria então como a mostrada na Figura 4.8 [DAL99].

Figura 4.7 – Relacionamento entre tabelas no modelo E-R.

Figura 4.8 – Inclusão de artefatos no data warehouse.

4.3.5 - Acomodação dos diferentes níveis de granularidade

Dependendo do caso, o nível de granularidade do sistema transacional pode ser o mesmo do data warehouse ou não. Quando o nível de granularidade se altera, o modelo do data warehouse deve representar esta mudança, 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 são armazenadas toda vez que uma entrega é feita. Quando este é passado para o data warehouse, duas agregações são feitas, alterando então a granularidade. Na primeira, o total de entregas é agregado mensalmente, fazendo com que a granularidade seja o mês, já na segunda, existe uma agregação das entregas feitas por mês e local de origem, fazendo então com que a granularidade seja o mês associado ao fornecedor [DAL99].

Figura 4.9 – Alteração do nível de granularidade.

4.3.6 - União 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 junção possa ser feita, as seguintes condições devem ser verdadeiras:

        As tabelas compartilham uma chave comum (ou chave parcial);

        Os dados das diferentes tabelas geralmente são usados juntos;

        Padrão de inserção nas tabelas é o mesmo.

Como exemplo, consideremos a Figura 4.10, onde temos as tabelas NOTAS e ITENS DAS NOTAS. Quando estas são colocadas no modelo do data warehouse, estas vão para uma mesma tabela. Dessa forma, a junção entre estas tabelas passa a não ser mais necessária quando uma consulta for feita. Neste caso, podemos ver que as três condições são atendidas: as tabelas compartilham parte da chave, ID da Nota; estas duas tabelas geralmente são usadas juntas; e o padrão de inserção é o mesmo, ou seja, sempre que uma nota é inserida seus itens também o são [DAL99].

Figura 4.10 – União dos dados de diferentes tabelas.

4.3.7 - Criação de arrays de dados

Os dados no modelo corporativo geralmente estão normalizados, onde a existência de grupos repetitivos não é permitida. Entretanto, em algumas situações no ambiente de data warehouse pode haver grupos repetitivos de dados. As condições para existência destes são:

        Quando o número de ocorrências do dado é previsível;

        Quando a ocorrência do dado é relativamente pequena (em termos de tamanho físico);

        Quando as ocorrências do dado geralmente são usadas juntas;

        Quando o padrão de inserção e remoção dos dados é estável;

 A Figura 4.11 mostra uma tabela no modelo corporativo com as previsões de gasto mensais. Quando esta é colocada no modelo do data warehouse, os dados são armazenados de forma que cada mês do ano é uma ocorrência no array [DAL99].

 

Figura 4.11 – Criação de array de dados.

 4.3.8 - Separação dos atributos de dados de acordo com sua estabilidade

A próxima atividade de projeto, referente à passagem do modelo de dados da empresa para o modelo de dados do data warehouse, consiste em realizar a análise de "estabilidade". A análise de estabilidade é uma tarefa que consiste em agrupar atributos de dados segundo sua propensão a alterações. A Figura 4.12 ilustra a análise de estabilidade de uma tabela de produtos. Neste exemplo é possível perceber que os dados que raramente sofrem alterações são agrupados com outros dados que apresentam essa mesma característica, dados que às vezes são alterados são agrupados com outros dados que às vezes são alterados e dados que freqüentemente são alterados são agrupados com outros dados freqüentemente alterados. O resultado final da análise de estabilidade é a criação de grupos de dados que apresentem características semelhantes [DAL99].

Figura 4.12 – Análise de estabilidade dos dados

Cap. V – Desenvolvimento do Data WarehouseO sucesso do desenvolvimento de um data warehouse depende fundamentalmente de uma escolha correta da estratégia a ser adotada, de forma que seja adequada às características e necessidades específicas 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 três dimensões: escopo do data warehouse (departamental, empresarial, etc), grau de redundância de dados, tipo de usuário alvo.

O escopo de um data warehouse pode ser tão amplo quanto aquele que inclui todo o conjunto de informações de uma empresa ou tão 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 criação e manutenção. Por isso, muitas empresas tendem a começar com um ambiente departamental e só após obter um retorno de seus usuários expandir seu escopo.

Quanto à redundância de dados, há essencialmente três níveis de redundância: o data warehouse virtual, o data warehouse centralizado e o data warehouse distribuído.

        O data warehouse virtual consiste em simplesmente prover os usuários finais com facilidades adequadas para extração das informações diretamente dos bancos de produção, não havendo assim redundância, mas podendo sobrecarregar o ambiente operacional.

        O data warehouse central constitui-se em um único banco de dados físico contendo todos os dados para uma área funcional específica, um departamento ou uma empresa, sendo usados onde existe uma necessidade comum de informações. Um data warehouse central normalmente contém dados oriundos de diversos bancos operacionais, devendo ser carregado e mantido em intervalos regulares.

        O data warehouse distribuído, como o nome indica, possui seus componentes distribuídos por diferentes bancos de dados físicos, normalmente possuindo uma grau de redundância alto e por conseqüência, procedimentos mais complexos de carga e manutenção.

Os padrões de uso de um data warehouse também constituem um fator importante na escolha de alternativas para o ambiente. Relatórios e consultas pré-estruturadas podem satisfazer o usuário final, e geram pouca demanda sobre o SGBD e sobre o ambiente servidor. Análises complexas, por sua vez, típicas de ambientes de suporte à decisão, exigem mais de todo o ambiente. Ambientes dinâmicos, com necessidades em constante mudança, são mais bem atendidos por uma arquitetura simples e de fácil alteração, ao invés de uma estrutura mais complexa que necessite de reconstrução a cada mudança. A freqüência da necessidade de atualização também é determinante: grandes volumes de dados que são atualizados em intervalos regulares favorecem uma arquitetura centralizada.

5.1 - Estratégia Evolucionária

Data warehouses, em geral, são projetados e carregados passo a passo, seguindo, portanto uma abordagem evolucionária. Os custos de uma implementação "por inteiro", em termos de recursos consumidos e impactos no ambiente operacional da empresa justificam esta estratégia.

Muitas empresas iniciam o processo a partir de uma área específica da empresa, que normalmente é uma área carente de informação e cujo trabalho seja relevante para os negócios da empresa, criando os chamados data marts (um data warehouse departamental), para depois ir crescendo aos poucos, seguindo uma estratégia "botton-up" ou assunto-por-assunto.

Outra alternativa é selecionar um grupo de usuários, prover ferramentas adequadas, construir um protótipo do data warehouse, deixando que os usuários experimentem com pequenas amostras de dados. Somente após a concordância 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 também pode ser criados como subconjunto de um data warehouse maior, em busca de autonomia, melhor desempenho e simplicidade de compreensão.

5.2 - Aspectos de Modelagem

A especificação de requisitos do ambiente de suporte à decisão associado a um data warehouse é fundamentalmente diferente da especificação de requisitos dos sistemas que sustentam os processos usuais do ambiente operacional de uma empresa.

Os requisitos dos sistemas do ambiente operacional são claramente identificáveis a partir das funções a serem executadas pelo sistema. Requisitos de sistemas de suporte à decisão são, por sua vez, indeterminados. O objetivo por trás de um data warehouse é prover dados com qualidade; os requisitos dependem das necessidades de informação individuais de seus usuários. Ao mesmo tempo, os requisitos dos sistemas do ambiente operacional são relativamente estáveis ao longo do tempo, enquanto que os dos sistemas de suporte à decisão são instáveis: dependem das variações das necessidades de informações daqueles responsáveis pelas tomadas de decisões dentro da empresa. No entanto, embora as necessidades por informações específicas mudem com freqüência, os dados associados não mudam. Imaginando-se que os processos de negócio de uma empresa permaneçam relativamente constantes, existe apenas um número finito de objetos e eventos com as quais uma organização está envolvida. Por esta razão, um modelo de dados é uma base sólida para identificar requisitos para um data warehouse.

De qualquer forma, é um erro pensar que técnicas de projeto que servem para sistemas convencionais serão adequadas para a construção de um data warehouse. Os requisitos para um data warehouse não podem ser conhecidos até que ele esteja parcialmente carregado e já em uso.

Outra questão interessante é a adequação do modelo Entidade-Relacionamento ao tipo de transação de sistemas OLTP. O principal objetivo da modelagem, neste caso, é eliminar ao máximo, a redundância, de tal forma que uma transação que promova mudanças no estado do banco de dados, atue o mais pontualmente possível. Com isso, nas metodologias de projeto usuais, os dados são "fragmentados" por diversas tabelas, o que traz uma considerável complexidade à formulação de uma consulta por um usuário final. Por isso, esta abordagem não parece ser a mais adequada para o projeto de um data warehouse, onde estruturas mais simples, com menor grau de normalização devem ser buscadas.

5.3 – Técnicas de gerenciamento da quantidade de dados operacionais pesquisados

Existem algumas técnicas que podem ser usadas para limitar a quantidade de dados pesquisados, conforme demonstrado na Figura 5.1, as técnicas 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 técnica consiste em pesquisar dados que apresentem marcas de tempo. Para isso é necessário que as aplicações registrem o momento da última alteração ou atualização em um registro para que ao ser executada a varredura para o data warehouse só sejam examinados os registros que tenham a data de atualização igual ou maior do que a data da última pesquisa.

A segunda técnica utiliza um arquivo de registros de alterações efetuadas. Este arquivo, também chamado arquivo “delta”. É criado por uma aplicação e contém apenas as alterações efetuadas por esta nos dados operacionais. Quando é possível contar com um arquivo delta o processo de varredura se torna muito eficiente uma vez que os dados que não sofreram alterações não serão acessados. O problema é que poucas aplicações geram arquivos delta.

A terceira técnica 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 diferenças significativas. Uma delas é que por ser o arquivo utilizado para a recuperação dos dados do banco de dados operacional em uma eventual falha não é interessante que se utilize este arquivo com outros propósitos. Outra diferença é que os arquivos de log normalmente possuem uma estrutura interna voltada aos objetivos de um sistema e não estão completamente preparados para a recuperação de dados por um data warehouse.

A quarta técnica empregada no gerenciamento da quantidade de dados pesquisados durante a extração para o data warehouse consiste em modificar o código da aplicação operacional. Essa pode ser a pior escolha, sobretudo quando o código da aplicação é antigo ou complexo.

A última opção consiste em moldar um arquivo de imagem "anterior" e "posterior". Segundo esta opção, uma cópia do banco de dados é tirada no momento da extração e quando for realizada outra extração, outra cópia será tirada. As duas cópias serão comparadas serialmente entre si para que seja detectada a atividade transcorrida neste período e então resgatadas às diferenças entre as duas copias. Esse método é pesado, complexo e demanda uma quantidade excessiva de recursos.

5.4 – Técnicas para incrementar a performance

O grande desafio de um sistema de apoio a decisão é que ele possua uma interface amigável e tempo de resposta satisfatório. Existem algumas técnicas que podem ser aplicadas no desenvolvimento de um data warehouse para incrementar sua performance. Essas tecnologias podem ser divididas em duas áreas: aquelas que propõem soluções baseadas em hardware e outras baseadas em software. Algumas destas técnicas baseadas em software são amplamente utilizadas no ambiente operacional e outras são específicas do ambiente de data warehouse, algumas técnicas são citadas a seguir, conforme [DAL99] e [PER99].

Uma proposta ao nível de hardware seria dividir o trabalho entre vários processadores. Porém, o sistema gerenciador de banco de dados deve ser capaz de dividir seu processamento entre esses processadores. Com o processamento paralelo, a percepção de melhora no desempenho é imediata, mas a tendência, ao longo do tempo, é voltarmos ao mesmo ponto, devido ao crescimento constante do data warehouse, atrelado às grandes mudanças que ocorrem freqüentemente no mundo dos negócios.

A distribuição 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 análise a respeito desse conceito vem novamente ao encontro de mesma atribuída ao processamento paralelo: dividir o trabalho. Portanto, podemos chegar à mesma conclusão, em termos de desvantagem, apresentada no processamento paralelo, ou seja, à medida que o número de dados aumentar, teremos sempre de buscar maneiras de subdividir o conjunto de dados.

Data marts são outra forma de distribuir os dados contidos no data warehouse. Os data marts, geralmente, contêm dados específicos de uma determinada área ou departamento. Dessa forma, podemos dizer que os data marts são “mini” data warehouses, armazenados provavelmente em plataformas diferentes. O processo de particionamento melhora o desempenho no resgate de informações, fazendo uso da segmentação dos dados em áreas lógicas diferentes.

Recursos sofisticados de indexação são a maneira mais eficiente de redução de I/O de disco, necessária para resgatar um subconjunto de dados. Com técnicas avançadas de indexação, a seleção de registros por qualquer critério é executada usando-se poucas leituras do disco. Dessa forma, obtemos, em segundos, seleções complexas em enormes bases de dados. Existem várias formas de indexação. Há índices nativos da estrutura de banco de dados relacionais: primários, B-tree (árvore B) e hash/hashing. Há também índices especializados, independentes da estrutura dos bancos de dados relacionais: invertidos, bitmap, combinados, R-tree (árvores R) e alguns outros específicos para determinadas aplicações.

Uma técnica relativa a estrutura do data warehouse que pode ser utilizada é a intercalação de tabelas onde o projetista deve procurar intercalar as tabelas afins em um mesmo local físico,

diminuindo assim a quantidade de E/S (entradas/saídas), tanto em termos de acesso aos dados, como em termos de acessos aos índices para a localização dos dados. A melhor estratégia de intercalação de tabelas deve ser defina com base nos tipos de dados e possíveis consultas que podem ser realizadas.

Outra técnica importante aplicada especialmente no ambiente de data warehouse consiste na introdução intencional de dados redundantes. A Figura 5.2 mostra um exemplo no qual a introdução deliberada de dados redundantes proporciona um excelente retorno. Na parte superior da Figura 5.2 o campo – descrição – está normalizado e não apresenta redundância. Dessa maneira todos os processos que precisam ver a descrição precisam acessar a tabela básica. Na parte inferior da Figura 5.2 o campo – descrição – foi intencionalmente colocado nas diversas tabelas em que ele precisa ser usado. O problema da replicação de dados é somente o aumento do volume do data warehouse, já que praticamente não existe a preocupação com atualizações neste ambiente.

 Figura 5.2 – Introdução intencional de dados redundantes.

A terceira técnica que pode ser utilizada para aumentar a velocidade de acesso aos dados é chamada de "separação de dados" que consiste em transformar uma tabela normalizada e que apresente probabilidades de acesso muito diferentes em duas tabelas separadas.

Para a construção de um data warehouse pode ser usada também uma técnica 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 usuário final, como informações sobre os produtos mais vendidos, clientes inativos e outras informações que possam antecipar os interesses da gerencia, como esta antecipação nem sempre é possível é necessário avaliar com cautela sobre quais os dados em que será aplicada esta técnica.

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 não são atualizados e representam informações ao longo do tempo, com isso os relacionamentos não permanecem iguais impossibilitando a criação de relacionamentos.

5.5 - Etapas do Desenvolvimento de um Data Warehouse

Na verdade, é difícil apontar no momento, uma metodologia consolidada e amplamente aceita para o desenvolvimento de data warehouses. O que se vê na literatura e nas histórias de sucesso de implementações em empresas, são 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 é construído de uma maneira "heurística", confirmando a estratégia evolucionária discutida no item anterior.

De qualquer forma, a metodologia a ser adotada é ainda bastante dependente da abordagem escolhida, em termos de ambiente, distribuição, etc. A seguir, apresentamos, a título de exemplo, as etapas sugeridas para um desenvolvimento do tipo estrela.

Desenvolver um data warehouse é uma questão de casar as necessidades dos seus usuários com a realidade dos dados disponíveis. Abaixo podemos analisar um conjunto de nove pontos fundamentais no projeto da estrutura de um data warehouse. São os seguintes os chamados pontos de decisão, que constituem definições a serem feitas e correspondem, de fato, a etapas do projeto:

        Os processos, e por conseqüência, a identidade das tabelas de fatos;

        A granularidade de cada tabela de fatos;

        As dimensões de cada tabela de fatos;

        Aos fatos, incluindo fatos pré-calculados;

        Os atributos das dimensões;

        Como acompanhar mudanças graduais em dimensões;

        As agregações, dimensões heterogêneas, minidimensões e outras decisões de projeto físico;

        Duração histórica do banco de dados;

        A urgência com que se dá a extração e carga para o data warehouse.

Recomenda-se que estas definições se façam na ordem acima. Esta metodologia segue a linha top-down, pois começa identificando os grandes processos da empresa.

Como exemplo, temos os processos de uma empresa revendedora de produtos: planos de estoque, ordens de compra, inventário, pedidos de clientes, expedição de pedidos, créditos, etc. Quando os processos estiverem identificados, cria-se uma ou mais tabelas de fatos a partir de cada um deles. Neste ponto é necessário então decidir o a um fato individual naquela tabela (esta é a granularidade da tabela). Exemplos de granularidade são: uma linha sobre um produto, um perfil de venda diário do produto, ou um perfil de venda mensal do produto. Após definir a granularidade da tabela de fatos, o próximo passo é definir as dimensões e suas granularidades. Neste exemplo, considera-se a tabela de fatos vendas acumuladas do produto. Uma vez definida a granularidade, as dimensões e suas respectivas granularidades podem ser identificadas. Assim, as dimensões tempo, produto e vendedor são criadas, além de outras dimensões descritivas como local-de-expedição, local-de-recebimento, modo-de-envio. A adição destas dimensões descritivas não altera o número de instâncias na tabela de fatos. A Figura 5.3 mostra a tabela de fatos com as dimensões identificadas. Cada dimensão pode ser vista como um ponto de entrada para a tabela de fatos. A escolha das dimensões é o ponto chave no projeto. O passo seguinte consiste em detalhar todos as medidas que constarão da tabela de fatos e finalmente completar as tabelas de dimensões. Neste instante, tem-se a estrutura do projeto lógico completa.

A partir de então, passa-se a trabalhar questões relativas ao projeto físico, avaliando mudanças graduais em dimensões e discutindo-se a inclusão de agregações, minidimensões e dimensões heterogêneas.

Figura 5.3 - A tabela de fatos e suas dimensões.

5.6 – Relacional versus multidimensional

Bancos de dados relacionais encontram em sua flexibilidade e potencial para consultas ad-hoc, um de seus pontos fortes. Bancos de dados relacionais são sabidamente mais flexíveis quando são usados com uma estrutura de dados normalizada. Uma típica consulta OLAP, no entanto, "atravessa" diversas relações e requer diversas operações de junção 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 conteúdo.

Para atender os requisitos deste tipo de transações, fornecedores de SGBDs relacionais têm adicionado funcionalidades a seus produtos. Estas funcionalidades incluem extensões às estruturas de armazenamento e aos operadores relacionais e esquemas de indexação especializados. Estas técnicas podem melhorar o desempenho para recuperações por conteúdo através da pré-junção 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 múltiplas tabelas e ponteiros para simular uma estrutura multidimensional. Também é possível usar algum outro mecanismo não relacional para armazenar algumas das agregações pré-calculadas enquanto outras são obtidas dinamicamente. Esta abordagem goza dos benefícios de um mecanismo relacional, tirando vantagem do cálculo prévio de algumas agregações. Normalmente a tabela central de fatos é bem grande enquanto as das demais dimensões são bem menores.

Por sua vez, bancos de dados multidimensionais permitem manipular diretamente objetos multidimensionais. As dimensões são identificadas ao criar a estrutura do banco, de forma que adicionar uma nova dimensão pode ser trabalhoso. Alguns bancos multidimensionais requerem uma completa recarga do banco quando uma reestruturação ocorre. Portanto, são mais recomendados para ambientes mais estáveis onde os requisitos sobre os dados não estejam em constante mudança.

5.5.1 - Um ou mais bancos

Embora se discuta o banco de dados de um data warehouse como se fosse um único repositório de dados, em grande parte dos casos isto não acontece. Na verdade, os dados podem estar distribuídos por múltiplos bancos de dados, inclusive sob diferentes sistemas de gerenciamento de banco de dados. Bancos de dados multidimensionais fornecem uma visão específica dos dados da empresa. Cada área pode, no entanto, requerer que a organização dos dados segundo um array multidimensional seja ditada pela sua visão do negócio, atendendo a suas necessidades. É muito pouco provável que o mesmo projeto de banco de dados multidimensional atenda igualmente bem a questões de tomada de decisão 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 relação às necessidades de cada área.

Uma solução freqüentemente encontrada é a separação do gerenciamento dos dados entre o data warehouse relacional integrado da empresa e os seus data marts satélites multidimensionais. Esta alternativa introduz a necessidade de uma estratégia de distribuição de dados que coordene a alimentação de novos dados aos bancos multidimensionais. Uma solução semelhante é adotada no caso em que o data warehouse possui diferentes níveis de detalhe: a camada atômica, de maior nível 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 extração, limpeza, transformação e migração de dados dos sistemas existentes na empresa para o Data warehouse constituem tarefas críticas para o seu funcionamento efetivo e eficiente. Diversas técnicas e abordagens têm sido propostas, algumas bastante genéricas e outras especialmente voltadas para a manutenção de integridade dos dados num ambiente caracterizado pela derivação e replicação de informações.

Os produtos oferecidos no mercado procuram automatizar processos que teriam de ser feitos manualmente ou utilizando ambientes de programação de mais baixo nível. De fato, não existe uma ferramenta única capaz de oferecer suporte aos processos de extração, limpeza, transformação e migração dos dados: diferentes ferramentas especializam-se em questões específicas.

O grande desafio por trás da alimentação de dados das fontes para o data warehouse não é técnico, mas gerencial. Muitos dos processos envolvidos - como mapeamento, integração e avaliação de qualidade - ocorrem de fato durante a fase de análise e projeto do data warehouse. Especialistas afirmam que identificar fontes, definir regras de transformação e detectar e resolver questões de qualidade e integração consomem cerca de 80 % do tempo de projeto. Infelizmente, não é fácil automatizar estas tarefas. Embora algumas ferramentas possam ajudar a detectar problemas na qualidade dos dados e gerar programas de extração, a maioria das informações necessária para desenvolver regras de mapeamento e transformação existe apenas na cabeça dos analistas e usuários. Fatores que certamente influem na estimativa de tempo para estas tarefas são o número de fontes e a qualidade dos metadados mantidos sobre estas fontes. As regras de negócio associadas a cada fonte - tais como validação de domínios, regras de derivação e dependências entre elementos de dados - são outra fonte de preocupações. Se estas regras tiverem de ser extraídas do código fonte das aplicações, o tempo para mapeamento e integração pode dobrar [CAM99].

6.1 – Extração

As várias alternativas para extração permitem balancear desempenho, restrições 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 extração. O desempenho das aplicações ligadas às fontes pode cair consideravelmente se transações on-line e as consultas para extração competirem entre si. Uma solução alternativa é criar uma cópia corrente dos dados das fontes a partir da qual se fará então a extração. Como desvantagem desta solução, podemos citar o espaço adicional de disco necessário para armazenar a cópia.

Outra alternativa é examinar o ciclo de processamento de algumas transações off-line que atuem nas fontes. Os programas que criam os arquivos de extração para a carga do data warehouse podem ser incorporados a um ponto apropriado deste esquema de processamento [CAM99].

As rotinas de extração devem ser capazes de isolar somente aqueles dados que foram inseridos e atualizados desde a última extração, este processo é conhecido como refresh. A melhor política de refresh deve ser avaliada pelo administrador do data warehouse, que deve levar em conta características como as necessidades dos usuários finais, tráfego na rede e períodos de menor sobrecarga, tanto das origens dos dados quanto do data warehouse, deve-se considerar que os períodos de sobrecarga podem variar para cada origem de dados [DAL99].

6.2 – Transformação e filtros

Uma vez que os dados são extraídos e colocados na área de trabalho temporária, estes devem passar por uma série de tratamentos. O primeiro destes tratamentos refere-se a limpeza ou filtragem dos dados onde o objetivo é garantir a integridade dos dados através 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 correção de erros de digitação, a descoberta de violações de integridade, a substituição de caracteres desconhecidos, a padronização de abreviações, podem ser exemplos de limpeza de dados.

O segundo passo é colocar os dados em uma forma homogênea aplicando uma metodologia de comparação de representações, que inclua os critérios a serem utilizados na identificação de semelhanças e conflitos de modelagem. Conflitos de modelagem podem ser divididos em: semânticos e estruturais. Conflitos semânticos são 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 nível de estrutura propriamente dito como no nível de domínios. Os principais tipos de conflito estruturais são os conflitos de domínio de atributo que se caracterizam pelo uso de diferentes tipos de dados para os mesmos campos. Conflitos típicos de domínio de atributo são:

Diferenças de unidades: quando as unidades utilizadas diferem, embora forneçam a mesma informação (como distância em metros ou quilômetros);

Diferenças de precisão: quando a precisão escolhida varia de um ambiente para outro (como quando o custo do produto é armazenado com duas posições ou com seis posições decimais);

Diferenças em códigos ou expressões: quando o código utilizado difere um do outro (como no caso de sexo representado por M ou F e por 1 e 2);

Diferenças de granularidade: quando os critérios associados a uma informação, embora utilizando uma mesma unidade, são distintos (como quando horas trabalhadas correspondem às horas trabalhadas na semana ou às horas trabalhadas no mês);

Diferenças de abstração: quando a forma de estruturar uma mesma informação segue critérios diferentes (como com endereço 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 representações equivalentes e de conversão para os padrões estabelecidos pelo data warehouse [DAL99].

6.3 - Derivação e Sumarização

Diferentes alternativas também 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 derivação quando o servidor de replicação distribui os

dados para os data warehouses. Ou então, derivar os dados "on-the-fly" quando o usuário submeter uma consulta ou lançar uma simulação [CAM99].

Cap. VII – Extraindo informações do Data WarehouseExistem várias maneiras de recuperar informações de um data warehouse, as formas de extração mais comuns no mercado hoje são:

        Ferramentas de consulta e emissão de relatórios;

        EIS (Executive Information Systems);

        Ferramentas OLAP;

        Ferramentas Data mining.

A nova tendência dessas soluções é a integração com o ambiente Web, permitindo maior agilidade em consultas estáticas e dinâmicas.

Nesta monografia veremos de forma básica e separadamente os conceitos das tecnologias OLAP e Data mining. A diferença básica entre ferramentas OLAP e data mining está na maneira como a exploração dos dados é abordada. Com ferramentas OLAP a exploração é feita na base da verificação, isto é, o analista conhece a questão, elabora uma hipótese e utiliza a ferramenta para confirmá-la. Com data mining, a questão é 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 análise e consultas ad hoc. Sistemas OLAP ajudam analistas e executivos a sintetizarem informações sobre a empresa, através de comparações, visões personalizadas, análise histórica e projeção de dados em vários cenários de "e se...". Sistemas OLAP são implementados para ambientes multi-usuário, arquitetura cliente-servidor e oferecem respostas rápidas e consistentes às consultas iterativas executadas pelos analistas, independente do tamanho e complexidade do banco de dados.

A característica principal dos sistemas OLAP é permitir uma visão conceitual multi-dimensional dos dados de uma empresa. A visão multi-dimensional é muito mais útil para os analistas do que a tradicional visão tabular utilizada nos sistemas de processamento de transação. Ela é mais natural, fácil e intuitiva, permitindo a visão em diferentes perspectivas dos negócios da empresa e desta maneira tornando o analista um explorador da informação [BIS99].

A modelagem dimensional é a técnica utilizada para se ter uma visão multi-dimensional dos dados. Nesta técnica os dados são modelados em uma estrutura dimensional conhecida por cubo. As dimensões do cubo representam os componentes dos negócios da empresa tais como "cliente", "produto", "fornecedor" e "tempo". A célula resultante da interseção das dimensões

é chamada de medida e geralmente representa dados numéricos tais como "unidades vendidas", "lucro" e "total de venda". Além dos componentes dimensão e medida outro importante aspecto do modelo multi-dimensional é a consolidação dos dados uma vez que para a tarefa de análise são mais úteis e significativas as agregações (ou sumarização) dos valores indicativas dos negócios [TEC99].

A expressão Decision Cube refere-se a um conjunto de componentes de suporte à decisão, que podem ser utilizados para cruzar tabelas de um banco de dados, gerando diversas visões através de planilhas ou gráficos. Envolve o cálculo, quando da carga do data warehouse, de dados que o usuário virá a solicitar, mas que podem ser derivados de outros dados. Quando o usuário solicita os dados, estes já estão devidamente calculados, agregados em um Cubo de Decisões [DAL99].

Além da visão multi-dimensional dos dados da empresa, outras importantes características dos sistemas OLAP são [TEC99]:

        Análise de tendências. A tecnologia OLAP é mais do que uma forma de visualizar a história dos dados. Deve, também, ajudar os usuários a tomar decisões sobre o futuro, permitindo a construção de cenários ("e se...") a partir de suposições e fórmulas aplicadas, pelos analistas, aos dados históricos disponíveis;

        Busca automática (reach-through) de dados mais detalhados que não estão disponíveis no servidor OLAP. Detalhes não são normalmente importantes na tarefa de análise, mas quando necessários, o servidor OLAP deve ser capaz de buscá-los;

        Dimensionalidade genérica;

        Operação trans-dimensional. Possibilidade de fazer cálculos e manipulação de dados através diferentes dimensões;

        Possibilidade de ver os dados de diferentes pontos de vista (slice and dice), mediante a rotação (pivoting) do cubo e a navegação (drill-up/drill-down) entre os níveis de agregação;

        Conjunto de funções de análise e cálculos não triviais com os dados.

Existe também um conjunto de 12 regras que servem para avaliar as ferramentas OLAP conforme [BIS99]:

1.      Visão conceitual multidimensional

2.      Transparência

3.      Acessibilidade

4.      Desempenho consistente de fornecimento de informações

5.      Arquitetura cliente/servidor

6.      Dimensionalidade genérica

7.      Manipulação dinâmica da matriz esparsa

8.      Suporte multiusuário

9.      Operações irrestritas com dimensões cruzadas

10.  Manipulação intuitiva dos dados

11.  Relatórios flexíveis

12.  Dimensões e níveis de agregação ilimitados

 Uma arquitetura OLAP possui três componentes principais: um modelo de negócios para análises interativas, implementado numa linguagem gráfica que permita diversas visões e níveis 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, através 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 execução de análises sofisticadas usando como gerenciador de dados um banco de dados multidimensional. Em um banco de dados MOLAP os dados são mantidos em arranjos e indexados de maneira a prover uma ótima performance no acesso a qualquer elemento. O indexamento, a antecipação da maneira como os dados serão acessados e o alto grau de agregação dos dados fazem com que sistemas MOLAP tenham uma excelente performance. Além de serem rápidos, outra grande vantagem destes sistemas é o rico e complexo conjunto de funções de análise que oferecem.

A maneira de se implementar os arranjos de dados pode variar entre fornecedores de soluções 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 dimensões. Por exemplo, um cubo onde a medida "vendas" é referenciada pelas dimensões "produto", "ano", "mes", "estado" e "cidade". Além da dificuldade em visualizar tal "cubo" (com cinco dimensões!!!). Outros problemas desta abordagem são a maior necessidade de espaço em disco e a existência de um mecanismo para controlar a esparsidade dos dados que ocorre quando não existe uma medida na interseção das dimensões. Por exemplo, quando um produto não é vendido em determinado estado. A grande vantagem é a consistência no tempo de resposta que é independente do número de dimensões envolvidas na consulta.

Na arquitetura multi-cubos uma medida é referenciada por dimensões selecionadas. Em um cubo, a medida "vendas" é referenciada pelas dimensões "semestre", "estado" e "produto" e em outro cubo, a medida "custo" é referenciada pelas dimensões "mês" e "departamento". Esta arquitetura é escalável e utiliza menos espaço 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 consistência do tempo de resposta.

Sistemas ROLAP fornecem análise 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 múltiplos passos e as tabelas temporárias necessárias para o processamento das consultas;

        Ou executar comandos SQL para recuperar os dados, mas fazer todo o processamento (incluindo joins e agregações) no servidor OLAP.

 Além das características básicas de sistemas OLAP, servidores ROLAP devem também:

         Utilizar metadados para descrever o modelo dos dados e para auxiliar na construção das consultas. Desta maneira um analista pode executar suas análises utilizando seus próprios termos.

        Criar comandos SQL otimizados para os bancos de dados com o qual trabalha.

A principal vantagem de se adotar uma solução ROLAP reside na utilização 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 primórdios 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 estão divergindo. Enquanto o warehouse pode ser uma boa fonte de dados para minerar, o data mining foi reconhecido como uma tarefa genuína, e não mais como uma colônia do warehouse [PAR99].

Apesar do termo data mining ter se tornado bastante popular nos últimos anos, existe ainda uma certa confusão quanto à sua definição. Data mining (ou mineração de dados) é o processo de extrair informação válida, previamente desconhecida e de máxima abrangência a partir de grandes bases de dados, usando-as para efetuar decisões cruciais. Data mining vai muito além da simples consulta a uma banco de dados, no sentido de que permite aos usuários explorar e inferir informação ú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 evidência no momento, envolvendo Inteligência Artificial e Banco de Dados [CAM99].

Um ambiente de apoio à tomada de decisões, integrando técnicas de data mining sobre um ambiente de data warehousing, possibilita um grande número de aplicações, que já vêm sendo implementadas em diversos segmentos de negócios, como manufatura, automação de pedido de remessas, varejo, gerenciamento de inventários, financeiro, análise de risco, transporte, gerenciamento de frotas, telecomunicação, análise de chamadas, saúde, analise de resultados, markenting, estabelecimento do perfil dos consumidores, seguros, detecção de fraude, dentre outros [PIN99].

Data mining pode ser utilizado com os seguintes objetivos [TEC99]:

        Explanatório: explicar algum evento ou medida observada, tal como porque a venda de sorvetes caiu no Rio de Janeiro;

        Confirmatório: confirmar uma hipótese. Uma companhia de seguros , por exemplo, pode querer examinar os registros de seus clientes para determinar se famílias de duas rendas tem mais probabilidade de adquirir um plano de saúde do que famílias de uma renda;

        Exploratório: analisar os dados buscando relacionamentos novos e não previstos. Uma companhia de cartão de crédito pode analisar seus registros históricos para determinar que fatores estão associados a pessoas que representam risco para créditos.

Quando determinados padrões de comportamento, como associação de produtos durante um processo de compras, por exemplo, começam a se repetir com freqüência, as ferramentas data mining indicam a presença de oportunidades e "insights" em relação àquele público consumidor. O diferencial do data mining está no fato de que as descobertas de padrões de consumo se dão por uma lógica de algoritmos com base em uma rede neural de raciocínios. São ferramentas de descobertas matemáticas feitas sobre os registros corporativos já processados contra descobertas empíricas [POL99].

7.2.1 - O processo do Data Mining

De uma vista de processo orientado, há três classes de data mining: descobrimento, modelagem de prognóstico e análise prévia.

Descobrimento é o processo de examinação em um banco de dados para encontrar padrões escondidos sem uma idéia ou hipótese pré-determinada sobre o que são esses padrões. Em outras palavras, o programa toma a iniciativa de encontrar aquilo que interessa aos padrões, sem que o usuário verifique se isto realmente interessa. Em uma grande base de dados, há muitos padrões que o usuário pode praticamente nunca imaginar as perguntas certas para as respostas. A solução lançada aqui é a riqueza dos padrões que podem ser expressos e descobertos e a qualidade de informação libertada - determinando a força e a utilidade da técnica de descoberta.

Na modelagem de prognóstico, os padrões descobertos no banco de dados são usados para prognosticar o futuro. Isto permite ao usuário submeter valores desconhecidos de campos nos registros, e o sistema irá supor os valores desconhecidos baseado em padrões previamente descobertos no banco de dados. Enquanto o processo de descobrimento encontra padrões em dados, o processo de modelagem de prognóstico aplica estes padrões para supor valores nos novos itens de dados.

A análise prévia é o processo de aplicação dos padrões extraídos para encontrar anomalias ou elementos de dados raros. Para descobrir os dados raros, nós primeiramente encontramos os dados que seguem uma norma ou os habituais, então detectamos aqueles que se desviam dos habituais dentro de um certo limiar.

Existem três tipos de atividade de data mining em um ambiente corporativo: episodic mining, strategic mining e continuous mining.

Na atividade episodic mining nós buscamos dados de um fato específico, tal como uma campanha de marketing direto. Nós podemos tentar entender este conjunto de dados ou usá-lo para prognóstico em uma nova campanha de marketing.

Na atividade strategic mining, nós olhamos um largo conjunto de dados corporativos com a intenção de ganhar um conhecimento global das medidas específicas. 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 nós tentamos entender como o mundo foi modificado em um determinado período de tempo e tentar compreender os fatores que influenciaram esta mudança. Neste caso, poderíamos perguntar: "como obter padrões de venda modificados neste mês?" ou "qual foi a fonte de mudança 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 – Retenção dos dados

Enquanto na "destilação de padrões" nós analisamos dados, extraímos padrões e deixamos os dados para trás, na retenção os dados são mantidos para posterior combinação. Quando novos dados são apresentados, eles são combinados com o conjunto de dados anterior.

Um exemplo bem conhecido de uma aproximação baseada na retenção de dados é o método "nearest neighbor" (vizinho próximo). Neste método, o conjunto de dados é mantido

(geralmente em memória) para a comparação com novos dados. Quando um novo registro está presente, por prognóstico, a "distância" entre ele e os registros semelhantes no conjunto de dados é encontrado, e os mais parecidos (ou vizinhos próximos) são identificados.

Algumas vezes, precisamos reter apenas um conjunto de "casos típicos" - podemos selecionar, por exemplo, uma série de 100 "padrões típicos" como base para comparações. Isto é muitas vezes denominado Case-based Reasoning (traduzindo livremente, poderia ser algo como "caso baseado no raciocínio").

7.2.4 – Destilação de padrões

Estas tecnologias extraem padrões a partir de uma série de dados e os usam para vários fins. Naturalmente, as primeiras duas questões aqui são: Que tipos de padrões podem ser extraídos e como serão representados?

Obviamente, os padrões necessitam ser expressos dentro de um formalismo e uma linguagem - para os escolhermos, temos três distintas formas de abordagem:

        sistema lógico (logic)

        sistema equacional (equations)

        classificação cruzada (cross-tabulations)

Cada uma dessas abordagens têm raízes históricas, levando-nos à distintas origens matemáticas.

7.2.4.1 – Semelhança lógica

A lógica forma a base da maioria das linguagens escritas, e é essencialmente trabalhada pelo lado esquerdo do cérebro. Padrões expressos em linguagens lógicas são distinguidos por duas principais características: Os primeiros são legíveis e compreensíveis enquanto que os outros são excelentes na representação sinuosa de "caixas" e agrupamento de dados.

O operador central numa linguagem lógica é normalmente uma variação do conhecido comando If / Then. Entretanto, devemos notar que enquanto a forma lógica mais comum é a lógica condicional, muitas vezes necessitamos usar outras formas lógicas como uma associação lógica com a regra When / Also. Ainda que as lógicas atribuídas e propostas (lógicas condicionais) sejam melhor conhecidas, outras formas de lógica (lógicas de variação e de tendência, por exemplo) são usadas também em análise dos dados objetos.

Sistemas de lógica condicional podem ser separados em dois grupos distintos: árvores de regras e de decisão. Regras condicionais podem ser implementadas por Indução ou Algoritmos Genéticos e várias outras formas de gerar árvores de decisão.

7.2.4.1.1 – Regras

Os relacionamentos lógicos são normalmente representados como regras. Simples regras podem expressar relações condicionais ou de associação.

Uma regra condicional é um comando na forma:

If Condição 1

Then Condição 2

 A conexão lógica é distinta a partir da lógica condicional, tanto em termos da linguagem da expressão como da estrutura de dados usadas. Análise por Conexão (ou Análise por Associação) [Affinity Analysis / Association Analysis] é a procura por padrões e condições que descrevem vários itens, como "grupos simultâneos" ou "acontecimentos simultâneos" [group together / happen together] numa série de eventos ou transações. Uma regra de afinidade possui a seguinte forma:

When Item_1

Also Item_2.

Regras têm a vantagem de serem mais competentes para trabalhar com dados numéricos e não-numéricos de uma maneira uniforme. Enquanto trabalha com dados numéricos, algumas aproximações valem-se da quebra de campos numéricos nos códigos ou nos valores especificados. Isto pode, efetivamente, remover todas as considerações numéricas dos códigos - resultando na perda dos padrões.

Regras podem também atuar bem em dados multidimensionais ou OLAP porque eles podem trabalhar com faixas de dados numéricos e seus formatos lógicos, permitindo que seus padrões possam ser mesclados ao longo de múltiplas dimensões.

 Regras podem ser vistas também como árvores de decisão, mas apesar da semelhança a nível superficial, têm uma técnica distinta, diferente. Isto é fácil de ver quando consideramos o fato que árvores de decisão não expressam associações ou padrões baseados em atributos.

A seguir, duas abordagens para a geração de regras são colocadas: regra indutiva e algoritmos genéticos. Entretanto, estas não são as únicas formas de abordagem do Data mining com regras. Algumas abordagens examinam, através de uma pré-computação, cada possibilidade da regra até numa série de dados que já estavam incluídas (previstas). Nesses casos, somente uma única coluna de dados pode ser usada porque o espaço lógico é imenso. Conseqüentemente, não é prático para aplicações em larga escala.

7.2.4.1.1.1 - Regra indutiva

Regra indutiva é o processo de olhar uma série de dados e, a partir dela, gerar padrões. Pelo fato de explorar automaticamente a série de dados, o sistema indutivo cria hipóteses que conduzem a padrões. O processo é em sua essência semelhante àquilo que um analista humano faria em uma análise exploratória.

7.2.4.1.1.2 – Algoritmos genéticos

Algoritmos genéticos também geram regras dos conjuntos de dados, mas não seguem a indução de protocolo de regras de exploração orientada. Ao contrário, eles contam com a

idéia de "mutação" para fazer trocas nos padrões até que uma forma apropriada de modelo surja via educação seletiva.

7.2.4.1.2 – Árvores de decisão

Árvores de decisão expressam uma forma simples de lógica condicional. Um sistema de árvore de decisão, simplesmente, divide uma tabela em tabelas menores pela seleção de subconjuntos baseados em valores de um atributo dado. Baseado no modo como a tabela é dividida, nós obtemos um algoritmo diferente de árvore de decisão.

7.2.4.2 – Tabulação cruzada

Tabulação cruzada é uma forma muito básica e simples de análise de dados, bem conhecida em estatística, largamente usada para reportagem. Uma tabulação cruzada de duas dimensões é semelhante a uma extensão de papel, com ambos cabeçalhos de linhas e colunas como valores de atributos. As células na extensão de papel representam uma ação agregada, freqüentemente o número de co-ocorrências de atributo avalia-se juntos. Muitas tabulações cruzadas são eficazmente dois equivalentes a um gráfico de barras de três dimensões o qual expõe somas totais de co-ocorrências.

7.2.4.2.1 - Agentes

O termo "agente" é usado algumas vezes para referir-se as tabulações cruzadas que são graficamente mostradas numa rede e permitem algumas conjunções (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 confiança

Redes de Confiança (algumas vezes chamada de redes causais) também contam com totais de co-ocorrência, mas ambas a reprodução gráfica e a representação probabilista são levemente diferentes dos agentes.

As redes de confiança são freqüentemente ilustradas usando uma representação gráfica de distribuição probabilistas (derivadas de somas totais). Uma rede de confiança é então em gráfico dirigido, consistindo de nós (variáveis representadas) e arcos (representando dependências probabilistas) entre as variáveis de nós.

7.2.4.3 – Aproximações equacionais

O método abaixo de expressão padrão nestes sistemas é a construção de superfície melhor do que a expressão lógica ou co-ocorrência de contagens. Tal sistema geralmente utiliza um grupo de equações para definir uma superfície dentro de um espaço numérico.

As aproximações equacionais quase sempre requerem que os dados sejam todos numéricos. Dados não numéricos precisam ser codificados em números (o contrário do que faz a tabulação cruzada).

7.2.4.3.1 – Redes neurais

Redes Neurais são uma classe de modelagem de prognóstico que trabalha por ajuste repetido de parâmetro. Estruturalmente, uma rede neural consiste em um número de elementos interconectados (chamados neurônios) organizados em camadas que aprendem pela modificação da conexão firmemente conectando as camadas.

Redes neurais geralmente constroem superfícies equacionais complexas através de interações repetidas, cada hora ajustando os parâmetros que definem a superfície. Depois de muitas repetições, uma superfície pode ser internamente definida que se aproxima muito dos pontos dentro do grupo de dados.

A função básica de cada neurônio é: (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 saída. Enquanto a operação de cada neurônio é razoavelmente simples, procedimentos complexos podem ser criados pela conexão de um conjunto de neurônios. Tipicamente, as entradas dos neurônios são ligadas a uma camada intermediária (ou várias camadas intermediárias) que é então conectada com a camada de saída.

Para construir um modelo neural, nós primeiramente "adestramos" a rede em um dataset de treinamento e então usamos a rede já treinada para fazer predições. Nós podemos, às vezes, monitorar o dataset durante a fase de treinamento para checar seu progresso.

Cada neurônio geralmente tem um conjunto de pesos que determina como o neurônio avalia a combinação dos sinais de entrada. A entrada para um neurônio pode ser positiva ou negativa. O aprendizado se faz pela modificação dos pesos usados pelo neurônio em acordo com a classificação de erros que foi feita pela rede como um todo. As entradas são 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 intermediária. Um termo popular chamado "backpropagation" (propagação realimentada) é usado quando os pesos são ajustados baseados nas estimativas feitas pela rede - suposições incorretas reduzem os limites para as conexões apropriadas.

ConclusãoA tecnologia de data warehouse mostra-se muito interessante para empresas que possuem grandes volumes de dados gerados e acumulados durante sua existência e necessitam recuperar estes dados de uma forma que eles possam auxiliar os administradores destas empresas a tomarem decisões estratégicas rapidamente e com segurança.

Os processos de extração, filtragem, carga e recuperação dos dados são bastante complexos, exigindo que pessoas altamente capacitadas façam parte do projeto para que os objetivos sejam atingidos no menor espaço de tempo possível e sem gastos de recursos desnecessários.

Como o data warehouse não é um sistema ou programa, mas sim um ambiente que necessita ser adaptado as necessidades das empresas é normal que cada ambiente de data warehouse possua características próprias, inviabilizando seu uso para outros objetivos que não os descritos no início do projeto.

Para a informática o ambiente de data warehouse mostrou ser um desafio aos processos que normalmente são utilizados para desenvolver um software. Um dos desafios é conseguir modelar os dados de maneira que todas as informações estejam disponíveis de forma clara e rápida para os usuários que a estão requisitando, outro desafio é disponibilizar as informações sobre os dados (metadados), para que os usuários possam saber quais informações estão disponíveis, de onde vieram, para onde vão, etc.

Também pode ser considerado um desafio aos profissionais de informática a melhor maneira de extração dos dados do data warehouse, de forma que ele realmente se torne um sistema de apoio a decisão. As duas maneiras estudadas neste trabalho foram a analise multidimensional através do OLAP e o data mining.

A diferença básica entre ferramentas OLAP e data mining está na maneira como a exploração dos dados é abordada. Com as ferramentas OLAP a exploração é feita na base da verificação, isto é, o analista conhece a questão, elabora uma hipótese e utiliza a ferramenta para confirmá-la. Com data mining, a questão é total ou parcialmente desconhecida e a ferramenta é utilizada para a busca de conhecimento.

Por fim, é importante destacar que este trabalho contribuiu muito para a ampliação dos conhecimentos do autor em relação aos ambientes de suporte a decisão. O que com certeza poderá ser aplicado na sua futura vida profissional.

Bibliografia[BIS99] BISPO, Carlos Alberto F. & CAZARINI, Edson Walmir. Análises sofisticadas com o

On-Line Analytical Processing. Developer’s Magazine, São 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] DAL’ALBA, 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 técnica de cubo de decisão. Developer’s Magazine, São 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.Developer’s Magazine, São Paulo, n.32, p.22-26, abr de 1999.

[PIN99] PINHEIRO, Carlos André Reis. Data mining: obtendo vantagens com seu data warehouse. Developer’s Magazine, São 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.