Universidade do Vale do Paraíba

Faculdade de Ciência da Computação

Curso de Ciência da Computação

Implementação de Cubo OLAP sobre um

Data Warehouse

Leonardo Christofoletti Schio

Relatório do Trabalho de Conclusão de Curso

apresentado à Banca Avaliadora da Faculdade de
Ciência da Computação da Universidade do Vale do
Paraíba, como parte dos requisitos para obtenção do
Título de Bacharel em Ciência da Computação.

São José dos Campos – SP

Dezembro de 2006
 Implementação de Cubo OLAP sobre um Data Warehouse

Leonardo Christofoletti Schio

Banca Avaliadora
Presidente Prof. Moacir de Souza Prado

Orientador Prof. Dr. Marcelo Limeira Saraiva

Membro A Prof. Dr. Nelson José Freitas da Silveira

_______________________________
Prof. Dr. Marcelo Saraiva Limeira
Orientador Acadêmico

______________________________________
Prof. Dr.Márcio Magini
Coordenador da Disciplina de TCC

Data:
 Resumo

Áreas de gerenciamento da informação adquiriram há décadas o conceito

de BI (Business Intelligence) para auxiliar em seus processos, porém muitas
empresas ainda utilizam ferramentas como planilhas eletrônicas ou bancos de
dados inadequados para realizar análise de seus dados, os quais não conseguem
cruzar muitas informações relevantes para controle e principalmente tomadas de
decisão. A fim de suprir estas necessidades, usuários costumam aliar os conteúdos
das planilhas com levantamento de dados manuais. Porém utilizando OLAP
(Online Analytical Processing), ferramenta de análise de dados multidimensional,
é possível agregar os dados trabalhando as informações desde um nível macro até
o menor detalhe além de apresentar uma flexibilidade de análise de ângulos
diferentes. Este trabalho de graduação tem como objetivo a transposição de dados
transacionais OLTP (Online Transaction Processing) que representam o volume
de dados de uma rede de supermercados, para o modelo de dados dimensional
utilizado no OLAP. Este modelo e suas composições arquiteturais são detalhadas
durante a implementação do cubo OLAP em um Data Warehouse utilizando a
base de dados citada.
 Sumário

1. Introdução
1.1 Antecedentes........................................................................................ 1
1.2 Descrição do Problema......................................................................... 4
1.3 Objetivo................................................................................................ 5
1.4 Restrições............................................................................................. 6
1.5 Organização do Trabalho...................................................................... 6

2. Embasamento teórico
2.1 Conceitos Básicos................................................................................. 7
2.1.1 Modelos de dados Relacional...................................................... 7
2.1.2 Sistemas OLTP............................................................................ 11
2.1.3 DataWarehouse........................................................................... 12
2.1.4 Data Warehouse versus dados operacionais................................ 15
2.1.5 Modelo de dados Dimensional.................................................... 16
2.1.5.1 Dimensões e Fatos........................................................... 17
2.1.5.2 Esquemas do tipo Estrela e Floco de Neve...................... 18
2.1.6 Características do Data Warehouse............................................ 21
2.1.6.1 Granularidade................................................................... 25
2.1.7 Data Marts.................................................................................. 27
2.1.8 Data Warehouses versus Data Marts.......................................... 29
2.1.9 Arquiteturas de um Data Warehouse.......................................... 31
2.1.10 Metadados................................................................................ 35
2.2 Metodologia......................................................................................... 37
2.2.1 Sistemas OLAP........................................................................... 38

3. Desenvolvimento
3.1 Especificação do Sistema…………………………………………….. 41
3.2 Projeto Preliminar……………………………………………………. 42
3.2.1 Base de Dados………………………………………………….. 42
3.2.2 Implementando Dimensões…………………………………….. 45
3.2.2.1 Níveis de Dimensões…………………………………… 47
3.2.3 Implementando o Cubo………………………………………… 48
3.2.3.1 Medidas……………………………………………….... 49
3.2.3.2 Processamento do Cubo………………………………... 49

4. Resultados
3.1 Validação…………………………………………………………….. 51

5. Conclusões …………………………………………………………….... 55
 Índice de Figuras

Figura 1 - Fluxo de dados para o Data Warehouse ........................................... 15

Figura 2 - Representação do Esquema Estrela (Star Schema) .......................... 19
Figura 3 - Integração de dados no Data Warehouse ......................................... 22
Figura 4 - Variável no tempo ............................................................................ 22
Figura 5 - Não volatilidade de dados no Data Warehouse ............................... 23
Figura 6 - Detalhe dos níveis de Granularidade ............................................... 25
Figura 7 - Níveis de Granularidade .................................................................. 27
Figura 8 - Arquitetura genérica de um Data Warehouse .................................. 32
Figura 9 - Arquitetura de 2 camadas ................................................................ 33
Figura 10 - Arquitetura de 3 camadas .............................................................. 35
Figura 11 – Conexão com a base de dados…………………………………… 43
Figura 12 – Estrutura de dados do Analysis Server Manager………………… 43
Figura 13 – OLE DB provider para drivers ODBC…………………………... 44
Figura 14 – Definição do tipo de dimensão…………………………………… 45
Figura 15 – Seleção de dados para uma dimensão……………………………. 46
Figura 16 – Definição de níveis……………………………………………….. 47
Figura 17 – Cube Editor, criação da tabela fato………………………………. 48
Figura 18 – Criação de medidas………………………………………………. 49
Figura 19 – Método de armazenamento………………………………………. 50
Figura 20 – Cubo “Vendas"…………………………………………………… 51
Figura 21 – Espaço em disco versus desempenho ............................................ 53
Figura 22 – Visualização do conteúdo do Cubo, relatório dinâmico…………. 54
Figura 23 – Troca de posição entre medidas e dimensão produto……………. 55
Figura 24 – Verificação de níveis hierárquicos………………………………. 56
Figura 25 – Drill-Down………………………………………………………. 56
 Índice de Tabelas

Tabela 1 - Dados Operacionais versus dados de Data Warehouse...................... 16

Tabela 2 - Diferença entre DM Dependente e Dm Independente....................... 29
Tabela 3 - Diferenças-chave entre Data Marts e Data Warehosues ................... 30
Tabela 4 – Snow Flake versus Star Schema model 52
 Lista de Símbolos, Acrogramas e Abreviações

BI Business Intelligence
OLAP Online Analytical Processing
OLTP Online Transaction Processing
DW Data Warehouse
SQL Structure Query Language
SGDB Sistema de Gerenciamento de Banco de dados
SSAS SQL Server Analysis Services
GUI Graphical User Interface
SAD Sistemas de Apoio à Decisão
ER Entidade Relacionamento
ODBC Open Data Base Connectivity
 1

Capítulo 1
Introdução
1.1 Antecedentes

O grande desafio de todo indivíduo que gerencia qualquer processo, é a análise

dos fatos relacionados a seu dever. Ela deve ser feita de modo que, com as ferramentas e
dados disponíveis, o gerente possa detectar tendências e tomar decisões eficientes e no
tempo correto. Com essa necessidade surgiu então o conceito de BI (Business
Intelligence).
Segundo Inmon [9], há milhares de anos atrás, Fenícios, Persas, Egípcios e
outros Orientais já faziam, a seu modo, Business Intelligence, ou seja, cruzavam
informações provenientes da natureza, tais como comportamento das marés, períodos de
seca e de chuvas, posição dos astros, para tomar decisões que permitissem a melhoria de
vida de suas comunidades.
Uma fábrica por exemplo, como se conhece hoje, começou a delinear-se após a
Revolução Industrial. Antes, a produção de bens se dava, basicamente, por meio de
pequenas oficinas, que tinham como uma característica importante o fato de que o
conhecimento a respeito do produto final e como fazê-lo estava associado àquele que
efetivamente fabricava o produto, ou seja, ao artesão.
A busca incessante do homem por melhores condições de vida, aliada ao
desenvolvimento tecnológico, gerou novas necessidades a respeito de qualidade,
quantidade e preço dos produtos, o que fez a antiga oficina dar lugar ao que chamamos
hoje de indústria. Nas indústrias, um conjunto de homens e máquinas passou a ocupar
um mesmo espaço na chamada produção seriada, e com ela ocorreu a transferência da
habilidade de fabricação do homem para a máquina. Com a indústria, o conhecimento
sobre o produto final foi separado daquele que o produzia. Essa separação deu origem a
uma nova classe social em substituição ao artesão, o proletariado, e a uma nova área em
substituição às oficinas, a fábrica.
Hoje encontram-se empresas onde a fábrica, ao contrário de um século atrás, é
organizada, limpa e segura, fruto de grandes investimentos em infra-estrutura,
automação e treinamentos. A fábrica exige profissionais qualificados para lidar com
 2

equipamentos complexos, buscar melhorias contínuas e com postura voltada à qualidade

e satisfação do cliente, foco que não existia no início da industrialização. Dentro deste
novo cenário, durante o processo produtivo é gerada uma grande quantidade de dados
relacionados à qualidade, produtividade, manutenção, máquinas, materiais, produtos,
funcionários, etc. No entanto, muitas empresas ainda não sabem o que fazer com essa
massa de dados, desconhecendo sua importante utilidade como matéria-prima para a
geração de informações úteis à gestão do negócio. Muitos gerentes, que hoje sofrem por
falta de informações, podem ter um grande aliado se dispuserem de ferramentas para
processar os dados.
Esses dados têm pouca utilidade em seu estado bruto, por isso precisam ser
tratados e interpretados para que deles seja possível tirar informações e conhecimento.
Para tal, existem hoje diversas ferramentas específicas e disponíveis
comercialmente. Empresas do mundo da Tecnologia da Informação, como Oracle, IBM,
Seagate e Microsoft, oferecem softwares que podem ser ajustados às necessidades de
cada usuário ou corporação. Esta área vem hoje sendo tratada como Sistemas de Apoio
à Decisão (SAD) ou Business Intelligence (BI).
Com o surgimento dos bancos de dados, dos PC’s e das interfaces gráficas como
o Windows, aliados ao aumento da complexidade dos negócios, começaram a surgir os
primeiros produtos realmente direcionados aos analistas de negócios, que possibilitavam
rapidez e uma maior flexibilidade de análise. Estes sistemas SAD, foram projetados
como ferramentas com o propósito de ajudar a administração a definir tendências,
apontar problemas e tomar decisões inteligentes.
Segundo Inmon [9], Business Intelligence é o processo organizacional pelo qual
a informação é sistematicamente coletada, analisada e disseminada como inteligência
aos usuários que possam tomar ações a partir dela. Algumas das características dos
sistemas de BI são:

 Extrair e integrar dados de múltiplas fontes.

 Fazer uso da experiência.
 Analisar dados contextualizados.
 Trabalhar com hipóteses.
 Procurar relações de causa e efeito.
 3

 Transformar os registros obtidos em informação útil para o conhecimento

empresarial.

O aumento de atividades nas empresas acarretou o desenvolvimento de grandes

sistemas computacionais, que entre muitas de suas responsabilidades, organiza, distribui
e armazena as informações geradas nos seus processos.
Sistemas operacionais com os mais diversos repositórios de dados foram
utilizados a fim de suprir a demanda desses processos e com eles surgiu a necessidade
de extrair deste grande volume, informações essenciais para tomada de decisões
estratégicas e gerenciais aliando as ferramentas computacionais com conceitos
administrativos.
Business Intelligence permite que empresas organizem enormes quantidades de
dados, de forma rápida, meticulosa e com aguçada precisão analítica, para melhor
tomada de decisões.
Segundo Netpartner [1], os objetivos da implementação de um sistema formal de
Business Intelligence podem ser também relacionados:

 Antecipar mudanças.
 Antecipar ações.
 Descobrir novos potenciais.
 Aprender com os sucessos e as falhas dos outros.
 Conhecer novas tecnologias, produtos ou processos que tenham impacto no
negócio.
 Conhecer sobre mudanças regulamentais que possam afetar o negócio.
 Rever as próprias práticas.
 Auxiliar na implementação de novas ferramentas gerenciais.
 4

