1

MODELAGEM GRFICA DE DATA

WAREHOUSES E DATA MARTS USANDO UML

JOANA SCHEEREN

Porto Alegre
2009

2
JOANA SCHEEREN

MODELAGEM GRFICA DE DATA

WAREHOUSES E DATA MARTS USANDO UML

Trabalho de Concluso de
Curso II apresentado
Faculdade de Informtica,
como requisito parcial
obteno do ttulo de
Bacharel em Sistemas de
Informao.

Orientador: Profa. Dra. Slvia

de Castro Bertagnolli

Porto Alegre
2009

Dedico este trabalho aos meus pais,

meus grandes mestres; ao meu marido
Maiquel, pela compreenso, apoio e
dedicao em todos os momentos e
minha me pelas lies de fora e
superao neste semestre.

Agradeo ao meu marido Maiquel pela

pacincia, auxlio e amizade nos
momentos confusos; professora
Slvia pelas grandes lies, pelo apoio
e incentivo. A todos os amigos,
colegas e familiares que me deram
fora e motivao para alcanar este
objetivo.

RESUMO

Os sistemas de Business Intelligence tornam-se muito importantes

nas organizaes em geral, uma vez que possibilitam analisar os histricos
dos processos para criar subsdios de apoio deciso. Os repositrios
destes sistemas os Data Warehouses ou Data Marts so construdos
de forma a atender a demanda destes sistemas e por isso possuem uma
abordagem de modelagem especfica. Este trabalho prope o estudo dos
diagramas da UML 2.0 a fim de adapt-los para permitir uma
documentao mais adequada para os projetos de Data Warehouses e
Data Marts, j que as suas abordagens de modelagem atuais, no cobrem
todos os elementos necessrios do projeto.

Palavras-Chave: Business Intelligence, UML 2.0, Data Warehouse, Data Mart.

ABSTRACT

The Business Intelligence systems become very important in

organizations, once it allows analyzing the historical processes to create
benefits for decision support. The databases of these systems - the Data
Warehouse or Data Marts - are constructed to attend the demands of these
systems and therefore have a specific approach to modeling. This article,
proposes the study of the diagrams of UML 2.0 in order to adapt them to
allow a more adequate documentation for the projects of Data Warehouse
and Data Marts, whereas its current modeling approaches do not cover all
the necessary elements of the project.

Keywords: Business Intelligence, UML 2.0, Data Warehouse, Data Mart.

LISTA DE FIGURAS

Figura 1 Cubo com Dimenses......................................................................24

Figura 2 Modelo Star Schema .......................................................................26
Figura 3 Identificando Fatos e Dimenses.....................................................27
Figura 4 Quatro Pontos Cardeais ..................................................................27
Figura 5 Modelo Snow Flake .........................................................................28
Figura 6 Diagramas da UML 2.0 ....................................................................30
Figura 7 Modelo Fonte das Informaes Viso Aplices ............................39
Figura 8 Modelo Fonte das Informaes Viso Metas................................39
Figura 9 Fato Venda com mtricas e mtricas calculadas.............................45
Figura 10 Dimenso Cia com atributos..........................................................46
Figura 11 Hierarquia de Clientes ...................................................................48
Figura 12 Hierarquia de Datas .......................................................................48
Figura 13 Regras de Negcio aplicadas a classe Cliente ...........................50
Figura 14 Diagrama de Classes viso Venda..............................................50
Figura 15 Diagrama de Seqncia de Carregar Cliente..............................54
Figura 16 Diagrama de Seqncia de Buscar Cliente.................................55
Figura 17 Diagrama de Implantao..............................................................58

LISTA DE QUADROS

QUADRO 1 Comparativo entre dados Operacionais e Informacionais..........19

QUADRO 2 Comparao entre Modelo Dimensional e Modelo ER...............24
QUADRO 3 Comparativo entre perguntas aos usurios e elementos definidos
para a modelagem ............................................................................................49

LISTA DE ABREVIATURAS E SIGLAS

BI

Business Intelligence

CASE

Computer Aided Software Engineering

DM

Data Mart

DW

Data Warehouse

ER

Entidade Relacionamento

ERP

Enterprise Resource Planning

ETL

Extraction, Transform and Load

HOLAP

Hybrid On-line analytical processing

MOLAP

Multidimensional On-line analytical processing

OLAP

On-line analytical processing

OLTP

On-line Transaction Processing

OMG

Object Management Group

ROLAP

Relational On-line analytical processing

SGBD

Sistemas Gerenciadores de Banco de Dados

SQL

Structured Query Language

UML

Unified Modeling Language

10

SUMRIO

INTRODUO ..........................................................................................12

REFERENCIAL TERICO ........................................................................16

2.1 BUSINESS INTELLIGENCE ...................................................................17
2.1.1 Data Warehouse e Data Mart ......................................................19
2.1.2 Modelagem Multidimensional.....................................................22
2.1.3 Modelos de Dados Multidimensionais.......................................26
2.2 UML.........................................................................................................29

SOLUO IMPLEMENTADA ...................................................................34

3.1 PLANEJAMENTO ...................................................................................36
3.2 LEVANTAMENTO DAS NECESSIDADES..............................................37
3.3 MODELAGEM DIMENSIONAL ...............................................................42
3.3.1 Primeira Etapa Definindo os fatos ou mtricas .....................44
3.3.2 Segunda Etapa Definindo as dimenses de negcio............45
3.3.3 Terceira Etapa Definindo a granularidade das informaes
em cada dimenso ...............................................................................47
3.3.4 Quarta Etapa Definindo a hierarquia de agrupamento de
informaes ..........................................................................................47
3.4 MODELANDO REGRAS DE NEGCIO .................................................49
3.5 PROJETO FSICO DO BANCO DE DADOS...........................................51
3.6 PROJETO DE ETL EXTRACT, TRANSFORM AND LOAD .................52
3.7 DESENVOLVIMENTO DE APLICAES...............................................56
3.8 VALIDAO E TESTE ............................................................................56
3.9 TREINAMENTO ......................................................................................56
3.10 IMPLANTAO.....................................................................................57

