UNIVERSIDADE FEDERAL DE SANTA CATARINA

DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA

CURSO DE CIÊNCIAS DA COMPUTAÇÃO

CONSTRUÇÃO DE UM CUBO OLAP PARA ANÁLISE DE METAS EM

SISTEMAS BASEADOS EM BSC

AUTOR:

RAFAEL MUELLER

FLORIANÓPOLIS, JUNHO DE 2005

2

1 INTRODUÇÃO ......................................................................................................................................3 1.1 MOTIVAÇÃO .........................................................................................................................................3 1.2 PROBLEMA ............................................................................................................................................3 2 BALANCED SCORECARD.................................................................................................................4 2.1 INTRODUÇÃO ........................................................................................................................................4 2.2 HISTÓRICO............................................................................................................................................4 2.3 CONCEITO .............................................................................................................................................4 2.3.1 PERSPECTIVA FINANCEIRA...............................................................................................................5 2.3.2 PERSPECTIVA CLIENTES ...................................................................................................................5 2.3.3 PERSPECTIVA PROCESSOS INTERNOS ..............................................................................................5 2.3.4 PERSPECTIVA APRENDIZADO E CRESCIMENTO ..............................................................................5 2.4 PROBLEMA ............................................................................................................................................6 3 DATA WAREHOUSE ...........................................................................................................................7 3.1 CONCEITO .............................................................................................................................................7 3.2 CARACTERÍSTICAS ...............................................................................................................................7 3.2.1 ORIENTADOS AO ASSUNTO ...............................................................................................................7 3.2.2 INTEGRADOS ......................................................................................................................................7 3.2.3 VARIANTE NO TEMPO........................................................................................................................8 3.2.4 NÃO VOLÁTIL ....................................................................................................................................8 3.3 POR QUE O DATA WAREHOUSE? .........................................................................................................8 3.4 ARQUITETURA ......................................................................................................................................9 3.4.1 ARQUITETURA DE PROJETO DO DATA WAREHOUSE........................................................................9 3.4.1.1 DEPÓSITO DE DADOS 1 – SISTEMAS DE ORIGEM.........................................................................10 3.4.1.2 FLUXO 1 – DA ORIGEM PARA A CAMADA DE INTEGRAÇÃO .......................................................10 3.4.1.3 DEPÓSITO DE DADOS 2 – CAMADA DE INTEGRAÇÃO..................................................................12 3.4.1.2 FLUXO DE DADOS 2 – DA CAMADA DE INTEGRAÇÃO PARA OS DATA MARTS ............................13 3.4.1.3 DEPÓSITO DE DADOS 3 – DATA MARTS .......................................................................................13 3.4.1.4 FLUXO DE DADOS 3 – DOS DATA MARTS PARA OS RELATÓRIOS................................................13 3.4.1.5 DEPÓSITO DE DADOS 4 – OS DADOS NOS RELATÓRIOS ..............................................................13 3.4.2 OUTRAS ARQUITETURAS PARA A CONSTRUÇÃO DE UM DATA WAREHOUSE ................................14 3.4.2.1 NENHUM DATA WAREHOUSE .......................................................................................................14 3.4.2.2 PROJETO NORMALIZADO ............................................................................................................14 3.4.2.3 APENAS DATA MARTS ...................................................................................................................14 3.5 DATA MARTS .......................................................................................................................................14 3.5.1 ESQUEMA ESTRELA.........................................................................................................................15 3.6 INDEXAÇÃO.........................................................................................................................................16 3.6.1 QUAIS COLUNAS INDEXAR ..............................................................................................................17 3.6.2 TIPOS DE ÍNDICES ............................................................................................................................17 3.6.2.1 ÍNDICE ARVORE B ........................................................................................................................17 3.6.2.2 ÍNDICE DE BITMAP ........................................................................................................................17 3.6.2.3 TABELAS ORGANIZADAS POR ÍNDICES ........................................................................................17 3.6.2.4 INDEXAÇÃO DE CHAVE INVERTIDA .............................................................................................17 3.6.2.5 ÍNDICES BASEADOS EM FUNÇÃO ..................................................................................................18 3.7 FRONT END .........................................................................................................................................18 3.7.1 ACESSO AOS DADOS .........................................................................................................................19 4 PROPOSTA ..........................................................................................................................................20 4.1 COMO SERÁ FEITO..............................................................................................................................20 4.2 ETAPAS................................................................................................................................................20 4.2.1 PLANEJAMENTO ..............................................................................................................................20 4.2.2 MODELAGEM DIMENSIONAL ..........................................................................................................20 4.3 ROTINAS DE CARGA EM JAVA............................................................................................................21 4.4 FRONTEND ..........................................................................................................................................21 5 CONCLUSÃO ......................................................................................................................................22 6 BIBLIOGRAFIA..................................................................................................................................23