1.2 Descrição do Problema

A ênfase do planejamento estratégico poderia trazer benefícios significativos

para empresas. Utilizando uma gestão voltada a informações, controlada e orientada
para o mercado, são capazes de oferecer com rapidez serviços e produtos personalizados
para seus clientes.
Com iniciativa para mudanças, as empresas podem utilizar a inteligência de
negócios, ou Business Intelligence, para proporcionar ganhos nos processos decisórios
gerenciais e nos de alta administração. Podem competir em um mercado mais dinâmico,
ao definir melhor seu posicionamento através da análise de itens como a concorrência,
os compradores e fornecedores, os sinais do mercado, os movimentos competitivos, o
mapeamento de grupos estratégicos, o cenário em que atuam, etc.
Segundo SAP [3], o desenvolvimento de uma estratégia é em essência o
desenvolvimento de uma fórmula ampla que norteará o modo como uma empresa irá
competir, quais serão suas metas a curto, médio e longo prazo, e quais serão as políticas
necessárias para o cumprimento destas metas. Além do planejamento estratégico, o
cenário atual é dinâmico e exige que empresas de todos os tamanhos tenham capacidade
de resposta imediata, apoiadas por um processo de tomada de decisões rápido e
objetivo. Para tanto, a informação precisa estar disponível para as pessoas certas, no
formato esperado, no momento e local desejado. Neste contexto, a informação
representa um recurso de alto teor estratégico, que necessita ser aproveitado como
gerador de diferenciais e vantagens competitivas.
Projetos de Business Intelligence utilizam softwares para análise de padrões e
gestão da informação. Estes se baseam em procedimentos e processos que facilitam a
gestão de um negócio e viabilizam a programação de sistemas de informação para apoio
operacional às rotinas de trabalho. Por isso, pensando em possuir uma ferramenta de
informações gerenciais que possa dar suporte a decisões estratégicas, é necessário
utilizar sistemas de informação e bancos de dados estruturados, onde é possível obter
respostas rápidas e mais confiáveis de uma determinada pesquisa além de ter histórico
de tudo que acontece. Portanto, a importância do BI no planejamento estratégico
começa a ser sentida a partir do momento em que uma empresa adota uma postura de
trabalho mais voltada à gestão da informação.
 5

Somente com a informação íntegra e confiável é possível criar estratégias que

atendam melhor seus clientes e colocar a empresa em um patamar de competitividade
mais lucrativo.
A todo o momento uma grande quantidade de informações sobre os mais
variados aspectos dos negócios de uma empresa é gerada e armazenada, passando a
fazer parte de uma base de conhecimento. Entretanto, esses dados estão espalhados por
vários sistemas de difícil integração, sem qualidade e indisponíveis para os gerentes e
altos executivos que são os tomadores de decisões estratégicas das organizações.
Para suprir essa deficiência pretende-se fazer uso de conceitos de Business
Intelligence, utilizando um Data Warehouse como base para o estudo, que se constitui
de um conjunto de arquiteturas e/ou sistemas de informação orientados a assunto que
existem em plataformas segregadas do ambiente operacional (transacional),
manipulando grande volume de dados, principalmente históricos, e dão origem a
consultas (read-only) invariavelmente não previsíveis, que tem por objetivo dar suporte
a esses processos.
Pretende-se apresentar os principais conceitos e questões envolvidas com esta
tecnologia, procurando enfatizar a criação de Cubo Multidimensional e inferir a
importância de sua utilização para garantir agilidade e segurança na tomada de decisão,
definindo o caminho a ser desenvolvido desde a modelagem até a implantação do Cubo
OLAP em um Data Warehouse.

1.3 Objetivo

A meta principal será definir e provar o conceito de Business Intelligence através

da implementação de um banco de dados secundário focado essencialmente para
realização de consultas. Obter por meio da utilização desta tecnologia aceleração no
sistema de processamento de dados.
Pretende-se agregar análises detalhadas coletando, analisando e extraindo
informações sobre bases de dados, que serão utilizadas no auxílio ao processo de
gerenciamento e tomadas de decisão.
Para alcançar os objetivos envolvidos pretende-se projetar um Cubo de dados
utilizando a tecnologia de sistemas OLAP, utilizando um protótipo de um base de dados
 6

relacional e constituindo um Data Warehouse, cujas definições arquiteturais serão

reproduzidas no embasamento teórico deste trabalho. Pretende-se aprender técnicas
clássicas de projeto de Data Warehouse, incluindo as principais responsabilidades de
mantê-lo.
Um levantamento das necessidades de uma organização, combinando com os
dados disponíveis, será realizado a fim de obter um melhor aproveitamento das
consultas.

1.4 Restrições

Para implementação deste trabalho foi utilizada a ferramenta de Sistema de

Gerenciamento de Banco de Dados (SGDB) Microsoft SQL Server 2000. Uma versão
de avaliação deste software foi utilizada somente para suprir os objetivos acadêmicos
deste trabalho.
As bases de dados utilizadas fazem parte de um protótipo de um banco de dados
de uma rede de supermercados, portanto não são configuradas como dados fictícios.

1.5 Organização do Trabalho

O trabalho está organizado em cinco capítulos. No capítulo 01 foi inserido uma

introdução de um problema encontrado em consultas de dados de uma organização que
é o escopo deste Trabalho de Conclusão de Curso. No capítulo 02 incluirá uma revisão
da teoria que embasa a solução do problema. No capítulo 03 será realizada uma
abordagem detalhada do problema e de como está sendo resolvido. No capítulo 04
pretende-se apresentar os resultados obtidos através da aplicação de conceitos de
Business Intelligence. O capítulo 05 incluirá as conclusões em que chegou-se com o
desenvolvimento do projeto, bem como as referências utilizadas no trabalho.
 7

Capítulo 2
Embasamento Teórico

2.1 Conceitos Básicos

O desenvolvimento da tecnologia da informação, aliado à globalização e ao

aumento da competitividade, nos mais diversos setores estão facilitando a integração
entre o mercado produtor e consumidor. A cada negócio realizado, ou seja, a todo o
momento, uma grande quantidade de dados é gerada e armazenada, passando a ser um
importante recurso da empresa.
Um dos principais problemas é que os processos de tomada de decisão na
maioria das vezes envolvem uma grande quantidade de dados, caracterizando-se pela
necessidade de determinar relacionamentos complexos.
De acordo com Hackathorn e Inmon [10], Sistema de Apoio à Decisão (SAD) é
um sistema computacional integrado, interativo, consistindo de ferramentas analíticas e
capacidades de gerenciamento da informação, projetado para auxiliar tomadores de
decisão na solução de problemas relativamente grandes e não estruturados.
Data Warehouse vem sendo consideravelmente utilizado nos últimos anos, com
o objetivo de fornecer um ambiente adequado a estas análises. Segundo Inmon [11], um
Data Warehouse é uma coleção de dados orientados por assuntos, integrado, não-volátil,
e variável em relação ao tempo, que tem por objetivo dar suporte aos processos de
tomada de decisão.
A tecnologia de Data Warehouse vem sendo utilizada como uma ferramenta de
suporte aos sistemas gerenciais de tomada de decisões, proporcionando descobertas de
conhecimentos relevantes que podem ser de extrema importância para as organizações.

2.1.1 Modelo de dados Relacional

O modelo de dados relacional é uma ferramenta de modelação importante

porque os seus conceitos básicos são simples e gerais e porque o seu desenho não
depende de nenhum tipo de programa.
 8

De acordo com Date [7], o objetivo fundamental do modelo relacional, como o

seu próprio nome indica, é a relação. O modelo relacional apresenta os dados como um
conjunto de relações e tem um sólido fundamento, com base na Teoria Matemática dos
Conjuntos e na Álgebra Relacional.
Uma relação pode ser visualizada como uma tabela que é o modelo físico de um
conceito matemático: a relação. A tabela é uma forma familiar de representação de
informação. O modelo relacional baseia-se em três conceitos básicos: domínio, relação
e atributo.
O domínio é um conjunto de valores que possuem determinadas propriedades
em comum; ao conjunto de todos os valores possíveis para um determinado atributo dá-
se o nome de domínio. O domínio engloba dados atómicos ou simples, porque não
podem sofrer mais nenhuma decomposição.
Uma relação representa um conjunto de objetos de um tipo particular. Os objetos
que pertencem à relação são, no essencial, os elementos que obedecem às propriedades
da relação. Assim, a relação é um conjunto com propriedades próprias, em que os seus
elementos se designam por tuplas ou linhas. A relação pode-se definir da seguinte
forma: dados os conjuntos C1, C2, ... Cn, R é uma relação sobre esses n conjuntos se for
um conjunto de n-tuplas, em que o seu primeiro elemento provém de C1, o segundo
elemento de C2 e assim sucessivamente. Isto é: R é um subconjunto do produto
cartesiano C1 X C2 X ...X Cn.
Uma relação define-se sobre um certo número de domínios e engloba dois
componentes: o cabeçalho e o corpo. O cabeçalho é um conjunto de atributos em que
cada atributo corresponde a um domínio. O corpo corresponde a um conjunto de tuplas
(mais precisamente ‘n-tuplas’ em que n é o número total de atributos). Cada tupla é um
conjunto de valores: um por cada atributo constante do cabeçalho.
Uma relação engloba elementos (atributos) provenientes de um ou mais
conjuntos. Os conjuntos numa relação funcionam como domínios, fornecem o intervalo
de valores que cada um dos seus atributos pode assumir. Os termos atributo e coluna são
aceitos como sinônimos. Cada linha da tabela, representa uma proposição sobre
determinada entidade. Enquanto que as linhas representam os valores atuais dos
atributos, os domínios simbolizam todos os valores possíveis. As linhas variam com as
circunstâncias enquanto que os domínios e os atributos são constantes.
 9

Uma relação pode conter qualquer número de linhas e de atributos. Se a relação

tiver um único atributo ela diz-se ‘unitária’; se tiver dois então é ‘binária’, e assim
sucessivamente. O número de atributos designa-se por grau da relação. O total de linhas
é a sua cardinalidade. Uma relação caracteriza-se por:

 Ter um nome único dentro do mesmo diagrama de modelo de dados relacional.

 Ter de zero a n linhas, cuja ordenação é indiferente dado que não são
identificadas pela sua posição. Uma relação sem nenhuma linha diz-se vazia.
 Ser composta por um ou mais atributos, onde a ordem não é importante, pois
identificam-se pelo nome e não pela sua posição.
 Cada um dos atributos contém valores retirados de um domínio particular, o que
quer dizer que num mesmo atributo os dados são obrigatoriamente todos do
mesmo tipo.
 Numa mesma relação não podem existir dois atributos com o mesmo nome.
 Cada relação tem que ter uma chave primária. Uma chave primária é um
atributo, ou combinação de atributos, cujos valores proporcionam uma
identificação unívoca das tuplas de uma relação, ou seja, um certo valor para a
chave só pode aparecer uma única vez em cada relação. Significa ainda que as
tuplas de uma relação são todas diferentes entre si e não são permitidas linhas
duplicadas.
 A intersecção de uma coluna com uma linha corresponde a um dado ou valor.
Não é permitida a existência de grupos de atributos repetidos.
 Os dados, ou valores, são sempre de tipo atómico.

Uma tabela que cumpra estes requisitos pode-se considerar equivalente a uma
relação. Estas tabelas, de tipo especial, poderão receber a designação de R-tabelas. Uma
base de dados relacional é composta por um conjunto de tabelas deste tipo muito
particular.
Um modelo de dados relacional é um conjunto de esquemas de relações sujeitos
a um conjunto de restrições de integridade. Há três tipos de restrições de integridade que
se especificam sobre os modelos de dados relacionais: a chave de uma relação, a
integridade da tabela, a integridade referencial. As regras ou restrições de integridade
 10

asseguram que o modelo de dados reflita adequadamente a realidade, sem qualquer