CONSIDERAES FINAIS ......................................................................59

REFERNCIAS BIBLIOGRFICAS .........................................................60

11
APNDICES .....................................................................................................62

12

1 INTRODUO

Com os avanos da tecnologia da informao, pode-se contar com

recursos que possibilitam s empresas manter, processar e controlar enormes
volumes de dados, representando todos os seus processos. A partir do banco
de dados criado e alimentado, possvel extrair informaes valiosas do
cenrio histrico e atual da empresa.
neste contexto que os sistemas de BI (Business Intelligence) ganham
fora, pois visam disponibilizar informao e conhecimento aplicados ao
negcio das empresas, enquanto o foco dos ERPs (Enterprise Resource
Planning) e demais sistemas OLTP (Online Transaction Processing) buscar
estabelecer subsdios de controle dos processos.
O Data Warehouse (DW) ou armazm de dados prope-se a lidar com
grandes volumes de dados histricos (oriundos dos sistemas transacionais) e
disponibilizar informaes s consultas dos usurios, sejam elas ad-hoc ou
no. Por sua vez, um Data Mart (DM) funciona como um repositrio menor,
com uma viso mais direcionada a algum assunto especfico da empresa, mas
tambm com a proposta de disponibilizar informaes que possibilitem anlises
diversas para apoio deciso.
Desse modo, os DW e os DM de uma empresa devem ser construdos
com muito planejamento, pois um projeto de implantao mal definido pode ser
traumtico em termos de custo, tempo e desempenho nas consultas
executadas posteriormente. A escolha da arquitetura do projeto do Data
Warehouse ou Data Mart pode ser considerada uma deciso prioritria, j que
a modelagem deve refletir a forma de pensar dos analistas e atender aos
requisitos de negcio da empresa.
Para que o projeto do Data Warehouse ou Data Mart da empresa possa
ser analisado pelos gestores e analistas envolvidos no projeto com eficcia,

13
imprescindvel que haja uma documentao completa e fidedigna da
modelagem proposta para auxiliar tanto na aprovao e definio do escopo,
como possibilitar o entendimento das vises e mtricas entregues ao final.
Atualmente, os modelos de dados, comumente utilizados para a
modelagem de projetos de DW ou DM so os modelos Star Schema (Estrela)
ou Snow Flake (Floco de Neve). Esses modelos, embora muito mais
conceituais do que prticos, possuem uma orientao representao dos
processos que podem ser considerados para modelar/construir o armazm de
dados e no apenas na composio fsica de seus componentes como prope
o modelo ER (Entidade-Relacionamento).
Ambos os modelos so muito importantes na fase de concepo do
projeto, pois derivam do levantamento das regras de negcio. Contudo, eles
no se preocupam em documentar com detalhes os requisitos e as
caractersticas do projeto, tampouco em atender as necessidades de
compreenso de todos os envolvidos nele.
H diversas outras formas de modelar sistemas computacionais. Destacase que um dos padres atuais de modelagem de software orientado a objetos
a UML (Unified Modeling Language), pois foi adotada internacionalmente pela
indstria de Engenharia de Software. A UML uma linguagem de modelagem
visual, utilizada para auxiliar na definio das caractersticas e requisitos dos
softwares, abrangendo todo o projeto. Criada para atender processos de
desenvolvimento de software que utilizem o paradigma de orientao a objetos,
esta linguagem possui muitos diagramas para que todos os passos do projeto
possam ser descritos e facilmente entendidos por todos os envolvidos na
construo - desde usurios at desenvolvedores.
Como a UML um dos padres atuais de modelagem, tem-se no
mercado uma diversidade de ferramentas CASE (Computer Aided Software
Engineering) que podem ser utilizadas na criao dos modelos de dados
requeridos. Alm disso, a preocupao em descrever todas as fases do projeto,
com uma viso dos processos de negcio, faz com que a UML seja uma
abordagem de fcil compreenso por todos os envolvidos em um projeto de
software.

14
Sendo assim, surge a idia de estudar os requisitos para a construo de
Data Warehouses e Data Marts, bem como os diagramas da UML 2.0 para
propor a representao visual e a documentao destes, de modo que
atendam ao requisito fundamental da fase de definio do projeto: o
entendimento do modelo e definio do escopo requerido, auxiliando tanto
usurios, como analistas a obter mais sucesso e eficcia no produto final,
evitando distores entre o que era esperado e o que efetivamente foi
construdo.
A proposta inclui, portanto, o estudo dos diagramas da UML, que possam
representar as fases de projetos de DW e DM, para que, em conjunto,
construam uma documentao eficaz que possibilite a fcil identificao das
decises tomadas e das regras de negcio abrangidas pelo modelo.
Desse modo, o objetivo geral deste trabalho a seleo e/ou adaptao
de diagramas da UML 2.0, que descrevam a fase de modelagem de dados de
um projeto de Data Warehouse ou Data Mart, auxiliando em um melhor
entendimento do escopo pelos envolvidos neste tipo de projeto.
Como objetivos especficos para este trabalho propem-se:

adquirir conhecimentos que propiciem embasamento terico

na rea de Data Warehouse e Data Mart;

adquirir conhecimentos quanto aos requisitos da modelagem
de um Data Warehouse ou Data Mart para entender como
devem ser exemplificados atravs de documentos e/ou
diagramas;

entender e estudar os diagramas da UML 2.0;

estudar e definir quais os diagramas da UML podem ser
selecionados e/ou adaptados para os projetos utilizados com o
escopo do trabalho, a fim de exemplificar de forma mais
simples e visual os requisitos e a modelagem;

elaborar um estudo de caso com os diagramas e documentos
propostos a fim de exemplificar a sua aplicao.

15

O texto deste trabalho prossegue organizado da seguinte forma:

Captulo 2 apresenta o referencial terico utilizado para

estudar e entender os conceitos dos objetos de estudo do
trabalho;

Captulo 3 apresenta a descrio da soluo elaborada e
aplicada em um estudo de caso;

Captulo 4 descreve as concluses obtidas com o
desenvolvimento deste trabalho.

O texto continua com a descrio dos aspectos tericos que

fundamentaram o desenvolvimento deste trabalho.

16

2 REFERENCIAL TERICO

Durante muitos anos, o foco de estudos e das empresas esteve em

aplicativos transacionais, como os ERPs (Enterprise Resource Planning), para
obter elementos de controle e automao dos processos da empresa
(MACHADO, 2006).
Os SGBDs (Sistemas Gerenciadores de Banco de Dados) utilizados por
estes aplicativos so os relacionais, que se preocupam com o armazenamento
e recuperao de dados, exatamente o que se necessita para responder s
necessidades de controle das transaes. Este foco no gerenciamento dos
dados garantiu a segurana, a eliminao das redundncias e a integridade do
banco de dados, porm a preocupao ainda o controle dos processos e no
apenas a recuperao dos dados controlados (MACHADO, 2006).
Contudo, o cenrio atual de dinamismo trouxe tona a necessidade de
se obter estratgias de negcio para adquirir vantagens competitivas frente aos
concorrentes. Mais do que isso, as empresas esto sendo obrigadas a criar
maneiras de se adaptar de uma forma contnua e rpida para que possam se
manter e crescer no mercado. Para que estas necessidades sejam atendidas, a
fim de incluir a empresa em um cenrio vantajoso, preciso que os gestores
tenham informaes para tomar as decises certas no momento adequado,
para analisar os dados disponveis e formular estratgias de forma rpida e
segura (COLAO JUNIOR, 2004).
neste contexto que se verifica a importncia dos sistemas de BI
(Business Intelligence) para as organizaes, pois aps a implantao dos
sistemas transacionais e do controle de seus processos, observa-se a
necessidade de sistemas que forneam informaes integradas e sumarizadas,
que possam prover insumos para anlise, planejamento e suporte deciso
(COLAO JUNIOR, 2004).

17
Assim como qualquer projeto de software, a documentao dos
requisitos e a modelagem do sistema so muito importantes para uma melhor
compreenso do escopo do projeto e de como ele ser estruturado. Isto
influencia o desenvolvimento eficaz e a manuteno aps a entrega. A
modelagem orientada a objetos auxilia, ainda, em uma melhor compreenso da
arquitetura do sistema tanto dos analistas, como dos usurios envolvidos.
Como a UML considerada um dos padres atuais neste tipo de modelagem,
ela pode ser estudada para utilizao nos projetos de BI (LARMAN, 2006).
As prximas sees apresentam um resumo dos principais aspectos
tericos relacionados BI e UML que sero utilizados por este trabalho.

2.1 BUSINESS INTELLIGENCE

Com o avano das tecnologias de informao e com o amadurecimento

dos sistemas dentro das empresas teve-se um aumento tanto na capacidade
de armazenamento e processamento dos sistemas, como no tamanho das
bases de dados com informaes das diversas formas de interao da
empresa com seu negcio (COLAO JUNIOR, 2004).
Os ERPs no lidam de forma eficaz com grandes volumes histricos,
pois o controle dos processos seria muito oneroso, levando-o a no atender
seu propsito principal. Alm disso, possuir grandes volumes de dados, mesmo
que seja possvel recuper-los, no garante a continuidade dos negcios.
Assim, surgem os armazns de dados ou Data Warehouses, e os Data Marts,
cujas bases de dados possuem informaes consolidadas e integradas,
capazes de apoiar os processos de tomada de decises com conhecimento
preciso e voltado ao negcio. Eles, tambm, possibilitam no nvel ttico da
organizao, a visualizao do desempenho de um departamento e at mesmo
de toda a corporao (MACHADO, 2006).
Pode-se definir um sistema de BI como um conjunto de tecnologias
orientadas disponibilizao da informao e do conhecimento estratgico
para os processos de tomada de deciso em uma empresa (MACHADO,
2006). Para alcanar estes objetivos, o BI de uma empresa utiliza variadas

18
fontes de informao, de acordo com a definio das estratgias de negcio,
para estar competitiva (BARBIERI, 2001).
As tcnicas de BI visam, portanto, extrair informaes dos sistemas
transacionais e armazen-las de forma eficiente para retirar o conhecimento
requerido e manter grandes histricos, a fim de subsidiar verificaes de
cenrios. Estas tcnicas podem ser utilizadas para descobrir as necessidades
de indicadores de negcio da empresa e para disponibilizar o conhecimento
estratgico de forma dinmica e precisa (MACHADO, 2006).
Como j mencionado, os modelos relacionais de banco de dados no se
mostram eficazes para o controle do volume e do formato de dados que requer
um sistema de BI. Para isto, utilizam-se os DW e os DM, pois so capazes de
armazenar e recuperar grandes volumes de dados, alm de recuper-los para
prover anlises no formato e agilidade que um sistema de BI requer
(MACHADO, 2006).
Para que os dados cheguem at o Data Warehouse ou ao Data Mart no
formato que se planejou, h uma etapa muito importante dentro do projeto do
BI: o processo de ETL Extraction, Transform and Load (extrao,
transformao e carga). Atravs dele, os dados so levados at uma rea
temporria que possui o objetivo de formatar e tornar consistentes estes dados
no repositrio final, conforme as necessidades ou o contexto (ANDRADE,
2003).
A extrao remete a busca dos dados para as fontes transacionais, onde
os processos so controlados. A transformao necessria para montar o
modelo de dados que atende ao sistema, pois a normalizao do modelo
transacional no eficaz nestes casos. Dentro da transformao, tambm
feita a limpeza dos dados que responsvel por isolar apenas as informaes
que so necessrias para as anlises que estaro disponveis no BI, de acordo
com a definio da empresa no projeto, alm de remover erros encontrados
nos dados. Por fim, a carga realiza a gravao dos dados no repositrio final,
criando o histrico da empresa e os subsdios para o sistema de BI
(ANDRADE, 2003).
Ao contrrio da abordagem tradicional de dados, o conceito de BI est
relacionado

