1marilde/PosGraduacaoLatoSensu... · Web view... que consiste na aplicação de algoritmos específicos sobre uma base de dados, com o objetivo de produzir uma série particular de

DATA WAREHOUSE

Profa Marilde Terezinha Prado Santos

Universidade Federal de São CarlosDepartamento de ComputaçãoCurso de Pós-Graduação “Lato-Sensu” em Computação


Apostila originalmente organizada por:

Profa. Marina Teresa Pires Vieira Prof. Joaquim Cezar Felipe

1


1. INTRODUÇÃO.............................................................................................................................................3

2. CONCEITOS BÁSICOS...............................................................................................................................6

2.1. Data Warehouse.................................................................................................................................62.2. Data Warehousing..............................................................................................................................62.3. Aplicações sobre o DW para tomada de decisão...............................................................................82.4. Características de Data Warehouses.................................................................................................92.5. Arquitetura do Data Warehousing...................................................................................................112.6. Data Mart (DM)................................................................................................................................12

3. MODELAGEM DE DADOS PARA DW..................................................................................................14

3.1. Modelo de dados multi-dimensional.................................................................................................143.2. Consultas OLAP...............................................................................................................................183.2.1. Agregação......................................................................................................................................193.2.2. Roll-up...........................................................................................................................................203.2.2. Drill-down......................................................................................................................................203.2.4. Pivot...............................................................................................................................................213.2.5. Comparando com consultas SQL..................................................................................................22

4. PROJETO DO DATA WAREHOUSE.....................................................................................................24

4.1. Esquema Estrela...............................................................................................................................244.2. Esquema Snowflack..........................................................................................................................264.3. Constelação de Fatos........................................................................................................................284.3. Visões Materializadas.......................................................................................................................284.4. Construindo um Data Warehouse.....................................................................................................304.5. Resumindo as Funcionalidades Típicas de Data Warehouses.........................................................334.6. Considerações Finais.......................................................................................................................344.6.1. Data warehousing e Visões............................................................................................................344.6.2. Dificuldades na Implementação de Data Warehouses..................................................................35

5. SERVIDORES OLAP.................................................................................................................................37

5.1. Servidores ROLAP............................................................................................................................375.2. Servidores MOLAP...........................................................................................................................385.3. Servidores HOLAP...........................................................................................................................385.4. On-Line Analytical Mining (OLAM).................................................................................................39

APÊNDICE A..................................................................................................................................................41

ESTUDO DE CASO 1 – Criação de um Data Mart...............................................................................41

APÊNDICE B...................................................................................................................................................47

ESTUDO DE CASO 2 – Cubo Multidimensional e OLAP......................................................................47

Bibliografia.......................................................................................................................................................55

2


1. Introdução

Os recursos tecnológicos de hardware e software, oferecidos nos últimos

anos, para o armazenamento, manutenção e compartilhamento de dados têm

permitido aos usuários de banco de dados (empresas, pesquisadores e órgãos

governamentais) manter quantidades de informações cada vez maiores em suas

bases de dados. Esse grande volume de dados excede a capacidade humana de

análise e compreensão, mesmo utilizando métodos como planilhas eletrônicas e

ambientes de consulta ad hoc. Isso motivou o grande investimento em pesquisa,

que vem ocorrendo, relacionada às tecnologias envolvidas em data warehousing.

Data Warehousing e On-Line Analytical Processing (OLAP) surgiram como

elementos essenciais de apoio à decisão, atraindo atenção cada vez maior da

indústria de bancos de dados. Data Warehousing é uma coleção de tecnologias

de apoio à decisão, voltadas a capacitar o usuário a realizar tomadas de decisão

mais rápidas e precisas. O “produto” da aplicação dessas tecnologias é o Data warehouse, uma base de dados temporais, não voláteis e integrados, tipicamente

mantida separadamente da base de dados operacionais da empresa. Para

facilitar análises e visualizações complexas, os dados em um warehouse são

modelados de forma multi-dimensional, onde cada elemento de importância

relevante corresponde a uma dimensão (por exemplo, produto, tempo e região

num warehouse de vendas). Essas dimensões podem ser organizadas em

hierarquias (por exemplo, produto - tipo - categoria) a fim de permitir diferentes

níveis de agregação durante a análise.

OLAP (on-line analytical processing) é um conjunto de operações que

podem ser executadas sobre o Data Warehouse, a fim de viabilizar a extração

eficaz de informações do mesmo. Os requisitos funcionais e de desempenho

dessas operações são totalmente diferentes do processamento de transações on-

line (OLTP – on-line transaction processing) das aplicações tradicionalmente

suportadas pelas bases de dados operacionais.

3


Aplicações OLTP tipicamente automatizam tarefas de processamento de

dados tais como transações bancárias e de processamento de pedido que são

operações rotineiras de uma organização. Essas tarefas são estruturadas e

repetitivas e consistem de transações curtas, atômicas e isoladas. As transações

requerem dados detalhados, atualizados e realizam operações de leitura e escrita

envolvendo alguns (poucos) registros tipicamente acessados através de suas

chaves primárias. O tamanho das bases de dados operacionais geralmente varia

de centenas de megabytes a gigabytes. Aspectos críticos a considerar são a

consistência e recuperação da base de dados e a métrica de desempenho chave

é maximizar o throughput das transações. Consequentemente, o banco de dados

é projetado para refletir a semântica operacional de aplicações conhecidas e, em

particular, para minimizar conflitos de concorrência.

Data warehouses, em contraste, são totalmente distintos de bancos de

dados tradicionais em sua estrutura (são estruturados para suporte à decisão),

funcionamento, desempenho e propósito. Dados históricos, sumarizados e

consolidados são mais importantes do que registros individuais detalhados.

Além dos recursos para tomada de decisão oferecidos pela tecnologia

OLAP, existem também técnicas e ferramentas "inteligentes", com o objetivo de

fazer emergir, automaticamente, padrões e regras de relacionamento entre os

dados, na busca do conhecimento intrínseco aos mesmos. Essas técnicas e

ferramentas são objeto de estudo de uma linha de pesquisa que aborda o

chamado processo de extração de conhecimento de Bases de Dados (Knowledge

Discovery in Databases - KDD). Uma etapa desse processo de KDD é a de

aplicação de métodos de Data Mining, que consiste na aplicação de algoritmos

específicos sobre uma base de dados, com o objetivo de produzir uma série

particular de padrões e regras que relacionem os dados da base de dados.

Resumindo, para a obtenção de informações contidas em um warehouse

tem-se um conjunto de ferramentas de análise e exploração dos dados, utilizando

consultas em SQL , consultas OLAP e técnicas de data mining. Consultas SQL

são construídas baseadas na álgebra relacional, com algumas extensões; OLAP

fornece idiomas de consulta de nível mais alto com base no modelo de dados

4


multi-dimensional e data mining fornece operações de análise mais abstratas.

Nos próximos capítulos são tratados os principais conceitos, questões e

tecnologia envolvidos com Data Warehouse, procurando focalizar os vários

aspectos envolvidos nessa abordagem.

5


2. Conceitos Básicos

2.1. Data Warehouse

Data warehouses têm sido desenvolvidos nas organizações para resolver

necessidades particulares, com enfoques variados, não possuindo, portanto, uma

definição única para o termo. Data warehouses são projetados para suportar

extração, processamento e apresentação eficientes de informação para

propósitos analíticos e tomada de decisão.

O significado de data warehouse tem sido difundido em uma variedade de

