UNIVERSIDADE PRESBITERIANA MACKENZIE

Faculdade de Computao e Informtica

A MODELAGEM DE DADOS NO AMBIENTE DATA WAREHOUSE

Daniele Del Bianco Hokama Denis Camargo Francine Fujita Joo Luiz Valentim Fogliene

So Paulo 2004

Daniele Del Bianco Hokama Denis Camargo Francine Fujita Joo Luiz Valentim Fogliene

A MODELAGEM DE DADOS NO AMBIENTE DATA WAREHOUSE

Trabalho de Graduao Interdisciplinar apresentado Faculdade de Computao e Informtica, da Universidade Presbiteriana Mackenzie, como exigncia parcial para a obteno do grau de Bacharel em Sistemas de Informao

Orientador: Prof. ROGRIO OLIVEIRA

So Paulo 2004

SUMRIO
INTRODUO 1.1 Conceitos 1.2.1 Extrao ................................................................................................ ............................................................. ....................................................... ....................................................................................................... ....................................................................................................... ............................................................................ ........................................................................................... ........................................................................................... ..................................................................................... .................................................................................. ............................................................................ ............................................................. ...................................................................... 09 12 12 15 16 17 18 19 20 22 24 28 28 32 34 37 38 38 40 42 44 45 48 51 51 52 53 56 57 57 58 60 60

1 - AMBIENTE DATA WAREHOUSE

1.2 ETL Extrao, Transformao e Carga 1.2.2 Transformao de dados 1.2.3 Carga de dados 1.3 Modelo de dados 1.3.1 Modelo Relacional 1.3.2 Modelo Dimensional

1.3.3 A escolha da modelagem

2 - A MODELAGEM DIMENSIONAL 2.1 Exemplo de Modelos de dados 2.2 Esquema Estrela 2.2.1 Tabela de Fatos

........................................................................................... ........................................................................................ ................................................................... ............................................................................... .................................................................................. ............................................................................ ................................................................... .................................................................................. ...............................................................................

2.2.2 Modelagem da Tabela de Fatos 2.2.3 Classificao dos Fatos 2.2.4 Tabela de Dimenso 2.2.6 Drill-down e Roll-up 2.3 Esquema Floco de Neve 2.4 Cubo 2.2.5 Hierarquia de Dimenses

2.2.7 Dimenses Descaracterizadas

................................................................................................................ ................................................................................................. ................................................................... ..................................................................................... .................................................................................. ....................................................... ...................................... .................................................................................. ....................................................

3 - TCNICAS DE MODELAGEM DIMENSIONAL ........................................ 3.1 Granularidade 3.1.1 Nveis duais de granularidade 3.1.2 Tabelas Agregadas 3.2 Vises materializadas 3.3.1 Sobrescrever o valor

3.3 Tcnicas de Rastreamento de Alteraes

3.3.2 Adicionar uma nova linha na tabela de dimenses 3.3.3 Adicionar uma nova coluna de dimenso 3.3.4 Artefatos de dados

.....................................................................................

3.4 Criao de Minidimenses 3.5 Criao de Novas Chaves 3.7 Tabela de fatos sem fatos 3.8 Dados desnormalizados 3.9 Dimenses de tempo

............................................................................ ............................................................................... .......................... ............................................................................... .................................................................................. .................................................................................. .......

61 64 66 67 70 72 76 76 77 79 81 82 83 84 87 92 96 100 103 105 108 109 110

3.6 Tratamento de Dimenses e Fatos com Cardinalidade M:N

4 QUESTES SOBRE ACESSO A DADOS MULTIDIMENSIONAIS 4.1.1 ndices bitmap

4.1 Estratgias de Processamento de Consultas .................................................... .............................................................................................. ..................................................................................... .................................................... 4.1.2 ndices com juno

4.1.3 Junes estrela (Star Join) ............................................................................ 4.2 Operador CUBE na Agregao Relacional 4.2.1 Agregao no SQL 4.2.3 Operador CUBE 4.2.2 Problemas com o group by ..................................................................................... ...................................................................... ........................................................................................... ...............................................................................

4.3 Manuteno de Vises ..................................................................................... 4.3.1 Informaes Completas CONCLUSO GLOSSRIO 4.3.2 Informaes Parciais ..................................................................................... ....................................................................................................... ....................................................................................................... ................................................................ ................................................................ ................................

REFERNCIAS BIBLIOGRFICAS BIBLIOGRAFIA COMPLEMENTAR

APNDICE A OLAP (Processamento Analtico On-line)

LISTA DE QUADROS
Quadro 1 Requisitos de processamento transacional e analtico ......24 Quadro 2 Diferenas entre OLAP e OLTP ...25

LISTA DE FIGURAS
Figura 1 Figura 2 Figura 3 Figura 4 Figura 5 Figura 6 Figura 7 Figura 8 Figura 9 Figura 10 Figura 11 Figura 12 Figura 13 Figura 14 Figura 15 Figura 16 Figura 17 Figura 18 Figura 19 Figura 20 Figura 21 Ambiente de Data Warehouse 16 Modelo relacional do sistema transacional de vendas de lojas de Departamento 29 Modelo dimensional do sistema analtico de Vendas de Lojas de departamento ..31 Representao da estrutura do Esquema Estrela. 33 Tabela de fatos Vendas ..36 Tabela de dimenso Produtos .39 Hierarquia explcita de Produto ... 41 Hierarquia implcita para Produto ..42 Exemplo de drill-down, detalhando uma informao de data e roll-up, sintetizando a informao ......43 Drill-down e drill-across de OLAP .44 Dimenso descaracterizada cdigo da venda na tabela de fatos vendas .45 Modelo de Dados do sistema de vendas de lojas de departamento utilizando o esquema floco de neve ...46 Modelo de dados floco de neve com as dimenses normalizadas se relacionando diretamente com a tabela de fatos .......48 Exemplo de um cubo aplicado ao sistema de vendas de uma rede de lojas de departamento ..49 Tabela de fatos Vendas e duas tabelas agregadas originadas da agregao da tabela Vendas ....53 Alterao de dimenso sobrescrevendo o valor antigo ...58

Alterao de dimenso por insero de novo registro 59 Rastreamento de alteraes por meio de artefatos de dados ..61 Minidimenso DEMOGRFICA .......................62 Exemplo de linhas de uma minidimenso de dados demogrficos .63 Chave substituta cdigo da loja na tabela de dimenso Lojas no lugar da chave original nmero da loja ....65

Figura 22 Figura 23 Figura 24 Figura 25

Chave substituta cdigo do produto para economizar espao em disco da chave original cdigo de barras .66 Tabela de fatos sem fatos Produtos a Venda ..68 Dados desnormalizados na tabela de dimenso Produtos . 71 Tabela de dimenso Data se relacionando com a tabela de fatos vendas no modelo do sistema de vendas de lojas de departamento, o que permite a visualizao dos fatos por diversos critrios diferentes de data 73 Exemplo de linhas em uma dimenso Data, a primeira linha corresponde a data "16/02/2004" e a segunda a "21/04/2004" .74 Dimenso Data com diversos atributos, todas as interpretaes de datas teis para o negcio devem ser armazenadas ..75 Exemplo de ndices com juno no data warehouse de Vendas 80 Tabela Empregados ..83 Mdia dos salrios ........83 Quantidade de departamentos ..84 Tabela de Roll Up de Vendas de carro por Modelo, por Ano e por Cor 85 Tabela de Vendas........................ 85 Linhas no includas na agregao da tabela de Vendas ..86 Cross tabulation de vendas da GM .........87 Agregaes em um cubo de N Dimenses ...88 Data Cube de 3 dimenses construdo a partir da tabela tbl_vendas ...90

Figura 26 Figura 27 Figura 28 Figura 29 Figura 30 Figura 31 Figura 32 Figura 33 Figura 34 Figura 35 Figura 36 Figura 37

Figura 38 Figura 39 Figura 40 Figura 41 Figura 42

Valores da relao tab_base.....................97 Valores da viso Visao1 com o nmero de derivaes para cada linha ..97 Valores da viso materializada Visao1 aps a excluso do registro (a, b) da relao base...................................................................................98 Instncia das relaes tab1 e tab2 ............99 Valores da viso com outer-join completo Visao1..............................99

RESUMO

Modelos multidimensionais so largamente utilizados em processos analticos que requerem complexos cruzamentos de informaes, pois so capazes de processar com performance razovel um grande volume de dados. Este trabalho busca apresentar as principais tcnicas da modelagem multidimensional utilizadas hoje. Essas tcnicas tm o objetivo de otimizar a estrutura dos modelos multidimensionais. Para tanto, foi empregado um mtodo baseado na apresentao de exemplos e na discusso dos problemas do modelo relacional para atender a demanda de informaes analticas e gerenciais.

ABSTRACT

Multidimensional models are wide used in analytical processes that require complexes data crosses because they can compute with moderate performance large amounts of data. This job presents the major multidimensional modeling techniques applied nowadays. These techniques have the objective to optimize multidimensional modeling structures. In order to do that, it was used a method based on the presentation of examples and on the discussion of the relational models problems to supply the analytical and the business information demand.

INTRODUO
Quando surgiram, os sistemas e aplicaes voltados para as funes operacionais tornaram o trabalho mais simples, pois, alm de garantirem maior agilidade na execuo de tarefas que antes requeriam um esforo muito grande, tambm minimizam possveis erros humanos.

Alm de vantagens como as citadas acima, essas aplicaes trouxeram outras indiretamente, como a capacidade de manter informaes histricas de forma agrupada e possvel de serem consultadas. Essas informaes poderiam ser usadas por reas estratgicas da empresa (marketing, alta gerncia, etc) para auxiliar em tomadas de deciso. Porm, agrupar essas informaes, interpret-las e tirar concluses no uma tarefa fcil. preciso extrair de cada base de dados as informaes que realmente interessam e padroniz-las para que possam ser analisadas.

O processo de data warehousing busca automatizar o processo de extrao e padronizao de dados, alm de prover ao usurio maneiras mais fceis e flexveis de visualizar os dados. Um data warehouse uma coleo de dados orientada por assuntos, integrada, variante no tempo, e no voltil, que tem por objetivo dar suporte aos processos de tomada de deciso [INMON, 1999].

De uma forma geral, sistemas de data warehouse compreendem um conjunto de programas que extraem e tratam dados do ambiente operacional da empresa, um banco de dados que os mantm, e sistemas que fornecem estes dados aos seus usurios, dando suporte a consultas ad-hoc (consultas com acesso casual nico e tratamento dos dados segundo parmetros nunca antes utilizados), relatrios analticos e tomada de deciso.

10 Com essas caractersticas voltadas anlise de negcios, natural que o ambiente de data warehouse requeira mudanas constantes em seus relatrios e consultas. Essa flexibilidade imprescindvel, uma vez que ter as informaes certas pode fazer a diferena na tomada de deciso. Porm, embora as necessidades por informaes especficas mudem com freqncia, os dados associados no mudam. Imaginando-se que os processos de negcio de uma empresa permaneam relativamente constantes, existe apenas um nmero finito de objetos e eventos com as quais uma organizao est envolvida. Por esta razo, um modelo de dados uma base slida para identificar requisitos para um data warehouse.

Um modelo de dados bem estruturado capaz de prover s empresas a capacidade de extrarem as informaes certas das mais diferentes formas e maneiras, independente da ferramenta ou do grau de complexidade exigido nas consultas. Ou seja, a importncia da modelagem de dados em data warehouse reside no fato de que, sem uma estrutura bem elaborada, a enorme quantidade de informaes pode tornar as consultas demasiado lentas, e com a possibilidade de tornar inviveis algumas operaes de consulta.

O objetivo geral desse trabalho mostrar a importncia da modelagem de dados no ambiente data warehouse, apresentar os conceitos da modelagem dimensional e oferecer tcnicas interessantes de construo de um modelo dimensional, visando oferecer ao usurio informaes interessantes para a realizao de consultas analticas, e buscando a otimizao da performance das consultas e das atualizaes na base de dados.

O trabalho encontra-se organizado como segue: o captulo um traz informaes acerca da modelagem de dados relacional como uma base de entendimento para os prximos temas. Trata de informaes acerca do ambiente data warehouse, seus termos e conceitos, e introduo sobre o modelo dimensional de dados, que ser discutido mais profundamente

11 no captulo dois, que dedica-se a modelagem dimensional. Os conceitos de tabela de fatos, o esquema estrela e floco de neve sero discutidos neste captulo em detalhe. O captulo trs trata das tcnicas de modelagem a serem exploradas na construo de um modelo dimensional, e discutem-se aspectos como a performance do modelo, a criao de chaves, o uso de agregaes e a redundncia controlada de dados. O captulo quatro apresenta estratgias que podem ser adotadas para reduzir o tempo de processamento para recuperar e atualizar as informaes contidas em um modelo dimensional. Um apndice foi includo para discutir o uso do OLAP (Processamento Analtico On-line), comparando os padres ROLAP e MOLAP, contribuindo para um maior aprofundamento dos temas discutidos.

12

Captulo 1 Ambiente Data Warehouse

1.1 Conceitos
Um data warehouse nada mais do que um banco de dados contendo dados extrados do ambiente de produo da empresa, que foram selecionados e depurados, tendo sido otimizados para processamento de consulta e no para processamento de transaes. Em geral, um data warehouse requer a consolidao de outros recursos de dados, alm dos armazenados em banco de dados relacionais, como informaes provenientes de planilhas eletrnicas, documentos textuais, etc. [INMON, 1999].

importante considerar que um data warehouse no contm apenas dados resumidos, podendo conter tambm dados primitivos. Deve-se prover ao usurio a capacidade de aprofundar-se num determinado tpico, investigando nveis de agregao menores ou mesmo o dado primitivo, permitindo tambm a gerao de novas agregaes ou correlaes com outras variveis. Alm do mais, extremamente difcil prever todos os possveis dados resumidos que sero necessrios: limitar o contedo de um data warehouse apenas a dados resumidos significa limitar os usurios apenas s consultas e anlises que eles puderem antecipar frente a seus requisitos atuais, no deixando qualquer flexibilidade para novas necessidades.

A especificao de requisitos do ambiente de suporte deciso, associado a um data warehouse, fundamentalmente diferente da especificao de requisitos dos sistemas que sustentam os processos usuais do ambiente operacional de uma empresa. Os requisitos dos sistemas do ambiente operacional so claramente identificveis a partir das funes a serem executadas pelo sistema. Geralmente, os sistemas do ambiente operacional que apiam os

13 usurios em suas funes do dia-a-dia so chamados OLTP (On Line Transaction Processing), e seu principal objetivo executar o maior nmero de transaes possveis no menor tempo de processamento. Em geral, os sistemas OLTP so pouco flexveis em relao quantidade de relatrios e consultas, devido s limitaes impostas por seu modelo de dados e linguagem SQL. Em sistemas de suporte a deciso, onde o volume de dados costuma ser muito maior e as consultas altamente complexas, os requisitos so difceis de determinar, o que culmina na necessidade de ferramentas altamente flexveis e customizveis. Para atender essa necessidade so adotados os sistemas OLAP (On Line Analytical Processing). Sistemas OLAP permitem aos usurios de alto nvel, como gerentes e analistas de negcio, navegarem entre os dados da empresa com maior facilidade, proporcionando uma viso multidimensional desses dados.

Inmon (1999) nos d uma definio bastante completa sobre o OLAP:

(...) uma tecnologia de software que permite a analistas, gerentes e executivos a obterem os dados de uma forma rpida, consistente e com acesso interativo para uma grande variedade de possveis vises da informao na empresa. Mais sucintamente, OLAP um conjunto de funcionalidades que tem, como principal objetivo, facilitar a anlise multidimensional. Sistemas OLAP fornecem uma viso multidimensional dos dados no importando como estes dados esto fisicamente armazenados. Os dados so percebidos pelo usurio como um cubo multidimensional onde cada clula contm um valor ou medida.

Cubo uma estrutura multidimensional de dados que expressa a forma na qual os tipos de informaes se relacionam entre si. O cubo de uma forma genrica armazena todas as informaes relacionadas a um determinado assunto, de maneira a permitir que sejam

14 montadas vrias combinaes entre elas, resultando na extrao de vrias vises sobre o mesmo tema.

Alguns conceitos so importantes para que se possa compreender melhor o funcionamento de um ambiente data warehouse e so definidos a seguir.

Sistemas operacionais de origem: So considerados sistemas operacionais de origem qualquer sistema de registro que captura as transaes da empresa. Sistemas de origem devem ser considerados como externos ao data warehouse porque se presume que se tenha um pouco ou nenhum controle sobre o contedo e formato dos dados nesses sistemas.

Metadados: Toda e qualquer informao no ambiente de data warehouse que no so os dados propriamente ditos, so chamados metadados. Estes so como uma enciclopdia para o data warehouse. Eles esto presentes em uma variedade de formas e formatos para suportar as necessidades desiguais dos grupos de usurios tcnicos, administrativos e de negcio do data warehouse.

Quando os dados esto na rea de armazenamento, encontramos metadados especficos para orientar os processos de transformao e carga, inclusive arquivos de teste e lay-outs de tabelas de destino, regras de transformao e filtragem, definies de dimenso e fato em conformidade, definies de agregao e resultados de log de execuo e cronogramas de transmisso ETL (O termo ETL tratado logo a seguir). At cdigos de programao personalizados que foram criados na rea de armazenamento, so metadados.

Os metadados que permeiam o SGBD Sistema Gerencial de Banco de Dados do data warehouse so responsveis por itens como tabelas de sistemas, configuraes de partio, ndices, definies de exibio e concesses e privilgios de segurana no nvel do

15 SGBD. Os metadados de ferramentas de acesso a dados identificam os nomes e as definies comerciais das tabelas e colunas da rea de apresentao, bem como filtros de restrio, especificaes de modelos de aplicao, estatsticas de uso e acesso e outras documentaes de usurio.

O objetivo dos metadados cercar, catalogar, integrar e melhorar essas diversas variedades de metadados, da mesma forma que os recursos de uma biblioteca [KIMBALL, 2002].

1.2 ETL Extrao, Transformao e Carga

No ambiente de data warehouse, os dados so inicialmente extrados de sistemas operacionais e de fontes externas, posteriormente integrados e transformados (limpos, eliminados, combinados, validados, consolidados, agregados e sumarizados), antes de serem carregados no data warehouse. Finalmente, os usurios acessam o DW atravs de ferramentas de front-end ou aplicaes submetendo suas consultas, de modo a obterem informaes que permitam a tomada de decises. Um DW contm dados sumarizados, histricos e detalhados para suportar a tomada de decises tticas e estratgicas. A figura 1 apresenta o ambiente data warehouse, mostrando o fluxo realizado at a disponibilizao dos dados aos usurios.

16

Figura 1: Ambiente Data Warehouse.

1.2.1 Extrao A extrao o primeiro passo na obteno de dados para o ambiente do DW. Significa basicamente ler e entender as fontes de dados e copiar as partes necessrias para a rea de transformao de dados, a fim de serem trabalhadas posteriormente. Na grande maioria dos DW, os dados provm de vrias fontes diferentes e independentes, podendo ser essas fontes as bases de dados dos sistemas transacionais, planilhas excel, etc.

Freqentemente, o grande desafio determinar quais dados extrair e que tipos de filtros aplicar, essa atividade uma das que mais consomem tempo na construo do DW. A extrao pode ser conduzida atravs da construo de programas cujo cdigo executado sobre um sistema fonte de modo a gerar arquivos com os dados desejados. Outra opo utilizar ferramentas de extrao especficas que geram cdigo prprio, interno ferramenta,