com

formas

alternativas

de

tratamento

das

informaes

(BARBIERI, 2001). Por isso, h grandes diferenas entre os dados constitudos

19
para o controle de processos e os que subsidiam anlises para a tomada de
decises.
O Quadro 1 apresenta um comparativo entre os dados de natureza
operacional e informacional.
QUADRO 1 Comparativo entre dados Operacionais e Informacionais
Caractersticas

Dados Operacionais

Dados Informacionais

Contedo

Valores Correntes

Valores Sumarizados, Calculados,

Integrados de vrias fontes

Organizao dos dados

Por aplicao/sistema de

Por assunto/ Negcios

informao
Natureza dos dados

Dinmica

Esttica at o refreshment dos

dados

Formato das Estruturas

Relacional, prprio para

Dimensional, simplificado, prprio

computao transacional

para atividades analticas

Atualizao dos dados

Atualizao campo a campo

Acesso, sem update

Uso

Altamente estruturado,

Desestruturado, com processamento

processamento repetitivo

analtico/heurstico

Otimizado para 2 a 3 segundos

Anlises mais complexas, com

Tempo de Resposta

tempos de respostas maiores

Fonte: (BARBIERI, 2001).

Um sistema de BI precisa, portanto, de uma modelagem diferenciada

que atenda seus requisitos de anlises e consultas, embora um banco de
dados ERP seja comumente confundido com um sistema de BI. Esta
modelagem dever subsidiar uma base que consiga integrar dados de
mltiplas fontes de forma concisa e no-normalizada e organiz-los para um
maior desempenho de suas consultas. Para formar estas bases, surgiu o
conceito de Data Warehouse, que ser descrito na prxima seo.

2.1.1 Data Warehouse e Data Mart

O Data Warehouse, cuja traduo literal armazm de dados, pode ser

definido como uma base de dados preparada para ser acessada por sistemas
de apoio deciso (MACHADO, 2006).

20
Os dados so armazenados em estruturas dimensionais e em vrios
graus

de

relacionamento

sumarizao

de

forma

possibilitar

processamento analtico por ferramentas especiais do tipo OLAP (On-Line

Analytical Processing), que atendem aos executivos de diferentes nveis,
responsveis pelas decises de negcios nas empresas (BARBIERI, 2001).
O DW tambm compreende a base de dados histrica da empresa, que
une de forma integrada e confivel as informaes de interesse da mesma,
permitindo verificar evolues, em geral, em grande espao de tempo
(BARBIERI, 2001).
Um Data Mart, tambm chamado Mercado de Dados, pode ser
considerado uma especializao, uma espcie de Data Warehouse com um
assunto-foco, que atende a reas especficas da empresa, porm voltado da
mesma forma para os processos decisrios gerenciais (BARBIERI, 2001).
Ambos tm os mesmos objetivos finais, porm a abrangncia de projeto
muda devido especializao do Data Mart. Pode-se tambm, afirmar que um
Data Warehouse formado pelos diversos Data Marts integrados. Como o DW
um banco voltado a consultas, no se pode projet-lo pensando na
consistncia entre os dados carregados (BARBIERI, 2001).
Por isto, a abordagem entidade-relacionamento no eficaz neste tipo
de projeto, j que ela se preocupa com a eliminao de redundncias de dados
e com a garantia da integridade destes, o que no ponto focal de um DW.
Nestes projetos utiliza-se mais a modelagem multidimensional (COLAO
JUNIOR, 2004).
Segundo Inmon (INMON, 1997), um Data Warehouse pode ser
considerado um conjunto de dados no-voltil, orientado a tpicos, integrado e
que varia com o passar do tempo servindo de suporte para o processo de
tomada de decises da gerncia. Estas caractersticas permitem compreender
sua formao:

no-voltil remete ao fato de DW permitir, na maior parte dos

casos, que os dados sejam apenas acessados e no alterados ou
atualizados. Assim, ao contrrio de um sistema transacional, cujo
objetivo a atualizao registro a registro, um DW efetua uma
carga inicial dos dados e os disponibiliza para consultas. As

21
alteraes tornam-se mais onerosas do que uma remoo e
recarga dos dados. H, contudo, excees como dados
contbeis, por exemplo, que podem ter que sofrer atualizaes ao
longo do tempo. Mas so raros os casos, j que a base tem o
objetivo de ser histrica e refletir todas as situaes do negcio
ao longo do tempo;

orientado a tpicos (ou temas) indica que as informaes que

ele armazena e que so necessrias para processos de tomada
de decises, so organizadas segundo temas ou assuntos de
negcio que so importantes para a empresa. Cada tema pode
possuir vrias tabelas e nveis de agregao como, por exemplo,
as diversas informaes que possam ser armazenadas dos
clientes e as formas que podem ser detalhadas;

integrado este aspecto remete consolidao dos dados de

diversas origens e possveis codificaes diferentes. Todos os
dados de um Data Warehouse precisam estar na mesma
conveno, perfeitamente integrados, para permitir todas as
interligaes possveis;

variante no tempo em um DW, os dados devem ser carregados,

como fotografias, da base operacional no momento da carga
para que incorpore as mudanas que permitiro anlises das
alteraes ao longo do tempo.

rea

de

reteno,

ou

Staging

Area,

responsvel

pelo

armazenamento intermedirio entre as fontes de dados dos sistemas