3

1 INTRODUÇÃO

1.1 Motivação

O desejo de aprender mais sobre data warehouse, sobre a criação e o

gerenciamento de um banco de dados com um grande volume de informações, junto

com a necessidade de um método para gerar relatórios rapidamente a partir deste

modelo. Um método indicado é o CUBO e técnicas de data warehouse.

1.2 Problema

Em sistemas baseado em BSC há a necessidade de trabalhar com grandes

volumes de informação. Toda essa informação quando armazenada em um esquema

transacional, traz toda a integridade referencial necessária, porém sua velocidade de

resposta não é suficientemente rápida por causa da quantidade de informações. Nestes

sistemas, grandes volumes de informações precisam ser acessados e o tempo de resposta

deve ser mínimo, para que os usuários possam fazer análise das informações. Também

existe a necessidade de uma ferramenta que permita flexibilidade para que o usuário

possa aplicar diversos filtros na informação analisada.

4

2 BALANCED SCORECARD

2.1 Introdução

O conceito do Balanced Scorecard (BSC) ajuda a traduzir a missão e a estratégia

das empresas em um conjunto balanceado e abrangente de medidas de desempenho, que

servem de base para um sistema de medição e de gestão estratégica.

2.2 Histórico

As empresas estão a meio caminho de uma transformação. A competição da era

industrial está se transformando na competição da era da informação. Durante a era

industrial (1850-1975), o sucesso das empresas era determinado pela maneira como se

aproveitavam dos benefícios das economias. A tecnologia era importante, porém as

empresas bem sucedidas eram sempre aquelas que incorporavam as novas tecnologias

aos ativos físicos que permitiam a produção em massa eficiente de produtos

padronizados. Medidas financeiras como o retorno sobre o capital empregado, eram

suficientes para medir a eficiência da empresa.

Entretanto, nas ultimas décadas muitas dessas premissas fundamentais da

concorrência industrial se tornaram obsoletas. As empresas não conseguem mais obter

vantagens competitivas sustentáveis apenas com a rápida alocação de novas tecnologias

e ativos físicos, e com a excelência da gestão eficaz dos ativos e passivos financeiros.

Os sistemas tradicionais de gestão e controle, ao focarem-se exclusivamente em dados

financeiros e contabilísticos, tornaram-se rapidamente obsoletos, não respondendo às

novas necessidades de monitorização do negócio. Este novo ambiente exige novas

capacidades para assegurar o sucesso competitivo.

2.3 Conceito

O Balanced Scorecard, segundo os autores, complementa as medidas financeiras

do desempenho passado, com medidas dos vetores que impulsionam o desempenho do

futuro. Os objetivos e medidas do scorecard derivam da estratégia da empresa e

focalizam o desempenho organizacional sob quatro perspectivas: financeira, clientes,

5

processos internos e aprendizagem e crescimento.

2.3.1 Perspectiva Financeira

Serve para definir o desempenho financeiro esperado da instituição e para a

maioria das instituições que utilizam o BSC, a perspectiva financeira é a meta principal

para os objetivos e metas das outras perspectivas.

2.3.2 Perspectiva Clientes

Esta perspectiva permite que as empresas identifiquem quais os segmentos de

clientes e mercados desejam competir. Conhecer os clientes é fundamental para uma

estratégia organizacional que tenha como um de seus principais focos a satisfação,

fidelidade, retenção e captação de clientes.

2.3.3 Perspectiva Processos Internos

Esta perspectiva identifica e mede os processos internos críticos, nos quais a

empresa deve alcançar a excelência para oferecer propostas de valor, capazes de atrair e

reter clientes e cumprir com as metas da perspectiva financeira.

2.3.4 Perspectiva Aprendizado e Crescimento