ambigüidade ou redundância.
A chave é um atributo cujo valor identifica uma e uma só linha de uma relação.
Por vezes essa identificação unívoca só é possível através de uma chave composta que
consiste na menor combinação de atributos com essa propriedade. Uma relação tem
sempre, pelo menos, uma chave: a chave primária que é escolhida do conjunto das
chaves candidatas. Para a inserção na relação de uma linha de dados ter êxito, é
obrigatório fornecer os valores para os atributos componentes da chave primária. Os
valores dos atributos que não pertencem àquela chave podem não ser conhecidos na
altura da inserção e podem ser representados por valores nulos. A construção de uma
chave primária não traz qualquer tipo de limitação no acesso aos dados, pois as linhas
continuam a poder ser encontradas através da indicação de valores para qualquer um
dos seus atributos. Como no modelo relacional a associação da informação se faz
através da comparação de valores contidos nos atributos das relações, a chave primária é
a única forma de se fazer associação de informação sem que haja lugar a qualquer tipo
de ambigüidade.
Uma relação é definida como um conjunto de tuplas. Por definição, todos os
elementos de um conjunto são distintos, pelo que as tuplas têm que ser necessariamente
diferentes entre si. Isto quer dizer que numa relação não pode haver duas tuplas com a
mesma combinação de valores para todos os seus atributos. No entanto, e em termos
práticos existe sempre um subconjunto de atributos que não se repetem. A essa
combinação de atributos dá-se o nome de super-chave da relação R.
Uma chave é uma super-chave a que não se pode retirar nenhum atributo sob
pena de já não ser assegurada a integridade dos dados.
Um esquema relacional pode ter mais de uma chave, a que se dá o nome de
chave candidata. Quando um esquema relacional tem várias chaves candidatas a escolha
deve recair sobre aquela que é composta pelo menor número de atributos ou que melhor
se insira no ambiente da relação.
Os atributos que compõem uma chave primária não podem conter o valor nulo,
pois numa relação de um diagrama de modelo de dados relacional utilizam-se os valores
constantes nesses atributos para identificar as respectivas linhas. Se, por exemplo, duas
ou mais linhas tiverem o valor nulo nos atributos não seria possível distingui-las entre
si. Por definição, um valor nulo não tem capacidade de identificação, pelo que uma
 11

chave primária nunca pode ser nula. Se a chave for composta nenhum dos seus
elementos pode ter o valor nulo, o cumprimento desta regra assegura que é sempre
possível identificar cada um das tuplas de uma relação.
Segundo Date [7], um banco de dados relacional é um banco de dados percebido
por seus usuários como uma coleção de “RelVars” ou de modo mais informal, tabelas.
Um sistema relacional é um sistema que admite bancos de dados relacionais e operações
sobre esses bancos de dados, incluindo em particular as operações de restrição, projeção
e junção. Essas operações, e outras semelhantes a elas, são conhecidas coletivamente
como álgebra relacional, e todas elas são operações em nível de conjunto. A
propriedade de fechamento dos sistemas relacionais significa que a saída de toda
operação é do mesmo tipo de objeto que a entrada (são todas as relações), o que
significa que podemos escrever expressões relacionais aninhadas. As RelVars podem
ser atualizadas por meio da operação de atribuição relacional. As operações conhecidas
de atualização INSERT, UPDATE e DELETE podem ser consideradas atalhos para
certas atribuições relacionais comuns.
A teoria formal em que se baseiam os relacionais é chamada modelo relacional
de dados. O modelo relacional trata apenas de questões lógicas, não de questões físicas.
Ele está relacionado com três aspectos principais dos dados: a estrutura de dados, a
integridade de dados e manipulação de dados. O aspecto estrutural tem a ver com as
relações propriamente ditas; o aspecto de integridade está relacionado com “chaves
primárias” e “chaves estrangeiras”; e o aspecto manipulativo tem a ver com os
operadores (de restrição, projeção, junção etc). O princípio da informação estabelece
que todo o conteúdo de informação de um banco de dados relacional é representado de
um e somente um modo, especificamente sob a forma de valores explícitos em posições
de colunas nas linhas das relações. As únicas variáveis permitidas em um banco de
dados relacional são, especificamente, RelVars (Variáveis Relacionais).

2.1.2 Sistemas OLTP

Em todas as empresas, o processo de criação de negócios é composto por uma

série de eventos que caracterizam suas atividades principais. A natureza e freqüência
destes eventos variam conforme o tipo de negócio em que uma empresa está envolvida:
 12

um produto é manufaturado, uma conta é creditada enquanto outra é debitada, um

assento é reservado, um pedido é incluído, etc.
O controle e processamento corretos destes eventos são críticos para uma
empresa, sendo que estas atividades contribuem para seu sucesso ou fracasso. Para isso,
a maioria das organizações possui um conjunto de sistemas conhecidos como Sistemas
Transacionais ou Sistemas OLTP (OnLine Transaction Processing) que capturam os
eventos de forma individual e todos os detalhes associados a eles.
Segundo Takai [10], cada um destes sistemas está encarregado de um tipo
diferente de atividades e trata das transações de negócios segundo um conjunto de
regras que garanta sua consistência e o armazenamento de todos os detalhes associados.
Para um sistema OLTP, os princípios de desenho como normalização e consistência de
transações são extremamente críticos. Porém, por tratar as transações de forma
individual, os sistemas OLTP falham no que se refere a questões sobre o processo do
negócio, como “quais foram os produtos mais vendidos durante o mês passado?” ou
“quais produtos estão perdendo market share?” ou ainda “quais são nossos clientes mais
fiéis?”.
Os sistemas transacionais (OLTP), são os sistemas de apoio às operações da
empresa registrando uma a uma cada operação que precisa de registro, são previsíveis e
suas funções usadas com freqüência regular. Em suas consultas são acessados pequenos
volumes de dados, sobretudo dados correntes exibidos por linha (ocorrência) das tabelas
de dados. Sistemas transacionais são fundamentais na operacionalização das
organizações e a base de informações para os sistemas de informação de apoio a
decisão.

2.1.3 Data Warehouse

O Data Warehouse é construído para responder questões que não estão limitadas
às transações individuais, porém tratam do processo como um todo. Para isso, o desenho
do Data Warehouse deve refletir a forma com que os especialistas enxergam o negócio e
este é o ponto chave que distingue um Data Warehouse de um sistema OLTP.
 13

Segundo Takai [10], “Warehousing” é uma técnica utilizada para recuperação e

integração de dados a partir de fontes distribuídas, autônomas e, possivelmente,
heterogêneas.
Estes dados são armazenados em um grande depósito chamado de Data
Warehouse. Um Data Warehouse sumaria os dados que são organizados em dimensões,
disponibilizando-os para consultas e análises através de sistemas de suporte à decisão.
Os Data Warehouses vêm sendo muito utilizados pelas empresas, já que
proporcionam um alicerce sólido de integração de dados corporativos e históricos para a
realização de análises gerenciais. Sua construção e implementação são feitas de uma
maneira passo a passo, organizando e armazenado os dados sob uma perspectiva de
longo prazo. Assim, partindo-se de dados históricos básicos, pode-se realizar análises de
tendências. Por sua característica básica – integração de dados provenientes de várias
fontes diferentes – a etapa mais complexa na implementação de um Data Warehouse é o
processo de carga. Neste processo, os dados distribuídos pelos vários ambientes
operacionais (bases de dados de produção, que contêm os dados utilizados pelos vários
sistemas transacionais de uma empresa) devem ser selecionados, trabalhados com o
objetivo de padronização e limpeza, transferidos para o novo ambiente e finalmente
carregados, sempre atendendo ao padrão da modelagem utilizada para o Data
Warehouse. Este processo é feito periodicamente, sendo que sua freqüência depende de
vários fatores relacionados ao modelo de negócios utilizado pela empresa e,
normalmente, não é menor que 24 horas. Desta forma, podemos dizer que os dados
armazenados no Data Warehouse são, para todos os propósitos práticos, uma longa série
de visões do banco de dados, tiradas ao longo do tempo. Uma vez que os dados são
armazenados no Data Warehouse, eles não mais sofrem atualizações, sendo, portanto,
um ambiente apenas de carga e acesso.
Após sua criação e primeira carga, o Data Warehouse passa a sofrer cargas
incrementais que devem refletir o ambiente operacional ao longo do tempo tornando-o
um imenso repositório para os sistemas de apoio à decisão.
Um Data Warehouse existe para responder as questões que as pessoas têm sobre
os negócios. Esta função contrasta fortemente com o propósito dos sistemas
transacionais que as empresas utilizam e requer que o desenho ou o modelo de dados do
Data Warehouse siga princípios completamente diferentes. As técnicas de modelagem
 14

dimensional, se aplicadas corretamente, garantem que o projeto do Data Warehouse

reflita a forma de pensar dos gerentes de negócio e possa ser utilizado para atendê-los.
A técnica utilizada para se obter um modelo para o Data Warehouse que
identifique e represente a informação importante para o modelo de negócios é a
modelagem dimensional. Quando bem definido, o modelo dimensional pode ser uma
ajuda de valor incalculável para as áreas de negócio, apoiando e otimizando todo o
processo de tomada de decisões. Um Data Warehouse corporativo possui dados
organizados da seguinte forma:

 Separados dos sistemas transacionais da empresa e populados a partir destes.

 Disponíveis, na sua totalidade, para a atividade de serem interrogados pelos
usuários de negócios.
 Integrados para ser uma base única e padrão para o modelo da empresa.
 Associados à informação temporal e a períodos de tempo definidos, como
fechamentos mensais ou baseados no ano fiscal.
 Orientados por assunto, ou seja, organizado para descrever o desempenho do
negócio.
 Acessível aos usuários que tenham um conhecimento limitado de sistemas
computacionais ou estruturas de dados.

Além desses aspectos que o fazem diferenciar de outros sistemas, destaca-se a

sua não-volatilidade, ou seja, uma vez que o dado foi carregado no Data Warehouse,
não deve mais sofrer alterações.
A figura 1 demonstra o fluxo de dados de variados sistemas OLTP, que seguem
o modelo relacional para o Data Warehouse, que disponibiliza uma base de dados para
consultas utilizadas por ferramentas específicas.
 15

Figura 1 – Fluxo de dados para o Data Warehouse

2.1.4 Data Warehouse versus dados operacionais

Os sistemas de banco de dados operacional, lidam com tratamento de muitos

usuários e transações. Segundo Mark [15], esses são freqüentemente referidos como
processamento transacional on-line (Online Transactional Processing – OLTP). Nesses
sistemas de produção, usuários poderiam estar constantemente adicionando, atualizando
e consultando informações.
Um exemplo de um OLTP é um típico aplicativo de entrada de pedido. Um
cliente chama um representante de vendas e faz um pedido de alguns produtos de um
catálogo. O vendedor pode chamar a tela de entrada de pedido e inserir os itens de linha
que o cliente deseja. O pedido é feito, o que desencadeia alocações de estoque e assim
por diante. Esse sistema OLTP requer que transações sejam rápidas e que os níveis de
inventário sejam exatos. O puro volume dessas diversas operações e a quantidade de
dados que é produzida fornecem um ambiente pobre para apoio à decisão.
Ao contrário, em um típico sistema de apoio à decisão, um representante de
maketing pode coletar dados sobre todos os clientes como alvo para uma promoção que
oferece produtos semelhantes. Como o banco de dados de Data Warehouse consiste em
informações consolidadas sobre assuntos como vendas, produtos ou clientes, isso se
revela uma tarefa simples. Além disso, como os sistemas operacionais arquivam as
 16

informações irrelevantes para operações rotineiras, a capacidade dos gerentes de

marketing de consultar eventos históricos teria sido árdua ou impossível.
Para entender o conceito de Data Warehouse, é freqüentemente esclarecedor
diferencia-lo dos sistemas operacionais comuns a partir dos quais ele ganha todas suas
informações. A tabela 1 lista algumas diferanças entre OLTP e armazenamento de
dados de Data Warehouse.

Tabela 1 – Dados Operacionais versus dados de Data Warehouse

Bando de dados operacional Banco de dados de Warehouse