maneiras na literatura. Inmon [1] caracterizou data warehouse (DW) como uma

coleção de dados orientada a assuntos, integrada, não volátil e variável no

tempo, que é usada para apoio a decisões gerenciais. Em comparação a bancos

de dados tradicionais, data warehouses geralmente contém quantidade muito

grande de dados vindos de diversas fontes que podem incluir bancos de dados de

diferentes modelos de dados e algumas vezes arquivos adquiridos de sistemas e

plataformas independentes.

2.2. Data Warehousing

Data Warehousing é um conceito cada vez mais poderoso de aplicação de

tecnologia de informação para resolver problemas empresariais. Compõe-se de

um conjunto de tecnologias de software e hardware voltadas a viabilizar e

otimizar a análise de dados em larga escala, gerando informações gerenciais

valiosas. Algumas das principais tecnologias utilizadas são:

Gerenciadores de bases de dados distribuídas, que suportam

processamento paralelo.

Produtos de conversão de dados operacionais.

Tecnologia cliente/servidor que permite acesso a dados distribuídos em

6


múltiplas plataformas.

Integração de ferramentas de análise e relatório em ambiente de

escritório (desktop).

Algumas aplicações usuais de Data Warehousing:

Análises de vendas e marketing.

Movimentação de inventário e acompanhamento de produção em

manufaturas.

Otimização de rotas e análise de riscos em transportes.

Análise de lucros e riscos em empreendimentos bancários.

Análise de reclamações ou detecção de fraudes em seguradoras.

Dados operacionais: são os dados originais utilizados nas transações normais

dos sistemas, ou seja, aqueles dados tipicamente armazenados, recuperados e

atualizados pelo sistema. São majoritariamente armazenados em bases de dados

relacionais, podendo, porém, ser armazenados em bases hierárquicas ou até

mesmo em arquivos simples. Algumas das características dos dados operacionais

incluem:

Freqüentemente atualizados através de transações online.

Dados não históricos (geralmente não mais que três a seis meses

anteriores).

Otimizados para processamento transacional.

Tipicamente normalizados em bases relacionais, para otimizar

atualizações, manutenção e integridade.

Dados informativos: são dados tipicamente armazenados com o objetivo de

tornar a análise mais eficaz. Essa análise pode ocorrer na forma de ambientes de

apoio à decisão, sistemas de informações executivas ou análises estatísticas

sofisticadas. Os dados informativos são criados a partir de seleções e

7


sumarizações criteriosas executadas sobre os dados operacionais.

O Data Warehouse é uma base de dados composta por dados informativos.

A criação do Data Warehouse a partir dos sistemas de dados operacionais é a

principal etapa do processo de data warehousing como um todo. A construção da

base de dados informativos é feita utilizando-se ferramentas de transformação e

propagação. Essas ferramentas não apenas movem os dados de múltiplas fontes,

mas freqüentemente manipulam os dados para um formato mais apropriado para

o warehouse. Essas alterações podem ser:

Criação de novos campos com resultados de cálculos.

Criação de novos campos com sumarizações de dados.

Desnormalização de dados com propósitos de performance.

Compatibilização de campos oriundos de diferentes bases.

2.3. Aplicações sobre o DW para tomada de decisão

Uma tendência com relação à abordagem de data warehousing é o

desenvolvimento de poderosas ferramentas de análise. Há três amplas classes de

ferramentas de análise emergentes [4]:

a) SGBDs projetados para suportar consultas complexas eficientemente.

Tais sistemas podem ser considerados como SGBDs relacionais otimizados para

aplicações de suporte à decisão.

b) sistemas que suportam uma classe de consultas que envolvem

tipicamente o operadores group-by e de agregação. Aplicações dominadas por

tais consultas são as chamadas OLAP (On-Line Analytical Processing). Esses

sistemas suportam um estilo de consulta em que os dados são melhor pensados

como um array multi-dimensional. Aplicações OLAP permitem a analistas,

gerentes e executivos realizar insights pelos dados – normalmente armazenados

em data warehouses – através de acessos rápidos, consistentes e interativos,

com uma ampla variedade de possíveis visões sobre as informações, para refletir

a real dimensão do negócio. OLAP é implementado num ambiente cliente/servidor

8


multiusuário e deve oferecer respostas rápidas a consultas, independentemente

do tamanho ou da complexidade da base de dados. OLAP ajuda o usuário a

sintetizar informações através de visualizações comparativas personalizadas,

assim como através de análises de dados históricos em diferentes modelos de

cenários.

c) ferramentas para análise exploratória de dados ou data mining, em que

o usuário procura por padrões de interesse. Por exemplo, um comerciante de

venda por catálogo pode querer analisar os registros dos clientes para identificar

clientes em potencial para uma nova promoção; essa identificação pode depender

do nível de salário, padrões de compra, áreas de interesse demonstradas, etc.

Em situações como essa, é muito difícil formular uma consulta que captura a

essência de um padrão de interesse e a quantidade de dados é muito grande

para permitir análise manual ou mesmo análise estatística tradicional.

2.4. Características de Data Warehouses

Um Data Warehouse apresenta as seguintes aspectos que os distinguem de

bancos de dados transacionais:

Possui um modelo de dados apropriado – o modelo de dados multi-

dimensional se adequa bem para OLAP e tecnologia de suporte à decisão;

É um armazém de dados integrados vindos de múltiplas fontes, processados

para armazenamento em um modelo multi-dimensional;

Tipicamente suportam séries de tempo e análise de tendências, os quais

requerem dados mais históricos do que aqueles geralmente mantidos em

bancos de dados transacionais;

São não voláteis, comparados com os bancos de dados transacionais – isto é,

9

Universidade Federal de São CarlosDepartamento de ComputaçãoCurso de Pós-Graduação “Lato-Sensu” em Computaçãoa informação no data warehouse muda muito menos freqüentemente e pode

ser considerado como não sendo de tempo-real com atualização periódica.

Atualizações no warehouse são manipuladas pelo componente de aquisição

do warehouse, que fornece todo o pré-processamento requerido.

Algumas características de data warehouses são:

Visão conceitual multi-dimensional;

Dimensionalidade genérica;

Níveis de dimensões e agregações ilimitadas;

Operações cross-dimensional irrestritas;

Manipulação de matriz esparsa dinâmica;

Arquitetura cliente-servidor;

Suporte a multi-usuário;

Manipulação de dados intuitiva;

Flexibilidade na elaboração de relatórios.

Geralmente data warehouses envolvem grandes volumes de dados (na ordem de

terabytes), o que leva a diferentes abordagens:

Data warehouses de todo o empreendimento são projetos muito

grandes requerendo investimento massivo de tempo e recursos.

Data warehouses virtuais fornecem visões de bancos de dados

operacionais que são materializadas para acesso eficiente.

Data marts são geralmente idealizados para um subconjunto da

organização, tal como um departamento, e são mais específicos.

2.5. Arquitetura do Data Warehousing

Um data warehousing pode ser descrito como uma coleção de tecnologias

10


de suporte à decisão, objetivando capacitar o trabalhador do conhecimento

(executivo, gerente, analista) a fazer decisões melhores e mais rápidas. A Figura

1 extraída de [2], apresenta uma arquitetura típica de data warehousing,

mostrando todo o processo envolvido. Essa arquitetura inclui ferramentas para:

extração de dados de múltiplas bases de dados operacionais e de fontes externas (por exemplo perfil dos clientes fornecida por consultores externos)

usando gateways ou interfaces externas padrão suportadas pelo SGBD de