Esta perspectiva desenvolve objetivos e medidas para orientar o aprendizado e o

crescimento organizacional. Os objetivos estabelecidos nas perspectivas, financeira,

clientes e processos internos revelam onde a empresa deve se destacar para obter um

ótimo desempenho. Os objetivos da perspectiva aprendizado e crescimento, oferecem a

infra-estrutura que possibilita a execução dos objetivos das outras três perspectivas.

Dentro de cada perspectiva, existem objetivos específicos. Dentro destes

objetivos, existem indicadores, que mostram o quanto e como está sendo cumprido

determinado objetivo. Para cada indicador, são cadastrados nove valores para cada

período. O primeiro valor é o padrão, que seria o pior resultado aceitável, o segundo

valor é a meta, que é a meta a ser atingida, e o terceiro valor é o realizado, o valor

6

obtido pela instituição para aquele indicador. Estes três valores são cadastrados dentro

de três diferentes cenários para a instituição. O cenário otimista possui estes valores

numa previsão melhor do que o esperado. O tendêncial possui os valores mais prováveis

de ocorrerem. O pessimista possui os valores para uma situação ruim da empresa.

Indicadores podem ter diferentes periodicidades (anual, semestral, quadrimestral,

trimestral, bimestral, mensal, quinzenal, semanal, diária ou alguma outra periodicidade

que a instituição achar necessária).

2.4 Problema

O grande volume de dados que é gerado por causa da quantidade de informações

que precisam ser armazenadas acaba gerando um problema. Cada indicador possui nove

valores para cada período e é necessário sempre manter o histórico dessa informação,

para poder ser feita análise, a quantidade de informação irá sempre crescer.

Outro problema vem do fato que as informações não estão isoladas, e a

visualização de todas essas informações pode se tornar complicado. O usuário de um

sistema de BSC precisa ter disponível uma ferramenta para visualização da informação,

de maneira que possa relacionar várias informações, agrupar por datas, objetivos,

indicadores, cenários e qualquer outro relacionamento de informações que ele deseje

fazer. É necessário montar diversos relatórios, cada um abrangendo uma situação de

relacionamento de informações específica.

7

3 DATA WAREHOUSE

3.1 Conceito

Segundo Inmon, um data warehouse é uma coleção de dados orientada por

assuntos, integrada, variante no tempo, e não volátil, que tem por objetivo dar suporte

aos processos de tomada de decisão.

O data warehouse é um banco de dados, usados unicamente para a produção de

relatórios, contendo dados extraídos do ambiente de produção da empresa, que foram

selecionados e depurados, tendo sido otimizados para processamento de consulta e não

para processamento de transações. Em geral, um data warehouse requer a consolidação

de outros recursos de dados além dos armazenados em banco de dados relacionais,

incluindo informações provenientes de planilhas eletrônicas, documentos textuais entre

outros.

3.2 Características

3.2.1 Orientados ao Assunto

Refere-se ao fato do data warehouse armazenar informações sobre assuntos

específicos importantes para a empresa. Caso uma empresa venda seus produtos através

de lojas, virtuais ou não, realiza vendas no varejo e no atacado, cada loja terá seu

sistema de controle de vendas, e cada sistema pode ter seu próprio banco de dados.

Estes sistemas podem oferecer relatórios sobre vendas a respeito das informações que

ele captura, mas caso um usuário queira consultar sobre todas as vendas em uma

determinada janela de tempo, e não somente as vendas de determinada loja. Para tratar

deste tipo de situação, data warehouses devem ser orientados ao assunto, organizando

em áreas de assunto, como vendas e não organizado na origem dos dados. Assim os

dados que se encontram separados em diversos sistemas podem ser acessados a partir de

um único lugar.

3.2.2 Integrados

8

Significa que os dados, independente da origem, estão no mesmo padrão. Os

sistemas de origem podem ter padrões diferentes para a mesma informação. Uma

informação sobre sexo pode ser armazenada como M/F, 0/1 ou ainda H/M. Quando esta

informação chegar ao data warehouse, ela deverá estar usando o mesmo padrão. Na fase

de ETL (Extração, Transformação e Carga) estes problemas devem ser resolvidos.

3.2.3 Variante no tempo

O data warehouse, no seu início irá receber uma carga grande, com todas as

informações dos sistemas de origem, e depois sofrerá apenas cargas incrementais. Estas