Transação orientada a entidades e
relacionamentos.
Muitas tabelas, esquema normalizado.
Usuários adicionando, atualizando e
excluindo registros.
Muitos usuários acessando registros,
menos usuários informando.
Logs de transação/reversão utilizados
Muitas linhas de detalhe
Índices menores para atualizações rápidas
Dados sempre exatos atualmente; podem
ser atualizados.
Sujeito a fatos e dimensões.
Menos tabelas, esquema desnormalizado
Usuários consultando registros apenas para
leitura.
A maioria dos usuários informando
Sem logs de transação/reversão necessários.
Linhas consolidadas, resumidas.
Índices vastos para consultas otimizadas.
Exato para um momento específico no
tempo.

2.1.5 Modelo de dados Dimensional

O modelo de dados tem um papel fundamental para o desenvolvimento

interativo do Data Warehouse. Quando os esforços de desenvolvimentos são baseados
em um único modelo de dados sempre que for necessário unir estes esforços, os níveis
de sobreposição de trabalho e desenvolvimento desconexo serão muito baixos, pois
todos os componentes do sistema estarão utilizando à mesma estrutura de dados.
 17

Existe um grande número de enfoques sobre modelagem de dados já

desenvolvidos por vários autores, a maioria deles pode ser usado para construir Data
Warehouse. Dentre estes modelos apenas o multidimensional, ou dimensional será
apresentado neste trabalho.
Segundo Machado [14] em vários aspectos a modelagem multidimensional é
mais simples, mais expressiva e mais fácil de entender que a modelagem Entidade-
Relacionamento (ER), entretanto a multidimensional é relativamente um novo conceito
e ainda não tem firmeza em seus detalhes de técnicas de desenvolvimento como já tem
o modelo ER.
O modelo dimensional, também chamado de multidimensional, é o modelo
utilizado para definir um Data Warehouse, representando os indicadores importantes
para uma área de negócios que são chamados de Fatos ou métricas, e os parâmetros
chamados Dimensões, através dos quais estas métricas são vistas.

2.1.5.1 Dimensões e Fatos

Obter respostas a questões típicas de análise dos negócios de uma organização

geralmente requer a visualização dos dados segundo diferentes perspectivas. Como
exemplo: imaginem uma rede de lojas que esteja querendo melhorar o desempenho de
seu negócio, para isso, necessita examinar os dados sobre as vendas disponíveis na
empresa.
Uma avaliação deste tipo requer uma visão histórica do volume de vendas sob
múltiplas perspectivas, como por exemplo: volume de vendas por modelo, volume de
vendas por fabricante, volume de vendas por período de tempo. Uma análise do volume
de vendas utilizando uma ou mais destas perspectivas, permitiria responder questões do
tipo: “Qual a tendência em termos de volume de vendas para o mês de dezembro?”
A capacidade de responder a este tipo de questão em tempo hábil é o que
permite aos gerentes e altos executivos das organizações formularem estratégias
efetivas, identificar tendências e melhorar sua habilidade de tomar decisões de negócio.
O ambiente tradicional de bancos de dados relacional certamente pode atender a
este tipo de consulta. No entanto, usuários finais que necessitam de consultas deste tipo
via acesso interativo aos bancos de dados, mostram-se seguidamente frustrados por
tempos de resposta ruins e pela falta de flexibilidade oferecida por ferramentas de
 18

consulta baseadas na linguagem de consulta estruturada SQL (Structured Query

Language). Daí a necessidade de utilizar abordagens específicas para atender a estas
consultas.
Para compreender melhor os conceitos envolvidos, será examinado em maior
detalhe o exemplo acima. Serão chamadas de ‘Dimensões’ as diferentes perspectivas
envolvidas, no caso, produto, loja, fabricante, mês. Estas Dimensões usualmente
correspondem aos campos ‘não numéricos’ em um banco de dados. Será considerado
também um conjunto de medidas, tal como vendas ou despesas, chamadas de Fatos.
Estas medidas, ou Fatos, correspondem geralmente a ‘campos numéricos’ em um banco
de dados. A seguir, avaliam-se agregações destes Fatos (medidas) segundo as diversas
Dimensões e são armazenadas para acesso futuro. Por exemplo, calcula-se a média de
todas as vendas por todos os meses por loja.
A forma como estas agregações são armazenadas pode ser vista em termos de
dimensões e coordenadas, dando origem ao termo multidimensional.
Intuitivamente, cada eixo no espaço multidimensional é um campo/coluna de
uma tabela relacional e cada ponto um valor correspondente à interseção das colunas.
Teoricamente, quaisquer dados podem ser considerados multidimensionais.
Entretanto, o termo normalmente refere-se aos dados representando objetos ou eventos
que podem ser descritos, e, portanto, classificados por dois ou mais de seus atributos.
Estruturas relacionais podem ser usadas para a representação e o armazenamento
de dados multidimensionais. Neste caso, as abordagens encontradas incluem desde a
adoção de formas específicas de modelagem, os chamados esquemas ‘Estrela’ e ‘Floco
de Neve’, até mecanismos sofisticados de indexação.

2.1.5.2 Esquemas do tipo Estrela e Floco de Neve

Segundo Machado [14], em um esquema do tipo estrela ou “Star Schema” as

instâncias, que são coleções de informações armazenadas no banco de dados em um
determinado momento, são armazenadas em uma tabela contendo o identificador de
instância, valores das Dimensões descritivas para cada instância, e valores dos Fatos, ou
medidas, para aquela instância chamada tabela de Fatos. Além disso, pelo menos uma
tabela é usada, para cada Dimensão, para armazenar dados sobre a Dimensão chamada
tabela de Dimensão. No caso mais simples, a tabela de Dimensão tem uma linha para
 19

cada valor válido da Dimensão. Esses valores correspondem a valores encontrados na

coluna referente àquela Dimensão na tabela de Fatos.
Este esquema é chamado de estrela, por apresentar a tabela de fatos, a principal e
dominante no centro do esquema e as tabelas de Dimensões nas extremidades. O
exemplo da figura 2 mostra a tabela de Fatos ligada às demais tabelas por múltiplas
junções, enquanto as tabelas de Dimensões se ligam apenas à tabela central por uma
única junção.

Figura 2 – Representação do Esquema Estrela (Star Schema)

A tabela de Fatos é onde as medidas numéricas do fato representado estão

armazenadas. Cada uma destas medidas é tomada segundo a interseção de todas as
dimensões. No caso do exemplo, uma consulta típica selecionaria fatos da tabela de
Fato a partir de valores fornecidos relativos a cada Dimensão.
Outro tipo de estrutura bastante comum é o esquema do tipo Floco de Neve ou
“Snowflake”, que consiste em uma extensão do esquema estrela onde cada uma das
‘pontas’ da estrela passa a ser o centro de outras estrelas. Isto porque cada tabela de
Dimensão seria normalizada, quebrando-se a tabela original ao longo de hierarquias
existentes em seus atributos. No caso do exemplo, a Dimensão Produto possui uma
hierarquia definida onde a categoria se divide em marca e marca se divide em produto.
Da mesma forma, a Dimensão tempo inclui ano que contém mês e mês que contém dia
do mês. Cada um destes relacionamentos muitos-para-um (n-1) geraria uma nova tabela
em um esquema Floco de Neve.
 20

O modelo Estrela tem uma arquitetura padrão e previsível. As ferramentas de

consultas e interfaces dos usuários podem se valer disso para fazer suas interfaces mais
amigáveis e fazer um processamento mais eficiente.
De acordo com Machado [14], todas as Dimensões do modelo são equivalentes,
ou seja, podem ser vistas como pontos de entrada simétricos para a tabela de Fatos. As
interfaces do usuário são simétricas, as estratégias de consulta são simétricas, e o SQL
gerado, baseado no modelo, é simétrico.
O modelo Dimensional é totalmente flexível para suportar a inclusão de novos
elementos de dados, bem como mudanças que ocorram no projeto. Essa flexibilidade se
expressa de várias formas, dentre as quais tem-se:

 Todas as tabelas de fato e dimensões podem ser alteradas simplesmente

acrescentando novas colunas a tabelas.
 Nenhuma ferramenta de consulta ou relatório precisa ser alterada de forma a
acomodar as mudanças.
 Todas as aplicações que existiam antes das mudanças continuam rodando sem
problemas. Existe um conjunto de abordagens padrões para tratamento de
situações comuns no mundo dos negócios. Cada uma destas tem um conjunto
bem definido de alternativas que podem então ser especificamente programadas
em geradores de relatórios, ferramentas de consulta e outras interfaces do
usuário.

Outra vantagem é o número cada vez maior de utilitários administrativos e

processos de softwares serem capazes de gerenciar e usar agregados, que são de suma
importância para um bom desempenho para respostas em uma arquitetura do Data
Warehouse.
 21

2.1.6 Características do Data Warehouse

Kimball [12] conceitua que Data warehousing é um conjunto de ferramentas e

técnicas de projeto, que quando aplicadas às necessidades específicas dos usuários e aos
bancos de dados específicos permitirá que planejem e construam um Data Warehouse.
De acordo com Inmon [11], para dar suporte ao processo gerencial de tomada de
decisão, um Data Warehouse deve possuir as seguintes características:

 Orientado por assuntos: consiste em uma das características mais importantes do

Data Warehouse, pois toda modelagem do Data Warehouse é voltada em torno
dos principais assuntos da empresa, como: vendas, serviços, entre outros.
Enquanto todos os sistemas transacionais estão voltados para processos e
aplicações específicas, os Data Warehouse objetivam assuntos, ou seja, um
conjunto de informações relacionadas com uma determinada área estratégica de
uma empresa.

 Integração: é através dessa característica que é definida uma representação única

para os dados de todos os sistemas que formarão a base de dados do Data
Warehouse. Por isso, uma boa parte do trabalho na construção de um Data
Warehouse está na análise dos sistemas transacionais e dos dados que eles
contêm. Esses dados geralmente encontram-se armazenados em vários padrões
de codificação. Isso se deve aos inúmeros sistemas existentes nas empresas, e ao
fato deles terem sido projetados por diferentes analistas. Isso quer dizer que os
mesmos dados podem estar em formatos diferentes. Os dados referentes aos
gêneros masculino e feminino podem estar representados de formas diferentes,
como: M (masculino) e F (feminino), ou H (homem para masculino) e M
(mulher para feminino). As mesmas informações estão em formatos diferentes, e
isso em um Data Warehouse, não pode acontecer. Portanto, é por isso que
deverá existir uma integração de dados como demonstrado na figura 3,
definindo-se uma maneira uniforme de se armazenar os mesmos, e isso gera
bastante trabalho.
 22

Figura 3 – Integração de dados no Data Warehouse

 Variável no tempo: é outra característica de um Data Warehouse. Os Data

Warehouses são variáveis em relação ao tempo, ou seja, eles mantêm o histórico
dos dados durante um período de tempo muito superior ao dos sistemas
transacionais. Em um sistema transacional, a finalidade é de fornecer as
informações no momento exato. Já no Data Warehouse, o principal objetivo é
analisar o comportamento das mesmas durante um período de tempo maior,
como ilustrado na figura 4. Assim, os gerentes tomam as decisões em cima de
fatos e não de intuições.

Variação em relação ao tempo

Operacional Data Warehouse

 Horizonte de tempo: atual até 60 –  Horizonte de tempo: 02 – 05 anos.

90 dias.  Inserção de registros.
 Atualização dos registros.  Estrutura de chave contém um
 Estrutura de chave pode conter ou elemento de tempo.
não um elemento de tempo.

Figura 4 – Variável no tempo

 23

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

Não volátil

Operacional Data Warehouse

 Incluir
 Excluir  Carregar
 Alterar  Acessar
 Acessar

Figura 5 – Não volatilidade de dados no Data Warehouse

Inmon [11] afirma que antes dos dados serem inseridos no Data Warehouse, eles
sempre passam por filtros. Com isso muitos deles jamais saem do ambiente
transacional. A maior parte dos dados é física e radicalmente alterada quando passa a
fazer parte do Data Warehouse. Dificilmente ocorre a redundância de dados entre os
dois ambientes, resultando em menos de 1 por cento de duplicações.
De acordo com Takai [10], a localização dos dados pode estar fisicamente
armazenada de três formas:
 24

 Centralizado: banco de dados num Data Warehouse integrado, com a finalidade