17 executado sobre o sistema fonte, de forma a obter os dados necessrios, de preferncia dentro de arquivos de formato no proprietrio, como, por exemplo, arquivos texto.

1.2.2 Transformao de dados

Aps a extrao dos dados dos sistemas fontes, so realizadas uma srie de atividades sobre esses dados de modo a convert-los em formato adequado para carga no data warehouse e valioso para o negcio. A transformao dos dados poder envolver um ou vrios processos, dependendo da necessidade e situao. Seguem alguns dos processos mais comumente utilizados: limpeza: constitui no conjunto de atividades realizadas, sobre os dados extrados, de modo a corrigir o uso incorreto ou inconsistente de cdigos e caracteres especiais, resolver problemas de conflito de domnios, tratar dados perdidos, corrigir os valores duplicados ou errados. Independente do problema a ser solucionado pelo processo de limpeza, a finalidade deixar os elementos de dados dentro de formatos padres (uniformizados), no duplicados, corretos, consistentes e espelhando a realidade; eliminao: constitui em desconsiderar os campos e dados provenientes de sistemas legados que no so teis ao DW; combinao: realizada quando fontes de dados possuem exatamente os mesmos valores de chaves representando registros iguais ou complementares; desnormalizao e normalizao: o padro no processo de transformao reunir as hierarquias de dados, separadas em vrias tabelas devido normalizao, dentro de uma nica dimenso, de forma desnormalizada. Pode ocorrer, entretanto, que dados provenientes do processo de extrao estejam

18 completamente desnormalizados dentro de arquivos texto, nesse caso possvel que seja necessrio normalizar partes dos registros. clculos, derivao e alocao: so transformaes a serem aplicadas s regras do negcio identificadas durante o processo de levantamento de requisitos. conveniente que as ferramentas a serem empregadas possuam um conjunto de funes, tais como manipulao de textos, aritmtica de data e hora, entre outras.

1.2.3 Carga de dados

Aps os dados serem transformados, eles so carregados no data warehouse. A parte de carga dos dados tambm possui uma enorme complexidade, e os seguintes fatores devem ser levados em conta: Integridade dos dados: no momento da carga, necessrio checar os campos que so chaves estrangeiras com suas respectivas tabelas para certificar-se de que os dados existentes na tabela da chave estrangeira esto de acordo com a tabela da chave primria; Tipo de carga a ser realizada - incremental ou a total: a carga incremental normalmente feita para tabelas de fatos e a carga total feita em tabelas de dimenso onde o analista ter que excluir os dados existentes e inclu-los novamente. Mas isso depende da necessidade do negcio em questo; Otimizao do processo de carga: todo banco de dados possui um conjunto de tcnicas para otimizar o processo de carga, tais como evitar a gerao de log durante o processo, criar ndices e agregar dados. Muitas dessas caractersticas podem ser invocadas dos bancos de dados ou registradas em scripts atravs da utilizao de ferramentas sobre a rea de organizao de dados;

19 Suporte completo ao processo de carga: o servio de carga tambm precisa suportar as exigncias antes e depois da carga atual, como eliminar e recriar ndices e particionamento fsico de tabelas e ndices.

1.3 Modelo de Dados

A elaborao do modelo de dados concentra-se na observao dos fatos relevantes que ocorrem na realidade, com a finalidade de construir um sistema que possa automatizar as necessidades de informao da mesma. Neste momento, os documentos que registram estes fatos s devem ser utilizados como apoio de entendimento, e no como base para o desenvolvimento do sistema de informaes, ou seja, no se deve ter a preocupao em simular o ambiente atual, seja ele manual ou automatizado [MACHADO, 1996].

O analista deve ter a preocupao de retratar as necessidades de informao que as pessoas (que agem sobre esta realidade) precisam para alcanar os objetivos desta mesma realidade. Ao coletar e selecionar os fatos relevantes, o analista deve identificar os elementos geradores de informao, as leis que regem esta realidade, bem como, as operaes que incidem sobre os elementos bsicos (dados).

Para registrar as necessidades de informao de uma realidade, necessrio fazer uso de um modelo, ou seja, algo que nos mostre como as informaes esto relacionadas (fatos). E, com base no modelo criado, os analistas podem interagir com os usurios validando seus objetivos e metas, permitindo a construo de um sistema de informaes, cada vez mais, prximo da realidade do usurio.

20 Como ser visto a seguir, os modelos de dados podem ser classificados segundo a arquitetura que utilizam. O modelo relacional surgiu para atender os sistemas transacionais (OLTP), j o modelo dimensional surgiu para atender os sistemas analticos (OLAP).

1.3.1 Modelo Relacional

Criado por Edgar F. Codd, nos anos 70, o Modelo Relacional, comeou a ser utilizado nas empresas a partir de 1977. A abordagem relacional est baseada no princpio de que as informaes em uma base de dados podem ser consideradas como relaes matemticas e que esto representadas de maneira uniforme, atravs do uso de tabelas bidimensionais. Este princpio coloca os dados dirigidos para estruturas mais simples de armazenar dados, que so as tabelas, e nas quais a viso do usurio privilegiada.

O modelo relacional um conjunto de dados visto segundo um conjunto de tabelas, e suas operaes sobre elas so feitas por linguagens que manipulam a lgebra relacional, no sendo procedurais, ou seja, manipulam conjuntos de uma s vez [MACHADO, 1996].

Esse modelo surgiu para atender sistemas transacionais que possuem operaes atmicas (que devem ocorrer por completo ou ento serem desfeitas) pr-definidas, geralmente, com um grande nmero de usurios simultneos realizando operaes repetidamente.

Para se compreender melhor o modelo de dados relacional, preciso o conhecimento de alguns conceitos que so definidos a seguir.

21 Chave: designa o conceito de item de busca, ou seja, um dado que ser empregado nas consultas base de dados. um conceito lgico de aplicao.

ndice: um recurso fsico visando otimizar a recuperao de uma informao, via um mtodo de acesso. Seu objetivo principal est relacionado com a performance de um sistema.

O modelo relacional deve estar preparado para ter um tempo de resposta pequeno, uma vez que, as transaes so curtas e operam sobre poucos dados. Uma tabela acessvel por qualquer campo independentemente se este declarado como chave ou no. O relacionamento entre conjunto de dados (tabelas) no existe fisicamente, pois este relacionamento apenas lgico e representado atravs das chaves estrangeiras (elos de ligao entre as tabelas). Esse modelo visa a eliminao de redundncia, deixando os dados em um nico lugar.

A base de dados de um modelo relacional reflete imediatamente as operaes realizadas, com atualizaes que so visualizadas em tempo real, no existindo um processo de carga de dados. A insero de um registro ou a atualizao de um registro j existente imediatamente vista pelos usurios do sistema e geralmente no existe a necessidade de consultas a dados histricos.

Por possuir atualizaes em tempo real com usurios simultneos, esse modelo exige controle de concorrncia, por meio de mecanismos de bloqueio, commit e rollback para evitar qualquer tipo de problema com os dados, como a perda de informaes.

22 Na criao de um modelo de dados relacional, so realizados aprimoramentos chamados de normalizao, tornando o modelo menos redundante e menos inconsistente.

Normalizao: o processo de reunir todos os dados que sero armazenados em um certo banco de dados e separ-los em tabelas. Atravs do processo de normalizao, pode-se substituir um conjunto de entidades e relacionamentos por um outro, o qual se apresenta purificado em relao s anomalias de atualizao (incluso, alterao e excluso), as quais, podem causar certos problemas, tais como: grupos repetitivos (atributos multivalorados) de dados, redundncia de dados desnecessrios, perdas acidentais de informao, dificuldade na representao de fatos da realidade [MACHADO, 1996].

Pode-se citar alguns benefcios do processo da Normalizao: estabilidade do modelo, mantendo-o inalterado face a mudanas que venham a ser percebidas ou introduzidas no ambiente que tenha sido modelado; flexibilidade, com o processo de normalizao das tabelas aumenta a capacidade de adaptao a demandas diferenciadas, a expanso e reduo, omisso ou presena (das tabelas); integridade, refere-se qualidade do dado, se um dado sobre certo objeto aparecer mapeado em mais de um local de modo diferente, pode-se ter indcios de que no h integridade entre eles; economia, com a existncia de redundncias nos dados, o custo de armazenamento, torna-se muito maior, alm de tambm aumentar o custo de manipulao dos dados.

1.3.2 Modelo Dimensional

Modelagem dimensional um nome para uma tcnica antiga que permitia tornar os bancos de dados fceis e compreensveis. Caso aps caso, a partir da dcada de 1970 as empresas de Tecnologia da Informao, as consultorias, os usurios finais e os fornecedores

23 migraram para uma estrutura dimensional simples para atender a necessidade humana fundamental de simplicidade [KIMBALL, 1998].

O modelo dimensional surgiu para atender sistemas de processamento analtico, com consultas para planejamento ttico e estratgico da empresa. Atualmente a utilizao desses sistemas pelo nvel operacional das empresas vem crescendo, auxiliando o processo de tomada de decises dirias. Normalmente, ele atende um pequeno nmero de usurios que realizam consultas planejadas (relatrios pr-definidos) e ad-hoc.

O tempo de resposta maior, devido a consultas longas que operam sobre grande volume de dados. Para melhor desempenho nas consultas, h redundncia planejada dos dados, compensando os gastos com armazenamento e atualizao das informaes. O resultado uma estrutura simples, com modelos que refletem o processo de anlise de negcios.

A base de dados no atualizada pelo usurio, portanto, no disponibiliza as alteraes realizadas entre uma atualizao e outra. As atualizaes so feitas periodicamente em batch, no havendo a necessidade de controle de concorrncia. Os usurios somente realizam consultas na base de dados, podendo extrair e formatar seus prprios relatrios, no dependendo da equipe de tecnologia para isso.

Para realizao de anlises, a base de dados planejada para armazenar muitos dados histricos, tipicamente de 12 a 60 meses.

Os sistemas analticos suportam a gesto da empresa, como planejamento de marketing (expanso de lojas, lanamento de ofertas), anlise de vendas (melhores e piores clientes / produtos / vendedores), etc.

24

Processamento Transacional: Dados normalizados Atualizao em tempo real Controle de concorrncia Dados correntes Respostas imediatas

Processamento Analtico: Dados consistentes Desempenho compatvel com o volume de dados (ou frmulas, etc) Clara representao do modelo de negcio (camada semntica) Ferramentas especiais para os usurios finais

Quadro 1: Requisitos de processamento transacional e analtico.

1.3.3 - A escolha da modelagem

O quadro 2 a seguir mostra as principais diferenas entre sistemas de processamento transacional (OLTP - On Line Transaction Processing) e sistemas de processamento analtico (OLAP - On Line Analytical Processing).

Se OLAP e OLTP so to distintos, a modelagem de dados para cada funo deve ser tambm distinta, pois OLAP e OLTP se propem a resolver problemas completamente diferentes.

um erro pensar que tcnicas de projeto que servem para sistemas convencionais sero adequadas para a construo de um data warehouse [INMON, 1999]. Os requisitos para um data warehouse podem no ser conhecidos at que ele esteja parcialmente carregado e j em uso.

O principal objetivo da modelagem relacional em um sistema OLTP eliminar ao mximo, a redundncia, de tal forma que uma transao que promova mudanas no estado do banco de dados, atue o mais pontualmente possvel. Com isso, nas metodologias de projeto

25 usuais, os dados so "fragmentados" por diversas tabelas, o que traz uma considervel complexidade formulao de uma consulta por um usurio final. Por isso, esta abordagem no parece ser a mais adequada para o projeto de um data warehouse, onde estruturas mais simples, com menor grau de normalizao devem ser buscadas [KIMBALL, 2002].

Transacional - OLTP
Usurios tpicos

Analtico - OLAP Gerentes, analistas de negcio Anlises do negcio Ad-hoc Leitura Consulta Orientado a assuntos Vrios registros por vez

Usurios em geral Operaes do dia-a-dia Pr-determinado Leitura/gravao Transao Orientado a processos Um registro por vez

Aplicao do sistema Interao do usurio Caractersticas de trabalho Unidade de trabalho Processamento Atualizao

Quadro 2: Diferenas entre OLAP e OLTP Fonte: Vaisman (1998, p. 5)

Obter respostas a questes tpicas de anlise dos negcios de uma empresa geralmente requer a visualizao dos dados segundo diferentes perspectivas. Por exemplo: uma agncia de automveis que esteja querendo melhorar o desempenho de seu negcio necessita examinar os dados sobre as vendas disponveis na empresa. Uma avaliao deste tipo requer uma viso histrica do volume de vendas sob mltiplas perspectivas: volume de vendas por modelo, volume de vendas por cor, volume de vendas por montadora, volume de vendas por perodo de tempo. Uma anlise do volume de vendas utilizando uma ou mais destas perspectivas permitiria responder questes do tipo:

Qual a tendncia, em termos de volume de vendas, para o ms de dezembro, de modelos Corsa Sedan pretos?

26 A capacidade de responder a este tipo de questo em tempo hbil o que permite aos gerentes e altos executivos das empresas formularem estratgias efetivas, identificar tendncias e melhorar sua habilidade de tomar decises de negcio. O ambiente tradicional de bancos de dados relacional certamente pode atender a este tipo de consulta. No entanto, usurios finais que necessitam de consultas deste tipo via acesso interativo aos bancos de dados se frustram devido a tempos de resposta ruins e pela falta de flexibilidade oferecida por ferramentas de consulta baseadas em SQL. Da a necessidade de utilizar abordagens especficas para atender a estas consultas.

So chamadas de dimenses as diferentes perspectivas envolvidas. Em nosso exemplo: loja, montadora, ms, essas dimenses usualmente correspondem a campos no numricos em um banco de dados. Considerando um conjunto de medidas, tal como vendas ou despesas com promoo, essas medidas correspondem geralmente a campos numricos em um banco de dados. A seguir, as agregaes dessas medidas so avaliadas segundo as diversas dimenses e armazenadas para acesso futuro. Por exemplo, calcula-se a mdia de todas as vendas por todos os meses por loja. A forma como essas agregaes so armazenadas pode ser vista em termos de dimenses e coordenadas, dando origem ao termo multidimensional.

Ao contrrio de aplicaes convencionais, como uma folha de pagamento ou inventrio, a classificao de instncias em problemas multidimensionais dependente do objetivo da anlise do usurio, no sendo consideradas propriedades prprias das entidades envolvidas. Os tipos de classificao usados fazem surgir as dimenses descritivas, segundo as quais observaes dos objetos ou eventos so observadas e medidas.

Cada eixo no espao multidimensional um campo/coluna de uma tabela relacional e cada ponto um valor correspondente interseo das colunas. Por exemplo, o valor para o

27 campo vendas, correspondente a ms igual a novembro e loja igual a Iguatemi um ponto com coordenada (novembro, Iguatemi). Nesse caso, ms e loja so duas dimenses e vendas uma medida.

Teoricamente, quaisquer dados podem ser considerados multidimensionais. Entretanto, o termo normalmente se refere a dados representando objetos ou eventos que podem ser descritos por dois ou mais de seus atributos. Estruturas relacionais podem ser usadas para a representao e o armazenamento de dados multidimensionais. Nesse caso, as abordagens encontradas incluem desde a adoo de formas especficas de modelagem (os chamados esquemas estrela e floco de neve) at mecanismos sofisticados de indexao.

Neste captulo foram tratados conceitos bsicos de data warehouse e modelo de dados, mostrando as diferenas bsicas entre o modelo relacional e o modelo dimensional, que ser tratado com maior profundidade no captulo que segue.

28

Captulo 2 - A Modelagem Dimensional

A modelagem dimensional uma metodologia que permite modelar logicamente dados para melhorar o desempenho de consultas e prover facilidade de utilizao a partir de um conjunto de eventos bsicos de medio. Os modelos dimensionais so compreensveis, previsveis, ampliveis e resistentes ao ataque especfico de grupos de usurios de negcio, por se manter fiel simplicidade, ter uma perspectiva voltada para as necessidades analticas da empresa, e especialmente ao seu formato simtrico, em que todas as dimenses normalmente so iguais pontos de entrada na tabela de fatos [KIMBALL, 2002]. Os modelos dimensionais so a base de muitos aprimoramentos de desempenho SGBD, inclusive agregaes e mtodos de indexao avanados.

2.1 Exemplo de Modelos de dados

O sistema empregado para apresentao dos exemplos de modelos de dados um sistema de vendas de uma rede de lojas de departamento. Essa rede possui diversas lojas distribudas em diferentes estados do Brasil. O sistema transacional gerencia todas as vendas efetuadas em cada uma das lojas.

O modelo relacional utilizado nesse sistema utilizado nesse sistema, ilustrado na figura 2, possui uma tabela Faturas que contm todos os dados relacionados a uma fatura, com seus itens vendidos sendo armazenados na tabela Itens_Fatura. Para gerenciar as vendas, possui tambm um cadastro de Lojas, de Clientes, de Funcionrios, de Produtos, de Categorias e de Fornecedores.

29 Cada venda ocorrida representa uma linha na tabela Faturas e n linhas na tabela Itens_Fatura, sendo que n o nmero de itens (produtos) diferentes vendidos nessa transao.

Figura 2: Modelo relacional do sistema transacional de vendas de lojas de departamento.

Para se realizar consultas analticas, o modelo relacional no oferece o desempenho adequado, pois cada informao se encontra em uma tabela diferente. A normalizao um dos princpios de tal modelo, sendo assim, o grande nmero de junes inevitvel, tornando o processamento muito lento.

Por exemplo, um analista de marketing quer saber qual o faturamento com a venda de cosmticos do fornecedor "Johnson & Johnson", em lojas da zona sul da cidade de So Paulo no perodo do dia das mes. No modelo relacional a consulta precisaria fazer a juno das tabelas Categorias, Produtos, Fornecedores, Itens_Fatura, Faturas e Lojas. Seria feita uma

30 busca por "cosmticos" na tabela Categorias, uma busca por "Johnson & Johnson" na tabela Fornecedores, e uma juno dessas tabelas com a tabela Produtos para identificar quais so os produtos dessa categoria e desse fornecedor. Na tabela Lojas seria feita uma busca por "zona sul" e cidade "So Paulo", e as datas referentes ao perodo do dia das mes teriam que ser limitadas manualmente na tabela Faturas. Com isso, possvel retornar o faturamento total da tabela Itens_Fatura.

Para realizar essa consulta no modelo relacional, foram utilizadas 6 tabelas, realizando um total de 5 junes, o que em um modelo dimensional poderia ser otimizado, como apresentado a seguir.

A figura 3 apresenta o modelo dimensional desse sistema, preparado para atender necessidades de anlises das vendas, a partir do cruzamento das informaes das lojas da rede, com os produtos vendidos, os clientes e a data da venda.

Esse modelo possui uma tabela central chamada Vendas que armazena os dados principais a serem analisados da venda, como o faturamento e o lucro. Essa tabela tem relacionamento com as demais tabelas necessrias para identificar um item de venda com base no cliente, data, loja e produto.

A tabela Clientes possui os dados necessrios para identificao do comprador, e dados importantes para filtr-los, como idade, faixa etria, renda, sexo, etc. A tabela Data armazena um registro para cada dia durante o perodo de existncia da rede de lojas de departamento, com campos para facilitar a busca por uma determinada data ou perodo, como a data no ano calendrio ou fiscal, se o dia um feriado ou no, qual a temporada de vendas dessa data (dia dos namorados, dia das mes, Natal), etc.

31

Figura 3: Modelo dimensional do sistema analtico de Vendas de Lojas de departamento.