cargas irão sempre adicionar novas informações ao data warehouse, nunca irão alterar

ou apagar alguma informação anteriormente migrada para o sistema. Esta característica

é importantíssima para possibilitar a análise de tendência, que é exigida em muitos

relatórios. A análise de tendência necessita do acesso aos dados históricos. Nos sistemas

operacionais, toda vez que é feita alguma alteração de alguma informação, a informação

anterior é perdida. Geralmente nem todo dado histórico deve ser mantido no mesmo

nível de detalhes. Informações mais recentes tendem a ter um nível de detalhamento

maior.

3.2.4 Não volátil

Significa que data warehouse é apenas para leitura. Ao contrário dos bancos de

dados operacionais, os data warehouses oferecem suporte para a geração de relatórios e

não para a captura de dados.

3.3 Por que o Data Warehouse?

Os sistemas operacionais não suportam os quatro critérios de um data

warehouse. Pois os sistemas operacionais são projetados para trabalhar com pequenos

volumes de informações. Exemplos:

• Projetos deste tipo de banco de dados são altamente normalizados e complexos,

caso seja necessário algum relatório sobre todas as vendas de algum

determinado ano, o tempo de espera pode ser inaceitável.

9

• Em um sistema operacional é necessário que as informações sejam atualizadas

em tempo real, se alguma característica do produto for alterada, esta alteração

deve refletir em todos os sistemas operacionais. No data warehouse é importante

que o produto não seja alterado, mas sim cadastrado como um novo produto,

para que possa permitir a análise de tendência do produto com essa nova

característica, em relação de como estava antes.

• Os sistemas operacionais são projetados para uma entrada rápida dos dados,

assim que a informação é lida, ela deve ser atualizada na base e a resposta deve

ser dada ao usuário. Nos data warehouses os dados são migrados, e geralmente

existe uma janela de tempo (geralmente das 20hs até às 6hs) grande para a

atualização das bases, onde a ênfase é a resposta rápida a pesquisa em

quantidades enormes de informações.

• Os padrões de utilização dos sistemas operacionais não sofrem grandes

alterações. Os sistemas de data warehouse não possuem padrões de utilização,

pois em qualquer momento pode haver alguma reunião da diretoria onde será

necessário fazer pesquisas intensas por algumas horas, e depois o data

warehouse pode ficar quase que inativo por alguns dias.

3.4 Arquitetura

3.4.1 Arquitetura de projeto do data warehouse

O data warehouse deve ter a capacidade de extrair dados de vários sistemas de

origem. Estes dados são integrados em um repositório comum, onde os dados devem ser

validados. O próximo passo é colocar os dados em um formato que os usuários possam

usar e finalmente fornecer as ferramentas de consultas para acessar o data warehouse.

A arquitetura mais utilizada é constituída de quatro depósitos de dados e três

fluxos de dados. O primeiro depósito de dados são os sistemas de origem, que

fornecerão os dados para o data warehouse. O segundo depósito é a camada de

integração. O terceiro é chamado de data mart, que é uma estrutura de consulta de alto

desempenho (HPQS). O quarto depósito são os dados nos relatórios feitos por usuários

do data warehouse. O primeiro fluxo dos dados é da origem para a camada de

integração, onde são padronizados. O segundo fluxo é da camada de integração para os

10

data marts. O terceiro fluxo é dos data marts até o usuário final. Um exemplo deste

modelo de projeto pode ser visto na figura 3.4.1.

Figura 3.4.1 Exemplo do Projeto de Data Warehouse

3.4.1.1 Depósito de dados 1 – Sistemas de origem

Sistemas de origem são aqueles sistemas que fornecerão dados para o data

warehouse. Eles podem ser sistemas de vendas, contabilidade, distribuição entre outros.

Eles podem ser pacotes de planejamento de recursos empresariais (ERP), podem ser

soluções internas da empresa, podem ser relatórios de fornecedores externos. Cada um

desses sistemas possui dados que os usuários finais precisam acessar. Freqüentemente o

usuário precisa acessar dados de todos esses sistemas para conseguir adquirir a

informação que ele busca.

3.4.1.2 Fluxo 1 – Da origem para a camada de integração

11

É neste fluxo que ocorre uma das etapas mais complexas da concepção do data