de maximizar o poder de processamento e agilizar a busca dos dados. Esse tipo
de armazenamento é bastante utilizado. Porém, há o inconveniente do
investimento em hardware para comportar a base de dados muito volumosa, e o
poderio de processamento elevado para atender satisfatoriamente às consultas
simultâneas de muitos usuários.

 Distribuído: vários Data Marts, armazenados por áreas de interesse. Por

exemplo, os dados financeiros num servidor, dados de marketing em outro e
dados da contabilidade em um terceiro lugar. Essa pode ser uma saída
interessante para quem precisa de bastante desempenho, pois isso não
sobrecarrega um único servidor, e as consultas poderão ser sempre atendidas em
tempo satisfatório.

 Níveis de detalhes: as unidades de dados são mantidas no Data Warehouse.

Armazenam-se dados altamente resumidos em um servidor, dados resumidos
noutro nível de detalhe intermediário no segundo servidor e os dados mais
detalhados (atômicos), num terceiro servidor. Os servidores da primeira camada
podem ser otimizados para dar suporte a um grande número de acessos e um
baixo volume de dados, enquanto alguns servidores nas outras camadas podem
ser adequados para processar grandes volumes de dados, mas prevendo um
baixo número de acessos. Cada nível de detalhe possui um horizonte de tempo
definido para a permanência dos dados. Então, o fato dos dados serem
transportados para níveis mais elevados não implica na exclusão do nível
anterior. O processo de envelhecimento ocorre quando este limite é ultrapassado,
e portanto os dados podem ser transferidos para meios de armazenamentos
alternativos ou passar de dados detalhados atuais para dados detalhados antigos.

A credibilidade dos dados tem um alto grau de importância para o sucesso de

qualquer projeto. Qualquer discordância pode causar problemas graves quando se deseja
extrair dados para suportar decisões estratégicas para o negócio das empresas. Dados de
má qualidade resultam em um suporte à decisão de baixo nível com alto risco para o
negócio da empresa.
 25

2.1.6.1 Granularidade

Consiste no nível de detalhe dos dados existentes em um Data Warehouse.

Quanto maior for o nível de detalhes, menor será o nível de granularidade. O nível de
granularidade afeta diretamente o volume de dados armazenados no Data Warehouse, e
ao mesmo tempo o tipo de consulta que pode ser respondida.
De acordo com Singh [13], o espaço em um disco e o número de índices
necessários são menores quando se tem um nível de granularidade muito alto, porém há
uma correspondente diminuição da possibilidade de utilização dos dados para atender a
consultas detalhadas.
A Figura 6 exemplifica o conceito de granularidade, utilizando dados históricos
das vendas de um produto. Cada uma das vendas ocorridas para este produto é
caracterizada por um nível de granularidade muito baixo, entretanto os somatórios das
vendas ocorridas por mês podem ser caracterizados por um nível muito alto de
granularidade.

Figura 6 – Detalhe dos níveis de Granularidade

É possível responder a qualquer consulta com o nível de granularidade muito

baixo, mas exige uma maior quantidade de recursos computacionais. Como em um Data
Warehouse, um evento isolado é raramente observado, é mais provável que ocorra a
utilização da visão de um conjunto de dados.
 26

Um nível intermediário na estrutura do Data Warehouse é formado por dados

levemente resumidos. Na passagem para este nível, os dados sofrem modificações. Por
exemplo, se as informações nos dados detalhados atuais são armazenadas por dia, nos
dados levemente resumidos estas informações podem estar armazenadas por semanas.
Neste nível, o horizonte de tempo de armazenamento normalmente fica em cinco anos e
após este tempo, os dados sofrem um processo de envelhecimento e podem passar para
um meio de armazenamento alternativo.
Um dos aspectos mais críticos no planejamento de um Data Warehouse é
conseguir o equilíbrio no nível de granularidade, pois na maior parte do tempo há uma
grande demanda por eficiência no armazenamento e no acesso aos dados, bem como
pela possibilidade de analisar dados em maior nível de detalhes. Quando uma
organização possui grandes quantidades de dados no Data Warehouse, faz sentido
pensar em dois ou mais níveis de granularidade, na parte detalhada dos dados. Na
realidade, a necessidade de existência de mais de um nível de granularidade é tão
grande, que a opção do projeto que consiste em duplos níveis de granularidade deveria
ser o padrão para quase todas as empresas.
O chamado nível duplo de granularidade se enquadra nos requisitos da maioria
das empresas. Na primeira camada de dados ficam os dados que fluem do
armazenamento operacional e são resumidos na forma de campos apropriados para a
utilização de analistas e gerentes. Na segunda camada, ou nível de dados históricos,
ficam todos os detalhes vindos do ambiente operacional. Como há uma verdadeira
montanha de dados neste nível, faz sentido armazenar os dados em um meio alternativo
como fitas magnéticas como ilustrado na figura 7.
Com a criação de dois níveis de granularidade no nível detalhado do Data
Warehouse, é possível atender a todos os tipos de consultas, pois a maior parte do
processamento analítico dirige-se aos dados levemente resumidos que são compactos e
de fácil acesso. E para ocasiões em que um maior nível de detalhe deve ser investigado,
existe o nível de dados históricos. O acesso aos dados do nível histórico de
granularidade tem alto custo e é complexo, mas caso haja necessidade de alcançar esse
nível de detalhe, ele estará disponível.
 27

Figura 7 – Níveis de granularidade

2.1.7 Data Marts

Como o Data Warehouse diz respeito a instituição como um todo, os

investimentos são altos e o retorno demorado. Geralmente os gerentes não gostam de
esperar tanto tempo por resultados e isto se constitui em uma ameaça a continuidade do
projeto.
A estratégia que as empresas normalmente adotam para amenizar estes
problemas, é começar por um Data Mart que significa uma espécie de um Data
Warehouse localizado (por setor e/ou departamento). Pega-se um processo ou setor que
é importante na organização e cria-se um Data Mart. Isto ameniza os problemas
fazendo com que uma vez tendo resultados, a organização venha a escolher outros Data
Marts serem desenvolvidos.
Para Inmon [11], um Data Mart pode ser definido como um SGBD (Sistema de
Gerenciamento de Banco de Dados) multidimensional que fornece uma estrutura
bastante flexível de acesso aos dados. Enquanto o Data Warehouse extrai, transforma e
limpa os dados dos sistemas transacionais, mantendo-os integrados em quantidades
massivas e em seu nível mais baixo, o Data Mart se serve destes dados, extraindo dados
para um departamento ou uma área de negócio, oferecendo flexibilidade e controle ao
 28

usuário final, pois com o Data Mart é possível fatiar e agrupar dados de diversas
maneiras.
Data Mart (DM) é um subconjunto do Data Warehouse, direcionado a um
departamento ou área de negócio. Para Kimball [12], o conjunto de todos os Data Marts
da organização, construídos de forma incremental, compartilhando Dimensões e Fatos
comuns, segundo um planejamento prévio, formam o Data Warehouse lógico da
organização.
O DM é uma coleção de assuntos de uma determinada área, baseado nas
necessidades de um departamento ou setor de uma empresa. Por exemplo, uma empresa
terá um DM para o departamento financeiro e outro para o departamento de marketing.
Normalmente, todos os DM possuem hardware, software, dados e programas
próprios. Esta característica de independência torna difícil o controle e coordenação dos
dados localizados em DM diferentes. Devido a esta dificuldade, torna-se necessário a
elaboração de um DM que trabalhe como um grande centralizador, ou de uma
ferramenta que permita centralizar os dados distribuídos pelos diferentes DM. De
acordo com Inmon [11] segue algumas características de um Data Mart:

 São especificados para atender a uma área ou conjunto de áreas de interesse.

 Empregam normalmente um esquema estrela no projeto de banco de dados. Esta
modelagem é elaborada com base nas exigências dos usuários finais.
 Contêm uma quantidade razoável de informações históricas, normalmente,
menor que o volume histórico do DW.
 Apresentam uma granularidade, normalmente, maior que a do DW. Esta
granularidade tem o propósito de atender às necessidades do usuário final.
 Apresentam um armazenamento dos dados altamente indexado.

Existem 2 tipos de Data Marts, DM dependente e DM independente,

relacionados na tabela 2.
 29

Tabela 2 – Diferenças entre DM Dependente e DM Independente

DM Dependente
Fonte de dados é o Data Warehouse.
Carga centralizada. Todos os DM são
atualizados pela mesma fonte.
Arquitetura de fácil crescimento.
DM Independente
Fonte de dados são os sistemas
operativos do ambiente operativo.
Carga descentralizada. Cada DM é
atualizado de forma separada e
exclusiva a partir do ambiente
operativo.
Difícil aproveitamento dos dados
existentes. A arquitetura dificulta o
crescimento.

2.1.8 Data Warehouses versus Data Marts

De acordo com Mark [15], os Data Warehouses podem ser vistos como sendo
semelhantes aos clubes de Warehouse no atacado. Eles contêm um grande inventário de
itens, mas não parecem especializar-se em uma área em particular. Os Data Marts são
como lojas de produtos especializados, como uma cafeteria ou uma padaria. Eles só
negociam café ou pães e os empacotarão em uma forma conhecida e esperada.
Um Data Mart e um Data Warehouse tendem a implicar a existência um do
outro. É largamente entendido que o projeto do Data Mart inicia a partir dos requisitos
do usuário. O projeto do Data Warehouse normalmente começa a partir da análise de
dados existentes atualmente e da maneira como pode ser coletado para ser utilizado
mais tarde.
Um Data Warehouse é uma agregação central de dados. Um Data Mart pode ser
derivado de um Data Warehouse ou o Data Warehouse pode ser derivado de Data Marts
menores especializados. O Data Mart enfatiza facilidade de acesso e capacidade de
utilização para um propósito particular de projeto. Em geral, um Data Warehouse tende
a ser estratégico mas freqüentemente incompleto; um Data Mart tende a ser tático e
dirigido para atender uma necessidade imediata. A tabela 3 resume algumas diferenças
chave entre Warehouses e Marts.
 30

Tabela 3 – Diferenças-chave entre Data Marts e Data Warehouses

Data Warehouse Data Mart

Utilização corporativa. Utilizado por departamento ou unidade
funcional.
Implementação complexa e demorada Implementação fácil e rápida
Maior volume de dados Volume de dados menor e mais
especializado
Desenvolvimento utilizando os dados Desenvolvimento a partir das necessidades
de dados dos usuários atualmente
disponíveis.

Os Data Marts são claramente a resposta rápida para as necessidades de um

departamento. O custo mais baixo e facilidade de uso permitem implementação rápida e
um retorno de investimento (ROI – Return on investment) quase instantâneo.
Freqüentemente, quando esforços de Data Mart de uma única divisão são vistos como
um sucesso, outros logo o seguirão com implementações próprias. De uma perspectiva
corporativa, a existência de vários Data Marts divisionais talvez signifique que a
organização esteja meramente a um passo de implementar uma solução no nível
corporativo.
Deve se tomar cuidado quando divisões de departamentos separados constroem
seus próprios Data Marts. É comum muitas divisões corporativas manterem diferentes
visualizações de certos conceitos de negócio. Se, por exemplo, tanto o departamento de
finanças como o de marketing implementam seu próprio Data Mart, cada um pode
monitorar as vendas mas defini-las de maneiras diferentes. Mais tarde, se alguém do
marketing precisar reunir algumas informações do Data Mart de finanças, como irá
resolver o problema das diferenças? É necessária uma visão unificada mesmo ao
construir Data Marts a partir do ponto de vista departamental.
 31

2.1.9 Arquiteturas de um Data Warehouse

Segundo SAP BW [3], uma arquitetura ‘genérica’ procura apenas sistematizar