A tabela Lojas possui os dados de identificao para cada uma das lojas, e dados para filtro, como um campo para indicar se uma loja pertence ou no a um shopping center. Por fim a tabela Produtos armazena os dados de cada um dos produtos comercializados pelas lojas da rede, sua categoria e fornecedor, e campos de caracterizao do produto, como o tipo de embalagem (garrafa, caixa, pacote) e peso.

Nesse esquema, a busca pelo faturamento dos cosmticos do fornecedor "Johnson & Johnson" vendidos na zona sul de So Paulo no perodo do dia das mes envolveria a juno

32 apenas das tabelas Vendas, Lojas, Produtos e Data. A busca por categoria e fornecedor envolveria uma nica tabela, j que todos estes dados esto armazenados na tabela Produtos. Na tabela Data seriam consultados todos os registros que tivessem o campo temporada de venda com o valor "dia das mes", deste ano calendrio. Essa uma maneira mais simples do que identificar quais foram os dias que fizeram parte desse perodo no momento da consulta, evitando possveis distores por parte dos usurios. Na tabela Lojas feita a seleo por regio "zona sul" e cidade "So Paulo", e, atravs da juno dessas trs tabelas na tabela Vendas, retornado o faturamento total.

Como o modelo relacional trabalha com normalizao, suas tabelas possuem menos registros e no tm redundncias, apresentando assim uma melhor performance nas tarefas do dia a dia, como incluses, alteraes e excluses de registros, mas ele s adequado para consultas simples de poucos registros. Para anlises mais complexas com um universo de registros maior, o modelo dimensional oferece uma melhor alternativa, economizando em junes com vrias tabelas, e armazenando dados que facilitam a anlise das informaes.

O modelo dimensional, alm de atender a consulta sobre as vendas no perodo do dia das mes com uma performance melhor, facilita outros tipos de anlise como comparaes entre os resultados das vendas do dia das mes desse ano com os resultados de anos anteriores, avaliao mdia do perfil dos compradores (faixa etria, renda mdia, etc.), etc.

2.2 Esquema Estrela

O esquema estrela uma estrutura simples, com poucas tabelas e ligaes (relacionamentos) bem definidas [POE, KLAUER, BROBST, 1998], assemelha-se ao modelo

33 de negcio, o que facilita a leitura e entendimento, no s pelos analistas, como por usurios finais no familiarizados com estruturas de banco de dados. Permite a criao de um banco de dados que facilita a execuo de consultas complexas, podendo ser realizadas de modo eficiente e intuitivo pelo usurio.

O modelo dimensional requer a utilizao de ferramentas de consultas analticas, desenvolvidas especialmente para consultar esse tipo de modelo, o que permite aos usurios a explorao de todos os dados disponveis durante a elaborao das consultas.

Figura 4: Representao da estrutura do Esquema Estrela.

34 O nome "estrela" est associado disposio das tabelas no modelo, que consiste de uma tabela central, a tabela de fatos, que se relaciona com diversas outras tabelas, as tabelas de dimenso (os conceitos de tabelas de fatos e tabelas de dimenso so apresentados em seguida). A figura 4 apresenta a estrutura geral de um esquema estrela.

O esquema estrela pode representar tanto o modelo lgico, como o modelo fsico do banco de dados. A representao mais simples de um modelo dimensional contm um esquema estrela com uma tabela de fatos relacionada com tabelas de dimenso, mas um modelo dimensional pode ter uma ou mais tabelas de fatos, relacionadas com tabelas de dimenso. Entretanto, a viso de um esquema por vez torna o modelo mais claro.

2.2.1 Tabela de Fatos

A tabela de fatos a principal tabela de um modelo dimensional, onde as medies numricas de interesse da empresa esto armazenadas [KIMBALL, 2002]. A palavra "fato" representa uma medida dos processos que estamos modelando, como quantidades, valores e indicadores. A tabela de fatos registra os fatos que sero analisados. composta por uma chave primria (formada por uma combinao nica de valores de chaves de dimenso) e pelas mtricas de interesse para o negcio.

As dimenses indicam a forma como as medidas sero vistas, os seja, so os aspectos pelos quais se pretende observar as mtricas. A interseco das chaves de dimenso define a granularidade da tabela de fatos, e importante que todas as medidas na tabela de fatos tenham a mesma granularidade.

35 A granularidade diz respeito ao nvel de detalhe ou de resumo contido nas unidades de dados existentes no data warehouse [INMON, 1997]. Quanto mais detalhe, mais baixo o nvel de granularidade. Quanto menos detalhe, mais alto o nvel de granularidade.

Os modelos dimensionais devem armazenar a informao mais detalhada no processo do negcio, preferencialmente dados que no podem ser subdivididos, como uma linha de item de uma venda, por exemplo. Por isso, normalmente uma tabela de fatos grande, com milhes de registros.

A tabela de fatos deve ser sempre preenchida com as medidas referentes ao fato. No se deve preencher uma linha da tabela fato com zeros para representar que nada aconteceu (por exemplo, que no houve vendas de um produto em determinada data), pois isso faria com que a tabela de fatos crescesse demais.

A tabela de fatos sempre esparsa, ou seja, possui um nmero relativamente pequeno de todas as combinaes possveis de valores de chaves. Por exemplo, no caso de um banco de dados de uma companhia area, a presena de todas as combinaes possveis representaria que todos os clientes voam todos os dias, e em todos os vos feitos pela companhia, o que na prtica impossvel. Por isso podemos dizer que esse banco extremamente esparso, pois uma porcentagem muito pequena de todas as combinaes possveis de clientes, nmero do vo e dia aparecero nele.

Outro ponto importante que a tabela de fatos deve representar uma unidade do processo do negcio, no devendo-se misturar assuntos diferentes numa mesma tabela de fatos.

36 Os atributos mais comuns em uma tabela de fatos so valores numricos. Estes valores so, em sua maioria, aditivos. As mtricas aditivas so as que permitem operaes como adio, subtrao e mdia de valores por todas as dimenses, em quaisquer combinaes de registros, como "total de itens vendidos" por combinao de data, produto e loja. Mtricas aditivas so importantes porque normalmente as aplicaes de data warehouse no retornam uma linha da tabela de fatos, mas sim centenas, milhares e at milhes.

Existem tambm mtricas no-aditivas e mtricas semi-aditivas. As mtricas noaditivas so valores que no podem ser manipulados livremente, como valores percentuais ou relativos. Para esses valores, os clculos devem ser realizados nos dados absolutos nos quais se baseiam. Exemplos de mtricas no-aditivas so preo de custo e preo de venda de um produto em uma venda. Por fim, as mtricas semi-aditivas so valores que no podem ser somados em todas as dimenses. Por exemplo: numa tabela com o registro dirio do saldo bancrio dos clientes de uma agncia, no faz sentido somar os saldos bancrios dirios de um cliente durante um ms, mas pode-se somar os saldos de todos os clientes de uma agncia em determinada data.

Um exemplo de uma tabela de fatos a tabela Vendas da rede de lojas de departamentos vista anteriormente, apresentada na figura 5.

Figura 5: Tabela de fatos Vendas.

37 2.2.2 Modelagem da Tabela de Fatos

Uma tcnica para modelar a tabela de fatos responder as seguintes perguntas: Que processo estamos modelando? O que usamos para medir este processo? Quais os indicadores crticos de desempenho desse processo?

Um processo uma atividade de negcio natural executada na empresa. Ouvir os usurios o meio mais eficiente de selecionar o processo de negcio. importante lembrar que no estamos nos referindo a um departamento ou funo de negcio de uma empresa quando falamos de processos de negcio. Se forem estabelecidos modelos dimensionais para cada departamento, inevitavelmente os dados sero duplicados com diferentes rtulos e terminologias [KIMBALL, 2002].

Os valores necessrios para se medir o processo podem ser encontrados prontos no sistema origem, ou ento podem ser calculados baseados em medidas do sistema origem. Os fatos tpicos so valores numricos aditivos.

Os indicadores crticos de desempenho so os indicadores em que a empresa se baseia para fazer suas anlises. A tabela de fatos deve conter fatos que permitam que esses indicadores sejam construdos.

Por exemplo: o usurio quer saber quais foram as vendas no perodo de janeiro a maro deste ano na regio sudeste e nordeste, quais os produtos mais rentveis, quem foram os maiores clientes, quais foram os melhores vendedores, onde vendi mais que o concorrente, e que produtos vendem menos que os do concorrente. Como resposta s perguntas, temos: Que processo estamos modelando? - Processo de vendas

38 O que usamos para medir este processo? - Usamos o valor das vendas e quantidade vendida Quais os indicadores crticos de desempenho desse processo? - Atingimento da cota de venda, margem de lucro, benchmark com o mercado

2.2.3 Classificao dos Fatos

Os fatos podem ser classificados em transaes individuais, em snapshots e em linhas de itens [KIMBALL et al, 1998].

As chamadas transaes individuais representam uma transao completa, normalmente, apresentam uma estrutura muito simples, possuem um campo acumulado que contm o valor total de uma transao.

Os fatos snapshots representam medidas de atividades extradas em tempo determinado, como, por exemplo, final do dia ou final do ms, com medies acumuladas durante esse perodo.

Os fatos do tipo linhas de itens so aqueles que representam exatamente uma linha de item, so armazenados no nvel mais detalhado dos fatos, como, por exemplo, itens de pedido, itens de entrega e itens de aplice de seguro.

2.2.4 Tabela de Dimenso

A tabela de dimenso contm as descries textuais do negcio, e possui as informaes necessrias para anlises ao longo de dimenses. Seus atributos so fonte das restries das consultas, agrupamento dos resultados, e cabealhos para relatrios. As

39 dimenses so os aspectos pelos quais se pretende observar as mtricas relativas ao processo que est sendo modelado.

A qualidade do banco de dados proporcional qualidade dos atributos de dimenses, portanto deve ser dedicados tempo e ateno a sua descrio, ao seu preenchimento e a garantia da qualidade dos valores em uma coluna de atributos [KIMBALL, 2002].

Cada dimenso definida com uma nica chave primria. Essa chave a base da integridade referencial no relacionamento com a tabela de fatos. Uma tabela de dimenso composta tambm de atributos, os melhores atributos so textuais e distintos, e devem consistir de palavras reais, evitando-se o uso de cdigos e abreviaes. Esses atributos descrevem as linhas na tabela de dimenso. A figura 6 mostra um exemplo de tabela de dimenso Produtos.

Figura 6: Tabela de dimenso Produtos.

A tabela de dimenso costuma ser bem menor que a tabela fato, geralmente com muito menos do que um milho de registros, no entanto comum existirem tabelas de dimenso com muitos atributos (de 50 a 100).

40 muito importante que os atributos das tabelas de dimenso sejam preenchidos com valores descritivos ao invs de cdigos sem sentido, criptografados ou abreviados [KIMBALL, 2002]. Por exemplo, em uma tabela de dimenso Alimentos, o campo perecvel deve ser preenchido com valores como perecvel ou No perecvel ao invs de usar simplesmente S e N. Em um relatrio com a listagem de milhares de produtos, um valor descritivo tem muito mais utilidade do que cdigos. Ao invs de usar uma aplicao para decodificar esses cdigos e mostrar uma descrio, melhor armazenar essas descries no banco de dados, tornando a informao disponvel ao usurio

independentemente de seu aplicativo de acesso aos dados.

2.2.5 Hierarquia de Dimenses

As hierarquias descrevem a lgica dos relacionamentos entre os dados so a base para a navegao entre os diferentes nveis de detalhe em uma estrutura multidimensional [MEYER, CANNON, 1998]. A figura 7 apresenta os nveis de agregaes, ou seja, agrupamentos que podem ser aplicados dimenso Produto. Muitas dimenses apresentam uma estrutura hierrquica ou multinvel.

Algumas estruturas hierrquicas so facilmente identificadas, como por exemplo, uma estrutura de tempo representada por horas, dias, semanas, meses, trimestres e anos ou uma estrutura geogrfica representada por cidades, municpios, estados, regies e pases [KIMBALL, 1996]. Dois tipos de hierarquia podem ser considerados para uma dimenso: explcita e implcita.

Hierarquias explcitas: As hierarquias so caracterizadas por uma seqncia de entidades interligadas, cujos relacionamentos, entre cada par de entidades na

41 seqncia, N:1. A figura 7 representa a hierarquia explcita para a dimenso Produto. Essa hierarquia constituda pelas dimenses Tipo e Categoria.

Figura 7: Hierarquia explcita de Produto.

Hierarquias implcitas: tambm conhecidas como mltiplas hierarquias, representam as hierarquias embutidas nos atributos das dimenses. Um exemplo para mltiplas dimenses representado na figura 8, com a classificao de produtos de acordo com Tipo de Armazenamento e Tipo de Embalagem. Os alimentos podem ser subcategorizados, quanto ao armazenamento refrigerado ou no refrigerado, ou quanto ao tipo de embalagem, em caixa e pacote. Do mesmo modo, os materiais de limpeza podem ser classificados, quanto sua frmula, em txica ou no txica, ou, quanto sua consistncia, em lquida, pastosa ou em p.

42

Figura 8: Hierarquia implcita para Produto.

Uma questo importante a ser abordada diz respeito influncia da hierarquia das dimenses sobre a tabela de fato. A tabela de fatos deve refletir a menor granularidade das dimenses, de modo a garantir que no sejam armazenados registros que representem totais referentes a um nvel mais alto na hierarquia de uma dimenso.

Dessa forma, se a dimenso Produto, na figura 7, apresenta a hierarquia:

Categoria / Tipo / Produto, os registros na tabela de fatos devem indicar totais no nvel de produto. Os registros que totalizem por Categoria ou Tipo no devem ser armazenados.

2.2.6 Drill-down e Roll-up

Uma caracterstica bastante interessante nas anlises dimensionais a possibilidade de detalhamento e de sintetizao das informaes, que chamamos respectivamente de drilldown e roll-up. A figura 9 apresenta um exemplo de drill-down e roll-up atravs de uma informao de data.

43

Figura 9: Exemplo de drill-down, detalhando uma informao de data e roll-up, sintetizando a informao. Drill-down no significa descer em uma hierarquia predeterminada. Significa a possibilidade de obter rapidamente cabealhos de linha de qualquer uma das dimenses associadas a uma tabela de fatos. Significa tambm a possibilidade de remover cabealhos e pesquisar em direes diferentes [KIMBALL, 1996].

Determina tambm o detalhamento de um consulta, as consultas so mais restritas se existirem mais detalhes nos critrios de seleo. O usurio pode querer comear sua anlise no nvel mais alto de agregao, e ento aprofundar a pesquisa passando pelos diferentes nveis at o nvel inferior de detalhe a fim de obter uma perspectiva diferente do que comps os valores do nvel mais alto. A acumulao e o aprofundamento de pesquisa so recursos teis do ambiente OLAP para a realizao da anlise multidimensional, porm, diferentes nveis de uma hierarquia no representam dimenses diferentes por si mesmas, desse modo, eles no so considerados requerimentos para se fornecer capacidades multidimensionais.

A figura 10 mostra o suporte OLAP ao processamento de drill-down. H dois tipos de processamento de drill-down relevantes: processamento de drill-down entre-OLAP e

44 processamento de drill-down OLAP-para-dados estruturados organizacional. O drill-down entre-OLAP usado para mostrar o relacionamento de resumo entre as diferentes instncias de dados dentro do ambiente OLAP, tambm conhecido como drill-across. Dados mais detalhados existem no nvel estruturado organizacional do data warehouse, o que d suporte a um nvel de drill-down que vai alm do projeto de cada instncia de OLAP departamental [INMON, 1999].

Figura 10: Drill-down e drill-across de OLAP. O roll-up o processo inverso do drill-down, permite que o usurio reduza o escopo da anlise. Ele sobe o nvel de detalhe, ou seja, incrementa o nvel de agregao.

2.2.7 Dimenses Descaracterizadas

As dimenses descaracterizadas, tambm conhecidas como dimenses degeneradas, so tipos de atributo normalmente empregados em tabelas de fatos onde a granularidade da tabela representa uma transao propriamente dita ou uma linha de item da transao, e pode ser usada para agrupar itens de linha em uma nica ordem.

45 A dimenso descaracterizada representa um identificador do registro. So representadas na tabela de fatos como chaves de dimenso sem que exista a tabela de dimenso. Muitas vezes dimenses descaracterizadas compem a chave primria da tabela de fatos junto com as chaves estrangeiras das outras dimenses. A figura 11 ilustra um exemplo de dimenso descaracterizada na tabela de fatos Vendas, com o atributo nmero da venda. Como as outras informaes, como Cliente e Data, j esto em outra dimenso, o nmero da venda se torna uma dimenso descaracterizada.

Figura 11: Dimenso descaracterizada cdigo da venda na tabela de fatos Vendas.

2.3 Esquema Floco de Neve

O esquema floco de neve uma variao do esquema estrela, no qual todas as tabelas de dimenso so normalizadas na terceira forma normal (3FN), ou seja, so retirados das tabelas os campos que so funcionalmente dependentes de outros campos que no so chaves. Recomenda-se utilizar o esquema floco de neve apenas quando a linha de dimenso ficar muito longa e comear a ser relevante do ponto de vista de armazenamento. A figura 12

46 representa a implementao do modelo floco de neve no modelo do sistema de vendas da loja de departamentos apresentado no tpico 2.1.

Figura 12: Modelo de Dados do sistema de vendas de lojas de departamento utilizando o esquema floco de neve. Se as tabelas de dimenso forem normalizadas podem surgir alguns problemas. A complexidade do modelo de dados aumenta e, conseqentemente, diminui a compreenso desse modelo por parte dos usurios.

A implementao do floco de neve frustra o uso de esquemas de indexao mais eficientes como o ndice de mapa de bits [KIMBALL, 2002]. Esses ndices so muito teis para indexar campos de baixa cardinalidade, agilizam muito o desempenho de uma consulta ou restrio nica coluna em questo, sendo assim ideais para tabelas desnormalizadas. Esse

47 esquema inevitavelmente interfere na possibilidade de explorao dessa tcnica de ajuste de desempenho.

O desempenho durante a fase de atualizao dos dados do data warehouse ser melhor com as tabelas normalizadas, mas isso no to importante em sistemas de apoio deciso, uma vez que esta operao feita normalmente durante a noite ou em momentos em que no estejam sendo executadas consultas por parte dos usurios. Mesmo assim, alguns projetistas utilizam o argumento de melhorar este desempenho para justificarem a necessidade de normalizar as dimenses.

J a performance das consultas realizadas pelos usurios tende a diminuir devido o aumento do nmero de junes, e essa sim pode ser crucial para o sucesso do ambiente visto que os usurios que esperam retornos cada vez mais rpidos.

Ralph Kimball [1996] aconselha os projetistas "bem-intencionados" a resistirem tentao de transformar esquemas estrela em esquemas floco de neve, devido ao impacto da complexidade deste tipo de estrutura sobre o usurio final, enquanto que o ganho em termos de espao de armazenamento seria pouco relevante.

A deciso de optar pelo esquema estrela ou pelo floco de neve deve ser tomada levando-se em considerao o volume de dados, o SGBD, as ferramentas utilizadas, etc.

Outra possibilidade mesclar o esquema estrela com o esquema floco de neve, normalizando apenas algumas dimenses. Essas dimenses normalizadas podem ou no ter um relacionamento direto com a tabela de fatos. A figura 13 mostra como ficariam relacionadas as tabelas no caso do modelo ter um relacionamento direto das dimenses normalizadas com a tabela de fato.

48