warehouse, a etapa de extração de dados. Um dos problemas é a ampla variedade de

tecnologias que podem ser utilizadas pelos sistemas de origem. Os dados poderiam estar

armazenados em planilhas eletrônicas, arquivos de textos, diferentes banco de dados

como Oracle, DB2, Informix, IMS, MySQL, PostgreSQL. É necessário extrair os dados,

independente da forma de armazenamento dos dados na origem.

Outro problema ocorre porque o data warehouse recebe uma carga inicial, e

depois apenas cargas incrementais. Realizar sempre uma carga completa é algo

problemático, pois isto iria eliminar o registro histórico, pois o histórico é

freqüentemente perdido nos sistemas de origem. Outro ponto que vai contra a realização

de cargas completas é o fato de que os data warehouses tendem a ser muito grandes. Em

muitos casos não é disponível a largura de banda e o tempo de processamento

necessários para uma carga completa. Optando por fazer apenas uma carga inicial e

depois apenas cargas incrementais, aparecem outros problemas, causados pelas cargas

incrementais. Existe uma dificuldade em determinar quais registros devem ser extraídos

do sistema de origem, pois é necessário saber como e quais dados foram alterados no

sistema de origem, para que apenas registros novos e alterados sejam movidos para o

data warehouse. Algumas técnicas para reconhecer alterações em banco de dado de

origem são:

• Indicações de tempo – Alguns dados são extraídos de sistemas que

indicam o tempo nos registros, quando são inseridos, atualizados ou

excluídos. Neste caso, a extração dos dados que devem ser migrados é

feita simplesmente através de uma pesquisa nas tabelas de origem.

• Gatilhos – Outra técnica para capturar alterações em registros é utilizar

gatilhos nos sistemas de origem. Sempre que algum registro é inserido,

alterado ou excluído, esses gatilhos gravam a alteração em algum log. A

extração então é feita com base neste log. Contudo este método não é

recomendado, pois ele exige que as bases dos sistemas de origem sejam

alteradas e a adição de gatilhos irá reduzir o desempenho dos sistemas de

origem.

• AIS (Application Integration Software) – São ferramentas de

integração de aplicativos, usadas para passar informações entre

aplicativos. Se a empresa utiliza o AIS para integrar os sistemas de

12

origem, é possível incluir o data warehouse como um nó que recebe

essas informações.

• Comparação de arquivos – Esta é a pior técnica para identificação de

alterações. É feita comparando o arquivo atual, com uma cópia do

arquivo da última vez que o data warehouse foi carregado.

3.4.1.3 Depósito de dados 2 – Camada de integração

A camada de integração (warehouse) é um banco de dados normalizado que

reúne as alimentações de todas as suas origens em um único lugar. As vantagens de ter

uma camada intermediária entre a origem e os bancos onde são executadas as consultas

são:

• Evitar a repetição da extração – Todos os data marts, irão retirar os

seus dados desta camada, evitando que mais de um data mart tenha que

acessar os dados de origem e realizar o processo de ETL. Mais de um

data mart pode acessar o mesmo sistema de origem, se não existir esta

camada de integração, o mesmo processo de ETL iria ser realizado mais

de um vez, produzindo o mesmo resultado, desperdiçando recursos.

• Garantir uma interpretação padronizada dos dados empresariais –

Todos os data marts terão a mesma informação. Retirando informações

diretamente dos sistemas de origem, possibilitando que algum data mart

trate a informação de uma maneira diferente.

• Fornecer um repositório flexível – Data marts são estruturas

desnormalizadas e difíceis de trabalhar, comprometendo o processo de

integração de dados.

Além dos dados integrados, reunidos dos sistemas de origem, a camada de

integração deve conter chaves substitutas. Geralmente são um número seqüencial, que

não tem nenhum significado comercial, nem associação com os sistemas de origem. A

justificativa de uma chave substituta pode ser facilmente entendida pelo exemplo a

seguir. Suponha que o sistema de origem tenha uma tabela chamada CLIENTES com

uma chame primária CD_CLIENTE e na camada de integração esta mesma tabela

existe. Agora, no sistema de origem, o endereço do cliente foi alterado, esta alteração

13

não pode ser refletida no data warehouse, pois ele precisa manter os dados históricos,

então, se na camada de integração a chave primária da tabela CLIENTES também fosse