transacionais e o Data Warehouse ou Data Mart. Nesta rea, ocorre a etapa de
Transformao que, aps a extrao, a etapa responsvel por isolar os
dados que sero utilizados no suporte deciso, para ento, executar a
limpeza destes e criar o modelo dimensional (ANDRADE, 2003).
A limpeza dos dados visa assegurar a consistncia destes que sero
armazenados, assim como ocorre na integrao, para que haja padronizao
de descries, codificaes, alm de formato de campos (ANDRADE, 2003). A
construo do modelo dimensional o agrupamento das informaes em
estruturas no-normalizadas na Staging Area para a posterior gravao no

22
modelo final. Estas estruturas atendero s demandas de consultas
complexas, que compreende o objetivo da estrutura dimensional de um sistema
de BI (MACHADO, 2006).
Com os dados consistentes, tratados na Staging Area, passa-se etapa
de carga, onde os dados, finalmente, so migrados para o Data Warehouse.
Esta carga pode ser incremental (adiciona-se somente os dados novos) ou
baseada nos dados, momento em que as dimenses so removidas
completamente e recarregadas a cada execuo. A escolha da forma de
atualizao uma deciso do projeto e poder variar conforme a tecnologia
escolhida para o BI da empresa (ANDRADE, 2003).
Todas estas peculiaridades de um Data Warehouse ou Data Mart fazem
com que um modelo entidade-relacionamento (ER) no seja o mais
recomendado. Por isso, em projetos de BI, deve-se estudar a modelagem
dimensional, como apresenta a prxima seo.

2.1.2 Modelagem Multidimensional

Segundo Colao Junior (2004) a modelagem dimensional atende aos

requisitos de sistemas categorizados como DW e DM:
As informaes contidas em um Data Warehouse possuem
caractersticas especficas que as distinguem das informaes
existentes em projetos de banco de dados convencionais. Grandes
volumes de dados, dados histricos e bases no normalizadas so
algumas das peculiaridades que impedem a utilizao das
metodologias tradicionais de anlise de sistemas. (COLAO JUNIOR,
2004, IV)

modelagem

multidimensional

ou

dimensional

uma

tcnica

estruturada que foi desenvolvida para a obteno dos modelos de dados

necessrios a projetos de Business Intelligence onde se pretende identificar, de
forma fcil, os aspectos de negcio da empresa (BARBIERI, 2001).
Segundo Barbieri (2001), a estrutura dimensional modifica a ordem de
distribuio de campos por entre as tabelas, permitindo uma formatao
estrutural mais voltada para os muitos pontos de entradas especficos (as

23
chamadas dimenses) e menos, para os dados granulares em si (os chamados
fatos). Esta estrutura baseada em mltiplas dimenses permite a visualizao
dos dados de diversas maneiras (KIMBALL, 1998).
O modelo multidimensional formado por trs elementos bsicos: fatos,
dimenses e medidas (MACHADO, 2006):

um fato modelado atravs de uma tabela que compreende as

colees de transaes ou eventos de negcio da empresa. Tais
colees so compostas pelas medies numricas que representam
a evoluo dos negcios de uma organizao;

as dimenses so os elementos dos fatos do negcio, so os

assuntos, os atributos classificatrios dos elementos de um fato.
Cada dimenso pode ter vrios nveis hierrquicos para agregar os
dados nos nveis necessrios e propiciar um melhor entendimento e
visualizao dos indicadores;

as medidas ou variveis so os atributos numricos que representam

os fatos, ou seja, os indicadores que mostram a evoluo do negcio
da empresa.

O modelo dimensional mais leve que o modelo relacional, pois

facilmente possibilita identificar seus componentes. Contudo, medida que se
adicionam novas extenses, ele pode se tornar mais complexo (BARBIERI,
2001).
As tcnicas da modelagem dimensional foram criadas para modificar
alguns conceitos dos projetos tradicionais de banco de dados, como o modelo
ER. Os projetos de BI precisam de estruturas mais geis do que as definidas
pelo modelo normalizado e em nveis agregados, precisando tambm
transgredir a premissa da no-redundncia do relacional, mesmo que para
chegar a tudo isso haja um considervel aumento no custo de armazenamento.

24
A Quadro 2 apresenta uma comparao entre o modelo entidaderelacionamento e o modelo dimensional.
QUADRO 2 Comparao entre Modelo Dimensional e Modelo ER
Modelo Dimensional

Modelo Relacional - ER

Padro de estrutra mais fcil e intuitiva

Modelo mais complexo

Anterior ao ER, anos 60

nfase nos bancos de dados relacionais, anos 70

Tabelas Fato e tabelas dimenso

Tabelas que representam Dados e

Relacionamentos

Tabelas Fato so o ncleo normalizadas

Todas as tabelas so comumente normalizadas

Modelo mais facilmente joined

Maior dificuldade de join, por ter um nmero

maior de tabelas

Leitura mais fcil do modelo por usurios no

Maior dificuldade de leitura pelo usurio no

especializados

especializado.

Fonte: BARBIERI, 2001

A forma mais comum de visualizar um modelo multidimensional um

desenho de um cubo. O cubo somente uma metfora, j que no h como
expressar nele todas as dimenses de visualizao, apenas trs. Porm, este
elemento visual auxilia muito no entendimento das mltiplas dimenses, vises
de um mesmo fato (MACHADO, 2006).
A Figura 1 ilustra um cubo voltado para a realidade do setor de Vendas
(Fato de Vendas), o qual composto por trs dimenses: tempo, produto e
cliente e a representao de uma mtrica da tabela fato.

Figura 1 Cubo com Dimenses

Fonte: Adaptado de BARBIERI, 2001

25
Para explorar os dados de um DW utiliza-se a abordagem OLAP (Online Analytical Processing) que possui um conjunto de operaes que
possibilitam anlises do comportamento dos indicadores de negcio permitindo
a descoberta de cenrios e tendncias da organizao (MACHADO, 2006).
As ferramentas OLAP so aplicaes que possibilitam aos usurios
extrair as informaes de apoio deciso de forma dinmica e flexvel. Isto se
torna possvel, pois as ferramentas implementam operaes como slice and
dice e drill que efetuam a anlise dimensional dos dados. Pode-se considerar
que, hoje, h trs formas de implementao das aplicaes OLAP (COLAO
JUNIOR, 2004):