Figura 13: Modelo de dados floco de neve com as dimenses normalizadas se relacionando diretamente com a tabela de fatos. Dessa forma, pode-se economizar com espao de armazenamento e melhorar a performance em alguns tipos de consultas, do que se fosse utilizado o esquema floco de neve puro. Por exemplo, no caso de se efetuar uma anlise de vendas por categoria.

2.4 Cubo
Uma idia fundamental da modelagem dimensional que quase todos os tipos de dados de negcio podem ser representados por um tipo de cubo de dados, onde as clulas deste cubo contm valores medidos e os lados do cubo definem as dimenses dos dados. Pode-se ter mais que trs dimenses, tecnicamente chamado de hipercubo, apesar de normalmente os termos cubo e cubo de dados serem usados como sinnimos de hipercubo [KIMBALL et al, 1998].

49 Cubo a estrutura multidimensional de dados que expressa a forma na qual os tipos de informaes se relacionam entre si. formado pela tabela de fatos e pelas tabelas de dimenso que a circundam e representam possveis formas de visualizar e consultar os dados. O cubo armazena todas as informaes relacionadas a um determinado assunto, de maneira a permitir que sejam montadas vrias combinaes entre elas, resultando na extrao de vrias vises sobre o mesmo tema.

Por exemplo, voltando ao exemplo da rede de lojas de departamento, podemos considerar o total de vendas de um determinado produto em um perodo do ano (como um ms) em uma loja especfica. Ns podemos imaginar estes dados atravs de um cubo tridimensional, onde uma dimenso representa os produtos disponveis, a outra o perodo e a ltima as lojas da rede, como mostrado na figura 14:

meia blusa
produtos

30 73 55 50 20
Jan/04

80 90 13 85 74
Fev/04 perodo

27 82 80 75 79
Mar/04

56 15 95 70 74
Abr/04 01 03 02 lojas

cala lenol sapato

Figura 14: Exemplo de um cubo aplicado ao sistema de vendas de uma rede de lojas de departamento No exemplo acima, demonstramos um cubo de trs dimenses. Se acrescentarmos mais uma dimenso (cliente, por exemplo), teremos ento um hipercubo de quatro dimenses.

50 Para se visualizar a anlise multidimensional em cubo utiliza-se a tcnica de slice e dice, ou seja, fatiar e cortar o cubo separando partes de um cubo [INMOM, 1999]. O uso integrado dos conceitos slice e dice permite rotacionar os lados de um cubo de dados (dimenses) em qualquer sentido, possibilitando a combinao de quaisquer dimenses e a obteno de informaes correspondentes sobre vrios enfoques.

Entende-se que com a modelagem dimensional possvel melhorar desempenho de consultas e facilitar anlises atravs das medidas armazenadas nas tabelas fatos e das descries das dimenses. Esse captulo apresentou os conceitos e terminologias da modelagem dimensional, apresentou as tabelas de fatos e tabelas de dimenso e os esquemas estrela e floco de neve. Porm existem tcnicas para se desenvolver o modelo dimensional e melhorar seu desempenho. Essas tcnicas sero apresentadas no prximo captulo.

51

Captulo 3 - Tcnicas de Modelagem Dimensional

As tcnicas de modelagem dimensional, ou multidimensional, representam uma maneira de se desenvolver um modelo dimensional. Estas tcnicas tm o propsito de gerar um modelo dimensional que seja correto do ponto de vista do negcio e apresente um bom desempenho para a execuo de consultas. A seguir so apresentadas algumas tcnicas interessantes de implementao da modelagem dimensional.

3.1 Granularidade
A mais importante questo de projeto que o desenvolvedor do data warehouse precisa enfrentar, refere-se definio da granularidade do data warehouse, ou seja, o nvel de detalhe ou de resumo dos dados existentes no data warehouse.

Quando a granularidade de um data warehouse apropriadamente estabelecida, os demais aspectos de projeto e implementao fluem tranqilamente; quando ela no estabelecida, todos os outros aspectos se complicam [INMON, 1997].

A razo pelo qual a granularidade a principal questo de projeto consiste no fato de que ela afeta profundamente o volume de dados que residem no data warehouse e, ao mesmo tempo, afeta o tipo de consulta que pode ser atendida.

Com um nvel de granularidade mais alto o volume de dados bem menor e menos ndices sero necessrios, como a quantidade de registro geralmente bem grande, a fora de processamento necessria para acessar os dados um fator importante.

52 O problema que medida que o nvel de granularidade aumenta, o nmero de consultas que podem ser atendidas diminui, sendo que numa granularidade mnima as consultas mais detalhadas podem ser respondidas.

3.1.1 Nveis duais de granularidade

As organizaes geralmente buscam uma eficincia de armazenamento e acesso a dados, assim como querem ter a possibilidade de consultar os dados em maior detalhe. Por isso, deve-se pensar em dois, ou mais, nveis de granularidade no data warehouse, ou seja, nveis duais de granularidade.

Um ambiente com nveis duais de granularidade consiste em ter dados a respeito de um mesmo assunto em granularidades diferentes. Por exemplo, em um sistema bancrio, pode-se armazenar os lanamentos individuais em contas correntes nos ltimos 60 dias, e armazenar o histrico resumido desses lanamentos nos ltimos 5 anos, com o valor total de lanamentos sumarizados por ms. Tanto os dados resumidos, quanto os detalhados estaro disponveis para o usurio.

O ponto de partida para a definio do nvel de granularidade apropriado consiste em se fazer uma estimativa do nmero de linhas de dados que o data warehouse conter. Se para o primeiro ano ultrapassar o total de 1.000.000 de linhas, nveis duais de granularidade se faro necessrios [INMON, 1997].

Nveis duais de granularidade permitem que voc processe eficientemente a enorme quantidade de solicitaes e atenda a qualquer questo que possa ser respondida. Essa a melhor de todas as situaes e deveria ser a opo de projeto padro [INMON, 1997].

53 3.1.2 Tabelas Agregadas

Em aplicaes de anlise de dados, um dos fatores mais crticos o tempo de resposta ao usurio devido ao grande volume de dados envolvido nas consultas desse tipo de aplicao. Uma tcnica utilizada para obter ganhos significativos de performance a criao de tabelas agregadas, esse um dos principais recursos para ajuste de desempenho de data warehouses. Consiste em criar novas tabelas com os dados da tabela de fatos, mas alterando a granularidade da mesma, gerando assim tabelas bem menores, com dados sumarizados.

evidente que se o usurio quiser fazer um drill-down na informao que estiver analisando, isto , detalhar mais a informao, ele acabar tendo que usar tabelas noagregadas, arcando, portanto, com um tempo maior de resposta.

Todo data warehouse deve conter tabelas de agregao pr-calculadas e prarmazenada. Como deve ser evitada a granularidade mista na tabela de fatos, cada agregao de tabela de fatos deve ocupar sua prpria tabela de fatos fsica. A figura 15 mostra algumas agregaes que poderiam ser feitas da tabela de fatos Venda.

Figura 15: Tabela de fatos Vendas e duas tabelas agregadas originadas da agregao da tabela Vendas.

54 importante avaliar bem o ambiente para definir quais agregaes devem ser criadas. preciso considerar o modelo de dados (relacionamentos, hierarquias e cardinalidades), realizar estatsticas de consultas para descobrir quais os requisitos mais freqentes e quais consultas so mais crticas, e assim definir quais agregadas sero mais teis, mais utilizadas.

impraticvel pensar na criao de todas as combinaes de agregao em potencial. A utilizao de tabelas agregadas requer um esforo adicional de manuteno, alm de aumentar o gasto com armazenamento, por isso deve-se sempre tentar criar agregadas que correspondam a mltiplas consultas.

Outro ponto a ser considerado a distribuio estatstica dos dados, ou seja, deve ser avaliado quantas instncias exclusivas existem em cada nvel da hierarquia e qual a compactao ser obtida ao se passar para o nvel seguinte. Por exemplo, se uma tabela tiver 50 produtos, e esses fossem agrupados em 10 marcas, estaremos resumindo 5 linhas da tabela base (na mdia) para calcular a agregao de marca. Nesse caso no vale o esforo de prarmazenar a agregao fisicamente. Por outro lado, se podemos evitar a consulta de 100 linhas base acessando a agregao, isso j pode ser vantajoso.

O uso de tabelas agregadas pode ser temporrio, por exemplo, se determinadas anlises so feitas freqentemente apenas em um determinado perodo, essas tabelas podem ser criadas apenas nesse perodo, economizando com armazenamento e manuteno. Ou ainda tabelas que sero utilizadas apenas uma vez, em anlises especiais.

A utilizao dessas tabelas deve ser sempre monitorada para verificar se realmente est se obtendo vantagem com a sua existncia. O benefcio gerado pela criao de uma agregada calculado baseado na reduo do volume de dados e na freqncia de sua

55 utilizao. Deve-se sempre levar em conta a possibilidade de uma agregada ser extinta e a manuteno que isso causaria a todo o processo.

Cada nova carga de dados no data warehouse acarretar no reclculo de toda ou pelo menos parte das tabelas agregadas, para que ela contemple os novos dados includos. Existem duas formas de atualizar uma tabela agregada:

Agregao completa: consiste em recriar a tabela agregada toda vez que houver uma carga na tabela de fatos;

Agregao incremental: os dados existentes na tabela so alterados e apenas os dados novos so inseridos.

Quando a agregao no for completa, mecanismos de limpeza precisam ser desenvolvidos para que os dados mais antigos sejam excludos. O perodo de reteno de uma tabela agregada nem sempre o mesmo que o da tabela de fatos. Muitas empresas adotam um perodo maior na tabela agregada, pois os dados esto sumarizados e gastam menos com o armazenamento. Por exemplo, uma tabela de fatos tem dados com viso diria de trs meses, mas o usurio pode acessar os dados dos ltimos doze meses em uma viso mensal.

A deciso por qual tabela agregada utilizar para responder cada consulta no uma tarefa to simples, pois muitas vezes a consulta pode ser executada em mais de uma tabela agregada retornando o mesmo resultado. Em algumas ferramentas analticas, durante o desenvolvimento do projeto so definidas as possibilidades de tabelas a serem utilizadas e a prioridade de cada uma, sendo a escolha feita baseada nos campos que o usurio utilizar na a consulta. Existem tambm ferramentas que determinam automaticamente qual tabela ser utilizada na consulta, baseados no nvel de granularidade de cada uma.

56 Outra forma de implementar agregaes utilizando as vises materializadas, apresentadas a seguir.

3.2 Vises materializadas

As vises materializadas so um tipo especial de viso, que existe fisicamente dentro do banco de dados. Elas existem para melhorar o tempo de execuo de consultas.

Nos ambientes de data warehouse as vises materializadas so usadas para o prclculo e armazenamento de dados gerados, como totais e mdias. Tambm podem ser usadas para pr-calcular relacionamentos com ou sem agregaes.

O otimizador de consultas do SGBD pode utilizar a viso materializada para aumentar a performance de acesso aos dados, reconhecendo automaticamente quando uma viso materializada pode ser utilizada para determinada requisio. O otimizador transparentemente direciona a consulta para a viso materializada em vez da tabela original.

Essa caracterstica do otimizador pode trazer muitos benefcios para ambientes com grandes volumes de dados, pois sem alterar a consulta do usurio, que utiliza tabelas com grandes volumes, o otimizador interpreta consultas e obtm o mesmo resultado mais rapidamente em uma das vises materializadas presentes no ambiente [FERNANDES, 2002].

Alguns SGBDs atualizam os dados das vises materializadas imediatamente aps as alteraes serem efetivadas na tabela original, no havendo necessidade de processamentos especiais durante o processo de carga do data warehouse.

57

3.3 Tcnicas de Rastreamento de Alteraes

No projeto de modelagem do data warehouse, as dimenses so normalmente projetadas para serem independentes de tempo. Infelizmente isso no reflete o que acontece no mundo real. Apesar de no haver mudanas constantemente nas dimenses, elas no possuem um valor sempre fixo (o estado civil de um cliente pode alterar de solteiro para casado, por exemplo).

Durante a fase de projeto do data warehouse, os projetistas devem determinar quais estratgias tomar para gerenciar as alteraes nas dimenses. Esse item geralmente esquecido pelos usurios durante a preparao dos requisitos do projeto, porm melhor estar preparado para estas situaes o quanto antes para desenvolver o modelo de dados adequado a essas mudanas.

preciso analisar cada atributo das dimenses, prevendo quais atitudes tomar se (e quando) o valor deste atributo mudar no mundo real [KIMBALL, 2002], e analisar qual a melhor alternativa para o modelo.

3.3.1 Sobrescrever o valor

Com essa abordagem, o valor antigo simplesmente substitudo pelo novo valor na tabela de dimenso responsvel por guardar este dado, sem afetar a tabela de fatos. Essa a soluo de implementao mais simples e til em situaes de acertos no cadastro (correo de informaes erradas, por exemplo), ou quando no importante armazenar o valor antigo do atributo alterado. Um exemplo a alterao da categoria do endereo do cliente Jos

58 Aguiar da Rua Pedro lvares Cabral, 299 na Vila Barros para Rua XV de Novembro, 14 no Centro, ilustrado na figura 16 com alguns dos campos da tabela Clientes. cod_cliente primeiro_nome sobrenome endereco 241 Jos Aguiar bairro

Rua XV de novembro, 14 Centro

Figura 16: Alterao de dimenso sobrescrevendo o valor antigo.

Porm essa soluo no mantm o histrico das informaes, e os fatos perdem esse acompanhamento. Caso haja alguma agregao ou consulta criada baseada no antigo valor deste atributo precisar ser refeita para que esta referencie o novo valor, do contrrio ela passar a no encontrar mais registros com o valor utilizado.

3.3.2 - Adicionar uma nova linha na tabela de dimenso

Com esta abordagem, adicionado um novo registro para a dimenso que foi alterada, contendo uma nova chave e o novo valor. Por exemplo, na alterao da residncia de um cliente, seria inserido um novo registro desse cliente, com uma nova chave e o endereo alterado.

Essa alternativa permite haver quantas alteraes quantas forem necessrias na tabela de dimenso, porm pode ocorrer um crescimento muito grande dessa tabela, no sendo uma alternativa muito adequada quando se atinge o patamar de milhes de linhas de dimenso [KIMBALL, 2002].

Uma complicao dessa abordagem a necessidade de utilizao de chaves substitutas (no poderia ser usado o RG do cliente, por exemplo), j que haver dois registros referenciando o mesmo item.

59 Nas necessidades de busca de todas as Vendas para esse cliente (independente de sua alterao), bastaria restringir a consulta pelo RG do cliente, ou pelo seu nome, retornando ento todos os fatos que referenciam o item.

No processo de carga do data warehouse, todos os novos fatos que referenciem essa dimenso alterada precisam conter a chave da nova dimenso, ocasionando numa partio natural da tabela de fatos cronologicamente. Essas chaves substitutas devem estar descritas nos metadados e serem tratadas pelas aplicaes do usurio final, que devem considerar que se trata do mesmo item, que sofreu uma alterao em algum atributo.

A figura 17 ilustra a alterao do endereo de um cliente atravs da insero de um novo registro na dimenso (somente so mostrados alguns atributos da tabela).

cod_cliente primeiro_nome sobrenome endereco 241 854 Jos Jos Aguiar Aguiar Rua XV de novembro, 14

bairro Centro

Rua Pedro lvares Cabral, 299 Vila Barros

Figura 17: alterao de dimenso por insero de novo registro.

Para a deteco e manipulao das alteraes durante a carga das dimenses, interessante adicionar um campo na tabela de dimenso contendo o resultado de um algoritmo de checksum em cada registro. Quando os novos registros forem carregados, executa-se o mesmo algoritmo nestes registros, caso o resultado de ambos seja igual, significa que o registro no foi alterado e no precisa de atualizao na tabela de dimenso. Caso tenha diferena, significa que houve alterao e que preciso adicionar uma nova dimenso para este item, com nova chave.

60 3.3.3 Adicionar uma nova coluna de dimenso

Apesar de haver o particionamento do histrico com a abordagem anterior, ela no permita a associao do novo valor com o valor antigo da dimenso. Muitas vezes, porm, os usurios podem querer buscar os fatos como se a alterao no tivesse ocorrido.

Por exemplo, a pesquisa por vendas para clientes do bairro Centro s retornaria dados a partir da data em que o novo valor entrou em vigor, e o usurio pode querer saber como as vendas do dia se comportariam sob a estrutura do dia anterior, com os dados antigos.

Para resolver esse tipo de necessidade, uma soluo adicionar uma nova coluna na tabela de dimenso, contendo o valor inicial de determinado atributo, e um novo atributo com a data em que o novo valor entrou em vigor. Essa data necessria porque com essa abordagem a chave da dimenso permanece inalterada, sendo atravs da data a nica maneira de identificar a alterao.

Essa soluo mais complexa do que as duas anteriores, e torna necessria a manuteno de dois campos para um atributo: um com o valor corrente, e outro com o valor original. Essa soluo tambm no atende o objetivo de acompanhar o histrico dos dados, pois no h o armazenamento dos valores intermedirios, apenas do atual e do original.

3.3.4 Artefatos de dados

Esta tcnica usada para preservar o relacionamento dos dados quando um ou mais atributos so dinmicos por natureza [INMON, 1999]. Consiste na criao de uma tabela de dimenso adicional com os dados que so alterados com o tempo, para manter o histrico dos

61 registros. Essa nova tabela contm a chave original do produto, a data de alterao, e os demais atributos que so dinmicos.

A cada alterao na dimenso em questo, um novo registro adicionado nessa tabela de histrico, conforme mostra a figura 18. Cliente cod_cliente 241 data_status 14/05/2004 primeiro_nome Jos sobre_nome Aguiar Histrico Cliente cod_cliente 241 241 241 data_alteracao 15/02/2002 18/03/2003 14/05/2004 endereco Rua Salvador, 344 Rua Pedro lvares Cabral, 299 Rua XV de Novembro, 14 bairro Jardim Aurora Vila Barros Centro Figura 18: Rastreamento de alteraes por meio de artefatos de dados.

Essa abordagem difere da abordagem que prega a insero de um novo registro na tabela de dimenso porque alguns dados so dinmicos por natureza, enquanto outros so estticos. Capturar todos os dados de uma dimenso a cada alterao em um atributo iria gerar redundncia demais. Outra vantagem dessa abordagem a persistncia da chave original do item da dimenso.

3.4 Criao de Minidimenses

No gerenciamento de alteraes nas dimenses, encontramos alguns problemas quando uma tabela muito grande e sofre alteraes freqentemente. A utilizao da tcnica de adicionar uma nova linha na tabela de dimenso a cada alterao se torna invivel numa

62 tabela que j contm milhes de registros, e sobrescrever tais valores faria com que o histrico dessas alteraes fosse perdido. A criao de minidimenses uma tcnica que permite vencer os desafios de anlise de desempenho e controle de alteraes em tabelas de dimenso muito grandes e que mudam rapidamente.

A tcnica de criao de minidimenses consiste em dividir uma dimenso muito grande em uma dimenso separada ou em minidimenses compostas por pequenos conjuntos de atributos que esto sempre sendo mudados ou analisados [KIMBALL, 2002]. Esses atributos devem estar estruturados para conter um nmero limitado de valores.

Por exemplo, no caso da tabela de Clientes, pode-se criar uma minidimenso separada por atributos demogrficos como idade, sexo, nmero de filhos e renda familiar, partindo do princpio que essas colunas seriam muito utilizadas em anlises.

Figura 19: Minidimenso DEMOGRFICA.

Cada registro da tabela de fatos deve conter duas chaves externas relacionadas a essa dimenso, a chave da dimenso normal e a chave da minidimenso, como mostra a figura 19.