suporte; limpeza dos dados para minimizar erros e preencher informações

ausentes, quando possível; transformação para reconciliar erros semânticos;

integração desses dados; carga dos dados no data warehouse, que consiste na

materialização das visões e no seu armazenamento no warehouse; e para

periodicamente executar o refresh do warehouse, para que esse reflita as

atualizações sofridas pela base operacional. Além do warehouse principal, pode

haver diversos data marts (subconjuntos específicos focados em assuntos

selecionados) departamentais. Os dados contidos no warehouse e nos data marts

são armazenados e gerenciados por um ou mais servidores de warehouse, que

oferecem visões multidimensionais dos dados para uma variedade de ferramentas

front-end: ferramentas de consulta, geradores de relatórios, ferramentas de

análises específicas e ferramentas de data mining. Finalmente, há um

repositório para armazenamento e gerenciamento de dados de log e ferramentas

para monitoramento e administração do sistema total.

11

Fontes externas

Dados operacionais

Data Marts

Data Warehouse

Servidores OLAP

Relatórios

Data Mining

Repositóriode Metadados

Monitoramento e Administração

Ferramentas

ExtraçãoTransformaçãoCargaRefresh

Análise


Figura 1. Arquitetura de Data Warehousing

As informações sobre os dados do warehouse são armazenadas no

catálogo do sistema e é freqüentemente armazenado e gerenciado em um banco

de dados separado chamado repositório de metadados. O tamanho e

complexidade do catálogo é em parte devido ao tamanho e complexidade do

warehouse em si e em parte porque uma grande porção de informação

administrativa deve ser mantida. Por exemplo, precisamos ser informados sobre a

fonte de cada tabela do warehouse e quando ela sofreu o último refresh, além da

descrição de seus campos.

2.6. Data Mart (DM)

É um data warehouse de pequena capacidade usado para atender a uma

unidade específica de negócios. Data Marts não são diferenciados dos DWs com

base no tamanho, mas no uso e gerenciamento. Entretanto, DMs são menores e

menos complexos do que DWs e portanto são tipicamente mais fáceis de

construir e manter.

Em média, um DM pode ser construído num período de 3 a 6 meses,

enquanto um DW leva de 2 a 3 anos para ser concluído.

Os motivos que levam ao desenvolvimento de um Data Mart podem ser:

servir como projeto piloto, atender necessidades imediatas de uma unidade,

atender a restrições de custo, tempo, etc., entre outros.

12


3. Modelagem de Dados para DW

3.1. Modelo de dados multi-dimensional

A fim de facilitar análises e visualizações complexas, os dados em um

warehouse são tipicamente modelados num formato multi-dimensional. Por

exemplo, num data warehouse de vendas, a época da venda, o local geográfico, o

cliente e o produto podem ser algumas das dimensões de interesse.

Freqüentemente essas dimensões são hierárquicas: a época da venda pode ser

organizada numa hierarquia dia – mês – trimestre – ano, e produto pode ser

organizado numa hierarquia produto – tipo – categoria.

A maioria das pessoas, intuitivamente, pensa no modelo como um cubo de

dados (matrizes multidimensionais), como mostrado na Figura 2, onde cada

aresta representa uma das dimensões com seus diferentes valores distribuídos ao

longo da mesma. Os pontos internos ao cubo representam os valores de medida

do negócio – no nosso exemplo, os valores de vendas.

Figura 2. Cubo de dados de vendas

A figura 3 mostra uma matriz bi-dimensional, apresentando os produtos

como linhas, com rendimento de venda para cada local compreendendo as

colunas. Essa matriz pode estar representando o rendimento das vendas por

13

Produto

Tempo

Local


local e por produto para um particular período de tempo.

LOC1 LOC2 LOC3 . . .P1P2P3P4...

Figura 3. Matriz bi-dimensional

A adição de uma dimensão tempo, produz uma matriz tri-dimensional que

pode ser representada usando o cubo de dados. A figura 4 mostra um cubo que

organiza dados de venda de produto por data e regiões de venda. Cada célula

representa a venda de um produto específico, em um período de tempo

específico (ano, trimestre, mês,...) em um local específico. Adicionando outras

dimensões, teremos um hipercubo.

Os dados podem ser consultados diretamente em qualquer combinação de

14

LOCAL

PRODUTO

Local (codLocal)

. . .

.

Reg3Reg2Reg1

P3

Tempo (codTempo)

t4

t3 t2

t1

P1

P2

...

Produto(codProd)

Figura 4. Cubo de dados de vendas


dimensões, permitindo que consultas complexas no banco de dados original

sejam realizadas de forma mais direta e com maior desempenho. Existem

ferramentas que permitem a visualização dos dados de acordo com a escolha de

dimensões do usuário.

Num ambiente relacional os dados da matriz multi-dimensional podem ser

representados como uma relação, como ilustrado na figura 5. Nessa relação as

tuplas estão agrupadas de acordo com as fatias (slices) verticais, paralelas com

relação ao eixo do tempo. Essa relação que associa as dimensões à medida de

interesse é chamada tabela fato. Note na figura 5 que somente constam da

tabela as composições produto-local-tempo que possuem valor de vendas. Cada

dimensão pode ter um conjunto de atributos associados. Por exemplo, a

dimensão Local é identificada pelo atributo codlocal, que foi usado para identificar

um local na tabela Vendas. A dimensão Local pode ter os atributos adicionais

Cidade, Estado e País. A dimensão Produto pode conter os atributos codProd,

Descrição, Marca, Categoria, Estilo, Preço. A Categoria de um produto indica sua

natureza geral; por exemplo, um produto camisa pode pertencer à categoria

roupa. O Estilo pode ser social, esporte, passeio, etc. A dimensão Tempo pode ter

os atributos Data, Semana, Mês, Trimestre, Ano, além do identificador

codTempo.

codProd codLocal codTempo vendasP1 loc1 t1 1000P1 loc2 t1 880P1 loc3 t1 1025P2 loc1 t1 775P2 loc2 t1 1002P3 loc1 t1 888P3 loc4 t1 989P4 loc2 t1 1550P4 loc3 t1 900P1 loc1 t2 1030P1 loc2 t2 920P2 loc1 t2 1010P2 loc2 t2 700

15

fatia (slice) doperíodo de tempo t1

fatia (slice) doperíodo de tempo t2

Universidade Federal de São CarlosDepartamento de ComputaçãoCurso de Pós-Graduação “Lato-Sensu” em ComputaçãoP2 loc4 t2 1100P3 loc1 t2 980P3 loc4 t2 980P4 loc2 t2 1550P4 loc3 t2 950

...Figura 5. Relação Vendas (tabela fato)

As dimensões podem ser representadas como relações:

Local (codLocal, Cidade, Estado, País)

Produto (codProd, Descrição, Marca, Categoria, Estilo, Preço)

Tempo( codTempo, Data, Semana, Mês, Trimestre, Ano)

Para cada dimensão, o conjunto de valores associados podem ser

estruturados em uma hierarquia. Por exemplo, cidades pertencem a estados e

estados pertencem a países. Datas pertencem a semanas e a meses; semanas e

meses estão contidos em trimestres e trimestres estão contidos em anos. A figura

6 mostra as hierarquias para Produto, Local e Tempo do exemplo aqui

considerado.

16

PRODUTO

categoria

estilo

código produto

TEMPO

ano

trimestre

semana mês

data

LOCAL

país

estado

cidade

Figura 6. Possíveis hierarquias para Produto, Tempo e Local


3.2. Consultas OLAP