ROLAP (Relational On-line Analytical Processing) utiliza um

repositrio relacional para guardar os dados e a aplicao OLAP
para gerenciar as consultas SQL (Structured Query Language)
definidas pelos usurios;

MOLAP (Multidimensional On-line Analytical Processing) utiliza,

como repositrio dos dados, um SGBD (Sistema Gerenciador de
Banco de Dados) que suporta uma viso multidimensional dos
dados;

HOLAP (Hybrid On-line Analytical Processing) uma variao

das duas abordagens anteriores. Uma vez que esta se utiliza
tanto de repositrio relacional (para grandes volumes de dados),
como de estruturas multidimensionais (por exemplo, cubos) para
consultas que necessitem maior agilidade na anlise das
informaes.

No modelo relacional, tem-se o Diagrama Entidade e Relacionamento

(DER) para representar graficamente as estruturas, operadores e regras que
definem os dados de um projeto de banco de dados. Para os projetos de BI de
construo de Data Warehouses, tambm necessrio o uso de elementos
textuais e grficos que dem suporte modelagem a ser definida. Esta
modelagem precisa atender a todos os conceitos da modelagem dimensional,
utilizada neste tipo de abordagem.

26
2.1.3 Modelos de Dados Multidimensionais

Os princpios bsicos de um modelo ER so identificar os itens

relevantes e geradores de informao para os processos do sistema, as
transaes e os objetivos; identificar as entradas e sadas; bem como as regras
de negcio que restringem a criao dos dados (COLAO JUNIOR, 2004).
Quando se trata de projetos cuja finalidade gerar consultas complexas
que atendam s necessidades de negcio, deve-se quebrar o paradigma de
eliminao de redundncias em um modelo de dados (a normalizao) e
buscar o armazenamento histrico dos dados (COLAO JUNIOR, 2004).
Dentro da modelagem multidimensional, tem-se duas abordagens
principais: o modelo Star Schema e o modelo Snow Flake (MACHADO, 2006).
O modelo Star Schema (estrela) a abordagem, proposta por Ralph
Kimball (1998), que visa criar um modelo mais simples e incremental. Esse
modelo prope o desenvolvimento de projetos de Data Marts menores e
independentes que, posteriormente, podem ser integrados. Esses Data Marts
possuem um assunto especfico, um foco de negcio da empresa. Assim, o
modelo transforma os dados em fatos e dimenses. Portanto, o assunto
principal fica ao centro do modelo e suas caractersticas, as dimenses, ficam
posicionadas ao seu redor, criando, assim, um modelo que lembra uma estrela,
conforme ilustra a Figura 2.

Figura 2 Modelo Star Schema

Fonte: Adaptado de MACHADO, 2006

27
Os relacionamentos entre a tabela central, a tabela Fato, e as
dimenses so ligaes simples, geralmente, um relacionamento de um-paramuitos. Observa-se que, no modelo Star Schema, no se aplica a terceira
forma normal s dimenses. Estas dimenses possuiro toda a hierarquia de
dados, pois isso facilitar a realizao de consultas posteriores.
Um modo de entender, de forma exemplificada, a diferena entre os
fatos e as dimenses, e seu arranjo grfico, utilizar quatro pontos cardeais
que podem auxiliar a descobrir as informaes de dimenso que estaro
dispostas ao redor da ocorrncia o fato.
O fato a ocorrncia, o acontecimento a ser modelado. Por exemplo,
em uma abstrao da venda do dia x de produtos por uma empresa a um
cliente y, tem-se a VENDA como o fato do modelo.
Os quatro pontos de referncia so: O que?, Quando?, Quem? e
Onde? (MACHADO, 2006). Assim, ao analisar o fato, necessrio verificar
quando ele ocorreu, onde se passou, quem o personagem principal e o que
seu objeto. Verificando atravs do exemplo, tm-se as perguntas e respostas
esquematizadas pela Figura 3.

O que? Produto
Quando? Dia x
Quem? Cliente y
Onde? Empresa
Figura 3 Identificando Fatos e Dimenses
Fonte: MACHADO, 2006

Neste caso, este modelo ficaria esquematizado conforme ilustra a Figura

4.

Figura 4 Quatro Pontos Cardeais

Fonte: Adaptado de MACHADO, 2006

28
importante frisar que nem todos os modelos tero os quatro pontos de
referncia podendo, ainda ter mais elementos a serem considerados. Contudo,
esta uma abstrao muito eficiente, j que atende a grande maioria dos
projetos e dos modelos.
O modelo Snow Flake (floco de neve) uma variao do modelo estrela.
Esse possui a mesma abordagem de colocar o fato ao centro e as dimenses
ao seu redor. Contudo, sua abordagem separa as hierarquias das dimenses
em tabelas diferentes, variantes da dimenso principal (MACHADO, 2006).
Este modelo resultado da terceira forma normal nas dimenses,
evitando a redundncia de valores textuais em uma tabela e deixando mais
visvel as hierarquias (MACHADO, 2006).
Porm, esta abordagem pode deixar o modelo bastante poludo
medida que aumentam as dimenses presentes no projeto. Com isso, ao invs
de facilitar a visualizao dos dados, h uma dificuldade de identificar as
dimenses principais e as hierarquias variantes delas (MACHADO, 2006).
Pode-se notar a diferena entre os modelos analisando o esquema da
Figura 5.

Figura 5 Modelo Snow Flake

Fonte: Adaptado de MACHADO, 2006.

Alm dos conceitos relacionados a BI foi necessrio fazer uma anlise

da UML, visto que se pretende identificar possveis adaptaes nesta notao
para a modelagem de sistemas de DW.

29
2.2 UML