63 A presena da chave da minidimenso garante um bom desempenho em consultas por atributos demogrficos.

Quando se cria uma minidimenso, os atributos devem assumir um nmero relativamente pequeno de valores discretos, por isso, os atributos que mudam com freqncia, como idade e receita, devem ser associados em faixas de valores. A utilizao de faixas com associaes provavelmente o compromisso mais importante associado tcnica da minidimenso porque, depois que decidido sobre as associaes de valor, ser difcil o registro da tabela dimenso mudar para um conjunto diferente de associaes mais adiante. A figura 20 ilustra como ficariam as linhas de uma minidimenso de dados demogrficos.

CHAVE DE DADOS DEMOGRFICOS 1 2 3 4 5 20

ESTADO CIVIL Solteiro Casado Divorciado Solteiro Casado Solteiro

IDADE 18-22 18-22 18-22 18-22 18-22 30-35

SEXO Masculino Masculino Masculino Masculino Masculino Feminino

RENDA FAMILIAR < R$2.000,00 < R$2.000,00 < R$2.000,00 R$2.000,00- R$4.000,00 R$2.000,00- R$4.000,00 R$5.000,00- R$8.000,00

Figura 20: Exemplo de linhas de uma minidimenso de dados demogrficos.

No caso do usurio precisar acessar o valor dos dados brutos especficos, ele dever ser includo tambm na tabela de fatos alm de ser representado como uma associao de valor na minidimenso de dados demogrficos, isso atenderia o usurio em consultas especficas como essa e seria performtico em anlises mais globais.

64 Uma outra vantagem da presena da chave da minidimenso na tabela de fatos que os perfis demogrficos histricos de um cliente, por exemplo, podem ser levantados a qualquer momento consultando a tabela de fatos. A tabela de dimenso armazena apenas o valor de chave da minidimenso referente aos valores atuais, no h necessidade de armazenar os valores antigos, se isso fosse na prpria tabela de dimenso o problema de aumentar muito a tabela que j muito grande continuaria a existir.

3.5 Criao de Novas Chaves

Tambm conhecidas como chaves sem significado, chaves inteiras, chaves no naturais, as chaves substitutas so, basicamente, um valor inteiro, atribudo seqencialmente a cada registro inserido, conforme a necessidade. Por exemplo: o primeiro produto inserido na dimenso Produto teria a chave 1, o prximo teria a chave 2, e assim sucessivamente. Sua funcionalidade exclusivamente para o relacionamento das tabelas de dimenso com a tabela de fatos [KIMBALL, 2002].

Manter uma chave substituta para as dimenses em vez de utilizar as chaves naturais operacionais vantajoso porque isso livra o ambiente data warehouse de alteraes operacionais. Manter uma chave sem significado possibilita ao data warehouse ser independente de alteraes nos sistemas transacionais para manter a compatibilidade dos dados.

Um exemplo de chave substituta o atributo cod_loja na tabela de dimenso Lojas. Enquanto a chave original do sistema transacional o nmero da loja (numero_loja),

65 no ambiente data warehouse foi criada a chave substituta cod_loja para evitar o gerenciamento de alteraes na tabela de dimenso lojas, conforme ilustra a figura 21.

Figura 21: Chave substituta cdigo da loja na tabela de dimenso Lojas no lugar da chave original nmero da loja. Outra vantagem de chaves substitutas a performance. Muitas vezes as chaves operacionais so volumosos textos alfanumricos. Para manter o relacionamento com a tabela de fatos, muito espao em disco desperdiado por causa do tamanho destas chaves. No entanto, uma chave numrica de 4 bytes consegue armazenar aproximadamente 2 bilhes de valores, o suficiente para guardar todos os registros de uma tabela de dimenso.

A figura 22 representa a utilizao da chave substituta cod_produto utilizada no lugar da chave original codigo_barras na tabela de dimenso Produtos. Ao se utilizar a chave substituta (de 4 bytes) neste caso, possvel economizar cerca de 10 bytes por registro da tabela de fatos (economia de aproximadamente 1Gb a cada 1 bilho de registros).

66

Figura 22: Chave substituta cdigo do produto para economizar espao em disco da chave original cdigo de barras. Como alternativa chave inteira seqencial, pode-se usar a chave operacional do item, adicionando-se dois ou mais dgitos ao final para indicar a verso do item [INMON, 1997]. Essa alternativa no resolve o problema da performance, j que o tamanho da chave ficar ainda maior do que a chave original, porm ajuda a rastrear as modificaes geradas nos itens atravs da chave primria, gerando um controle de verso de fcil manipulao.

3.6 Tratamento de Dimenses e Fatos com Cardinalidade M:N

Segundo Kimball [KIMBALL et al, 1998], apesar de, normalmente, a cardinalidade entre as dimenses e a tabela de fatos ser 1:N (um-para-muitos), podem acontecer casos em que essa cardinalidade seja M:N (muitos-para-muitos). A identificao deste tipo de cardinalidade empregando um desenvolvimento baseado apenas em tcnicas dimensionais no uma tarefa trivial. Neste tipo de desenvolvimento as dimenses e a prpria tabela de fatos so definidas de acordo com a especificao do usurio final. Para identificar a existncia da

67 cardinalidade M:N necessria uma anlise mais minuciosa, cruzando o modelo gerado com as regras do negcio [SOARES, 1998].

Na abordagem de Kimball [KIMBALL et al, 1998], aps a definio do modelo dimensional necessria uma anlise de cada dimenso existente, verificando-se a cardinalidade de seu relacionamento com a tabela de fatos. O propsito desta anlise identificar as dimenses que apresentem um relacionamento M:N com a tabela de fatos.

Quando esse tipo de cardinalidade identificado, Kimball [KIMBALL et al, 1998] recomenda a adio de uma nova dimenso que representar uma ponte entre a dimenso original e a tabela de fatos. Essa dimenso ponte representa efetivamente a cardinalidade M:N, tendo alm de sua chave normal, uma chave que permite identificar o conjunto de informaes. Essa chave, nica para um conjunto, ser inserida na tabela de fatos. Dessa forma, ser possvel realizar as consultas pela dimenso origem, garantindo que no havero repeties na tabela de fatos. Essa nova dimenso, mais simples, deve permitir o desenvolvimento de consultas a partir dela para a tabela de fatos.

3.7 Tabela de fatos sem fatos

Uma das premissas na criao e populao da tabela de fatos a obrigatoriedade das medidas serem preenchidas. No se pode ter um registro na tabela de fatos com as medidas contendo o valor zero, pois isso iria aumentar bastante a quantidade de registros.

No data warehouse de exemplo que registra Vendas, pode haver a necessidade de saber quais produtos no tiveram nenhuma venda em determinada data, em determinada loja.

68 No se pode inserir um registro com essas trs dimenses e preencher as medidas com zeros.

Para suprir necessidades de registrar um fato onde no temos medidas (nada aconteceu), so utilizadas tabelas de fatos sem fatos. Uma tabela de fatos sem fatos consiste basicamente de uma tabela que servir de relacionamento entre todas as dimenses necessrias para atender a uma necessidade bsica, porm no contendo nenhuma medida. Seus registros apenas relacionam as dimenses relacionadas a ela. A tabela de fatos sem fatos tem como linhas todo o universo possvel de relacionamento entre as dimenses envolvidas, sem nenhum atributo de medida.

Figura 23: Tabela de fatos sem fatos Produtos a Venda.

69 No caso dos produtos que no foram vendidos, seria criada uma tabela fato sem fatos chamada Produtos a Venda. Essa tabela possui apenas os atributos para relacionamento com as tabelas de dimenso Produtos, Lojas e Data. importante notar que ela no possui relacionamento com a tabela de dimenso Clientes, e tambm no possui a dimenso descaracterizada Venda, j que a granularidade desta tabela o produto por loja por data, conforme mostra a figura 23.

Essa tabela ento preenchida com todo o universo de produtos disponveis para venda em cada loja, a cada dia, contendo os registros com esses relacionamentos. Para saber quais produtos no foram vendidos, basta consultar na tabela Produtos a Venda o universo de produtos nas datas/lojas desejadas e, aps consultar a tabela de fatos Vendas com as mesmas condies, a diferena entre os dois resultados a resposta ao problema.

Como a tabela de fatos sem fatos armazena um registro para cada associao possvel entra as dimenses, ela geralmente contm uma quantidade de registros muito grande. No necessrio existir uma relao entre a tabela de fatos sem fatos e a tabela de fatos, podendo, no nosso exemplo, a granularidade da tabela de fatos sem fatos ser produtos disponveis por semana, ao invs de usar granularidade diria. Isso reduziria a quantidade de registros da tabela, porm continuaria a atender necessidade.

Uma tabela de fatos sem fatos tambm pode ser usada como uma tabela associativa entre as dimenses, onde no necessrio armazenar nenhuma medida. O registro de eventos normalmente feito desta forma, onde no existem medidas para ser analisadas, apenas a relao entre as dimenses.

Um exemplo dessa abordagem um data warehouse de uma instituio de ensino, com a necessidade de analisar os alunos, as matrias que eles cursam, e em quais campi. Para

70 isso, pode-se criar uma tabela de fatos sem fatos Matrcula possuindo relacionamentos com as dimenses Alunos, Matrias e Campi. Essa tabela armazenaria os registros de quais alunos cursam quais matrias, e em qual campus. Apenas estas so as informaes importantes para este data warehouse, no existe nenhuma medida para ser armazenada e analisada, portanto a tabela de fatos somente teria as chaves das tabelas de dimenso.

3.8 Dados desnormalizados

Redundncia gerenciada uma caracterstica do data warehouse que ajuda no suporte ao processamento de informaes, para dar ao usurio um conjunto de dados adequados necessidade do negcio, permitindo visualizar os dados como informaes mais facilmente [INMON, 1999].

Os dados redundantes normalmente so desnormalizados armazenando-se as definies dos registros juntamente com os prprios cdigos, na mesma tabela. Dessa maneira, no so necessrias repetidas junes entre tabelas de dados (tabelas de fatos) e tabelas de referncia (tabelas de dimenso) para obter as definies descritivas dos dados, apenas a consulta a uma tabela j traz essas informaes, ao invs de cdigos confusos.

Isso permite ao usurio fazer uma consulta SQL no banco de dados qualificando sua consulta pelo cdigo (mtodo mais eficiente), e exibindo o resultado pelas suas descries (mtodo mais informativo) sem precisar juntar tabelas distintas, melhorando a performance das consultas.

71 No tabela de dimenso Produtos, esto armazenados os campos de cdigo da categoria (cod_categoria) e tambm o campo descrio da categoria (desc_categoria). Com isso, o usurio pode limitar a consulta pelo cdigo, enquanto que o resultado exibido pela descrio, sem relacionar outras tabelas, conforme exemplifica a figura 24.

Figura 24: Dados desnormalizados na tabela de dimenso Produtos.

Deve ser aplicado um controle sobre quais dimenses so boas candidatas a serem desnormalizadas na tabela de fatos. Quando o valor sempre preenchido na tabela de dimenso, e quando a tabela relacionada existe somente para descrever este dado, uma boa idia fazer a desnormalizao. Porm melhor deixar uma tabela de dimenso normalizada quando ocorrer uma das seguintes situaes:

a dimenso no preenchida constantemente, ou seja, o dado preenchido na tabela de dimenso somente em uma pequena porcentagem de registros [INMON, 1999];

a dimenso armazena dados importantes alm da descrio do campo, isto , outros dados da tabela relacionada so importantes para o esquema, alm da definio descritiva do dado [INMON, 1999];

72 quando existe uma hierarquia que pode ser usada para diferentes modos de agregao e classificao dos dados para diferentes propsitos [INMON, 1999].

3.9 Dimenses de tempo

Todo data mart geralmente uma relao de fatos baseados em um tempo, por isso recomendado a criao de uma dimenso de tempo, como a dimenso Data criada no modelo exemplo, ao invs de armazenar a data diretamente na tabela de fatos.

Uma dimenso Data explcita importante porque muitas vezes uma consulta SQL no permite um filtro de datas por dias de semana e finais de semana, ou por feriados, perodos fiscais, temporadas e eventos importantes. Com isso, uma tabela de dimenso Data permite armazenar todas as opes de filtragem desejadas e facilitar consultas e anlises de dados.

Um exemplo de tabela de dimenso Data a utilizada no exemplo do captulo 2, conforme ilustrado na figura 25.

Na tabela de dimenso Data armazenado um registro por dia, no sendo utilizada para armazenar dados de hora. Isso permite armazenar registros de um perodo de dez anos em uma tabela de dimenso Data, totalizando em apenas 3.650 registros, sendo uma tabela de dimenso relativamente pequena.

73

Figura 25: Tabela de dimenso Data se relacionando com a tabela de fatos Vendas no modelo do sistema de vendas de lojas de departamento, o que permite a visualizao dos fatos por diversos critrios diferentes de data. Nas necessidades de armazenar a hora da transao da anlise em questo, mais conveniente a criao de uma dimenso Hora do dia, separada da dimenso Data, contendo registros para cada minuto do dia, resultando em uma tabela com apenas 1.440 registros. Caso fosse armazenada a hora na dimenso Data, com granularidade de minutos, a quantidade de registros necessrios para o armazenamento de um perodo de dez anos aumentaria para 5.256.000, um valor extremamente alto e difcil de manipular [KIMBALL, 2002].

A chave primria dessa tabela pode ser um campo numrico inteiro, ao invs de um campo de data. Os campos de data baseados no SQL normalmente so armazenados em 8 bytes, enquanto um campo inteiro armazenado em apenas 4 bytes. Isso representa uma economia de 4 bytes em cada registro da tabela de fatos, onde existe uma chave estrangeira referenciando essa tabela.

74 Observe na figura 26 como ficariam preenchidos alguns atributos de uma dimenso Data, para as datas "16/02/2004" e a "21/04/2004".
DIA DIA DA SEMANA NUMRICO DA SEMANA

CHAVE DA DATA

DIA DO MS

DIA DO ANO

MS CALENDRIO

NOME DO MS

INDICADOR DE FERIADO

1 50

segunda-feira quarta-feira

2 4

16 21

47 112

2 4

fevereiro abril

no feriado feriado

Figura 26: Exemplo de linhas em uma dimenso Data, a primeira linha corresponde data "16/02/2004" e a segunda a "21/04/2004". A dimenso Data deve conter todos os atributos que podem ser utilizados para anlise e seleo dos dados. melhor armazenar todos esses atributos de tempo na tabela ao invs de usar as aplicaes de acesso para converter e classificar as datas da maneira desejada.

Na dimenso Data do exemplo, foram colocados atributos como dia da semana, dia no ms, dia no ano, ms calendrio, nome do ms, semana fiscal, indicador de feriado, etc. Mas uma dimenso Data pode conter uma infinidade de campos, todas as interpretaes de datas teis para o negcio devem ser armazenadas. Por exemplo, para determinado negcio pode ser interessante saber o nmero do dia na poca, ou seja, um nmero de dia consecutivo comeando pelo incio de alguma poca. A figura 27 mostra uma dimenso Data com mais alguns atributos que podem auxiliar nas anlises.

75

Figura 27: Dimenso Data com diversos atributos, todas as interpretaes de datas teis para o negcio devem ser armazenadas.

Entende- se que as tcnicas de modelagem dimensional so importantes para gerar um modelo correto do ponto de vista do negcio e com um bom desempenho. Neste captulo foi apresentada a importncia de adotar a granularidade adequada, alm de abordar tabelas agregadas, tcnicas de rastreamento de alteraes, minidimenses, desnormalizao, entre outras tcnicas.

76

Captulo 4 - Questes sobre acesso a dados multidimensionais

J foi apresentado como uma modelagem dimensional pode prover as informaes necessrias a processos analticos. Tambm foi visto como construir esse modelo e suas vantagens sobre o modelo relacional para este tipo de aplicaes. Porm, com este modelo, uma quantidade muito maior de informaes precisa ser armazenada e, conseqentemente, recuperadas. No tarefa simples recuperar e atualizar as informaes contidas em modelo dimensional, agregando, derivando ou simplesmente selecionando-as sem que seja necessrio um tempo de processamento elevado.

As estratgias de que este captulo trata podem ser adotadas para reduzir este tempo de processamento. Embora muitas vezes no seja possvel obter um tempo de resposta consideravelmente rpido, se comparada a operaes transacionais, a aplicao destas tcnicas pode trazer um ganho significativo neste tempo, reduzindo o custo de processamento de muitas atividades em um ambiente de processamento analtico.

4.1 Estratgias de Processamento de Consultas

Conforme foi visto, as consultas em um sistema OLAP so muito diferentes das consultas realizadas em um sistema OLTP. Enquanto um sistema OLTP desenvolvido para retornar resultados de um nmero limitado de consultas, este no o caso nos sistemas OLAP. Os modelos dimensionais tentam abranger essas novas caractersticas. Como conseqncia, fornecedores e pesquisadores comearam a pensar em maneiras de resolver consultas envolvendo agregaes, rankings, etc, em bancos de dados com muitos gigabytes de

77 dados. O uso correto de ndices uma estratgia de otimizao no processamento das consultas.

Usualmente, os bancos de dados dos sistemas OLTP e os data warehouses residem em diferentes sistemas, sendo que no existem limitaes de ndices nos data warehouses. Pode-se criar ndices em quantas colunas das tabelas forem necessrias. Em geral, os data warehouses podem ser indexados com ndices de alta seletividade.

Por exemplo, uma consulta para saber quantas vendas houve para homens de So Paulo com escolaridade universitria, num sistema OLTP, geraria problemas com ndice, j que a coluna "sexo" no poderia ser indexada, devido sua alta seletividade. Alm disso, ter ndices em muitas colunas levaria a problemas de performance durante atualizaes da tabela. Ento, uma consulta desse tipo seria otimizada, normalmente, por apenas um ndice. Em um banco de dados com bilhes de vendas para milhares de clientes, o tempo de resposta no seria aceitvel.

Na consulta do exemplo, o processador de consultas precisa selecionar dados na tabela de Clientes, que vai retornar as linhas de acordo com os atributos "estado", "sexo" e "educao", e ento fazer a juno com a tabela de Vendas.

Para esse tipo de problema, foram criadas novas tcnicas de indexao e processamento da consulta.

4.1.1 ndices bitmap

Em um ndice B-tree tradicional, os ns-folhas possuem um valor e a lista de posies das linhas que satisfazem esse valor. Em alguns casos, possvel utilizar uma

78 alternativa melhor que essa: em vez de uma lista com as posies, pode-se utilizar um vetor de bits [VAISMAN, 1998].

Um nmero associado a cada linha de uma tabela (por exemplo, Clientes). Considerando a necessidade de criar um ndice no atributo "educao", presumindo que haja 5 possveis valores para esse atributo. O ndice seria um vetor de bits de tamanha N (sento N a quantidade de registro em Clientes). Em cada posio desse vetor, o bit preenchido com 1 ou 0 caso o cliente na linha em questo possua educao universitria ou no, respectivamente. Para ter um ndice bitmap, basta criar um vetor de bits para cada valor possvel do atributo, e armazenar o vetor nos ns folhas do B-tree. Como exemplo, pode-se considerar o seguinte bitmap: 0011011001001.....1 Esse vetor afirma que os clientes nas linhas 3, 4, 6, 7, 10, 13 e N possuem educao universitria.