CD_CLIENTE, alguma informação seria perdida, contudo, como a chave primária na

camada de integração é a chave substituta, simplesmente é adicionado o novo registro

com a informação atualizada do cliente.

3.4.1.2 Fluxo de dados 2 – Da camada de integração para os data marts

Os usuários finais nunca podem consultar dados diretamente na camada de

integração, eles sempre devem fazer suas consultas na estruturas de consultas de alto

desempenho (data marts). Os dados são inseridos nos data marts através de outro fluxo,

outro conjunto de programas de extração e carregamento. Deverá ser construído outro

conjunto de tarefas para a extração, transformação e carregamento de dados. Neste caso,

assim como no carregamento de dados para a camada de integração, deve ser feita uma

carga inicial e depois somente cargas incrementais. Entretanto, esse processo de ETL

será muito mais simples, pois os dados já estarão integrados, e os dados necessários

para cada carregamento serão facilmente reconhecidos, pois eles possuem indicação de

tempo em sua camada de integração.

3.4.1.3 Depósito de dados 3 – Data marts

Data marts são banco de dados configurados especificamente para oferecer

suporte para consultas do usuário final. Geralmente o esquema estrela é utilizado nesses

bancos de dados. Data marts e a camada de integração são estruturas lógicas e não

físicas, elas podem estar compartilhando a mesma instância do banco de dados. A

diferença física está no projeto de suas tabelas, devido a suas diferentes finalidades.

3.4.1.4 Fluxo de dados 3 – Dos data marts para os relatórios

Este fluxo de dados é criado por ferramentas, que fazem consultas SQL para os

data marts, pegam o resultado e apresentam em forma de relatório para o usuário.

3.4.1.5 Depósito de dados 4 – Os dados nos relatórios

14

O destino final dos dados são os relatórios, para que os usuários possam analisar

a informação.

3.4.2 Outras arquiteturas para a construção de um data warehouse

3.4.2.1 Nenhum data warehouse

Talvez não haja necessidade de um data warehouse, isto não significa que não

será possível fornecer relatórios para o usuário. Os relatórios podem ser gerados

diretamente dos sistemas de origem, desde que esses sistemas suportem as consultas,

que geralmente são mais pesadas para a geração do relatório. Uma boa saída para este

tipo de sistemas é o uso de tabelas de resumo dentro desses sistemas de origem, então os

relatórios são gerados a partir dessa tabela de resumo.

3.4.2.2 Projeto Normalizado

Neste caso, não são criados os data marts, os relatórios são gerados através de

consultas diretamente na camada de integração, resultando em um desempenho inferior.

Outro problema é o enorme número de tabelas que o usuário terá que trabalhar, por se

tratar de uma estrutura altamente normalizada.

3.4.2.3 Apenas data marts

Neste projeto não é construída a camada de integração. Ele se aplica melhor para

soluções momentâneas, que não precisam de dados vindos de vários sistemas diferentes.

Geralmente antes de construir um data warehouse, as empresas optam por construir

apenas um data mart, como uma fase de testes para descobrir se será vantajoso investir

em um projeto de data warehouse.

3.5 Data marts

Data marts são banco de dados que compartilham muitos dos recursos dos

warehouses, mas têm abrangência menor. Assim como um warehouse, os dados do data

mart podem ser provenientes de vários sistemas de origem, embora esses dados já

15

tenham sido integrados no warehouse, antes de chegarem ao data mart. O data mart

geralmente, assim como o warehouse, é orientado ao assunto, integrado, não volátil e

variante no tempo.

Os data marts se diferenciam dos warehouses, pois no warehouse se concentram

as necessidades da empresa inteira, e os data marts são dedicados a áreas de assuntos

específicos ou às necessidades de um departamento.

Consultando dados diretamente no data mart, os usuários terão um desempenho

muito melhor, pois enquanto os warehouses são grandes bancos de dados, estruturados

para fornecer uma origem de dados confiável e integrada, os data marts são banco de

dados menores, estruturados para fornecer acesso rápido aos dados. Os usuários também

terão muito mais facilidade em navegar pelos dados em um data mart, a

desnormalização nesses bancos reduz drasticamente o número de tabelas necessárias.

3.5.1 Esquema Estrela

Esquema estrela é uma modelagem onde o objetivo é limitar o número de uniões