papéis no ambiente do Data Warehouse, permitindo que as diferentes abordagens
encontradas no mercado atualmente possam ser adaptadas a ela, deve-se considerar que
esta arquitetura tem o objetivo de representar a funcionalidade do Data Warehouse
sendo que várias camadas propostas podem ser atendidas por um único componente de
software, ou seja, um software gerenciador de todo o processo do Data Warehouse.
Esta arquitetura é composta pela camada dos dados operacionais e outras fontes
de dados que são acessados pela camada de acesso aos dados. As camadas de
gerenciamento dos processos, transportes e cargas formam o centro da arquitetura do
Data Warehouse e são elas as responsáveis por manter e distribuir os dados. A figura 8
mostra a camada de acesso à informação, é formada por ferramentas que possibilitam
aos usuários extrair informações do Data Warehouse.
Todas as camadas desta arquitetura interagem com o dicionário de dados
metadados, que será abordado neste trabalho e, com o gerenciador de processos. A
seguir pode-se acompanhar as camadas que compõe o Data Warehouse.

 Camadas de bancos de dados operacionais e fontes externas: É composto pelos

dados dos sistemas operacionais das organizações e informações provenientes de
fontes externas que serão integradas para compor o Data Warehouse.
 Camada de acesso à informação: Envolve o hardware e o software utilizado para
obtenção de relatórios, planilhas, gráficos e consultas. É nesta camada que os
usuários finais interagem com o Data Warehouse, utilizando ferramentas de
manipulação, análise e apresentação dos dados, incluindo as ferramentas de
visualização dos dados.
 Camada de acesso aos dados: Esta camada faz a ligação entre as ferramentas de
acesso à informação e os bancos de dados operacionais. Esta camada se
comunica com diferentes sistemas gerenciadores de bancos de dados, sistemas
de arquivos e fontes sob diferentes protocolos de comunicação, o que é
denominado de acesso universal de dados.
 32

 Camada de metadados (Dicionário de dados): Metadados são as informações que

descrevem os dados utilizados por uma organização, isto envolve informações
como descrições de registros, comandos de criação de tabelas, diagramas
Entidade Relacionamento ER, dados de um dicionário de dados. É necessário
que exista uma grande variedade de metadados no ambiente de arquitetura do
Data Warehouse para que ele mantenha sua funcionalidade e os usuários não
precisem se preocupar onde residem os dados ou a forma com que eles estão
Armazenados.
 Camada de gerenciamento de processos: É a camada responsável pelo
gerenciamento dos processos que contribuem para manter o Data Warehouse
atualizado e consistente. Está envolvida com o controle das várias tarefas que
devem ser realizadas para construir e manter as informações do dicionário de
dados e do Data Warehouse.
 Camada de transporte: Esta camada gerencia o transporte de informações pelo
ambiente de rede. Inclui a coleta de mensagens e transações e se encarrega de
entregá-las em locais e tempos determinados. Também é usada para isolar
aplicações operacionais, do formato real dos dados nas duas extremidades.
 Camada do Data Warehouse: Descreve o Data Warehouse propriamente dito,
corresponde aos dados utilizados para obter informações. Às vezes o Data
Warehouse pode ser simplesmente uma visão lógica ou virtual dos dados,
podendo não envolver o armazenamento dos mesmos ou armazenar dados
operacionais e externos para facilitar seu acesso e manuseio.

Figura 8 – Arquitetura genérica de um Data Warehouse

 33

Uma opção de arquitetura para o Data Warehouse é a arquitetura de ‘2 camadas’

onde utiliza-se um computador de alta capacidade como servidor, isto é uma
incorporação das aplicações utilizadas pelos usuários (front-ends) com os componentes
do servidor back-end (interface interna, codificada em forma de algoritmo,
procedimentos seqüenciais não vistos pelo usuário final). Aplicações front-ends
construídas com ferramentas Cliente/Servidor fornecem uma interface gráfica amigável,
suportam funções específicas da organização, possibilitam o acesso transparente aos
dados dos sistemas já existentes e escondem a complexidade e a falta de consistência
dos bancos de dados atuais além de facilitar a utilização e a visualização dos resultados.
Os sistemas operacionais de uma organização podem estar em uso por 2 ou 5
anos e podem ter altas taxas de redundância. A redundância e a falta de consistência dos
dados podem dificultar a administração da empresa e o acesso aos dados e impede o
desenvolvimento de novas aplicações front-end. Uma das maneiras de tratar esta
situação é partir de um só sistema e construir uma espécie com facilidade de acesso aos
dados do servidor principal.

Figura 9 – Arquitetura de 2 camadas

A arquitetura para construir o Data Warehouse em duas camadas que consiste de

componentes dos clientes front-ends e componentes do servidor back-end é atrativa
porque ela utiliza os sistemas existentes bem como os servidores de bancos de dados
 34

existentes e requer um investimento mínimo em hardware e software. Entretanto, a

arquitetura de duas camadas não é escalonável, ou seja, não processa várias tarefas ao
mesmo tempo, e não suporta um grande número de usuários simultaneamente. Isto
estimula o desenvolvimento de estações clientes muito pesadas, pois muito
processamento é alocado para processar nestas estações.
Uma alternativa é utilizar a arquitetura de informação em múltiplas camadas.
Esta arquitetura flexível suporta um grande número de serviços integrados, na qual a
interface do usuário, as funções de processamento do negócio e as funções de
gerenciamento do banco de dados são separadas em processos que podem ser
distribuídos através da arquitetura de informação. A arquitetura em três camadas é
amplamente utilizada para o Data Warehouse. Na terceira camada ficam as fontes de
dados. Dados e regras de negócio podem ser compartilhados por uma organização,
assim como os bancos de dados para o Data Warehouse ficam armazenados em
servidores de alta velocidade na segunda camada. A figura 10 mostra que na primeira
camada ficam as aplicações de interface com os usuários que devem ser gráficas e
baseadas em rede.
No ambiente do Data Warehouse, os servidores de banco de dados e os
servidores de aplicações da segunda camada fornecem um acesso eficiente e veloz aos
dados compartilhados. Os dados do Data Warehouse são tipicamente estáticos, por
exemplo, não variam com o tempo e devem ser integrados, de natureza histórica e
sumarizados ou agregados para que sejam significantes para os analistas de negócios.
Dados operacionais e bancos de dados para o Data Warehouse são freqüentemente
armazenados em servidores fisicamente separados. Bancos de dados operacionais são
otimizados para se obter alto desempenho no processamento de transações on-line,
conhecido como processamento transacional em tempo real OLTP (On-line Transaction
Processing). Bancos de dados para Data Warehouse são otimizados para ter alto
desempenho em consultas e análises, conhecido como OLAP.
 35

Figura 10 – Arquitetura de 3 camadas

Reconhece-se que não existe uma arquitetura correta para o Data Warehouse.
Para algumas organizações pode ser atrativo utilizar a arquitetura em duas camadas, por
que ela minimiza o custo e a complexidade de construção do Data Warehouse. Para
outras que requerem grande desempenho e escalabilidade, a arquitetura em três camadas
pode ser mais apropriada. No planejamento do Data Warehouse, as organizações devem
examinar as alternativas disponíveis de arquiteturas e selecionar aquela que satisfaça os
seu requisitos estratégicos e organizacionais.

2.1.10 Metadados

Segundo SAP BW [3], os metadados são os principais componentes do Data

Warehouse. A definição mais comum que se encontra na literatura sobre metadados é
que eles representam "dados sobre dados". De uma forma um pouco mais completa
pode-se dizer que o metadado é a "descrição do dado, do ambiente onde ele reside, de
como ele é manipulado e para onde é distribuído".
 36

Metadados são uma abstração dos dados, e permite que os dados armazenados
em vários formatos tenham um determinado significado. Eles descrevem ou qualificam
outro dado, incorporando, a este, um significado. Sem metadado, a informação se
restringe a um conjunto de dados sem significado.
Com a utilização de metadados é possível avaliar o impacto das mudanças nos
sistemas transacionais. Consequentemente a manutenção desses sistemas se torna menos
complexa. Assim, os metadados assistem o processo de construção e manutenção do
Data Warehouse.
O processo de construção de um Data Warehouse é constituído de várias tarefas,
onde a extração de dados é uma delas. Assim, a integração de todos os dados exige o
conhecimento dos seus significados, estruturas, locais de armazenamento e sistemas que
os mantêm atualizados. Os metadados devem possuir todo esse conhecimento.
A carência de metadados integrados, competentes em descrever os dados
totalmente, dificulta ainda mais a integração e o compartilhamento dos dados nas
empresas.
Os metadados assumem um papel de extrema importância no processo de
transformação dos dados, pois através deles, serão armazenadas as lógicas das
transformações e os mapeamentos entre os dados dos sistemas transacionais e aqueles
mantidos no Data Warehouse.
Dentre as funções dos metadados relacionadas por Singh [13], pode-se destacar
as seguintes:

 Aumentar a produtividade do Data Warehouse, pois uma vez definido, um

atributo poderá ser reutilizado.
 Permitir ao usuário final e aos desenvolvedores, uma "navegação" pelos dados.
Isto torna possível descobrir a origem de uma informação.
 Permitir ao DW e aos DM, apresentarem atributos com termos empregados
pelos analistas de suporte e apoio à decisão.
 Gerenciar o mapeamento entre o ambiente operativo, o Data Warehouse e os
Data Marts. A gerência de mapeamento de dados engloba as conversões,
filtragens, alterações estruturais e qualquer outra informação necessária ao
rigoroso acompanhamento das transformações.
 37

 Manter o acompanhamento das alterações estruturais dos dados ao longo dos

anos.

Para garantir o cumprimento dessas funções, os metadados devem manter

informações sobre:

 Estrutura de dados, segundo a visão do programador.

 Estrutura de dados, segundo a visão do usuário final.
 Fonte de dados que alimentam o Data Warehouse.
 Transformações sofridas pelos dados no momento de sua migração para o Data
Warehouse.
 Transformações sofridas pelos dados no momento de sua migração para o Data
Mart.
 Modelo de dados.
 Relacionamento entre o modelo de dados, o Data Warehouse e os Data Marts.
 Histórico de extrações.

2.2 Metodologia

Pretende-se utilizar o conceito de Business Intelligence agregando um banco de

dados exclusivo para realização de consultas que darão suporte ao processo de tomada
de decisão. Este banco de dados será o Data Warehouse e portanto utilizará a arquitetura
prevista neste modelo.
Os dados encontram-se no modelo relacional e para se adequarem a metodologia
de BI serão extraídos para o modelo dimensional de dados e colocados em um novo
banco de dados OLAP através da ferramenta Microsoft SQL Server 2000 e seus
serviços de Analysis Services.
 38

2.2.1 Sistemas OLAP

Online analytical processing", ou OLAP fornece para organizações um método

de acessar, visualizar, e analisar dados com alta flexibilidade e performance. No mundo
globalizado de hoje as empresas estão enfrentando maior concorrência e expandindo sua
atuação para novos mercados. Portanto, a velocidade com que executivos obtêm
informações e tomam decisões determina a competitividade de uma empresa e seu
sucesso de longo prazo. OLAP apresenta informações para usuários via um modelo de
dados natural e intuitivo. Através de um simples estilo de navegação e pesquisa,
usuários finais podem rapidamente analisar inúmeros cenários, gerar relatórios "ad-hoc"
(específicos), e descobrir tendências e fatos relevantes independente do tamanho,
complexidade, e fonte dos dados. De fato, colocar informação em bancos dados sempre
foi mais fácil do que extraí-las. Quanto maior e complexa a informação armazenada,
mais difícil é para retirá-la. A tecnologia OLAP acaba com estas dificuldades levando a
informação mais próxima ao usuário que necessita. O OLAP é freqüentemente utilizado
para integrar e disponibilizar informações gerenciais contidas em bases de dados
operacionais. Estas características tornaram-no uma tecnologia essencial em diversos
tipos de aplicações de suporte à decisão e sistemas para administradores.
Portanto Devlin [8], define que OLAP é uma ferramenta de BI utilizada para
apoiar as empresas na análise de suas informações, visando obter novos conhecimentos
que serão empregados na tomada de decisão. Os conceitos de OLAP incluem a idéia de
dimensão com hierarquia e referências cruzadas, assim o banco de dados é
desnormalizado, fugindo das regras convencionais de normalização, que ocasionam
valores redundantes.
Este tipo de modelagem do OLAP é descritiva. Nela não se utiliza código, nem
siglas, e sim nomes representativos que permitem a identificação por qualquer pessoa
que, mesmo não sendo da área, entenda os valores apresentados em um relatório.
As ferramentas OLAP foram criadas para prover o processamento analítico
online das informações de uma empresa/corporação, contrastando com uma ferramenta
anteriormente usada, a OLTP (On-Line Transaction Processing), para, como o próprio
nome sugere, a análise de qualquer processo transacional de uma empresa a partir de
dados estáticos, geralmente encontrados em bases de dados relacionais.
 39