fcil estimar o tamanho desse tipo de ndice: considerando como exemplo a tabela Clientes com 250.000 linhas, e 5 possveis valores para o atributo "educao". Um ndice bitmap neste atributo (considerando somente os ns folhas) iria ocupar 250.000 * 5 / 8 = 0.14 mb. Um ndice B-tree tradicional, como este usado no exemplo, iria ocupar 250.000 * 4kb = 0.95 mb. Essa no uma diferena significativa na tabela de Clientes, mas em uma tabela com bilhes de linhas (como a tabela Vendas), passa a ser um ganho considervel. O espao necessrio para ndices bitmap proporcional quantidade de valores do ndice (enquanto ndices tradicionais so independentes dessa quantidade). Para sistemas de suporte a deciso, que necessitam de ndices em atributos de grande seletividade, esses ndices so os mais adequados [VAISMAN, 1998].

79 A maior vantagem dos ndices bitmap, no entanto, a alta performance alcanada no processo de consulta [VAISMAN, 1998]. Quando for necessrio realizar uma operao com AND, OR ou NOT, o sistema apenas far uma comparao de bits.

No exemplo, a seleo busca sexo = "M" e educao = "Universitrio", supondo dois vetores de bits para cada valor como:

0110010110010110 para sexo = M e 1001010110110101 para educao = Universitrio simples para um programa em qualquer linguagem, com um custo de processamento muito baixo, gerar um vetor que armazene o resultado da operao AND, comparando bit a bit: 0000010110010100 = sexo = M e educao = Universitrio

4.1.2 ndices com juno

Uma juno conhecida por ser a operao com maior custo de performance em um SGBD. Existem algumas estratgias de processamento de junes em modelos relacionais, como hash-join, sort-merge join, entre outras. Para estratgias focadas para o suporte a deciso, as principais estratgias so o uso de ndices com juno e star join [VAISMAN, 1998].

Essas estratgias tiram vantagem do esquema estrela do data warehouse, no qual a tabela de fatos est relacionada com as dimenses por chaves estrangeiras. As junes que sero requeridas pelas consultas iro usar essas chaves estrangeiras.

Considerando a seguinte consulta:

80

sum(Vendas)

( Vendas

( estado=SP ( Cliente ) ) )

possvel criar um ndice com uma juno na chave estrangeira, na tabela de Vendas, junto com o atributo "estado".

Isso parece estranho, porque o estado no pertence a "Vendas". Na verdade, criado um ndice apontando para os registros de Vendas que armazenam vendas para clientes de SP. Isso feito primeiramente com a juno das tabelas pela chave estrangeira, e ento criando um bitmap em Vendas para cada estado. A figura 28 ilustra como ficaria um ndice bitmap para o exemplo de Vendas.

Cada bitmap ter N bits, sendo N o nmero de linhas na tabela Vendas, e no caso de ter mais condies, pode-se criar um ndice com juno para cada condio. Vendas cod_venda 1 2 3 4 5 6

cod_produto 5 45 8 13 2 9 Cliente cod_cliente 1 2 3 4

cod_cliente 3 3 2 4 1 4 estado SP RJ SP PR

qtde_vendida 50 100 200 150 300 50

O ndice ficaria como no exemplo: SP 110010 RJ 001000 PR 000101 Figura 28: Exemplo de ndices com juno no data warehouse de Vendas.

81 Esse conceito pode ser generalizado, no sendo restrito a apenas um relacionamento, e tambm til quando as condies so colocadas em diferentes tabelas de dimenses. A vantagem desse tipo de ndice sua flexibilidade, facilitando a alterao ou adio de condies.

Alguns sistemas permitem o uso de ndices para junes com mais de duas tabelas. A idia a mesma do ndice explicado anteriormente, ou seja, filtrar valores da tabela de fatos. Mas, neste caso, um ndice multi-colunas criado.

Como exemplo, pode-se utilizar a tabela de fatos Vendas e as tabelas de dimenses Tempo e Cliente, e a necessidade de buscar a quantidade de vendas dos clientes de So Paulo, no ms de dezembro de 2003, com essa consulta representada abaixo:

sum(Vendas) ( Vendas ( estado=SP ( Cliente ) ) ( mes_calendario=12 ano_calendrio=2003( Data ) ) )

Para criar um ndice, preciso fazer a juno das trs tabelas e criar o ndice na forma (estado, mes_calendario), com um registro no ndice para cada par de valores da tabela Vendas.

Os sistemas que implementam esse tipo de estratgia de indexao precisam saber da existncia desses ndices ao processas as consultas, para tirar melhor proveito.

4.1.3 Junes estrela (Star Join) Star Join uma tcnica que aumenta a performance de uma juno sem criar ndices com juno, considerando-se que h um ndice em cada um dos atributos envolvidos nas restries.

82 Para a consulta de vendas de dezembro de 2003, para clientes de SP, apresentada anteriormente, o sistema iria primeiro selecionar todos os cdigos dos clientes em "SP", armazenando-os em uma tabela temporria (T1). Ento seriam selecionados todos os dias do ms de dezembro de 2003 e armazenados em outra tabela temporria (T2), e finalmente, seria feito o produto cartesiano T1 X T2 para fazer a juno com o ndice (cod_cliente, cod_data) j existente na tabela Vendas.

Um problema dessa tcnica acontece quando a tabela de fatos esparsa (o que bastante comum em grandes organizaes). Neste caso, os recursos so divididos para calcular o produto cartesiano, para formar linhas que no participaro da juno. Cabe utilizar a tcnica mais adequada em cada situao.

4.2 Operador CUBE na Agregao Relacional

Aplicaes de anlise de dados, geralmente, fazem agregao dos dados atravs de muitas dimenses. Essas aplicaes sumarizam valores dos dados, extraem informaes estatsticas e ento contrastam uma categoria com outra.

A agregao dos dados realizada atravs de funes de agregao SQL e o operador GROUP BY. Atravs destes operadores so produzidas respostas de zero-dimenso ou uma-dimenso. Para serem produzidas respostas com n-dimenses utilizado o chamado operador CUBE.

83 4.2.1 Agregao no SQL O SQL padro conta com cinco funes de agregao de valores: COUNT ( ) usado para contar a quantidade de registros em uma tabela de acordo com o critrio, o SUM ( ) que soma os valores em uma tabela de acordo com critrios, o MIN ( ) que seleciona o valor mnimo em uma tabela, o MAX ( ) que seleciona o valor mximo em uma tabela e o AVG ( ) que obtm o valor mdio em uma seleo. Alm dessas, o SQL tambm capaz de agregar valores que se repetem em uma seleo, usando o comando DISTINCT.

Por exemplo, poderamos considerar o cdigo abaixo aplicado sobre a tabela EMPREGADOS (figura 29): SELECT AVG(salario) AS media_sal FROM Empregados; Nome Paulo Mendes Antonio Gusmo Patrcia da Silva Marisa Santana depto 121 121 010 005 salario 3.000,00 5.000,00 1.500,00 8.000,00

Figura 29: Tabela Empregados.

E como resultado obteramos o seguinte (figura 30):

Media_sal 4.375,00 Figura 30: Mdia dos salrios. Da mesma forma, os outros operadores podem ser aplicados obtendo-se os resultados de acordo com cada operador utilizado. A exceo o comando DISTINCT usado na sintaxe da seguinte maneira:

84 SELECT COUNT(DISTINCT Depto) AS qtd_dep FROM Empresa; Obtendo-se o seguinte resultado (figura 31):

Qtd_dep 3 Figura 31: Quantidade de departamentos. Essas funes so extremamente teis, mas quando tratamos de consultas analticas de dados, elas no so suficientes. Existem alguns tipos de consulta muito complexas de serem implementadas com o SQL tradicional e so desses problemas que o prximo tpico trata com mais detalhes.

4.2.2 Problemas com o group by

Como vimos, o SQL possui algumas funes de agregao que, embora atendam muitas demandas, no so suficientes para atender a complexidade de um processo de consulta analtica.

Certas agregaes analticas so extremamente complexas, embora no sejam impossveis de serem construdas com o SQL tradicional. Dentre os problemas mais comuns encontrados nestes casos esto pertinentes ao uso de roll-up/drill-down [GRAY, 1995].

Roll-up e drill-down usam totais e sub-totais para relatrios. Relatrios comumente agregam dados em um nvel menos granular e ento, sucessivamente, diminuem essa granularidade at obterem um resultado mais detalhado sobre o dado. O relatrio de vendas de carro na figura 32 pode dar a idia deste problema.

85 A tabela representada na figura 32 no pode ser relacional, uma vez que possui valores nulos na chave primria. A figura 33 uma tabela relacional e mostra uma representao mais conveniente que a do exemplo anterior.

Modelo GM

Ano 1994

Cor Preto Branco Preto Branco

Vendas por Modelo, Ano e Cor 50 40 85 115

Vendas por Vendas por Modelo e Modelo Ano 90

1995

200

290

Figura 32: Tabela de Roll Up de Vendas de carro por Modelo, por Ano e por Cor.

Modelo GM GM GM GM GM GM GM

Ano 1994 1994 1994 1995 1995 1995 ALL

Cor Preto Branco ALL Preto Branco ALL ALL

Unidades 50 40 90 85 115 200 290

Figura 33: Tabela de Vendas.

Para se construir essa tabela a soluo proposta foi incluir um valor chamado ALL para denotar a agregao dos campos. Desta forma, um Roll-up pode ser calculado com este cdigo:

SELECT FROM WHERE GROUP BY

Modelo, 'ALL', 'ALL', SUM(Unidades) Vendas Modelo = 'GM' Modelo

86 UNION SELECT FROM WHERE GROUP BY UNION SELECT FROM WHERE GROUP BY Modelo, Ano, Cor, SUM,(Unidades) Vendas Modelo = 'GM' Modelo, Ano, Cor; Modelo, Ano, 'ALL', SUM(Unidades) Vendas Modelo = 'GM' Modelo, Ano

A representao da tabela de vendas (figura 33), com a unio dos GROUP BYs, resolve o problema da representao dos dados agregados em um modelo de dados relacional.

Este exemplo um roll-up de 3 dimenses. Agregaes de n-dimenses requerem tambm n-unies (Union), ou seja, quanto mais dimenses a serem agregadas, mais complexo ser o cdigo SQL para acessar os dados.

Note que a tabela de vendas (figura 33) no contempla a agregao das linhas que representam o total de vendas por ano. As linhas que no foram includas so as seguintes (figura 34): Modelo Ano GM ALL GM ALL Cor Preto Branco Unidades 135 155

Figura 34: Linhas no includas na agregao da tabela de Vendas. Para que as mesmas sejam includas na consulta, necessrio inserir ao final do cdigo utilizado na obteno da tabela de vendas da figura 34 as seguintes linhas:

87 UNION SELECT FROM WHERE GROUP BY Modelo, 'ALL', Cor, SUM (Vendas) Vendas Modelo = 'GM' Modelo, Cor;

Cross tabulation a agregao de duas ou mais dimenses. Por exemplo, na figura 35 podemos observar uma cross-tab de duas dimenses.

GM
Preto Branco Total (ALL)

1994 1995 50 40 90 85 115 200

Total (ALL) 135 155 290

Figura 35: Cross tabulation de vendas da GM.

A representao de uma cross tab equivalente a uma representao relacional, usando o valor ALL, generaliza-se uma cross tab de n-dimenses.

4.2.3 Operador CUBE

Podemos dizer que a dimenso 0 de um cubo de dados um ponto, a dimenso 1 uma linha com um ponto, a dimenso 2 uma cross tabulation, um plano, duas linhas e um ponto enquanto a dimenso 3 um cubo com trs interseces de cross tabulations de duas dimenses. A Figura 36 apresenta, dentro do exemplo que estamos utilizando, um cubo de dados [GRAY, 1995].

88
Group By (com total) Agregao Sum By Color Vermelho
Branco Azul Vermelho Branco Azul

Cross Tab
Ford GM

By Color

Por Fabricante Sum Sum

As Agregaes no Cubo de Dados

Por fabricante e ano
2001 Ford GM Vermelho 2002 2003 2004

Por fabricante

Por ano

Branco Azul

Por Cor e Ano Por fabricante e Cor Por cor Sum

Figura 36: Agregaes em um cubo de N Dimenses.

O operador Data Cube ou cubo de dados a generalizao em N-Dimenses de funes simples de agregao. Esse operador constri uma tabela contendo todos os valores agregados e o total agregado representado como uma tupla:

ALL, ALL, ALL, ..., ALL, f(*)

89 O GROUP BY tradicional pode gerar um cubo de dados de n-dimenses. Agregaes com poucas dimenses aparecem como pontos, linhas, planos, cubos ou hipercubos. Pontos em planos com mais dimenses, possuem menos valores ALL.

A sintaxe SQL usando o operador CUBE a seguinte:

GROUP BY ( { ( < nome-da-coluna><expresso>) [ AS <nome correlato> ] [<clusula>] , ...) [WITH (CUBE ROLLUP)] } A figura 37 representa o uso da sintaxe SQL abaixo: SELECT Modelo, Ano, Cor, SUM(Vendas) AS Vendas FROM TBL_VENDAS WHERE Modelo IN (Ford , GM) AND Ano BETWEEN 2002 AND 2004 GROUP BY Modelo, Ano, Cor WITH CUBE; Podemos considerar que a cardinalidade de N atributos so C1, C2..., CN, ento, a cardinalidade do cubo resultante, pode ser expressa pela projeo de (C1+1). O Valor extra em cada domnio ALL. Por exemplo, a tabela TBL_VENDAS possui 2x3x3=18, considerando 2 possveis valores para o atributo Modelo (' FORD' e' GM' ), 3 para Ano (' 2002' , ' 2003'e ' 2004' ) enquanto a tabela resultante aps a aplicao do operador CUBE, possui 3x4x4=48, incluindo o valor ALL.

90

Modelo GM GM GM GM GM GM GM GM GM FORD FORD FORD FORD FORD FORD FORD FORD FORD

TBL_VENDAS Ano Cor Vendas 2002 Vermelho 5 2003 Branco 13 2004 Azul 12 2002 Vermelho 25 2003 Branco 27 2004 Azul 32 2002 Vermelho 14 2003 Branco 17 2004 Azul 31 2002 Vermelho 52 2003 Branco 16 2004 Azul 20 2002 Vermelho 6 2003 Branco 8 2004 Azul 16 2002 Vermelho 20 2003 Branco 54 2004 Azul 9

CUBE

Modelo FORD FORD FORD FORD FORD FORD FORD FORD FORD FORD FORD FORD FORD FORD FORD FORD GM GM GM GM GM GM GM GM GM GM GM GM GM GM GM GM ALL ALL ALL ALL ALL ALL ALL ALL ALL ALL ALL ALL ALL ALL ALL ALL

TBL_Vendas CUBO Ano Cor 2002 ALL 2002 Azul 2002 Branco 2002 Vermelho 2003 ALL 2003 Azul 2003 Branco 2003 Vermelho 2004 ALL 2004 Azul 2004 Branco 2004 Vermelho ALL ALL ALL Azul ALL Branco ALL Vermelho 2002 ALL 2002 Azul 2002 Branco 2002 Vermelho 2003 ALL 2003 Azul 2003 Branco 2003 Vermelho 2004 ALL 2004 Azul 2004 Branco 2004 Vermelho ALL ALL ALL Azul ALL Branco ALL Vermelho 2002 Azul 2002 Vermelho 2002 Branco 2003 Azul 2003 Vermelho 2003 Branco 2004 Azul 2004 Vermelho 2004 Branco ALL Azul ALL Vermelho ALL Branco 2002 ALL 2003 ALL 2004 ALL ALL ALL

Venda 78 20 6 52 78 54 8 16 45 9 16 20 201 83 30 88 44 14 25 5 57 17 27 13 75 31 32 12 176 62 84 30 34 57 31 71 29 35 40 32 48 145 114 118 122 135 120 377

Figura 37: Data Cube de 3 dimenses construdo a partir da tabela tbl_vendas. Cada valor ALL representa um conjunto de todos os valores que foram agregados. Na tabela resultante os conjuntos respectivos so: Modelo.ALL = ALL (Modelo) = ('Ford','GM') Ano.ALL = ALL (Ano) = ('2002','2003','2004') Cor.ALL = ALL (Cor) = ('Vermelho','Branco','Azul')

91 O valor ALL aparece como um valor essencial na agregao usando o comando CUBE. Sem ele, seria impossvel obter super agregaes como visto na figura 37 (totais por Modelo, Ano e Cor exibidos simultaneamente, assim como totais gerais), porm, ele cria uma complexidade substancial. Ele um "no-valor" como o NULL e durante sua implementao alguns aspectos devem ser observados. Abaixo citamos alguns:

O ALL torna-se uma palavra-chave denotando um conjunto de valores.

A sintaxe ALL [NOT] ALLOWED deve ser adicionada sintaxe de definio da coluna e aos atributos da coluna no catlogo do sistema, para permitir ou no a incluso de valores ALL.

ALL, como NULL, no participa de nenhuma agregao, exceto COUNT().

Embora existam outros aspectos, estes do uma idia das particularidades ao se utilizar o valor ALL [GRAY, 1995].

Embora o SQL padro conte com diversas funes de agregao muito teis no diaa-dia de um usurio, estas no so suficientes para atender completamente a demanda de agregaes exigidas por processos analticos. Nesta demanda pode-se considerar a necessidade de se realizar Roll-Up e Drill-Down das informaes. Para que o SQL consiga agrupar as informaes para exibi-las de maneira eficiente para um processo que envolva Roll-Up/Drill-Down, complexas consultas precisam ser realizadas. O operador CUBE reduz a complexidade destas consultas, uma vez que, por si s, consegue extrair as informaes no formato adequado com as devidas agregaes.

92

4.3 Manuteno de Vises

Uma viso uma relao derivada, definida a partir das relaes bases, ou seja, relaes que esto fisicamente armazenadas. Portanto, uma viso define uma funo de um conjunto de tabelas base em uma tabela derivada, essa funo recomputada toda vez que uma viso referenciada.

As vises materializadas so um tipo especial de viso, onde os registros so armazenados fisicamente dentro do banco de dados. Nos ambientes de data warehouse elas so utilizadas para pr-clculos e armazenamento dos dados gerados, so usadas tambm para pr-calcular relacionamentos com ou sem agregaes. A utilizao dessas vises pode gerar uma melhoria significativa no tempo de execuo de consultas.

Em contrapartida, quando um dado base for atualizado, as vises materializadas derivadas desse dado tambm devem ser atualizadas. O processo de atualizar uma viso materializada em resposta a modificaes em um dado base chamado de manuteno de vises. Esse processo nem sempre envolve recalcular a viso completamente, na maioria das vezes isso seria um desperdcio de processamento, pois possvel computar nas vises apenas as modificaes ocorridas nas relaes base. Isto chamado de manuteno incremental de vises.

Existem quatro dimenses atravs das quais o problema da manuteno de vises pode ser analisado [GUPTA, 1995]:

Dimenso Informao: Refere-se quantidade de informaes que esto disponveis para manuteno de vises. Essa dimenso trata de quais dados so

93 usados para computar uma alterao em uma viso, como quais relaes base tm que ser acessadas, as restries de integridade, chaves, etc.

Dimenso Modificao: Refere-se a quais modificaes um algoritmo de manuteno de vises pode tratar. Incluso e excluso de registros nas relaes bases, alterao de registros, se so tratados diretamente ou so modelados como uma excluso seguida de uma incluso, as mudanas na definio da viso, conjuntos de alteraes, etc.

Dimenso Linguagem: Refere-se a fatores como se a viso pode ser expressa como uma consulta seleo-projeo-juno, ou em algum outro subconjunto de lgebra relacional, se utiliza SQL ou subconjunto de SQL, se pode ter duplicidades, usar agregao, recursividade, etc.