Sobre o cubo de dados (data warehouse) podem ser aplicadas as

operações típicas de OLAP, para viabilizar a extração eficaz de informações do

mesmo.

As operações suportadas pelo modelo multi-dimensional são fortemente

influenciadas por ferramentas existentes para usuário final tal como aquelas que

trabalham com planilhas eletrônicas. A meta é oferecer ao usuários finais, que

não são especialistas em SQL, uma interface intuitiva e poderosa para tarefas

comuns de análise de negócio. Cada operação sobre o conjunto de dados multi-

dimensional retorna ou uma apresentação diferente ou uma sumarização desse

conjunto de dados. O conjunto de dados está sempre disponível para o usuário

manipular, independente do nível de detalhe em que ele está sendo visto.

3.2.1. Agregação

Uma operação muito comum é agregar uma medida sobre uma ou mais

dimensões. Exemplos de consultas típicas são:

Encontrar o total de vendas.

Encontrar o total de vendas para cada cidade.

Encontrar o total de vendas para cada estado.

Encontrar os cinco produtos mais vendidos.

As três primeiras consultas podem ser expressas como consultas SQL sobre

17


as tabelas fato e dimensão, mas a última consulta não pode ser expressa em

SQL (embora se possa conseguir um resultado satisfatório ordenando o total

de vendas através de ORDER BY).

Um outro uso de agregação é sumarizar em diferentes níveis de hierarquia.

Isso é conseguido através das operações OLAP roll-up e drill-down que

oferecem visualizações hierárquicas dos dados.

3.2.2. Roll-up

A operação roll-up realiza um aumento no nível de agregação dos dados,

agrupando em unidades maiores ao longo da dimensão. Por exemplo, a figura 7

mostra os dados de venda usando a operação roll-up que, a partir de informações

de venda de produtos individuais por local (por cidade), faz um agrupamento de

categorias de produtos, apresentando o total de vendas por categoria de produto

(por exemplo: categoria Roupa abrange os produtos P1 a P10, a categoria

Calçado abrange os produtos P11 a P15, etc.).

São Carlos Ribeirão Preto ...Roupa 10.000 15.000 ...Calçado 7.000 10.000 ...Bijuteria 30.000 20.000... ... ... ...

3.2.2. Drill-down

A operação drill-down oferece a capacidade oposta, fornecendo uma

visão mais detalhada. Por exemplo, dado o total de vendas por estado e por

categoria de produto, podemos solicitar uma apresentação mais detalhada

18

LOCAL

CATEGORIASDE

PRODUTOS

Figura 7. A operação roll-up (venda por categoria/cidade)


desagregando vendas de cada estado por cidade e também quebrando categoria

de produtos por estilos, conforme figura 8.

S.Carlos Rib.Preto Lins Assis P. Alegre Caxias Sul

ABCDABDABC...

19

Estilos Roupa

Estilos Calçado

Estilos Bijouteria

São Paulo

...Rio Grande do Sul


Figura 8. A operação drill-down

3.2.4. Pivot

A mudança de uma hierarquia dimensional (orientação) para uma outra é

facilmente obtida em um cubo de dados utilizando a técnica chamada pivoting (ou rotação). A operação pivot realiza uma re-orientação do ângulo de visão dos

dados. Nessa técnica, os eixos podem ser mostrados em orientações diferentes.

Por exemplo, pode-se fazer uma rotação no cubo de dados da figura 4 para

mostrar rendimentos de vendas regionais como linhas, os totais de rendimentos

diários como colunas e os produtos da companhia na terceira dimensão (figura 9).

Isso equivale a ter uma tabela de venda regional para cada produto

separadamente, onde cada tabela mostra, para o produto específico, totais de

vendas para cada local e cada período considerado.

20

Reg3

Reg2

Reg1Tempo ...

.

t3t2t1

Produto P4

P3P2

P1

...

Local

...

Figura 9. Rotação (Pivot) do cubo de dados de vendas


3.2.5. Comparando com consultas SQL

Algumas consultas OLAP não podem ser (ou não podem ser facilmente)

expressas em SQL. Por exemplo, das quatro consultas a seguir, as duas

primeiras podem ser expressas como consultas SQL sobre as tabelas fato e

dimensão. A terceira consulta pode ser expressa também, mas é mais

complicada em SQL. A última consulta não pode ser expressa em SQL, se n é

para ser um parâmetro da consulta. Observe que todas as consultas a seguir

envolvem o tempo. Na verdade a dimensão Tempo é muito importante em OLAP.

Consultas:

Encontre o total de vendas por mês.

Encontre o total de vendas por mês para cada cidade.

Encontre a variação de porcentagem no total de vendas mensalmente para

cada produto.

Encontre a média de movimento de vendas de n dias. (Para cada dia, deve ser

calculada a média de vendas diária sobre os n dias precedentes).

Um grande número de consultas OLAP, entretanto, pode ser expresso em

SQL. Tipicamente elas envolvem agrupamento e agregação, e uma única

operação OLAP conduz a várias consultas relacionadas. Por exemplo, a mesma

informação apresentada na tabela da figura 7 pode ser obtida através da seguinte

consulta:

SELECT SUM (V.vendas)

FROM Vendas V, Produto P, Local L

WHERE V.codProd=P.codProd AND V.codLocal=L.codLocal

GROUP BY P.Categoria, L.Cidade

A operação realizada na tabela da figura 7 é a Roll-up, que agrupa os

dados em unidades maiores. Cada operação roll-up corresponde a uma consulta

21


SQL com GROUP BY. Em geral, dada uma medida com k dimensões associadas,

podemos fazer um roll up sobre qualquer subconjunto dessas k dimensões e

então tem-se 2k possíveis consultas SQL.

Uma extensão proposta para o SQL chamada CUBE é equivalente a uma

coleção de comandos GROUP BY, com um comando GROUP BY para cada

subconjunto das k dimensões. Por exemplo, considere a consulta:

CUBE codProd, codLocal, codTempo BY SUM Vendas

Essa consulta fará um roll up sobre a tabela Vendas sobre todos os oito

subconjuntos do conjunto { codProd, codLocal, codTempo}. Ela é equivalente a

oito consultas da forma:

SELECT SUM (V.vendas)

FROM Vendas V

GROUP BY lista-do-agrupamento

As consultas diferem somente na lista-do-agrupamento, que é algum

subconjunto do conjunto { codProd, codLocal, codTempo}.

22


4. Projeto do Data Warehouse

4.1. Esquema Estrela

Diagramas entidade-relacionamento e técnicas de normalização são

popularmente usadas para projetos de bases de dados operacionais. Nos

sistemas de apoio à decisão, porém, devem prevalecer métodos de projeto que

tenham como alvo a eficiência nas consultas [19].

A maioria dos data warehouses utilizam um esquema estrela para representar

o modelo multi-dimensional de dados [12]. A base dos dados consiste de uma tabela

dimensão para cada dimensão, além de uma tabela fato, a qual contém um

relacionamento com cada uma das tabelas dimensão e um valor para a dimensão do

negócio relativo ao conjunto de dimensões referenciadas. A Figura 10 mostra o

esquema estrela para o exemplo de vendas de produto adotado no capítulo 3.

23

VENDAS(tabela fato)

REGIÃO

PRODUTOTEMPO

codProdcodTempocodRegiãovendasvalor-vendas

codTempoDataSemanaMês TrimestreAno

CodProdutoCategoria DescrCategoriaEstiloPreço

CodRegCidadeEstadoPaís

(tabelas dimensão)(tabela dimensão)