O uso de ferramentas OLAP se baseia na modelagem dimensional dos dados do

Data Warehouse, pois, através da divisão das hierarquias dos dados em dimensões, é
possível que os dados sejam apresentados e analisados sob a ótica do gerente ou do
tomador de decisão, facilitando a análise de dados através de sumarizações das
informações contidas no modelo, aliando esta análise à possibilidade de visualizar
qualquer intervalo de tempo definido no Data Warehouse. Entretanto, o fato de
refletirem a representação da realidade dos dados sob a ótica de quem irá analisá-los
torna a OLAP uma solução não imediata, pois configurar o programa de OLAP e ter
acesso aos dados requer uma clara compreensão dos modelos de dados da empresa e das
funções analíticas necessárias aos executivos e outros analistas de dados.
Típicas aplicações de negócios para as ferramentas OLAP incluem o
desempenho e proficiência de produtos, a eficácia de um programa de vendas ou de uma
campanha de marketing, a realização da previsão das vendas, e capacidade de
planejamento.
Segundo Kimball [12], as mais freqüentes funcionalidades oferecidas pelas
ferramentas OLAP são:

 Tabelas Cruzadas: são as tradicionais tabelas eletrônicas, a diferença é que os

dados são apresentados em planilhas com mais de duas dimensões, normalmente
quatro ou mais.
 Drill-across: é a requisição de dados das tabelas de dimensão com o valor das
consultas modificado, ocorre quando o usuário pula um nível intermediário
dentro de uma mesma dimensão.
 Drill-down: aumento do nível de detalhe da informação, por parte do usuário,
para solicitar uma visão mais detalhada em um conjunto de dados.
 Drill-up: é o contrário do Drill-down, ocorre quando o usuário diminui o nível
de detalhe da informação, solicitando uma visão menos detalhada de um
conjunto de dados.
 Drill-trought: é parecido com o Drill-across, mas neste o usuário passa de uma
informação contida em uma dimensão para outra dimensão.
 Slice-dice: é a descrição padrão para a habilidade de acessar os dados do Data
Warehouse através de qualquer uma das dimensões de forma igual. Serve para
modificar a posição de uma informação, alterar linhas por colunas de maneira a
 40

facilitar a compreensão dos usuários e mudar de dimensão sempre que

necessário.
 Pivoting (pivoteamento): é a mudança do arranjo das linhas e colunas em um
relatório tabular, onde freqüentemente as linhas ou as colunas são derivadas de
dimensões diferentes. É a inversão dos eixos das dimensões, para obter-se novas
visões de consultas.

Existem divisões dentro da OLAP, usadas de acordo com o banco de dados a ser
explorado. A ROLAP (OLAP relacional) é ligada aos conceitos básicos de Banco de
Dados Relacionais para a análise dos dados, transformando consultas em rotinas SQL
padrão. A partir dela, o usuário recebe resultados cruzados de tabelas em forma de
planilha multidimensional ou de outra forma que suporte a rotação, Drill-down e
manipulação. A MOLAP (OLAP multidimensional) difere da ROLAP no
armazenamento dos dados. Na MOLAP os dados são processados a partir de um
servidor multidimensional, onde o acesso aos dados ocorre diretamente no banco de
dados. Através dela o usuário trabalha, monta e manipula os dados diretamente no
servidor, o que traz benefícios com relação à performance que os usuários podem
atingir, mas é uma modelagem mais cara para a aquisição, por ser elaborada para um
Banco de Dados Multidimensional. Existe também a HOLAP (OLAP híbrido), que
consiste de uma mistura das tecnologias usadas na ROLAP e na MOLAP. Nela os dados
de agregação, isto é, dados de baixo nível da tabela de fatos que são resumidos e
armazenados em tabelas intermediárias para agilizar as consultas, são armazenados em
MOLAP, enquanto que os dados de base são armazenados no Banco de Dados
Relacional. Então, em consultas que utilizam resumos, a HOLAP é análoga ao MOLAP,
enquanto que, nas consultas aos dados de base, não é necessário que os usuários
manipulem diretamente os dados, podendo interagir através de consultas simples, como
no ROLAP. Além disso, o banco de dados pode ser modelado ou como um Banco de
Dados Multidimensional ou como um Banco de Dados Multirelacional, projetado para
aceitar propriedades multidimensionais.
 41

Capítulo 3
Desenvolvimento
3.1 Especificação do sistema

Os Data Warehouses podem ser utilizados para os mais diversos assuntos, por se
tratarem de uma nova metodologia para o armazenamento e acesso a informação. Esta
nova metodologia, adotada na forma com que os dados são dimensionados e
armazenados no Data Warehouse, é que o torna mais complexo e, ao mesmo tempo,
mais atraente do que os banco de dados tradicionais para realizar estes tipos de
consultas.
Devido a sua arquitetura diferenciada, a qual já foi devidamente detalhada neste
trabalho, o tratamento de grandes volumes de dados históricos não se torna uma tarefa
tão desgastante e, muitas vezes quase impossível de ser feita. Este fato deve ser
mostrado de forma a encorajar empresários de várias áreas a adotarem o uso do Data
Warehouse para tornar eficiente o uso dos dados que possuem, tornando capazes de
alcançar diferencial competitivo no mercado.
Neste trabalho, pretende-se ter como foco o problema do armazenamento de
dados históricos utilizando um protótipo de um banco de dados multidimensional.
Com o rápido crescimento do número de empresas a competitividade aumenta
gradualmente, o desenvolvimento e comercialização de produtos, busca de novos
parceiros comerciais, todos estes fatores contribuem para o aumento das informações.
As informações vinculadas a esses produtos por exemplo, devem ser plenamente
conhecidas e dominadas pelos empresários de diversos ramos, para permanecerem à
frente do mercado. Porém, atualmente, é reproduzido um modelo onde não existe um
ambiente que reúna todas estas informações de uma forma otimizada, para que estes
usuários efetuem suas consultas. O que torna a tomada de decisão, por parte desses
usuários, uma tarefa difícil e que exige pesquisa em diversas fontes diferentes, a qual
não oferece uma visão global dos dados necessários.
Tendo em vista a otimização na análise de grandes volumes de dados históricos
que os Data Warehouses oferecem, neste trabalho procurou-se estudar qual a melhor
forma de disponibilizar os dados, relativos a um ambiente comercial, em um Data
 42

Warehouse, para que venha a solucionar o problema de análise dos dados, apresentado
acima.

3.2 Projeto detalhado

O trabalho visa a criação de um Cubo através da implementação de um banco e

dados OLAP, bem como dimensões e fatos, proporcionando um entendimento básico
dos conceitos por trás do desenvolvimento de um banco de dados multidimensional
utilizando a ferramenta Microsoft Analysis Services.
O primeiro passo ao utilizar Analysis Services é criar seu banco de dados OLAP,
a fim de trazer algum valor do mundo real a essa discussão.
O trabalho consiste em criar um banco de dados OLAP multidimensional para o
departamento de vendas de uma cadeia de supermercados. O departamento gostaria de
analisar dados de vendas através de uma variedade de categorias geográficas,
demográficas e baseadas em produto.

3.2.1 Base de dados

Segundo Mark [15], a origem de dados para um banco de dados OLAP pode ser
praticamente qualquer armazenamento de dados relacional e, no caso específico do
Analysis Services, qualquer banco de dados relacional que possa expor os dados via um
provedor OLE DB, que é o modelo de objeto de acesso a dados universal da Microsoft.
Para criar uma origem de dados para o banco OLAP foi utilizada uma conexão
para a fonte de dados, “Data Source”, através do ODBC Data Source Administrator do
sistema operacional. O ODBC, “Open Data Base Connectivity”, permite conectar um
banco de dados relacional que esteja utilizando um driver do aplicativo Microsoft
Access, que é o utilizado neste trabalho. A figura 11 demonstra a conexão criada
utilizando o ODBC Data Source Administrator.
 43

Figura 11 – Conexão com a base de dados

No banco de dados OLAP configura-se a Data Source criada no sistema

operacional, disponibilizando os dados relacionais para a ferramenta OLAP utilizada,
Analysis Server Manager. Ao conectar o Analysis Server Manager ao banco de dados
local, uma estrutura de dados é criada permitindo disponibilizar esta Data Source que
utiliza driver do Microsoft Access para implementação multidimesional. Esta estrutura
de dados é demonstrada na figura 12.

Figura 12 – Estrutura de dados do Analysis Server Manager

 44

Importante ressaltar que o banco de dados OLAP pode conter múltiplas origens
de dados, extraindo de vários sistemas transacionais para um banco de dados
multidimesional OLAP.
Pode-se observar na figura 13 uma caixa de diálogo de origem de dados
disponibilizada pelo Analysis Server Manager. Nesta há uma lista de provedores OLE
DB disponíveis provando que o banco de dados OLAP pode ser criado utilizando
múltiplas fontes de dados. Segundo Mark [15], a Microsoft incorporou inteligência
nessa caixa de dialogo para alterar informações requeridas de conexão com base no
provedor OLE DB escolhido. Isso é feito porque cada provedor de OLE DB talvez
requeira parâmetros únicos de conexão a fim de estabelecer uma conexão com origem
de dados. Neste trabalho utilizou-se o provedor OLE DB para ODBC.

Figura 13 – OLE DB provider para drivers ODBC

 45

3.2.2 Implementando Dimensões

Após a criação das conexões para o banco de dados OLAP, inicia-se a definição
das dimensões compartilhadas. De acordo com Mark [15], uma dimensão compartilhada
é uma dimensão que está disponível para qualquer cubo no banco de dados OLAP, são
categorias através das quais pode-se analisar e resumir dados. A criação das dimensões
é realizada através de entradas de parâmetros fornecidos pelo desenvolvedor via
Analysis Server Manager e pela Data Source configurada a ele. Seguindo a mesma
estrutura de dados, selecionando a área de dimensões compartilhadas, as quais foram
detalhadas na figura 12, pode-se iniciar o processo de criação que é suportado por
mecanismos standard do sistema de análise.
Escolhe-se o tipo de dimensão a ser criada, de acordo com a figura 14. Mark
[15] define que o tipo de dimensão é baseado nas tabelas subjacentes de dados originais
para as dimensões. Entre os tipos disponíveis optou-se pelo modelo “Star Schema,
single dimension table” como pré-definido nos capítulos anteriores. Essa é uma
dimensão básica que utiliza uma única tabela subjacente de banco de dados para definir
suas características.

Figura 14 – Definição do tipo de dimensão

 46

Depois que escolheu-se o tipo de dimensão que deseja-se criar, é necessário

escolher uma tabela de dimensão. A tabela de dimensão é a tabela que fornece os dados
originais para a dimensão a ser criada.
Expandindo a origem de dados pode-se exibir uma lista de tabelas disponíveis.
Como abordado nos capítulos anteriores do trabalho, o banco de dados OLAP pode ter
diversas origens de dados, pode-se até criar uma nova origem de dados a partir do
Dimension Wizard através do botão New Data Source. É possível também navegar
pelos dados que estão contidos na tabela de dimensão selecionada através do botão
Browse Data. Os detalhes podem ser verificados na figura 15.
É necessário definir todas as dimensões desejadas antes da implementação do
cubo. As dimensões fornecem a definição para a maneira como usuários são capazes de
analisar os dados que serão armazenados no banco de dados multidimensional.