entre tabelas e reduzir a complexidade dessas uniões. Este esquema é composto por dois

tipos básicos de tabela: tabelas de fato e tabelas de dimensão. A tabela de fatos contém

as transações ou valores reais que estão sendo analisado. Já as de dimensão contêm

informações descritivas a respeito dessas transações ou valores.

Cada registro de uma tabela de fatos contém uma chave primária constituída de

uma concatenação de chaves estrangeiras com tabelas de dimensão e as medidas

identificadas exclusivamente por essa chave primária. Quando é projetada uma tabela de

fatos, é necessário identificar quais medidas devem ser guardadas para serem

analisadas. A tabela de fatos é uma tabela altamente normalizada, pois cada registro

consiste em um número de atributos que podem ser designados a apenas uma chave

primária. Ela não possui grupos de repetição, todos os atributos são dependentes da

chave primária e nenhum dos atributos é dependente de atributos que não são chave,

isto garante que esta tabela esteja na terceira forma normal. A desnormalização do

esquema estrela ocorre nas tabelas de dimensão.

16

Para criar as tabelas de dimensão, são unidas várias tabelas normalizadas, assim

cada registro descreve totalmente um elemento de dimensão. Isto melhora o

desempenho da consulta do usuário, pois quando as consultas forem executadas, o

trabalho necessário para unir as tabelas já foi realizado. Tabelas de dimensão tendem a

ter muitas colunas, devido a desnormalização e curtas, comparada com as tabelas de

fatos, pois pode haver milhares de registros na tabela de fatos que correspondem a

apenas um registro na tabela de dimensão. Um campo de flag ativo geralmente esta

presente para auxiliar a armazenar o histórico da dimensão. Um exemplo de esquema

estrela esta na figura 3.5.1 abaixo.

Figura 3.5.1 O esquema estrela

3.6 Indexação

O índice na maior parte dos casos é uma estrutura separada dos dados da tabela a

que ele se refere. O índice armazena a localização de linhas no banco de dados, baseado

nos valores de colunas especificados quando o índice é criado.

17

3.6.1 Quais colunas indexar

Duas regras principais definem quais colunas devem ser indexadas: seletividade

(medida do número de valores distintos na coluna de uma tabela, comparado ao número

de linhas da tabela inteira) e critérios de seleção (especificam quais linhas de

informação devem ser incluídas no conjunto de resultados da consulta). Colunas com

seletividade menor do que 5% são boas candidatas para um índice. As colunas

apresentadas como parte dos resultados da consulta, mas não utilizadas como parte de

um predicado, não são boas candidatas para índice, desde que não sejam aplicadas

funções nessas colunas. Se alguma coluna é consultada sempre utilizando alguma

função, o índice dessa coluna deve ser criado também utilizando esta função.

3.6.2 Tipos de índices

3.6.2.1 Índice Árvore B

Estes índices contêm uma hierarquia de nível mais alto e sucessivos blocos de

índices de nível mais baixo. Esse é o tipo de índice mais comum, encontrado em quase

todos os bancos de dados.

3.6.2.2 Índice de bitmap

Envolvem a construção de um fluxo de bits, com cada bit relacionando-se a um

valor de coluna em uma única linha de uma tabela. Índices de bitmap são um fluxo de 0

e 1.

3.6.2.3 Tabelas organizadas por índices

É a mesclagem de dados e o índice no mesmo segmento, os dados e o índice são

a mesma coisa.

3.6.2.4 Indexação de chave invertida

18

Instrui o banco de dados para que indexe no valor inverso da coluna que está

sendo indexada. Às vezes isto ajuda a evitar uma concentração de blocos folhas em um

subconjunto da árvore.

3.6.2.5 Índices baseados em função

São índices construídos com algum tipo de expressão nas colunas que estão

sendo indexadas.

3.7 Front End

São ferramentas de consultas utilizadas pelos usuários do data warehouse para

buscar as informações. Algumas ferramentas como simples cliente para execução de

consultas SQL, são para usuários mais avançados que já estão familiarizados com

instruções SQL. Geralmente as ferramentas de front end tendem a isolar o usuário da

complexidade da estrutura do banco de dados. Estas ferramentas precisam satisfazer

alguns critérios:

• Deve permitir que os usuários vejam e imprimam os dados;

