universidade federal de santa catarina … · o primeiro valor é o padrão, que seria o pior...
TRANSCRIPT
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