Dimenso Instncia: Refere-se possibilidade dos algoritmos de manuteno de vises trabalharem ou no sobre todas as instncias de um banco de dados e se eles trabalham ou no para todas as instncias de modificao. Sendo assim uma instncia pode ser de dois tipos: instncia de banco de dados e instncia de modificao.

A seguir so apresentados exemplos que ilustram as dimenses utilizadas para a classificao do problema da manuteno de vises.

Exemplo 1: Dimenses Informao e Modificao

Em uma empresa de desenvolvimento de sistemas, os mdulos desenvolvidos podem ser genricos, sendo, nesses casos, reaproveitados em diversos sistemas, tendo apenas

94 um custo de adaptao. Considerando a seguinte relao que trata o mdulo, custo da adaptao e o sistema em que o mdulo foi incorporado:

Sistema_modulo(modulo, custo, sistema)

E a seguinte viso que contm todos os mdulos que custaram mais do que R$ 1000:

Modulos_caros(modulo) = modulo custo>1000(Sistema_modulo)

Se for inserido um registro como (mod1, 500, CW), isso no gera nenhum impacto na viso, pois o custo menor que R$1000. Porm, se for includo o registro (mod2, 1250, WH) ser necessrio contemplar esse registro na viso, pois o custo maior que R$1000. Diferentes algoritmos de manuteno de vises podem ser designados, dependendo das informaes disponveis para determinar se o mod2 deve ser inserido na viso:

Se a viso materializada antiga estiver disponvel, basta consult-la para verificar se o mdulo mod2 j est na viso, se estiver a viso no precisa ser modificada, seno o mod2 dever ser inserido.

Se a relao base Sistema_modulo estiver disponvel, ela pode ser utilizada para verificar se existe algum registro com o mesmo mdulo, mas com o custo igual ou maior. Se for encontrado algum registro, o novo registro inserido no precisa ser contemplado na viso.

Se o mdulo for chave na relao Sistema_modulo e esse mdulo est sendo includo agora, significa que ele no pode j estar na viso, portanto deve ser inserido.

95 Outro problema da manuteno de vises responder s excluses realizadas. Supondo que o registro (mod1, 6000, IF) seja excludo. Como o custo dele maior que 1000, esse mdulo est na viso, mas no se pode simplesmente excluir o mod1 da viso, preciso saber se no existe outro registro na relao base que determine com que o mod1 continue na viso, como, por exemplo, o registro (mod1, 2000, DN). Portando, o algoritmo de manuteno no capaz de resolver o problema da excluso utilizando apenas a viso materializada, sempre sero necessrias outras informaes como os prprios dados da relao base, restries ou chaves.

Exemplo 2: Dimenses Linguagem e Instncia

O exemplo 1 considerou uma linguagem de definio de viso consistida de operaes de seleo e projeo, no exemplo 2, ser ampliada a linguagem de definio da viso com a operao juno (join). A viso definida a seguir mostra os mdulos distintos que fazem parte de sistemas em fase de homologao, definindo uma juno entre as relaes Sistema_modulo(modulo, custo, sistema) e Sistema(sistema, status):

Mod_hom (modulo) = modulo ( status=Hom(Sistemas)

Sistemas_modulo)

No caso de incluso de um registro (mod2, 250, IF), se j existir o mdulo mod2 na viso Mod_hom, essa incluso no afeta a viso, mas no caso de no existir, no possvel determinar o efeito dessa incluso utilizando apenas a viso. Na viso Modulos_Caros do exemplo 1, era possvel determinar a manuteno em resposta s incluses utilizando apenas a viso, mas quando se utilizam junes isso se torna impossvel.

96 A viso Mod_hom mantida se ela j tiver o mdulo mod2, mas no caso contrrio. Assim, a manutenibilidade de uma viso depende tambm de instncias particulares dos bancos de dados e das modificaes.

4.3.1 Informaes completas

Os casos em que os algoritmos utilizam informaes completas, so aqueles que as relaes bases e as vises materializadas esto disponveis durante o processo de manuteno. Esses casos se aplicam a maioria dos trabalhos de manuteno de vises, e o foco tem sido buscar tcnicas eficientes para manter vises expressadas em diferentes linguagens (iniciando de seleo-projeo-juno lgebra relacional, e SQL), considerando funcionalidades como agregaes, duplicidades, recursividade, e outer-join.

No que diz respeito aos casos de utilizao de informaes completas, so aplicadas a trs tipos de vises: vises no-recursivas, vises outer-join e vises recursivas.

Vises no-recursivas

Utiliza o algoritmo de contagem, o qual pode ser definido usando unio, negao e agregao. A idia bsica contar o nmero de alternativas de derivaes pra cada registro de uma viso e armazenar isso como uma informao extra na prpria viso. Dessa forma, se for excludo um registro em uma relao base, possvel verificar se ele deve ou no ser excludo da viso.

Por exemplo, considerando a seguinte viso: CREATE VIEW Visao1 as SELECT DISTINCT t1.Campo1, t2.Campo2 FROM tab_base t1, tab_base t2

97 WHERE t1.Campo2 = t1.Campo1 E os valores abaixo para a relao tab_base: Campo1 a b b a d Campo2 b c e d c

Figura 38: Valores da relao tab_base.

A viso Visao1 ficar dessa forma ao ser includo o nmero de derivaes para cada linha, nomeado de Conta: Campo1 a a Campo2 c e Conta 2 1

Figura 39: Valores da viso Visao1 com o nmero de derivaes para cada linha

Supondo a excluso do registro (a, b) da relao base, embora o registro (a, c) da viso seja derivada de (a, b), ele tem duas alternativas de derivaes, como mostra o atributo Conta, ou seja, o registro (a ,b) no o nico que gera o (a, c) na viso, portanto, no deve haver a excluso do registro na viso. A expresso abaixo aplica a diferenciao para definir a viso:

-(tab_base) = (a,b)

tab_base U tab_base

(a,b) U (a,b) (a,b) = {(a,c), (a,e)}

O algoritmo Contagem computa -(tab_base) ( + para inseres). Cada registro em associado com um valor de contagem (negativo para excluses). Nesse exemplo, ficaria

98 (a, c, -1), (a, e, -1). Combinando isso com a viso materializada Visao1 atual, o resultado seria a seguinte viso: Campo1 a Campo2 c Conta 1

Figura 40: Valores da viso materializada Visao1 aps a excluso do registro (a, b) da relao base. O algoritmo de contagem executa esse processo para cada viso materializada presente no sistema.

Vises outer-join

Para definir uma viso outer-join utilizada a seguinte sintaxe: CREATE VIEW Visao1 AS SELECT x1, x2, ..., xn FROM tab1 FULL OUTER JOIN tab2 ON g(y1, y2, ...) Onde g(y1, y2, ...) uma conjuno de predicados.

Registros podem ser inseridos ou excludos de tab1 ou tab2. Isso representado por:

+ (tab1) e

( tab1)

O outer-join pode ser reescrito como um par de outer joins pela esquerda e pela direita: s1 - SELECT x1, x2, ..., xn FROM (tab1) LEFT OUTER JOIN tab2 ON g(y1, y2, ...) s2 - SELECT x1, x2, ..., xn FROM tab1_novo RIGHT OUTER JOIN (tab2) ON g(y1, y2, ...) Obs.: tab1_novo a relao tab1 depois das alteraes.

Considerando tab1(A, B) e tab2(A, C), e as seguintes instncias:

99 A 10 20 B 15 25 A 10 30 C bb dd

Figura 41: Instncia das relaes tab1 e tab2.

O outer-join completo :

A 10 20 null

B 15 25 null

A 10 null 30

C bb Null dd

Figura 42: Valores da viso com outer-join completo Visao1.

Inserindo (40, 45) em tab1, inserido um registro (40, 45, null, null) na viso. Se for inserido um registro que j tenha um correspondente em tab2 como (30, 35), obtida a combinao (30, 35, 30, dd). Porm, o algoritmo deve excluir o registro (null, null, 30, dd) da viso. Assim como se o registro (30, 35) for excludo de tab1, deve ser adicionado na viso (null, null, 30, dd).

Em resumo, s1 computa na viso Visao1 as mudanas de tab1, e s2 faz o mesmo com as mudanas ocorridas em tab2.

Vises Recursivas

O algoritmo utilizado na manuteno dessas vises chamado de DRed Excluso (Deletion) e Rederivao (Rederivation). Como seu nome j revela, esse algoritmo formado por duas fases. A primeira exclui todos os registros afetados pela expresso da viso. No exemplo do algoritmo de contagem, seriam excludos ambos os registros, (a, c) e (a, e), no

100 importando quantas alternativas de derivao cada registro tem. Nesse caso, uma superestimao de registros derivados excludos obtida. Ento, essa superestimao aprimorada procurando as alternativas de derivao de cada registro excludo. Dessa forma, (a, c) ser reinserido na viso. A incluso executada usando a viso (uma vez atualizada parcialmente) e as relaes bases.

4.3.2 Informaes parciais

Ao contrrio da manuteno de vises que utiliza informaes completas, uma viso nem sempre exige uma manuteno quando a modificao utiliza somente informaes parciais. Assim, o algoritmo primeiro verifica se a viso deve ser atualizada, depois, caso isso seja possvel, efetivamente faz a manuteno.

Consultas independentes de alterao

Um algoritmo verifica se uma alterao na relao base afeta a viso. Se a viso no afetada pela alterao, nada feito. Se ela afetada, ento os algoritmos de manuteno so aplicados.

Vises auto-atualizveis

Uma viso chamada de auto-atualizvel, quando sua manuteno pode ser feita utilizando apenas a viso materializada e as restries de chave. Essa uma idia importante quando as vises materializadas so aplicadas em data warehouses, porque assim, no necessrio varrer os dados base para atualizar as tabelas sumarizadas.

101 Pode-se dizer que uma viso auto-atualizvel com respeito modificao tipo T em uma relao base R se a viso pode ser auto-atualizada para todas as instncias de um banco de dados em resposta a todas as modificaes de tipo T sobre a relao R.

No segundo exemplo apresentado no incio dessa seo de manuteno de viso:

Mod_hom (modulo) = modulo ( status=Hom(Sistemas)

Sistemas_modulo)

Se for excludo um registro em Sistemas_modulo, como (mod2, 250, IF), no se pode excluir o mdulo mod2 da viso sem verificar se esse mdulo foi implementado tambm em outro sistema da empresa. Sendo assim, a viso Mod_hom no auto-atualizvel com respeito a excluses em Sistemas_modulo. Assim como essa viso no auto-atualizvel com respeito a incluses em qualquer uma das duas relaes bases.

A maioria das vises seleo-projeo-juno no auto-atualizvel com respeito a incluses, mas muitas vezes so auto-atualizveis com respeito a excluses e alteraes. Por exemplo:

Uma viso seleo-projeo-juno que faz a juno de duas ou mais relaes distintas no auto-atualizvel com respeito a incluses.

Uma viso seleo-projeo-juno auto-atualizvel com respeito a excluses em tab1 se os atributos chaves de cada ocorrncia de tab1 na juno tambm esto includos na viso, ou so igualadas a uma constante na definio da viso.

Uma viso Visao1 com outer-join pela esquerda ou completo definida usando duas relaes tab1 e tab2 auto-atualizvel com respeito a todos os tipos de

102 modificaes na relao tab2, desde que as chaves de tab1 e tab2 sejam distintas e todos os atributos expostos de tab2 sejam distintos. Um atributo distinto em uma viso Visao1, se ele aparece na clusula SELECT de definio da viso. Um atributo A pertencente a uma relao tab1 exposto numa viso Visao1, se A for utilizado no predicado da definio.

Com as tcnicas apresentadas neste captulo, possvel melhorar o desempenho em tarefas que recuperam dados em um data warehouse. Seja atravs de ndices como os usados em consultas, como na manuteno correta e otimizada de vises ou ainda com a agregao relacional, um tempo e um custo razovel de processamento podem ser economizados, propiciando maior eficincia na entrega de resultados ao usurio.

103

CONCLUSO
Uma modelagem de dados eficientemente construda fundamental na construo de um data warehouse e, para permitir o acesso a informaes em grandes bases de dados. Observou-se que, o modelo relacional apresenta um timo desempenho para qualquer tipo de operao transacional (inseres, alteraes e excluses), que seu objetivo, mas no atende plenamente a demanda por informaes, j que sua performance baixa para executar consultas complexas, envolvendo perodos de tempo ou grandes quantidades de tabelas e registros.

Com o modelo multidimensional possvel obter-se um desempenho superior, no que se refere s consultas e anlise de grandes volumes de dados. Esse modelo permite, ainda, que as consultas sejam realizadas de maneira mais intuitiva e flexvel pelo usurio.

Esses resultados so obtidos, em geral, pela utilizao de esquemas do tipo estrela e floco de neve. A composio formada por uma nica tabela de fatos, onde se encontram as medidas dos valores analisados, e circundada por quantas tabelas dimenso que trazem as descries textuais do negcio (esquema estrela), fornece uma estrutura desnormalizada e mais adequada a consultas a ser definida de acordo com a rea de negcio que ir atender.

A modelagem deve permitir a obteno do mais baixo nvel de detalhe possvel sobre os dados, armazenando-se no s dados sumarizados tais quais valores mensais ou quinzenais, mas tambm informaes de cada operao de negcio. Essa capacidade de navegao para baixo (drill-down) ou para cima (roll-up), no detalhe das informaes, se d pela adoo de hierarquias nos esquemas multidimensionais, que definem os nveis navegveis que o usurio poder acessar.

104 Com essa estrutura, as consultas tendem a requerer maior tempo de processamento, uma vez que, totais precisam ser calculados sempre que um nvel de detalhe mais alto solicitado. Quando esse tipo de consulta se torna suficientemente freqente, a criao de tabelas agregadas, que contm os dados pr-calculados para alguns nveis, pode ser uma alternativa de soluo, apesar de seu custo de armazenamento.

Um problema a ser contornado no modelo dimensional o gerenciamento de alteraes de dados nas tabelas dimenso. Muitas informaes, como o estado civil ou o endereo de uma loja alternam-se com o tempo e o data warehouse deve estar preparado para controlar essas alteraes da maneira mais adequada possvel. Em alguns casos, dados podem ser simplesmente sobrescritos pelos novos, mas em geral, uma alterao como essa poderia trazer problemas com as agregaes ou consultas baseadas no valor antigo. Nesse caso, outras tcnicas podem ser utilizadas como a adio de uma nova linha na tabela dimenso, alterando as novas informaes, ou ento a criao de uma nova coluna contendo o valor inicial de determinado atributo, ou ainda o uso de artefatos de dados.

So muitas as alternativas para construo de modelos multidimensionais e, um bom modelo parece estar condicionado ao problema especfico que tratamos. Desse modo, a ausncia de receitas facilmente aplicveis e gerais torna a modelagem multidimensional uma atividade complexa, mas, da qual, em muito dependem os resultados dos data warehouses e dos sistemas de suporte a deciso.

105

GLOSSRIO
Ad-hoc So consultas com acesso casual nico e tratamento dos dados segundo parmetros nunca antes utilizados, geralmente executado de forma iterativa e heurstica. Isso tudo nada mais do que o prprio usurio gerar consultas de acordo com suas necessidades de cruzar as informaes de uma forma no vista e com mtodos que o levem a descoberta daquilo que procura. Linhas fsicas em um banco de dados, na maioria das vezes criadas pela soma de outros registros nos bancos de dados visando melhorar o desempenho de consulta. Decomposio de campos operacionais, com o nome ou o endereo em partes elementares padro. Local em que o data warehouse est organizado, armazenado e disponvel para consulta direta dos usurios, ferramenta de acesso de dados e outras aplicaes analticas. Coluna (campo) em uma tabela de dimenso Banco de dados em que os dados so apresentados em cubos de dados, em oposio a tabelas em uma plataforma de banco de dados relacional. Unidade de medida formada por 8 bits de dados. Em um banco de dados, uma chave formada por vrias colunas. Coluna em uma tabela de banco de dados relacional cujos valores so extrados de valores de uma chave primria localizada em uma outra tabela. Coluna em uma tabela de banco de dados que exclusivamente diferente de cada linha na tabela. Ordenar os dados de acordo com critrios projetados Clusula SQL que lista as tabelas necessrias para a consulta Clusula SQL que lista exclusivamente os itens no agregados na lista SELECT, ou seja, tudo o que no seja SUM, COUNT, MIN, MAX, AVG. Clusula SQL que determina a ordem das linhas do conjunto de respostas. Estrutura de dados que contm um item de dados especficos dentro de uma linha (registro). Equivalente a um campo do banco de dados. Solicitao feita pelo usurio de informaes armazenadas em um data warehouse Nome de uma estrutura dimensional em uma plataforma de banco de dados de processamento analtico on-line (OLAP) ou multidimensional, originalmente referindose ao caso simples de trs dimenses: produto, mercado e hora. Os dados mais granulares detalhados capturados por um processo corporativo. Devem ser disponibilizados na rea de apresentao dos dados para responder a consultas especficas e imprevisveis.

Agregaes Anlise rea de Apresentao de Dados Atributo Banco de dados multidimensional Byte Chave composta Chave estrangeira (FK) Chave primria (PK) Classificar Clusula FROM (SQL) Clusula GROUP BY (SQL) Clusula ORDER BY (SQL) Coluna Consulta (Query) Cubo

Dados atmicos

106
Data Staging Area rea de armazenamento e conjunto de processos que limpam, transforma, combinam, retiram duplicidades, armazenam e preparam dados de origem para serem usados no data warehouse Aglomerao das reas de staging e de apresentao do data warehouse de uma empresa, em que dados operacionais esto estruturados especificamente para consulta e desempenho de anlise e facilidade de utilizao. Aceitao de redundncia em uma tabela para que ela permanea simples e no normalizada. Esse procedimento tem por objetivo melhorar o desempenho e facilitar ainda mais a utilizao. Entidade independente em um modelo dimensional que serve como ponto de entrada ou como mecanismo para aplicar o recurso de separao e combinao (slicing and dicing) das medidas aditivas localizadas na tabela de fatos do modelo dimensional. Ato de solicitar dados com a mesma identificao de duas ou mais tabelas de fatos em um nico relatrio, quase sempre envolvendo consultas separadas que so intercaladas com uma segunda passagem atravs da correspondncia de cabealhos de linhas. Ato de adicionar um cabealho de coluna ou substituir um cabealho de linha em um relatrio para dividir as linhas pelo conjunto de respostas mais minuciosamente. Veja Sistemas de suporte tomada de decises Capacidade de acomodar exigncias de crescimento futuras Tabela de fatos que possui um nmero relativamente pequeno de todas as combinaes possveis de valores chaves. Conjunto de processos atravs dos quais os dados operacionais de origem so preparados para o data warehouse Uma ferramenta cliente que consulta, obtm ou manipula dados armazenados em um banco de dados relacional, de preferncia um modelo dimensional localizado na rea de apresentao de dados Aplicao de software normalmente residente no cliente e no servidor que ajuda nos processos de extrao/transformao da carga de dados da produo. Nvel de detalhe capturado no data warehouse Estrutura de dados associada a uma tabela que esta ordenada logicamente pelos valores de uma chave e usada para melhorar o desempenho do banco de dados e a velocidade de acesso consulta. Qualquer dado mantido para sustentar as operaes ou a utilizao de um data warehouse; funciona como uma enciclopdia para o data warehouse Metodologia que permite modelar logicamente dados para melhorar o desempenho de consultas e prover facilidade de utilizao a partir do conjunto de eventos bsicos de medio. Implementaes de processamento analtico on-line dedicadas que no dependem de bancos de dados relacionais. Tcnica de modelagem lgica que remove redundncia de dados separando os dados em muitas entidades distintas, cada uma das quais se torna uma tabela e um SGBD relacional.