A UML (Unified Modeling Language ou Linguagem de Modelagem

Unificada) uma notao grfica criada para modelar sistemas com o
paradigma de orientao a objetos.
Destaca-se que esta no uma linguagem de programao, mas uma
linguagem de modelagem que se tornou um padro nos ltimos anos por ser
adotada internacionalmente em projetos de software (GUEDES, 2007).
Assim que a primeira verso da UML foi lanada, em 1996, diversas
empresas passaram a utiliz-la at ter sido adotada pela OMG (Object
Management Group) como um padro de modelagem.
Esta metodologia baseada em vrios diagramas que permitem
modelar o sistema sob diversos aspectos. Com isto, um diagrama
complementa o outro e a possibilidade de incorrer em falhas, na fase de
desenvolvimento, muito reduzida, j que ao longo da anlise pode-se verificar
erros ou alteraes a serem feitas nos diagramas anteriores (GUEDES, 2007).
Com a UML possvel modelar um software, em diferentes nveis de
abstrao, atravs de diferentes pontos de vista, fazendo com que se tenha
uma identificao e seleo de alternativas mais adequadas ao sistema a ser
modelado, levando-o a um resultado de melhor qualidade (SILVA, 2007).
A verso 2.0 da UML agregou diagramas e props melhorias para
preencher lacunas que as verses anteriores apresentavam, fazendo com que
ela seja mais eficaz e completa para a modelagem de projetos de software
(SILVA, 2007).
A UML 2.0 composta de treze diagramas, classificados em duas
categorias: os diagramas estruturais e os diagramas comportamentais (SILVA,
2007). Os diagramas so desenhados para permitir uma visualizao total do
sistema, sob diferentes perspectivas (BOOCH et. al, 2005). Os primeiros tratam
da parte estrutural tanto do sistema, como das classes. J os ltimos visam
especificar os aspectos do sistema quando em execuo (GUEDES, 2007).
A Figura 6 ilustra as classificaes adotadas pelos diagramas da UML,
considerando a verso 2.0.

30

Figura 6 Diagramas da UML 2.0

Fonte: GUEDES, 2007

Aps o estudo dos treze diagramas foram identificados como passveis

de subsidiar a documentao de algumas das etapas do projeto de sistemas de
BI os seguintes diagramas: Diagrama de Casos de Uso, Diagrama de Classes,
Diagrama de Seqencias, Diagrama de Implantao e Diagrama de Pacotes.
Um resumo de cada um dos diagramas utilizados neste trabalho
apresentado no prximo captulo, durante a sua utilizao.
Os demais diagramas foram excludos da soluo proposta por (i) no
agregarem novas informaes ao projeto, e seu uso s faria o processo ser
mais burocrtico; (ii) terem objetivos que no so aderentes a modelagem de
Data Warehouses ou Data Marts, onde no h interao com usurios no
sistema para o cadastro e controle de informaes. Assim, este trabalho tentou
tornar o processo, de modelagem de DWs, mais documentado e menos
burocrtico, com o intuito de tornar a documentao eficaz atravs do uso de
diagramas.
Desta forma, os diagramas da UML 2.0 no utilizados neste trabalho
foram: Diagrama de Objetos, Diagrama de Estrutura Composta, Diagrama de
Comunicao, Diagrama de Mquina de Estados, Diagrama de Atividades,
Diagrama de Interao Geral, Diagrama de Componentes e Diagrama de
Tempo. Algumas consideraes sobre cada um deles pode ser verificada nos
pargrafos que seguem,
O diagrama de objetos pode ser definido como uma variao do
diagrama de classes, porm com o objetivo de fornecer uma viso dos

31
valores armazenados pelos objetos das classes em determinado momento da
execuo do sistema (GUEDES, 2007). Como em projetos convencionais, em
projetos de BI este diagrama no acrescentar nenhuma informao nova,
apenas demonstrar exemplos dos dados que os objetos armazenaro. Assim,
ele pode ser usado em projetos de DW ou DM quando for necessrio para uma
exemplificao das informaes do projeto, porm no como um componente
crtico para a modelagem do sistema.
O diagrama de estrutura composta um dos trs novos diagramas
propostos pela UML 2.0, sendo um dos diagramas estruturais da linguagem.
Ele voltado a um detalhamento da interligao entre os elementos em tempo
de execuo, por estes estarem envolvidos em prol de um objetivo ou tarefa
em comum (SILVA, 2007). Por ser um complemento da modelagem estrutural,
ele no obrigatrio em projetos de sistemas orientados a objetos e tambm
no nos projetos de BI propostos neste trabalho. Este diagrama pode ser
utilizado quando uma interao precisa ser claramente documentada.
O diagrama de comunicao (at a verso 1.5 da UML) era conhecido
como diagrama de colaborao, tendo seu nome alterado por ser um
complemento do diagrama de seqncias e determinar as conexes entre os
objetos. Ele demonstra praticamente as mesmas informaes do diagrama de
seqncia, contudo sem se preocupar com a temporalidade (GUEDES, 2007).
O diagrama de comunicao no um diagrama essencial no projeto, podendo
servir de apoio quando existirem etapas mais complexas do diagrama de
seqncias que necessitem de uma documentao mais completa para
descrever as regras de negcio que contm. No entanto, verificou-se que, para
modelagens de projetos de Data Warehouse ou Data Marts, os diagramas de
comunicao no agregariam mais informaes alm daquelas j modeladas
pelo diagrama de seqncias que abordaro as fases do processo de ETL.
O diagrama de mquina de estados utilizado para modelar os
diferentes comportamentos ou situaes que um objeto pode assumir ao
longo do processo. Este diagrama pode representar os diversos estados de um
objeto ou os comportamentos do sistema inteiro (GUEDES, 2007). Em uma
modelagem de Data Warehouse ou de Data Mart, acredita-se que ele no ser
til. Uma vez que no h troca de estados de um objeto durante o processo de
carga e a informao no pode ser uma durante a carga e outra ao inseri-la no