Figura 10. Esquema estrela do exemplo dado (fig.4)


Uma outra maneira de representar esquema estrela é fornecido na figura 11.

O volume maior dos dados está tipicamente na tabela fato, que não tem

redundância. Usualmente ela está na Forma Normal de Boyce Codd (FNBC).

Para minimizar o tamanho da tabela fato, os identificadores das dimensões (ex.

CodLocal, CodTempo) são gerados pelo sistema.

As tabelas dimensão usualmente são não normalizadas. A razão para isso

é que um banco de dados usado para OLAP é estático; assim, anomalias de

atualização, inserção e eliminação não são importantes. Além disso, o espaço de

armazenamento ganho através da normalização das tabelas dimensão é

desprezível, frente ao tempo de processamento gasto para combinar a tabela fato

com as tabelas dimensão, caso estas fossem quebradas em tabelas menores

normalizadas (que podem conduzir a junções adicionais).

24

PRODUTO

CodRegião Cidade Estado País

CodTempo Data Semana Mês Trimestre Ano

TEMPO

REGIÃO

CodProd CodLocal CodTempo vendas valor-vendas

VENDA

Figura 11. Outra representação de esquema estrela

CodProd Categoria DescrCategoria Estilo Preço


4.2. Esquema Snowflack

Esquemas estrela não fornecem explicitamente suporte para hierarquias de

atributos. Um modelo refinado do esquema estrela é o chamado esquema

snowflack, no qual as tabelas dimensão são organizadas em uma hierarquia

através de sua normalização, como mostrado na Figura 12. Isso traz vantagens

para a manutenção das tabelas-dimensões. Entretanto, a estrutura não

normalizada das tabelas dimensão nos esquemas estrela podem ser mais

apropriados para a manipulação das dimensões.

As figuras 13 e 14 apresentam um outro exemplo de esquemas estrela e

snowflack.

25

CATEG-PROD

VENDA(tabela fato)

TEMPO

PRODUTO

REGIÃOCodProdCodRegiãoCodTempovendasvalor-vendas

CodRegiãoCidadeEstado

CodProdutoCategoriaEstiloPreço

CodTempoData SemanaMêsAno

(tabelas dimensão)(tabelas dimensão)

EstadoPaís

ESTADO

CategoriaDescriçãoCateg

Mês Trimestre

Figura 12. Esquema Snowflack


26

RENDIMENTOVENDAS(tabela fato)

VENDEDOR

DATACIDADE

PRODUTO

PEDIDO

CLIENTE

NroPedidoCodVendedorCodClienteCodProdutoChaveDataCidadeQuantidadeValorTotal...

NroPedidoDataPedido...

CodClienteNomeClienteEndereçoClienteCidadeCliente...

CodVendedorNomeVendedorCidadeVendedorCota...

CodProdutoNomeProdutoDescrProdutoCategoriaDescrCategEstiloProdutoPreçoUnitario...

ChaveDataDataMêsAno...

CidadeEstadoPaís...

Figura 13. Outro exemplo de esquema estrela

MÊS

ESTADO

VENDAS(tabela-fato)

VENDEDOR

DATACIDADE

PRODUTO

PEDIDO

CLIENTE

NroPrdidoCodVendedorCodClienteCodProdutoChaveDataCidadeQuantidadeValorTotal...

NroPedidoDataPedido...

CodClienteNomeClienteEndereçoClienteCidadeCliente...

CodVendedorNomeVendedorCidadeVendedorCota...CodProduto

NomeProdutoDescrProdutoCategoriaPreçoUnitario...

ChaveDataDataMês...

CidadeEstado...

CategoriaDescrCateg

EstadoPaís

MêsAno

Figura 14. Esquema Snowflack


4.3. Constelação de Fatos

Constelação de fatos são exemplos de estruturas mais complexas nas

quais múltiplas tabelas fato compartilham tabelas dimensão. A figura 15 mostra

uma constelação de fatos com duas tabelas fato, Resultado de Vendas e Previsão

de Vendas, que compartilham a tabela dimensão Produto. Constelações de fatos

limitam as possíveis consultas para o warehouse.

Outro exemplo seria uma constelação de fatos representando despesas projetadas e

despesas reais, contendo duas estrelas que compartilham várias dimensões.

4.3. Visões Materializadas

A fim de otimizar a análise multi-dimensional, tornando-a viavelmente

utilizável pelo usuário, uma das soluções adotadas atualmente é a pré-

computação de agregações em alguns subconjuntos de dimensões e suas

hierarquias correspondentes. Outra solução comumente usada é a materialização

de consultas muito freqüentes. Essas tabelas especiais são chamadas de visões

materializadas.

As visões materializadas geralmente consistem de junções da tabela fato com

um subconjunto de tabelas dimensão, com a sumarização de uma ou mais medidas

de valor do negócio, agrupadas por um conjunto de atributos das tabelas dimensão.

27

RESULTADO.VENDAS(tabela fato)

PRODUTO

CodProdutoCodRegiãoCodTempoVendas

CodProdutoCategoriaDescrCategoriaEstiloPreço

(tabela dimensão)

PREVISÃOVENDAS(tabela fato)

CodProdutoCodRegiãoCodTempoFuturo ProjeçãoVendas

Figura 15. Uma constelação de fatos


A seleção das visões a materializar deve levar em conta a freqüência de

utilização, características de carga de trabalho, custo de atualizações

incrementais e exigências de armazenamento.

Como um exemplo, suponha que num ambiente de vendas, como o do exemplo

aqui considerado, uma grande maioria das consultas é baseada na performance de vendas

no estado de São Paulo, do trimestre mais recente. Ter uma tabela que contenha dados

sumários sobre esses parâmetros pode acelerar significativamente o processamento das

consultas. A figura 16 ilustra esse exemplo.

Vendas - Estado São Paulo

Categoria

Data

01/07/99 02/07/99 ... 25/11/99

Roupa 2000 3000 ... 1000

Calçado 500 650 ... 220

Bijuteria 300 550 ... 430

Vendas - Estado São Paulo

Categoria Trimestre 3

Roupa 21200

Calçado 5670

Bijuteria 6980

Figura 16. Agregação

Consultas ad hoc realizadas pelos usuários são respondidas usando as

tabelas originais juntamente com sumários pré-computados.

28

agregação


4.4. Construindo um Data Warehouse

Há muitos desafios na criação e manutenção de um data warehouse. É

necessário projetar um bom esquema de banco de dados para manter uma

coleção integrada de dados copiados de diversas fontes. Por exemplo, o data

warehouse de uma companhia pode incluir os bancos de dados do departamento

de Estoque e de Pessoal, junto com os bancos de dados de Vendas mantidos por

escritórios em diferentes países (ou filiais). Uma vez que os dados são criados e

mantidos por diferentes grupos, existem algumas questões que devem ser

avaliadas, tais como erros semânticos, diferenças na forma como as tabelas

foram normalizadas ou estruturadas, nomes diferentes para o mesmo atributo.,

entre outros.

Para construir um data warehouse, é necessário ter uma visão antecipada

do uso do warehouse. Não há uma maneira para antecipar todas as possíveis

consultas ou análises durante a fase de projeto. Entretanto, o projeto deve

especificamente suportar consultas ad-hoc, isto é, acesso aos dados com

qualquer combinação significativa de valores para os atributos na tabela

dimensão ou tabela fato.

A aquisição de dados para o warehouse envolve os seguintes passos:

extração de dados: Os dados podem ser extraídos de múltiplas fontes