• Deve proporcionar a capacidade de investigar os valores gerados pelo

relatório;

• Deve permitir que os usuários desenvolvam seus próprios relatórios com

facilidade e o reproduzam conforme for exigido;

• Deve ter facilidade de uso. Esta facilidade esta concentrada em duas

áreas: a construção de relatórios e a flexibilidade de apresentação;

• Deve ter um bom desempenho. O desempenho está relacionado com todo

o data warehouse, o banco de dados, a ferramenta de consulta e o código

SQL;

• Deve permitir várias origens de dados. Possibilitando que além do data

warehouse, seja usada também outra fonte de dados para o relatório;

• Deve garantir a segurança dos dados;

• Deve permitir a análise integrada. Além de mostrar valores para o

usuário, a ferramenta deve possibilitar que ele navegue entre os dados,

19

para poder investigar detalhadamente de onde e porque ele obteve aquele

valor como resultado final;

• Preferencialmente que seja compatível com a web.

3.7.1 Acesso aos dados

O acesso aos dados pode ser feito por três métodos:

• Relatórios padrão: são os relatórios específicos que são distribuídos para

alguns usuários;

• Consultas ad hoc: estas consultas geralmente são feitas utilizando-se de

ferramentas para navegação entre os dados;

• Análise multidimensional (OLAP): OLAP permite que o usuário analise

profundamente os dados, vendo estas informações em diferentes ângulos.

20

4 PROPOSTA

4.1 Como será feito

Será construído um data mart, que terá como origem um sistema que já está em

funcionamento. Os dados, depois de carregados e tratados, serão inseridos diretamente

nesse data mart, que será modelado com um esquema estrela. A fase de ETL será feita

com rotinas em Java. Como ferramenta de relatório será usada Oracle Discoverer.

4.2 Etapas

4.2.1 Planejamento

Primeiramente foi realizado o estudo teórico sobre data warehouse e os assuntos

que envolvem desenvolver e gerenciar um banco de dados multidimensional. Em

seguida foi desenvolvida uma primeira versão da modelagem dimensional. A próxima

etapa é iniciar o desenvolvimento da ferramenta de ETL e aperfeiçoar a modelagem

dimensional.

4.2.2 Modelagem Dimensional

A versão atual da modelagem pode ser vista na figura 4.1 abaixo. Ainda falta

definir quais as uniões que serão feitas, e como será a tabela de auditoria.

21

Figura 4.1 Modelagem inicial

4.3 Rotinas de carga em Java

As rotinas para extração, tratamento e carregamento dos dados da origem até o

data mart serão feitas utilizando Java.

4.4 FrontEnd

Foi selecionado o Oracle Discoverer como Front-End, pois é uma ferramenta

que pode ser executada via o navegador do usuário, assim como o sistema no qual serão

extraídas informações, além de cumprir com a maioria dos requisitos necessários de

uma ferramenta front end.

22

5 CONCLUSÃO

O propósito desses seis primeiros meses de trabalho foi estudar as características

de construção e gerenciamento de um data warehouse, modelagem multidimensional e

ferramentas que serão utilizadas no projeto.

Após esses primeiros seis meses, estes objetivos foram atingidos. São de

conhecimento as características de um banco de dados com ênfase no desempenho de

grandes consultas, e também os assuntos sobre modelagem multidimensional, já estando

pronto o primeiro protótipo da modelagem do sistema. As ferramentas que serão

utilizadas no projeto serão o Oracle como base de dados, o Oracle Discoverer como

ferramenta de front end e, para realizar a ETL, será utilizado um programa na

linguagem Java.

O trabalho para os próximos seis meses será aperfeiçoar a modelagem

multidimensional, iniciar os estudos e a implementação da ferramenta de ETL e

aperfeiçoar o estudo do Oracle Discoverer.

23

6 BIBLIOGRAFIA

[1] KAPLAN, Robert. S., e NORTON, David P. A estratégia em ação: Balanced Scorecard. Rio de Janeiro: Campus, 1997

[2] KAPLAN, Robert. S., e NORTON, David P. Kaplan e Norton na prática. Rio de Janeiro: Campus, 2004 [3] COREY Michael, ABBEY Michael, ABRAMSON Ian, TAUB Ben. Oracle 8i Data Warehouse. Rio de Janeiro: Campus, 2001