Figura 15 – Seleção de dados para uma dimensão

 47

3.2.2.1 Níveis de Dimensões

Depois de selecionar uma tabela de dimensão, o próximo passo no processo é

definir os níveis e membros dentro da dimensão. O Dimension Wizard permite criar
níveis dentro da dimensão, para tal escolheu-se as colunas de tabela de dimensão que
correspondem aos níveis requeridos.
Segundo Mark [15], os níveis devem ser organizados dos dados mais resumidos
aos menos resumidos, é possível que uma dimensão tenha somente um nível. Isso
implica que cada nível pai contenha menos membros que o nível abaixo dele. Isso
mantém um relacionamento essencial de um para muitos entre a hierarquia de dados que
assegura um drill-down e um roll-up precisos. Dentro de cada nível estão os membros,
estes representam os valores dos dados reais dentro das dimensões e os níveis
representam a hierarquia. A figura 16 detalha a etapa do processo de criação de níveis
hierárquicos.

Figura 16 – Definição de níveis

A figura 16 permite visualizar a criação da dimensão de “Cliente” que é

composta de informações geográficas sobre a localização de cada cliente. Os níveis
 48

hierárquicos para esta dimensão são representados pela seqüência dos atributos país,
estado, cidade e nome.

3.2.3 Implementado o Cubo

A definição das dimensões ou as categorias através das quais deseja-se analisar e

resumir dados, proporciona o desenvolvimento do Cubo. O Cubo é o bloco de
construção básica do banco de dados OLAP multidimensional, que associa as
dimensões definidas com os dados quantitativos que deseja-se analisar, como números
de vendas ou custos. Ainda utilizando a estrutura de dados detalhada na figura 12, pode-
se expandir a área de Cubos que permite acessar o “Cube Editor”. É através desta
ferramenta de edição que avalia-se os dados disponíveis expandindo a origem de dados
criada para a criação de uma tabela de Fatos. A tabela de fatos é uma tabela que contém
registros detalhados orientados à transação, como registros de vendas. Cada Cubo deve
ser baseado somente em uma tabela de fatos. Na figura 17 abaixo pode-se verificar
detalhes da seleção de dados para a tabela fato através do Cube Editor.

Figura 17 – Cube Editor, criação da tabela fato

 49

3.2.3.1 Medidas

Segundo Mark [15], as medidas representam as colunas provenientes da tabela

de fatos que contém os dados numéricos que deseja-se analisar.
Através do Cube Editor escolheu-se as colunas para análise inserindo uma
medida. Neste caso foi implementado medidas para as colunas store_sales, store_cost e
unit_sales. Todos os dados contidos nessas colunas na tabela de fatos serão as bases de
todos os dados que estão contidos nesse Cubo. Pretende-se definir um cubo que ajude a
analisar as vendas de armazenamento e vendas de unidade em várias dimensões.

Figura 18 – Criação de medidas

3.2.3.2 Processamento do Cubo

É no processamento do cubo que se define a arquitetura empregada. O modo de

armazenamento determina como o Analysis Services armazena os dados de Cubos
detalhados.
 50

Neste trabalho optou-se pelo método de armazenamento MOLAP que

proporciona um desempenho máximo do cubo projetado. O único problema identificado
na utilização desta arquitetura é que os dados só podem ser acessados através de
aplicações suportadas por OLE DB porque esta estrutura de armazenamento é
proprietária do Analysis Services. A figura 19 ilustra a etapa do processamento do cubo
onde opta-se pelo método de armazenamento MOLAP.

Figura 19 – Método de armazenamento

 51

Capítulo 4
Resultados
4.1 Validação

Nesta etapa foram analisadas as funcionalidades do Cubo e consistência de

informações geradas. A melhor forma encontrada para avaliar o conteúdo do Cubo
desenvolvido foi através do “Browse Cube”, uma função contida no Analysis Services
cujos dados podem ser visualizados dinamicamente dispondo das flexibilidades que esta
arquitetura de análise proporciona.
A figura 20 abaixo demonstra o Cubo “Vendas” que foi desenvolvido a partir de
uma base de dados relacional contendo dados que simulando uma rede de
supermercados.

Figura 20 – Cubo “Vendas”

 52

Neste esquema do Cubo Vendas é possível verificar todas as dimensões

relacionadas a uma única tabela de fatos. Entre os atributos da tabela de fatos
“sales_fact_1998” foram definidas três medidas (“measures”) cujos campos são
numéricos e representam os dados mensuráveis que podem ser analisados pelos
tomadores de decisão.
Todas as tabelas de dimensão foram definidas a partir do modelo “Star Schema”
com exceção das tabela de dimensão “produto” ou “product” cujo modelo utilizado é o
“Snow Flake Schema”. Este modelo foi utilizado para definição de uma hierarquia de
produtos representada por mais uma tabela dimensional relacionada por uma chave
primaria e uma chave estrangeira.
Como visto no capítulo anterior, a implementação do OLAP começa pelas
dimensões, visto que elas serão incorporadas ao cubo. Criando uma dimensão pela
opção Wizard da ferramenta, pode-se optar pelos modelos Star Schema e Snow Flake
Model, entretanto o modelo escolhido foi o Star Schema para a grande maioria do
projeto do Cubo, com exceção da hierarquia de produto.
A tabela 4 apresenta uma comparação de performance das duas modelagens. Por
esta comparação de performance pode-se concluir que o desempenho da Star Schema é
superior, por este motivo foi escolhida no desenvolvimento.

Tabela 3 – Snow Flake versus Star Schema

Condições de Teste
Máquina: Pentium III 450 MHz 256 mb RAM
SGDB: Microsoft SQL Server 2000
Registros na Fato: 90.064
Objetivo: Provar que a modelagem Snow Flake é extremamente prejudicial para
performance de consultas.
Resultados das Consultas
Snow Falke Star Schema
1° tentativa 81,46 s 1° tentativa 59,52 s
2° tentativa 78,26 s 2° tentativa 58,33 s
3° tentativa 77,77 s 3° tentativa 54,45 s
Média 79,14 s Média 57,43 s
 53

O Analysis Services fornece a capacidade de realizar pré-agregação parcial. Isso

significa que pode-se determinar a mistura apropriada entre requisitos de espaço de
armazenamento e aprimoramento de desempenho ao criar agregações. Na figura 21 é
possível verificar o gráfico no lado direito da caixa de diálogo onde é exibido
dinamicamente o espaço em disco versus ganho de desempenho enquanto as agregações
são projetadas. Não exigindo muito das consultas realizadas, optou-se por 40% de
otimização de desempenho, que parece oferecer a melhor relação de troca entre espaço
em disco versus desempenho para o volume de dados estudado.

Figura 21 – Espaço de disco versus desempenho

 54

O conteúdo do Cubo Vendas pode ser verificado acessando a função “Browse

Cube”. É possível analisar as dimensões e também as medidas criadas como na figura
22, o relatório montado nesta figura representa nas linhas a dimensão cliente e nas
colunas as três medidas definidas na tabela de fatos.

Figura 22 – Visualização do conteúdo do Cubo, relatório dinâmico.

Ainda utilizando a mesma consulta foi adicionado a dimensão produto trocando

pelas posições das medidas (measures) contidas nas colunas do relatório através da
técnica “drag” e “drop” na figura 23.
 55

Figura 23 – Troca de posição entre medidas e dimensão produto.

Uma validação importante é em relação a utilização dos níveis hierárquicos

definidos para as tabelas dimensionais. Os níveis de tempo podem ser verificados
através da abertura do ‘box’ de seleção do Browse Cube para esta dimensão tempo
visualizada na figura 24, onde destacam-se os trimestres ou “quarters” que são atributos
provenientes da origem de dados relacional.
A aplicação da técnica de drill-down também é parte importante no processo de
validação já que é uma das vantagens de consulta deste modelo utilizado. É
representado na figura 25 uma execução de drill-down , onde primeiramente foram
trocadas através de drag e drop as dimensões produto e cliente, posteriormente
expandiu-se os produtos para suas subcategorias.
 56

Figura 24 – Verificação de níveis hierárquicos.

Figura 25 – Drill-Down.
 57

Capítulo 5
Conclusões

Empresas líderes em seus segmentos detêm conhecimento de seu negócio. Este

conhecimento vem de informações, porém não basta possuir a informação, é preciso
emprega-la da melhor forma possível.
Inteligência nos negócios significa saber para onde olhar, o que perguntar e
como lidar com a informação. É num mercado competitivo e ágil que as ferramentas de
BI, encaixam-se auxiliando os tomadores de decisão.
Este trabalho não abrange somente a utilização de uma ferramenta para criar um
banco de dados no formato multidimensional, mas também proporciona compreensão
dos conceitos e a forma correta de modelar um Data Warehouse de maneira a extrair
informações que realmente ajudem ao tomador de decisão. A maior dificuldade
apresentada é a modelagem correta dos dados para que realmente as informações
extraídas sejam úteis à empresa. Conclui-se que o sucesso do OLAP está no estudo das
necessidades do usuário e na modelagem correta dos dados.
Concluiu-se neste trabalho que, independentemente do assunto ou área em
questão, a criação de Data Warehouses é a fonte de todo o projeto que se destina
auxiliar na descoberta de conhecimento. O uso de Data Warehouses vem a otimizar o
crescimento das empresas, pois no momento em que estas possuem seus dados
armazenados de forma planejada, não há motivo para temerem um crescimento no
volume de dados a serem analisados para tomarem decisões, e estas também podem, a
partir da experiência adquirida e de informações bem fundamentadas, planejarem o
futuro.
Analisando a base de dados transacional utilizada, é possível verificar a
possibilidade de ampliação do Data Warehouse, possibilitando criar Cubos que atendam
outras áreas do negócio, além da área de vendas que fora implementada neste trabalho.
 58

Referências Bibliográficas

Apostilas:
[1] NETPARTNER consultoria e Sistemas Ltda. Business Intelligence, técnicas de
modelagem para construção de Data Warehouse (JOHNSON & JOHNSON)

[2] NETPARTNER consultoria e Sistemas Ltda. Treinamento de BI, BUSINESS

INTELLIGENCE NETPARTNERS (2001).

[3] SAP BW310 3.0 mySAP Business Intelligence (PARTICIPANT HANDBOOK)

Educação e Treinamento SAP Brasil. (2001).

Websites:
[4] iMasters FFPA Informática Ltda. http://www.imasters.com.br (2001).

[5] Codeline Tecnologia em Informática Ltda. http://www.linhadecodigo.com.br (2001).

[6] Microsoft Corporation. http://www.microsoft.com.br (2006)

Livros:
[7] DATE C. J., Introdução a Sistemas de Banco de Dados. Rio de Janeiro: Editora
Campus (2004)

[8] DEVLIN, Barry, Data Warehouse from Architecture (1997)

[9] Richard D. Hackathron & W. H. Inmon, Como usar o Data Warehouse. IBPI press
(1997).

[10] TAKAI, kotaro Oswaldo; ITALIANO, Cristina Isabel; FERREIRA Eduardo João.
Introdução a Banco de Dados. DCC – IME – USP. São Paulo (2005)

[11] INMON, William H.,Como Construir o Data Warehouse. Rio de Janeiro: Editora
Campus (1997).

[12] KIMBALL, R. Data Warehouse Toolkit: Técnicas para Construção de Data

Warehouse Dimensionais. São Paulo: Makron Books, (1998).

[13] SINGH, H., Data Warehousing: Concepts, Technologies, Implementations, and

Management, Upper Saddle River, New Jersey, USA. Prentice-Hall (1997).

[14] MACHADO, Felipe Nery Rodrigues. Tecnologia e Projeto de Data Warehouse.

Rio de Janeiro: Editora Erica (2002).

[15] MARK Spenik, ORRYN Sledge. Microsoft SQL Server 2000 DBA, Guia de
Sobrevivência. Rio de Janeiro: Editora Campus (2001)
Webinsider Ltda , 08 de julho de 2006,