heterogêneas. Durante essa fase pode ser necessário selecionar dados sobre

itens específicos ou categorias de itens, ou de armazéns em uma região

específica do país;

formatação: Os dados devem ser formatados para ficar consistentes com o

warehouse. Nomes, significados e domínios de dados vindos de fontes não

relacionadas devem ser conciliados. Por exemplo: companhias subsidiárias de

uma grande corporação podem ter diferentes calendários fiscais com os

trimestres terminando em diferentes datas, tornando difícil agregar dados

financiais por trimestre; outro exemplo é a existência de diferentes unidades

monetárias. Essas inconsistências de formato devem ser resolvidas.

Limpeza dos dados: Os dados devem passar por uma limpeza para

29


minimizar erros, preencher informação ausente, quando possível, e deixar os

elementos de dados dentro de formatos e significados padronizados e

consistentes. Limpeza dos dados é um processo complexo que tem sido

identificado como o componente que demanda maior trabalho na construção

do data warehouse. Para dados de entrada, a limpeza deve ocorrer antes que

os dados sejam armazenados no warehouse. A limpeza de dados que requer o

reconhecimento e correção automáticos de dados errôneos e incompletos é

uma tarefa difícil. Alguns aspectos, tais como checagem de domínio, são

facilmente codificados em rotinas de limpeza de dados, mas reconhecimento

automático de alguns problemas de dados pode ser mais desafiador.

Por exemplo, o processo de limpeza pode corrigir CEPs inválidos ou

eliminar registros com prefixos de telefone incorretos.

A tabela da figura 17 a seguir apresenta alguns exemplos de dados que

necessitam de um tratamento:

nome de cidade errado ("Centro"), e não padronizado (São Paulo e

S.Paulo)

nome de bairro errado ("XXX") e não padronizado ("Centro" -

transformar para letras maiúsculas).

as datas devem seguir um mesmo formato.

valores nulos devem ter um tratamento adequado (data com valor

"000000")

eliminar dados inúteis para o data warehouse: a última linha da tabela não

representa informação útil.

CIDADE BAIRRO DATA

SÃO CARLOS CENTRO 10/09/99

CENTRO Centro 08/03/1999

30


RIO DE JANEIRO XXX 13-05-99

SÃO PAULO PINHEIROS 15101998

S. PAULO SANTANA 000000

RIBEIRÃO PRETO CENTRO 10/06/1998

XXXX 000000

Figura 17 - Erros durante a fase de limpeza

Os dados devem ser ajustados no modelo de dados do data warehouse. Os

dados vindos de várias fontes devem ser instalados no modelo de dados do

warehouse. Os dados podem ter que ser convertidos de bancos de dados

relacionais, orientados a objetos ou legados (redes ou hierárquicos) para um

modelo multi-dimensional.

Os dados devem ser carregados no warehouse. Essa tarefa é significativa

devido ao grande volume de dados do warehouse. São requeridas

ferramentas de monitoração para a carga, bem como métodos para

recuperação a partir de cargas incompletas ou incorretas. Questões sobre a

atualização dos dados também são levadas em conta. As seguintes questões

devem ser consideradas:

Até que ponto os dados podem ser atualizados?

O warehouse pode se tornar off-line e por quanto tempo?

Quais são as interdependências de dados?

Qual é a disponibilidade de armazenamento?

Quais são os requisitos de distribuição (tais como para replicação

e particionamento)?

Qual é o tempo de carga (incluindo limpeza, formatação, cópia,

31


transmissão, reconstrução de índice, ...)?

Uma tarefa de projeto muito importante é avaliar quais tabelas sumário devem

ser materializadas para alcançar o melhor uso de memória disponível e

responder consultas ad hoc comumente realizadas com tempo de resposta

interativo.

Quando o warehouse usa um mecanismo de reabastecimento (refreshing) de

dados incremental, pode ser necessário purgar periodicamente os dados; por

exemplo, um warehouse que mantém dados sobre os últimos 3 anos pode

purgar seus dados a cada ano.

4.5. Resumindo as Funcionalidades Típicas de Data Warehouses

O objetivo dos data warehouses é facilitar consultas complexas e que

envolvem muitos dados. Eles devem fornecer um suporte de consulta maior e

mais eficiente do que os oferecidos nos bancos de dados transacionais. Os

suportes do componente de acesso do data warehouse incluem:

- funcionalidades melhoradas de ferramentas que trabalham com

planilhas eletrônicas: isto é, suportes conhecidos oferecidos para

planilhas eletrônicas bem como suporte de programas de

aplicação OLAP.

- Processamento de consulta eficiente

- consultas estruturadas

- consultas ad hoc

- data mining

- visões materializadas

As funcionalidades pré-programadas que são oferecidas pelos data

warehouses são:

- Roll-up: os dados são sumarizados com crescente generalização (por

ex., de semanalmente para trimestralmente para anualmente).

32


- Drill-down: crescentes níveis de detalhe são revelados (operação

oposta de roll-up).

- Pivot (rotação): é realizada tabulação cruzada.

- Slice and dice: são realizadas operações de projeção sobre as

dimensões.

- Ordenação: os dados são ordenados através de um atributo.

- Seleção: os dados são disponíveis por valor ou agrupados em

categorias de valores.

- atributos derivados (computados): valores derivados através de

operações sobre dados armazenados.

4.6. Considerações Finais

4.6.1. Data warehousing e Visões

Data warehouses têm sido considerados por algumas pessoas como sendo

uma extensão de funções e visões do banco de dados. Entretanto visões

fornecem somente um subconjunto das capacidades de data warehouses. Visões

e data warehouses são parecidos nos seguintes aspectos:

- ambos têm dados extraídos de bancos de dados;- são orientados ao assunto .

Data warehouses são diferentes de visões nos seguintes aspectos:

- Data warehouses existem como armazenamento persistente ao invés

de ser materializado sob demanda;

- Data warehouses não são usualmente relacionais, mas sim

multidimensionais. Visões de um banco de dados relacional são

relacionais.

- Data warehouses podem ser indexados para otimizar performance.

Visões não podem ser indexadas independente dos bancos de dados

33


utilizados.

- Data warehouses caracteristicamente fornecem suporte específico de

funcionalidade; visões não podem fornecer.

- Data warehouses fornecem grande quantidade de dados integrados e

freqüentemente temporais, geralmente mais do que está contido em um

banco de dados, enquanto que visões são um extrato de um banco de

dados.

4.6.2. Dificuldades na Implementação de Data Warehouses

A construção de um warehouse de um amplo empreendimento em uma

grande organização pode levar anos, considerando desde a fase inicial de

concepção até a implementação. Devido à dificuldade e quantidade de tempo

requerido para uma tal tarefa, o desenvolvimento e emprego difundido de data

marts pode fornecer uma alternativa atrativa, especialmente para aquelas

organizações com necessidades urgentes de OLAP, sistemas de suporte à

decisão e/ou suporte de data mining.

Alguns aspectos a serem considerados são:

A administração de um data warehouse é uma tarefa intensiva, proporcional

ao tamanho e complexidade do warehouse.

O controle de qualidade dos dados e a consistência são aspectos importantes

a considerar. Cada vez que um banco de dados fonte muda, o administrador

do data warehouse deve considerar as possíveis interações com outros

elementos do warehouse.

Projeções de uso devem ser estimadas antes da construção do data

warehouse e devem ser revisadas continuamente para atender requisitos

correntes.

Administração de data warehouse irá requerer habilidades mais amplas do

34