Data warehouse

Desnormalizao

Dimenso

Drill across (interligao) Drill down (descer na hierarquia) DSS Escalabilidade Esparsa Extrao, Transformao e Carga (ETL) Ferramenta de acesso a dados Ferramenta de ETL Granularidade ndice

Metadados Modelagem dimensional MOLAP (OLAP Multidimensional) Normalizao

107
OLAP (Processamento analtico on-line) OLTP (Processamento de transaes on-line) Processamento analtico SGBD(Sistema Gerenciador de Banco de Dados) Sistema de origem Sistema de suporte tomada de decises (DSS, Decision Support System) Sistema operacional de registro Slice and Dice um conjunto de princpios vagamente definidos que fornecem uma estrutura dimensional de suporte tomada de decises. Descrio original de todas as atividades e sistemas associados entrada segura de dados em um banco de dados. Utilizao de dados para fins de anlise visando suportar a tomada de decises na empresa. uma aplicao de computador para armazenar, recuperar e modificar dados de uma forma altamente estruturada Sistema operacional de registro cuja funo capturar as transaes ou outras medidas de desempenho de processos de uma empresa. Nome original do processo de data warehouse.

Sistema operacional para captura de dados sobre as operaes e processos de negcio de uma empresa. Capacidade de acessar igualmente um data warehouse atravs de qualquer uma de suas dimenses. o processo de separao e combinao de dados do warehouse em combinaes aparentemente infinitas. Dimenso normalizada em que uma dimenso de tabela simples decomposta em uma estrutura de rvore com, potencialmente, muitos nveis de alinhamento Linguagem padro para acesso a bancos de dados relacionais Coleo de linhas (registros) que possuem colunas associadas (campos). Tabela em um modelo dimensional com uma chave primria composta por uma nica parte e colunas de atributos descritivos. Tabela de fatos que no possui fatos, mas captura determinados relacionamentos de muitos para muitos entre as chaves de dimenso. mais normalmente usada para representar eventos ou fornecer informaes que no aparecem nas outras tabelas de fatos. Instruo SQL que cria cpias lgicas de uma maneira que uma consulta completa possa ser usada separadamente em uma instruo SELECT.

Snowflake (Floco de neve) SQL (Structured Query Language) Tabela Tabela de dimenso Tabela de fatos sem fatos

Viso (SQL)

108

REFERNCIAS BIBLIOGRFICAS

COLOSSI, N.; MALLOY, W.; REINWALD B. Relational Extensions for OLAP. IBM Systems Journal, vol 41, n 4, 2002. FERNANDES, Lcia. Oracle 9i Para Desenvolvedores Curso Completo. Rio de Janeiro. Axcel Books do Brasil, 2002. 1614 p. GRAY, Jim; BOSWORTH, Adam; LAYMAN, Andrew; PIRAHESH, Hamid. Data Cube: A Relational Aggregation Operator Generalizing Group-By, Cross-Tab, and Sub-Totals. Technical Report MSR-TR-95-22. Redmond, WA. GUPTA, Ashish, MUMICK, Inderpal Singh. Maintenance of Materialized Views: Problems, Techniques, and Applications. San Jose, 1995. INMON, W.H. Como construir o Data Warehouse. Rio de Janeiro: Editora Campus, 1997. 388p. INMON, W.H, WELCH, J. D., GLASSEY, K. L. Gerenciando Data Warehouse. So Paulo: Makron Books, 1999. 375p. KIMBALL, Ralph. Data Warehouse Toolkit. So Paulo: Makron Books, 1996-b. 388 p. KIMBALL, Ralph, REEVES, Laura, ROSS, Margy, THORNTHWAITE, Warren. TheIData Warehouse Lifecycle Toolkit Expert Methods for Designing, Developing andIDeploying Data Warehouses. New York: John Wiley & Sons, Inc., 1998. 771 p. KIMBALL, Ralph, ROSS, Margy. The Data Warehouse Toolkit (Segunda Edio). Rio de Janeiro: Editora Campus, 2002. 494 p. MACHADO, F. N. R.; ABREU, M. P. Projeto de Banco de Dados: uma viso prtica. So Paulo: rica, 1996. MEYER, Don, CANNON, Casey. Building a Better Data Warehouse. New Jersey: Prentice-Hall PTR, 1998. 227 p. POE, Vidette, KLAUER, Patricia, BROBST, Stephen. Building a Data Warehouse for Decision Support. New Jersey. Prentice-Hall, Inc, 1998. 285 p. SOARES, Vnia Jesus de Araujo. Modelagem Incremental no Ambiente de Data Warehouse (tese de mestrado). Rio de Janeiro, 1998. VAISMAN, Alejandro A. Olap, Data Warehousing, and Materialized Views: a Survey. Buenos Aires, 1998.

109

BIBLIOGRAFIA COMPLEMENTAR
COUGO, Paulo. Modelagem Conceitual e Projeto de Banco de Dados. Rio de Janeiro: Campos, 1997. FIGUEIREDO, Adriana Maria C.M. MOLAP x ROLAP: Embate de Tecnologias para Data warehouse. Developers Magazine. Rio de Janeiro: Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, n 18 p.24. PEDERSEN, T. B., JENSEN, C. S. Multimensional Database Technology. Revista Computer, 2001. PENDSE, N. What Is OLAP? The OLAP Report, see http://www.olapreport.com/fasmi.htm. THOMSEN, E. OLAP Solutions. John Wiley&Sons, Inc., Hoboken, NJ (1997).

110

APNDICE A - OLAP (Processamento Analtico On-line)

A anlise multidimensional para OLAP surgiu aps a publicao de A Programming Language (Ken Iverson,1962). Com base nessas idias a IBM desenvolveu e implementou a primeira linguagem com anlise multidimensional, no final da dcada de 60, chamada de APL. A evoluo desta linguagem culminou na criao das ferramentas OLAP na dcada 90.

A aplicao OLAP soluciona o problema de sntese, anlise e consolidao de dados, pois o processamento analtico online dos dados. Tem capacidade de visualizao das informaes a partir de muitas perspectivas diferentes, enquanto mantm uma estrutura de dados adequada e eficiente. A visualizao realizada em dados agregados, e no em dados operacionais porque a aplicao OLAP tem por finalidade apoiar os usurios finais a tomar decises estratgicas.

medida que os usurios do data warehouse ampliam seu conhecimento das capacidades do processamento DSS (Decision Support System) e que cresce o volume de dados exponencialmente, a necessidade de tcnicas mais sofisticadas para facilitar o uso do ambiente do data warehouse tambm aumenta.

Para suprir esta demanda por um ambiente OLAP completo e eficiente, um conjunto de regras baseadas na arquitetura foram definidas por E.F.Codd, servindo de guia para fornecedores de ferramentas de anlise e outros produtos.

111

Viso conceitual multidimensional Transparncia Acessibilidade Performance de relatrio consistente Arquitetura ClienteServidor Dimensionalidade genrica

Todos os atributos necessrios para dar suporte ao processamento DSS devem ser moldados e os dados capturados para que seja possvel haver qualquer viso conceitual de dimenses. O acesso a qualquer nvel de data warehouse dever ser transparente ao usurio. O data warehouse deve permitir acessibilidade aos dados possibilitando transform-los em informao O tempo de resposta na gerao dos relatrios deve ser constante , independente de ambiente ou outras circunstncias. O data warehouse uma arquitetura e no uma tecnologia, portanto independente de plataforma. Qualquer atributo que seja necessrio a um usurio-alvo deve estar disponvel aquele usurio como uma dimenso. Assim, todas as dimenses e os atributos ou grupos de atributos que elas representam so genricos. Os nveis departamentais podem ser construdos para dar suporte a qualquer operao dimensional cruzada. (drill-across) O uso de metadados muito importante pois eles fornecem definies em um contexto de negcio para os usurios, fazendo com que todos eles tenham a mesma compreenso dos dados. O data warehouse deve permitir ao usurio a maior flexibilidade possvel na construo de relatrios. Depende de como o nvel atmico do data warehouse projetado. O data warehouse arquitetado ir suportar capacidades de pesquisas (drilldown) tanto no nvel departamental quanto individual. Atualmente os sistemas de gerenciamento de bancos de dados multidimensionais no suportam atualizao incremental de dados, por isso o banco de dados inteiro deve ser recarregado com os dados novos. Um data warehouse pode e deve suportar um nmero adequado e os tipos de matrizes a fim de satisfazer as necessidades de informao dos diferentes usurios alvo. a seleo de subconjuntos a partir do nvel atmico do data warehouse, usado para popular os nveis departamentais e individuais. A arquitetura do data warehouse suporta a localizao fsica dos dados to perto do usurio final quanto apropriado. A implementao descentralizada da arquitetura do data warehouse, especialmente nos nveis departamental e individual, um de seus recursos mais poderosos.

Operao dimensional cruzada irrestrita Manipulao de dados intuitiva Flexibilidade quanto a relatrios Dimenso e nveis de agregao ilimitados Pesquisa de detalhes (Nvel de Linha) Atualizao incremental de banco de dados Arrays mltiplos

Seleo de subconjuntos Suporte a dados locais

Quadro 1: Regras OLAP Fonte: Inmon W. H. (1999)

112

1 Origem dos dados do OLAP

A origem dos dados do OLAP o nvel de dados estruturado organizacional de um DW que j foi previamente carregado por outros processos aleatrios advindos de outros sistemas da empresa.

Informao

Estruturado individual

Menos

Detalhado

Normalizado

Histrico

Estruturado departamental

Dados

Mais

Estruturado organizacional

Figura 1: A arquitetura de Data Warehouse.

O OLAP possui um tamanho reduzido em comparao ao nvel de dados estruturado organizacional (cerca de trs vezes menor). Isso se d devido ao fato do OLAP atender determinadas reas de negcio, adequando seu contedo apenas s necessidades dos usurios que iro utiliz-lo, e/ou armazenando um perodo histrico menor dos dados. Ou seja, os dados so interpretados e agregados para atender determinadas reas de negcios (departamentos) da empresa, segmentando e preparando os dados de maneira particular para cada necessidade, como mostra a figura 1. Tal medida de extrema importncia para garantir um tempo de resposta mais rpido nas consultas.

113 Podemos dizer ento que, como o OLAP envolve um volume de dados reduzido em relao ao nvel de dados estruturado organizacional, ele mais flexvel.

2 OLAP e a carga de trabalho

Uma das vantagens mais interessantes do OLAP a redistribuio da carga de trabalho (processamento) gerados pelo acesso a dados realizado no ambiente estruturado organizacional para uma combinao de aquisio de dados do ambiente estruturado organizacional para o ambiente OLAP, e o acesso a dados realizado em ambos. A figura 2 mostra as diferenas antes e depois do ambiente OLAP ter sido criado [INMON, 1999].
consulta consulta

consulta

consulta

consulta

consulta

consulta consulta

consulta consulta consulta

consulta consulta consulta

consulta

consulta

consulta

consulta consulta

consulta

VS

Consultas muito complexas requeridas mesmo pelas mais simples solicitaes de informao. consulta

Consultas mais simples e diretas usadas com OLAP

consulta

consulta

Figura 2: OLAP desvia profundamente a carga de trabalho

114 Quando no h ambiente OLAP, todas as consultas so executadas no ambiente estruturado organizacional. Executar todas as consultas no ambiente estruturado organizacional pode no ser o problema contanto que no haja muitos dados e que no haja muito processamento ocorrendo nele.

No instante em que houver muitos dados no ambiente estruturado organizacional ou processamento demais no ambiente, uma opo para facilitar o acesso a esses dados a criao de um ambiente OLAP.

O uso deste ambiente provoca um desvio de processamento de consultas do nvel estruturado organizacional do data warehouse para o prprio OLAP, proporcionando:

Economia de processamento;

Alta flexibilidade;

Personalizao de dados necessrios por determinada rea de negcio;

Tirar vantagem de diferentes softwares para satisfazer diferentes necessidades, residindo em uma plataforma OLAP;

Permitir que partes significativas de dados sejam isoladas;

Permitir que subconjuntos de dados sejam isolados.

115

3 Necessidades do ambiente OLAP

Alguns dos fatores que aceleram a necessidade de uma ambiente OLAP para fornecer um acesso a dados mais eficiente na transformao de dados em informaes incluem:

Pr-agregao de dados para obter uma performance melhor.

Pr-categorizao de dados para uma melhor compreenso e usabilidade por parte dos usurios finais.

Padronizao de clculos, mtricas e outros dados derivados para assegurar a preciso por toda a organizao.

Um nico ponto de acesso (dados estrutural organizacional) versus muitos (dados OLAP).

Apesar das vantagens oferecidas pelo ambiente OLAP, nem sempre possvel atender s necessidades dos usurios somente com este nvel de detalhe. Algumas vezes, consultas requerem um nvel de detalhe ou tipos de dados necessrios tais, que somente no ambiente estruturado organizacional possvel obter os resultados esperados.

4 Metadados no OLAP
Devido s freqentes alteraes nas regras de negcio que servem de base para a aquisio dos dados no ambiente OLAP, torna-se imprescindvel a utilizao de metadados,

116 uma vez que, sem eles, seria impossvel reconhecer e compreender as alteraes feitas aos dados ao longo de diferentes perodos de tempo.

Os componentes dos metadados OLAP so muito similares aos encontrados no nvel estruturado organizacional, dentre eles esto:

Informao descritiva sobre o que est no ambiente OLAP (contedo, estrutura, definio etc.);

A origem dos dados (dados estruturados organizacionais ou dados externos);

O nome comercial e tcnico dos dados;

Uma descrio do resumo, subconjunto, superconjunto e/ou os processos de desnormalizao que descrevem a jornada dos dados do nvel estruturado organizacional ao ambiente OLAP;

Mtricas que descrevem quantos dados e de que tipos encontram-se em um ambiente OLAP;

Informao da programao de atualizao, descrevendo quando os dados OLAP foram inseridos;

Informao sobre modelagem, descrevendo como os dados no ambiente OLAP se relacionam ao modelo de dados corporativo e ao modelo de dados de OLAP.

H a necessidade de metadados tanto globais quanto locais no ambiente OLAP. Os metadados locais so utilizados para uma determinada rea de negcio que cada ambiente

117 OLAP atende, j os metadados globais servem para reter informaes que so aplicadas a diversos ambientes OLAP, mantendo assim uma integrao entre eles.

5 Arquiteturas OLAP
A arquitetura em que a aplicao OLAP trabalha deve ser elaborada de acordo com o mtodo de armazenamento de dados. Os principais mtodos de armazenamentos so MOLAP e ROLAP. Cada um deles deve ser utilizado quando suas particularidades melhor atenderem s necessidades da rea de negcio que far uso do OLAP.

5.1 MOLAP (Multidimensional OLAP)

MOLAP (Multidimensional On Line Analytical Processing) uma classe de sistemas que permite a execuo de anlises bastante sofisticadas usando como gerenciador de banco de dados, um banco multidimensional [FIGUEIREDO, 1998].

A tecnologia MOLAP no somente uma ferramenta de visualizao, e sim, uma tecnologia complexa de armazenamento e visualizao de dados onde devemos nos preocupar com todo o processo de engenharia de banco de dados, tamanho, estruturao, processo de carga, indexao, otimizao, etc.

No MOLAP os dados so armazenados em matrizes proprietrias concebidas especificamente para anlises dimensionais e indexados de maneira a prover um timo desempenho no acesso a qualquer elemento. Os ndices so necessrios apenas para o gerenciamento de dados esparsos e cabem na memria principal.

118 Usando indexao, antecipao da maneira como os dados so acessados e alto grau de agregao dos dados no processamento das agregaes, o MOLAP capaz de apresentar uma melhor performance em relao ao ROLAP no tempo de resposta ao usurio, uma vez que no processo de carga dos dados ele pode pr-calcular diversas informaes.

Servidores MOLAP aplicam estratgias de compresso para manipular cubos esparsos (cubos em que a maioria das clulas no tem valor), fazendo um uso eficiente do caching. Por outro lado, ele consome muito espao. Como conseqncia, o MOLAP geralmente usado em Data Marts (pequenos DW envolvendo somente um nico setor de uma organizao).

5.2 ROLAP (Relacional OLAP)

Sistemas ROLAP fornecem anlise multidimensional de dados armazenados em uma base de dados relacional. Atualmente existem duas maneiras de se fazer este trabalho:

fazer todo o processamento dos dados no servidor da base de dados, neste caso o servidor OLAP gera os comandos SQL em mltiplos passos e as tabelas temporrias necessrias para o devido processamento das consultas;

executar comandos SQL para recuperar os dados, mas

fazer todo

processamento (incluindo junes e agregaes) no servidor OLAP.

No ROLAP a sumarizao executada por uma ferramenta externa, os dados so mapeados nos registros nas tabelas do modelo estrela, agregaes so pr-calculadas nas tabelas sumrio e metadados so armazenados em tabelas relacionais (ndices).

119 No final dos anos 80 e aproximadamente incio dos anos 90, um grande nmero de produtos foi desenvolvido para explorar este mtodo de organizao de dados multidimensionais. Em 1986, Ralph Kimball, foi um dos fundadores da Red Brick Systems para desenvolver um sistema de bancos de relacional desenhado especificamente para tratar consultas em um modelo estrela. Entretanto, a linguagem SQL como implementada no incio dos anos 90 implicou em srios problemas de performance na implementao de cubos OLAP. Alguns destes problemas foram:

GROUP BY: No podem ser usados para retornar os resultados de clulas com diferentes nveis de agregao. Isto significa que muitas consultas diferentes foram necessrias para obter todos os valores solicitados.

Consultas altamente agregadas podem referenciar virtualmente todas as linhas da tabela fato de maneira que poucos valores das clulas so retornados.

Geralmente no existia memria para armazenar os resultados de grandes clculos, ou seja, para cada consulta era necessrio reiniciar o processamento. Como agregaes para vrios nveis eram calculados, as linhas da tabela de fatos eram lidas repetidamente.

SQL suportava apenas algumas funes de agregao (SUM, COUNT, AVG, MIN e MAX), entretanto alguns sistemas de bancos de dados relacionais tinham extenses com capacidades analticas adicionais.

Os catlogos de bancos de dados no continham informaes sobre os meta dados dos modelos estrela. Como resultado, modelos estrela tinham que ser descritos diversas vezes uma vez para cada aplicao ou ferramenta usada.

120 Como os metadados no faziam parte dos catlogos de bancos de dados, informaes estruturais de chaves ficavam indisponveis para os compiladores de consulta.

Em geral, a soluo encontrada para resolver os problemas de performance nos sistemas ROLAP foi manter um nmero como sumrio da tabela fato e tabelas dimenso associadas. Em tal sistema, sempre que dados na tabela fato so modificados, a tabela sumrio precisa ser ajustada. Apesar desses problemas, sistemas ROLAP foram largamente implementados. Em tempo de consultas, se a tabela sumrio no estiver disponvel com a agregao desejada, o sistema OLAP deve escolher uma tabela sumrio apropriada contendo parcialmente resultados agregados ou ento consultar a base da tabela fato [COLOSSI, 2002].

Uma vantagem na adoo de uma soluo ROLAP reside na utilizao de uma tecnologia estabelecida, de arquitetura aberta e padronizada como a relacional, beneficiando-se da diversidade de plataformas, escalabilidade e paralelismo de hardware [FIGUEIREDO, 1998].