32
repositrio. Na verdade, o repositrio conter a ltima posio do sistema
transacional.
O diagrama de atividades foi considerado um caso especial dentro da
UML por estar ligado ao diagrama de estados (hoje denominado de diagrama
de mquina de estados). A partir da verso 2.0 da UML, ele passou a ser
considerado um diagrama independente e voltado a descrever as atividades ou
os passos a serem executados durante o processo. Ele d nfase ao nvel de
algoritmo e provavelmente um dos diagramas com mais detalhes da UML
(GUEDES, 2007). Assim como o diagrama de mquina de estados, o diagrama
de atividades descreve aes a serem realizadas ao longo de um processo.
Como em uma carga de dados para um Data Warehouse ou um Data Mart, os
dados lidos j devem estar prontos, pois no h atividades transacionais aps
esta carga, o diagrama de atividades pode ser dispensado.
O diagrama de interao geral uma variao do diagrama de
atividades. Contudo, esse no se preocupa com a modelagem de cada ao
das atividades, mas, sim, com as interaes modeladas em outros diagramas,
pois seu objetivo fornecer uma viso geral do controle de fluxo. Como o
diagrama uma especializao do diagrama de atividades, criado para
representar o fluxo dos casos de uso, ele no ser um diagrama essencial para
projetos de BI.
O diagrama de componentes um diagrama estrutural que visa
identificar os componentes que fazem parte do sistema modelado. Estes
componentes podem ser representaes de componentes lgicos (de
processos ou de negcios), bem como de componentes fsicos como arquivos
de cdigo-fonte, bibliotecas, arquivos de ajuda etc. (GUEDES, 2007). Para
projetos de sistemas de BI, o uso deste diagrama no apresenta a mesma
eficcia, uma vez que estes sistemas no possuem etapas de processamento.
Um sistema de BI busca os dados finais do sistema transacional, no
necessitando executar etapas mais complexas para obter os dados, e
conseqentemente, no haver muitos componentes para documentar.
O diagrama de tempo enfoca o mesmo escopo que o diagrama de
mquina de estados as alteraes de estado de um objeto. Contudo, o de
tempo utiliza o fator tempo para esta representao. Ou seja, ele modela as
alteraes de estado j descritas na mquina de estados, porm ao longo do

33
tempo (GUEDES, 2007). Assim como o diagrama de mquina de estados, o
diagrama de tempo no ter utilidade em projetos de DW ou DM, pois no h
alterao de estados nos componentes ou destes ligados ao fator tempo. Os
dados so lidos do sistema sem que sejam necessrias transaes posteriores
nos objetos.

Ao concluir esta fundamentao terica, passou-se para o estudo e

validao da soluo, como descreve a prxima seo.

59

4 CONSIDERAES FINAIS

A busca por uma forma de documentar de modo claro, visual e eficiente

projetos de Business Inteligence (BI) foi motivada pela experincia da autora do
trabalho (no papel de analista de sistemas) em suporte, manuteno e controle
desse tipo de sistema. Os modelos Star Schema e Snow Flake, por si s, no
identificam por que os modelos foram desenhados ou como esto
implementados, deixando lacunas importantes para as futuras manutenes
que a empresa possa necessitar no sistema.
Com a concluso do presente trabalho e atravs da validao da
soluo proposta com um estudo de caso real, verificou-se que a proposta de
utiliz-los para a documentao grfica de projetos de BI, foco deste trabalho,
realmente possvel e pode trazer inmeras vantagens aos envolvidos com o
projeto.
A utilizao dos esteretipos facilitou atingir o objetivo do trabalho, uma
vez que proporcionou a aderncia dos diagramas na realidade dos projetos
foco deste trabalho. Pode-se considerar que o estudo da UML, das aplicaes
e das possveis extenses com os esteretipos tenham sido a etapa mais difcil
para o desenvolvimento desta monografia, visto que os conceitos do modelo de
dados, dos requisitos de projetos e dos conceitos de BI j eram conhecidos na
prtica.
Como trabalhos futuros pretende-se implementar toda a modelagem
criada para a validao do presente trabalho, j que a empresa pretende
utilizar o sistema de BI para suas anlises e tomada de decises. Outra
possibilidade de continuao deste trabalho poderia ser a adaptao de
alguma ferramenta para a criao de diagramas, a fim de prever os
esteretipos criados e, assim, facilitar a documentao de projetos de BI.

60

5 REFERNCIAS BIBLIOGRFICAS

ANDRADE, Fbio Bahia. Conceitos de Staging Area aplicados a Data

Warehouses. CienteFico, Salvador, ano III, v II, 2003.

BARBIERI, Carlos. BI: Business Inteligence. Rio de Janeiro: Axcel Books,

2001.

BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML: guia do usurio. 8. ed. Rio
de Janeiro: Campus, 2005.

GUEDES, Gilleanes T.A. UML 2: Guia Prtico. So Paulo: Novatec Editora,

2007.

INMON, W. H. Como construir o Data Warehouse. Rio de Janeiro: Campus,

1997.

ITALIANO, Isabel C.; ESTEVES, Luiz A. Modelagem de Data Warehouses e

Data Marts Parte 1. SQL Magazine, Rio de Janeiro, n. 13, p. 42-45, 2004.

COLAO JUNIOR, Methanias. Projetando Sistemas de Apoio Deciso

Baseados em Data Warehouse. Rio de Janeiro: Axcel Books, 2004.

KIMBALL, Ralf. Data Warehouse Toolkit. So Paulo: Makron Books, 1998.

LARMAN, Craig. Utilizando UML e padres: uma introduo anlise e ao

projeto orientados a objetos. Porto Alegre: Bookman, 2006.

61
MACHADO, Felipe Nery Rodrigues. Tecnologia e Projeto de Data
Warehouse: Uma viso multidimensional. Tatuap: rica, 2006.

SILVA, Ricardo Pereira. UML 2: Modelagem Orientada a Objetos. Florianpolis:

Visual Books, 2007.