que são necessárias para administração de banco de dados tradicional.

35


5. Servidores OLAP

Servidores que utilizam bancos de dados relacionais tradicionais não foram

concebidos para propiciar o uso inteligente de índices e de outros recursos

necessários para suportar visões multidimensionais de dados. Em adição aos

servidores relacionais tradicionais, há três opções principais para a

implementação do servidor OLAP: servidores ROLAP (Relational OLAP), que

armazenam os dados em tabelas, servidores MOLAP (Multi-dimensional OLAP),

que armazenam os dados em arrays, e servidores HOLAP (Hibrid OLAP), que são

híbridos dos dois anteriores.

5.1. Servidores ROLAP

Nos servidores OLAP Relacionais (ROLAP) os dados são armazenados em

tabelas de bancos de dados relacionais ou relacionais estendidos. Eles utilizam

SGBDs relacionais para gerenciar os dados e agregações do esquema estrela do

warehouse. Também suportam extensões a SQL e acesso e métodos de

implementação especiais, tais como o OLAP midleware para a implementação

eficiente do modelo multi-dimensional e suas operações. Dessa forma, sua

estrutura de dados é implementada por tabelas relacionais, e uma célula do

espaço multi-dimensional é representada por uma tupla. Essa tupla carrega

alguns atributos que identificam a posição da célula no espaço multi-dimensional,

além de outros atributos que contém os valores de dados correspondentes àquela

célula.

Por utilizarem bancos de dados relacionais para implementar o modelo

multi-dimensional, os servidores OLAP precisam reescrever as consultas dos

usuários para compatibilizá-las com as visões materializadas e gerar múltiplas

consultas SQL para o servidor. A principal vantagem dos servidores ROLAP está

no armazenamento de grandes conjuntos de dados, devido ao fato de se poder

36


armazenar dados esparsos de forma mais compacta em tabelas do que em

arrays.

5.2. Servidores MOLAP

Outra opção amplamente adotada são os servidores OLAP

Multidimensionais (MOLAP). Servidores MOLAP implementam as visões

multidimensionais diretamente, armazenando dados em algumas estruturas

especiais (por exemplo, arrays esparsos) e executando as operações OLAP

diretamente sobre essas estruturas. O cubo de dados é implementado através do

mapeamento de suas dimensões para os índices do array, de forma que o

conteúdo do array é formado pelos valores contidos em cada célula do cubo.

Servidores MOLAP possuem excelentes propriedades de indexação devido

ao fato de ser mais simples localizar uma célula num array do que numa tabela.

Por outro lado, quando os dados são esparsos, os servidores MOLAP perdem

performance, sendo que nesses casos algumas técnicas de matrizes de

compressão devem ser exploradas. Para pequenos e médios conjuntos de dados,

eles são mais eficientes em armazenamento e recuperação dos dados.

5.3. Servidores HOLAP

Alguns servidores OLAP adotam uma forma de armazenamento em dois

níveis, a fim de manipular conjuntos de dados densos e esparsos. O conjunto de

dados de alguns subcubos dimensionais que são identificados como densos são

armazenados no formato de arrays. O restante dos subcubos, que são esparsos,

são armazenados em tabelas empregando tecnologias de compressão. Isso

resulta em um método de armazenamento híbrido chamado de OLAP Híbrido

(HOLAP).

37


5.4. On-Line Analytical Mining (OLAM)

Considerando o alto poder do método OLAP para se realizar análises

multidimensionais e vislumbrando as vantagens geradas pela possibilidade de

utilizar essa análise na preparação dos dados na aplicação de Data Mining, J.

Han e sua equipe desenvolveram um mecanismo batizado de OLAM (On-Line

Analytical Mining), que propicia a aplicação de KDD num ambiente multi-

dimensional em grandes bases de dados e data warehouses .

As principais vantagens geradas por essa abordagem são:

A maioria das ferramentas de Data Mining necessitam trabalhar com dados

integrados, consistentes e limpos, que exigem um árduo trabalho de limpeza,

transformação e integração dos dados nas fases que precedem a aplicação de

DM no processo KDD. Num data warehouse, a maior parte dessa preparação

normalmente já foi realizada, servindo esse warehouse para a aplicação tanto

de OLAP quanto de DM.

DM efetivo necessita de análises exploratórias de dados. O usuário

frequentemente deseja navegar de forma flexível ao longo da base de dados,

selecionar diferentes partes de dados relevantes e analisar os dados em

diferentes granularidades.

A integração de OLAP com múltiplas funções de DM permite ao usuário

investigar diferentes tarefas de data mining de forma fácil e flexível.

38


39


Apêndice A

ESTUDO DE CASO 1 – Criação de um Data Mart

Este estudo de caso descreve a criação de um data mart realizada em uma

empresa que comercializa pedras e concreto, situada no estado de Maryland,

EUA [8].

O objetivo foi auxiliar na análise de vendas e marketing para os seus

principais clientes, que são empresas de construção e pavimentação, além de,

eventualmente, avaliar a eficiência da rede de distribuição.

Os dados de entrada originam-se de sistemas IBM ES/9000 e AS/400.

A ferramenta utilizada para a execução do projeto foi o Oracle Data Mart

Suite para Windows NT.

Objetivou-se fornecer aos usuários do sistema acesso ad hoc gráfico às

informações gerenciais, sem envolver grande volume de processamento a cada

acesso realizado.

A principal área de interesse identificada foi a análise dos lucros.

O primeiro passo foi a identificação acurada de todas as informações que o

usuário realmente necessitava em suas consultas, definindo-se, assim, o grau de

detalhamento que o sistema deveria contemplar. O estudo dos relatórios já

existentes foi um ponto de partida.

O passo seguinte foi a compreensão do mecanismo de cálculo dos lucros

da empresa, já que o antigo sistema de contas não fornecia explicitamente esses

valores, mas sim um grande número de campos que poderiam levar a esses

valores. O projeto das tabelas foi tal que o lucro pudesse ser pré-calculado e

armazenado na tabela fato, evitando, assim, cálculos no momento da consulta.

40


Outra característica a ser definida foi o período de tempo em que o usuário

gostaria de ter suas informações armazenadas, já que a dimensão tempo é

crucial para o esquema estrela.

Iniciou-se, então, o projeto do banco de dados, descrito a seguir.

O esquema estrela é construído objetivando-se simplicidade e velocidade

de recuperação. Cada tabela dimensão possui uma chave primária, usualmente o

ID. A tabela fato contém uma chave composta por todas as chaves das

dimensões.

Ao invés de utilizar diretamente os identificadores das tabelas dimensão,

foram criadas chaves sintéticas tanto para as chaves primárias das tabelas

dimensão, quanto para as chaves estrangeiras da tabela fato. Esse procedimento

torna mais eficientes as consultas, além de manter uma homogeneidade na base

de dados, garantindo também a unicidade dos identificadores e uma maior

facilidade na manutenção do data mart.

A tabela fato da empresa foi construída a partir de tickets e faturas de

produtos (pedras) que foram comprados e transportados para um certo local.

O grau de granularidade (nível de detalhe informacional) que o cliente

deseja obter nos relatórios tem um impacto sobre o projeto da tabela fato.

Importante: obter dos clientes o que eles necessitam ver e não o que eles

querem ver.

As tabelas dimensão criadas são mostradas a seguir.

Tabela dimensão Fábrica:

Tabela estática com detalhes sobre todas as fábricas da empresa.

41

FÁBRICA

CódigoDescriçãoId-linha-produto

DIM-FÁBRICA

Chave-FábricaCod-FábricaDescr-FábricaRegião-Fábrica


Tabela dimensão Tempo:A tabela Tempo foi necessária, pois os relatórios necessitam avaliar os dados por dia, feriados, períodos fiscais, etc. Se os agrupamentos fossem somente referentes a anos/meses a tabela Tempo poderia ser dispensada.

Tabela dimensão Item:

42

DIM-TEMPO

Chave-tempoId-dataDia-do-mêsNumero-mêsDescr-mêsSemana-do-anoDescr-diaNum-anoDia-do-anoNúmero-trimestreData-venda

DIM-ITEM

Chave-itemTipo-itemCód-linha-item Descr-linha-itemClasse-itemSub-classe-itemFlag-itemDescrição-item

ITEM

CódigoTipoDescriçãoId-linha-itemClasse

LINHA-ITEMCódigoDescrição


Tabela dimensão Cliente:

Tabela dimensão Representante de Vendas :

Tabela dimensão Transportadora:

43

CLIENTE

CódigoNomeEndereço1Endereço 2CidadeEstadoCEPRepresent-vendaTipo

DIM-CLIENTE

Chave-clienteCod-clienteNome-clienteCod-Repres-vendaNome-repres-vendaTipo-cliente

REPRES-VENDA

CódigoNome

DIM-REPRES-VENDA

Chave-repr-vendaCodigo-repr-vendanome-repr-venda

TRANSPORTADORA

CódigoNome

DIM-TRANSPORTADORA

Chave-TransportadoraCódigoNome


Tabela fato Ticket -Fatura:

Tabela dimensão Região de Entrega:

44

TICKET-FATURA

Número-faturaNúmero-ticketTipo-ticketCod-FábricaCod-clienteCódigoData-envioCod-produtoQtde-enviadaPreço-produtoCusto-fixado-produto-por-unidadeCusto-variavel-produto-por-unidadeCód-transportadoraCusto-transporte-por-unidadeRegião-entregaLocal-entrega

DIM-REGIÃO-ENTREGA

Chave-entregaEstado-entregaPaís-entregaLocal-entregaRegião-entrega


O negócio da empresa era rastrear e avaliar as faturas e tickets para cada

carga transportada por seus caminhões. Havia vários tickets por fatura. Cada

ticket tinha medidas e preços tais como datas da transportadora, quantidades de

itens, custos totais, etc. Devido ao relacionamento entre tickets e faturas, decidiu-

se fundir as duas tabelas em uma tabela fato principal. Para cada fatura pode

haver vários tickets.

Para a tabela fato, a solução adotada foi a criação de uma única tabela

contendo as informações sobre os tickets e os pedidos que os contém.

Tabelas sumário:

A fim de reduzir o tempo de processamento de recuperação de dados que

são freqüentemente executadas, foram criadas tabelas sumário para a dimensão

tempo, devido à sua alta freqüência de consultas. As tabelas criadas produzem

freqüentemente relatórios por mês, trimestre e ano.

45


Apêndice B

ESTUDO DE CASO 2 – Cubo Multidimensional e OLAP

Este estudo de caso descreve a implementação do cubo multidimensional para consultas OLAP realizada em uma usina de açúcar e álcool, situada no estado de São Paulo.

O objetivo foi auxiliar nas análises setoriais, gerar regras de negócio, analisar riscos e produtividade e permitir a comparação e a combinação de informações. Algumas perguntas das quais desejava-se conhecer as respostas:

- com quais clientes praticou-se o melhor preço?- quais clientes geram maior lucratividade?- quais os mercados mais lucrativos?- qual é o perfil dos clientes?- em que regiões concentram-se as vendas?

Inicialmente, foram comparadas as duas alternativas: OLTP e OLAP, a fim de verificar as vantagens da solução OLAP, justificando, assim a implementação do projeto. Algumas das características levantadas foram:

OLTP OLAP- utilização da base de dados operacionais;- demora na execução de consultas e relatórios;- pouca flexibilidade;- muitos relatórios utilizados apenas uma vez;- necessidade de pessoal de informática para desenvolvimento de templates de relatórios;- grande volume de informações a serem processadas.

- utilização de data marts- consultas e relatórios obtidos instantaneamente- visão multidimensional das informações;- transparência da origem dos dados (Ingres, texto, excel, web);- arquitetura cliente/servidor, permitindo utilização remota;- geração de regras de negócio.

Para o desenvolvimento do projeto, foi contratada uma empresa de consultoria com experiência na área.

A ferramenta utilizada para a extração/visualização dos dados foi a O3.

A criação do cubo foi realizada utilizando-se o aplicativo O3 Designer, seguindo-se os seguintes passos:

46


Definição das dimensões e medidas do cubo e das origens de dados:

Definição das queries:

47


Codificação das queries:

Definição dos campos das queries:

48


Definição das hierarquias dimensionais:

Definição das medidas:

49


A seguir são ilustrados alguns exemplos de consultas com visualização gráfica.

Volume de vendas anual do produto açúcar para os diferentes ramos de atividade:

Drill-down no ramo Doces, enfocando o ano de 98 (vendas mensais):

50


51


Volume de vendas anual do produto açúcar para os diferentes destinos:

Enfoque no ano de 98 (vendas mensais):

52


Receita líquida obtida no ano de 98, com o produto açúcar, para o cliente Vonpar:

53


Bibliografia

[1] Inmon, W.H. Building the Data Warehouse. John Wiley, 1992.

[2] Chaudhuri, S., Dayal, U. An Overview of Data Warehousing and OLAP Technology, ACM SIGMOD Record, vol.26, 65-74, 1997.

[3] Elmasri, R., Navathe, S. Fundamentals of Databases, 3ª edição, 2000.

[4] Ramakrishnan, R. Database Management Systems. McGraw-Hill, 1998.

[5] Felipe, J.C. O Processo de Extração de Conhecimento de Bases de Dados Aplicado a Bancos de Dados Multimídia Orientados a Objetos.

Monografia de Exame de Qualificação de Mestrado. Programa de Pós-

Graduação em Ciência da Computação, Departamento de Computação -

UFSCar, São Carlos, Fevereiro 1999.

[6] Becker, K., Pereira, W. Tutorial de Data Warehouse, XIV Simpósio

Brasileiro de Banco de Dados, outubro, 1999, Florianópolis, SC, Brasil.

[7] Oracle, Oracle Data Mart Suite.

http://www.twinsoft.de/english/produkte/dmsuite_E.htm

[8] Oracle, Data Marte Suite Design - A Case Study.

http://www.avanco.com/dmdesignstudy.htm.

[9] IBM, Data Warehousing Concepts.

http://as400.rochester.ibm.com/db2/dataware.htm , 1998.

[10] Tam, Y. J., Datacube: Its Implementation and Application in OLAP Mining, Thesis submitted for the degree of Master of Science in the

Department of Computer Science of Simon Fraser University, Canada,

september 1998.

[11] Harinarayan, V., Rajaraman, A., Ullman, J. D., Implementing Data Cubes Efficiently, Proc. ACM SIGMOD Int. Conference on Management of Data,

June 1996.

54

url:http://as400.rochester.ibm.com/db2/dataware.htm


[12] Roussopoulos, N., Materialized Views and Data Warehouses, ACM

SIGMOD Record, Vol. 27, No. 1, Março 1998.

55

Documents

1marilde/PosGraduacaoLatoSensu... · Web view... que consiste na aplicação de algoritmos específicos sobre uma base de dados, com o objetivo de produzir uma série particular de