tcc joao paulo de sousa neto
DESCRIPTION
Trabalho de Conclusão de Curso focando em Data WarehouseTRANSCRIPT
FACULDADE 7 DE SETEMBRO - FA7 CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO
Implementação de um modelo dimensional utilizando aplicativos freeware
JOÃO PAULO DE SOUSA NETO
FORTALEZA – 2010
JOÃO PAULO DE SOUSA NETO
IMPLEMENTAÇÃO DE UM MODELO DIMENSIONAL UTILIZANDO APLICATIVOS FREEWARE
Monografia apresentada à Faculdade 7 de Setembro como requisito principal para conclusão da disciplina TCC II e obtenção do título de Bacharel em Sistemas de Informação.
Orientador: Prof. Marcelo Bezerra de Alcântara, MSc
FORTALEZA – 2010
IMPLEMENTAÇÃO DE UM MODELO DIMENSIONAL UTILIZANDO APLICATIVOS FREEWARE
Monografia apresentada à Faculdade 7 de Setembro como requisito principal para conclusão da disciplina TCC II e obtenção do título de Bacharel em Sistemas de Informação.
João Paulo de Sousa Neto
Monografia aprovada em: / /
1° examinador:
2° examinador:
Prof. Marum Simão Filho, MSc. (FA7)
Coordenador do Curso
RESUMO
Data warehouse possibilita gerar relatórios que auxiliam na tomada de
decisão dos gestores organizacionais. Esta ferramenta auxilia a gestão na
mensuração quantitativa dos parâmetros que sejam necessários para seu negócio,
como vendas, tempo e etc. A base estrutural de um data warehouse consiste em
tabelas de dimensões e fatos. A primeira armazena a descrição textual da dimensão
do negócio enquanto a segunda, armazena medidas numéricas do negócio, esses
dados são divididos em níveis chamados grãos que são determinados de acordo
com a necessidade de avaliação podendo ser em dia, meses ou anos. As
arquiteturas de data warehouse mais conhecidas são a de [Kimball,2002],
referenciando uma arquitetura global, [Machado, 2000] definindo uma arquitetura de
Data Mart independente e [DWBrasil] citando uma arquitetura de Data Marts
Integrados. A implementação pode ser efetuada de três formas: top-down, a
abordagem bottom-up e a arquitetura BUS. Cada uma destas deve ser utilizada de
acordo com as necessidades da empresa. Umas das vantagens do modelo
dimensional é o aumento de desempenho nas consultas, uma vez que não há
normalização das tabelas, a busca dos dados se torna mais eficiente. Por tanto este
trabalho visa mostrar, passo a passo, a implementação de um data warehouse,
usando ferramentas livres no contexto de um sistema de apoio à decisão.
Palavras-chaves: data warehouse, modelo dimensional, sistemas de apoio
à decisão, OnLine Analytical processing, Data Mart, top-down, a abordagem bottom-
up e a arquitetura BUS.
ABSTRACT
Data warehouse allows to generate reports that helps organizations
managers make their decisions. This tool assists the management’s process by the
parameters quantitative measurement that will be necessary for your business, like
sales, times, etc. The data warehouse’s structural basis consists in a dimension and
facts table. The first one stores the business dimension’s textual description, and the
second one, the business numerical measurement. These data are divided into
levels called “grains”, which are determinated according the evaluation needs, that
could be days, months, or years. The the most know data warehouse’s architecture
are [Kimball, 2002]’s referencing a global architecture, [Machado2000] defining an
independent data mart architecture and [DWBrasil] citing an Integrated Architecture
Data Marts. Implementation can be accomplished in three ways: top-down, bottom-
up approach and BUS architecture. Each of these must be used according to the
company's needs. One of the advantages of the dimensional model is the query’s
performance increase, since there is no normalization of tables, the data search
becomes more efficient. Therefore this paper shows, step by step, the data
warehouse´s implementation, using free tools in the context of a decision support
system.
Keywords: data warehouse, dimensional model, decision support systems, Online
Analytical Processing, Data Mart, top-down, bottom-up approach and architecture
BUS.
LISTA DE FIGURAS
Figura 1: Arquitetura em duas camadas [PANEGASSI, 2006] ............................................................................. 13
Figura 2: Arquitetura em três camadas [PANEGASSI, 2006] .............................................................................. 14
Figura 3: Arquitetura do projeto de DW (Ivairton Monteiro Santos adaptada de KIMBALL (1998)).................. 15
Figura 4: http://www.devmedia.com.br/post-5656-Artigo-SQL-Magazine-13-Modelagem-de-Data-Warehouses-
e-Data-Marts-Parte-1.html ..................................................................................................................................... 18
Figura 5: Nível dual de granularidade [PANEGASSI, 2006] ................................................................................ 18
Figura 6: http://imasters.com.br/artigo/3836/modelo_dimensional_para_data_warehouse .................................. 19
Figura 7: http://mymsiad.blogspot.com/2007/09/o-modelo-dimensional-md-uma-tcnica-de.html ....................... 20
Figura 8: http://www.shammas.eng.br/acad/sitesalunos1106/dw/mod_dime.htm ................................................ 21
Figura 9: http://www.infoescola.com/informatica/data-warehouse/ ...................................................................... 23
Figura 10: exemplo arquitetura top-down (BEVILACQUA, 2003; BITU 2003) ................................................. 25
Figura 11: exemplo arquitetura bottom-up (BEVILACQUA, 2003; BITU 2003) ............................................... 25
Figura 12: Power Arquitect modelagem dimensional ........................................................................................... 29
Figura 13: Spoon ETL ........................................................................................................................................... 31
Figura 14: Schema Workbench ............................................................................................................................. 32
Figura 15: Pentaho tela inical ................................................................................................................................ 34
Figura 16: Relatório gerado a partir de um cubo OLAP ........................................................................................ 35
SUMÁRIO
INTRODUÇÃO ............................................................................................................................................... 8
1.1 MOTIVAÇÃO ............................................................................................................................................. 8
1.2 OBJETIVOS ............................................................................................................................................... 9
1.2.1 OBJETIVO GERAL ................................................................................................................................ 9
1.2.2 OBJETIVOS ESPECÍFICOS .................................................................................................................. 9
1.3 METODOLOGIA ....................................................................................................................................... 9
1.4 ESTRUTURA DO TRABALHO ............................................................................................................. 10
DATA WAREHOUSE .................................................................................................................................. 11
2.1 HISTÓRICO ............................................................................................................................................. 11
2.2 ARQUITETURA ...................................................................................................................................... 12
2.2.1 ARQUITETURA EM DUAS CAMADAS ........................................................................................... 12
2.2.2 ARQUITETURA EM TRÊS CAMADAS ............................................................................................ 13
2.2.3 ARQUITETURA EM VÁRIAS CAMADAS ....................................................................................... 14
2.3 MODELAGEM ......................................................................................................................................... 16
2.3.1 MEDIDAS ............................................................................................................................................. 17
2.3.2 GRANULARIDADE............................................................................................................................. 18
2.3.3 TABELA DE FATOS E DIMENSÕES ................................................................................................ 19
2.4 MODELAGEM DAS TABELAS ............................................................................................................. 20
2.5 FASES PARA CONSTRUÇÃO DE DATA WAREHOUSE ............................................................... 22
2.6 DATA MART ............................................................................................................................................ 24
2.7 CONCLUSÃO .......................................................................................................................................... 26
ESTUDO DE CASO ..................................................................................................................................... 27
3.1 DEFINIÇÃO DO ESTUDO DE CASO .................................................................................................. 27
3.2 MODELAGEM ......................................................................................................................................... 28
3.2.1 POWER ARCHITECT .......................................................................................................................... 28
3.3 ETL ............................................................................................................................................................ 30
3.3.1 SPOON .................................................................................................................................................. 30
3.4 GERAR BANCADA DE TRABALHO .................................................................................................... 31
3.4.1 SCHEMA WORKBENCH .................................................................................................................... 32
3.5 FERRAMENTA DE BI ............................................................................................................................. 33
3.5.1 CONFIGURANDO PENTAHO ............................................................................................................ 33
3.6 CONCLUSÃO .......................................................................................................................................... 36
CONCLUSÃO ............................................................................................................................................... 37
4.1 TRABALHOS FUTUROS....................................................................................................................... 38
REFERÊNCIAS .................................................................................................................................................... 39
8
INTRODUÇÃO
1.1 MOTIVAÇÃO
Durante a década de 80, devido aos avanços tecnológicos em todo o mundo,
existiam áreas as quais os bancos de dados relacionais não eram aplicáveis, devido
à complexidade de novos tipos de dados. Medicina, física e multimídia são exemplos
de algumas das áreas que necessitavam de um meio para representar seus dados
complexos.
A busca pela informação nas organizações ocorre há tempos. No entanto,
muitos até conseguem reunir dados, mas com pouca significância para a
organização, visto que só se tornam informação se estes têm significância para a
organização. Para resolver esta questão, procurou-se então construir uma
ferramenta que fizesse tal trabalho e facilitasse as decisões.
Em 1964, surgiu o Sistema de Informação à Gestão (SIG), no entanto
forneciam relatórios estruturados e que não ajudavam na tomada de decisão. Na
década de 80 surgiram os Executive Information Systems (EIS), os quais utilizavam
os sistemas de base de dados relacionais. Ainda nessa década surgiu um conceito
acadêmico: data warehouse (DW), que tinha o objetivo de integrar dados e
transformá-los em informação. Na década de 90, o DW já possibilitava tratar grandes
volumes de dados, e começou a ser considerado uma ferramenta de apoio à
decisão.
Um das premissas de um DW é a não utilização da Terceira Forma Normal1,
mas sim um modelo dimensional, onde seu processamento é baseado no modelo
OnLine Analytical Processing(OLAP) , no qual seus dados são divididos em tabela
de fatos2 e tabela de dimensões3 com base em um nível de granularidade4.
O uso de um data warehouse vem sendo aplicado nas mais diversas áreas,
como gestão, vendas, compras e outros exemplos conforme ilustrado por [KIMBALL,
2002].
1 3FN – Refere-se à normalização das tabelas de um banco de dados.
2 Armazena medidas numéricas do negócio
3 Armazena descrição textual da dimensão do negócio
4 Nível de detalhamento da medição dos dados
9
Este trabalho se propõe a implementar fisicamente um modelo dimensional
proposto, destacando as fases necessárias para a construção de um data
warehouse, com base em ferramentas livres. Servindo de referência aos
profissionais de sistemas de informação que se interessam em conhecer e aplicar
uma base estrutural de um DW nas organizações.
1.2 OBJETIVOS
1.2.1 OBJETIVO GERAL
Mostrar como implementar um data warehouse utilizando ferramentas livres.
Descrevendo passo a passo a criação de um DW para apoio à decisão, destacando
as ferramentas utilizadas, servindo como orientação para os profissionais na área de
tecnologia da informação que desejam desenvolver uma ferramenta de apoio à
decisão.
1.2.2 OBJETIVOS ESPECÍFICOS
Estudar a base estrutural de um data warehouse definido por [KIMBALL,
2002] e sua aplicabilidade.
Adotar ferramentas livres que permitam implementar um data warehouse.
Elaborar um estudo de caso para mostrar a elaboração de um data
warehouse.
1.3 METODOLOGIA
Este trabalho dar-se-á de maneira qualitativa, com práticas de pesquisa e
desenvolvimento tecnológico.
O problema proposto será abordado mediante pesquisa experimental, e
dissertado da seguinte forma:
- Estudo da base estrutural de um data warehouse.
10
- Adoção de uma ferramenta livre, que permitam implementar um data
warehouse.
- Busca de uma fonte de dados que permita a extração, tratamento e carga
de dados, e mensuração de sua granularidade.
Este conjunto de passos deverá resultar em um guia para a implantação de
um data warehouse, contendo imagens de telas e relatórios. Citando os requisitos
mínimos de hardware e software.
1.4 ESTRUTURA DO TRABALHO
Este trabalho apresenta a estrutura de um data warehouse e a forma de
implementá-lo, estando dividido assim em 4 capítulos. Neste primeiro capítulo é
tratado a parte de introdução, motivação e objetivos do projeto. No segundo capítulo
trataremos do surgimento do DW, tipos de arquitetura, tipos de modelagem, suas
composições e fases para implementação. No terceiro capítulo utilizaremos o passo
a passo sugerido no capítulo anterior para realizar esta atividade, demonstrando
como foi realizado. Por fim, o último capítulo trata de um levantando dos pontos
positivos e dificuldades encontradas durante o projeto.
11
DATA WAREHOUSE
2.1 HISTÓRICO
A partir de 1960 os departamentos de tecnologia da informação começaram a
gerar relatórios estruturados gerados a partir de aplicativos e, em 1965, surgem
problemas como o grande acúmulo de fitas magnéticas, a complexidade na
manutenção dos aplicativos além de dificuldade de sincronização, atualização e
redundância dos dados.
Já em 1970 começa a ser utilizado o Direct Access Storage Device - DASD ,
que conhecemos como disco rígido, e a partir de então surgem os Management
System Database - DBMS, e a partir dele todos os dados seriam processados e
armazenados a partir de um banco de dados único.
Em 1975 surge o Online Transaction Processing - OLTP, com isso
possibilitava atividades que necessitavam de resposta imediata. Em 1980,
começaram a surgir os Management Information Systems - MIS e junto com Fourth-
Generation Programming language - 4GL foi possível manipular melhor os dados e a
partir daí iniciou-se os investimentos na área de Business Intelligence - BI e
conseqüentemente foi gerado uma separação em sistemas transacionais e de apoio
á decisão.
Na década de 90, surgiram, no mercado soluções conhecidas como
extratores, os quais obteriam informações dos sistemas transacionais de várias
bases de dados e armazenavam em outro ambiente. Estes dados já passavam por
uma transformação e padronização, no entanto, muitas vezes havia quebra de
integridade relacional, acarretando assim em descrédito da informação. Isto foi
solucionado com a centralização e o compartilhamento de dados, permitindo fazer
uma análise histórica. A partir de então a forma de armazenamento dos dados
começou naturalmente a ter uma modelagem dimensional, sendo então criado o
conceito de data warehouse.
Um data warehouse, segundo [INMON, 96], é “um conjunto de dados, não
volátil, orientado a tópicos, integrado, que varia com o passar do tempo e que serve
de suporte para o processo de tomada de decisão”. O objetivo deste trabalho é
descrever o processo de construção de um data warehouse, levando em
12
consideração a utilização de ferramentas apenas freeware. Os dados carregados no
data warehouse foram obtidas de bases de dados pertencentes a uma organização
que se utiliza de um DW.
2.2 ARQUITETURA
Data warehouse não é apenas copiar os dados dos sistemas transacionais e
descarregá-lo em um banco de dados maior. É necessário fazer uma análise do que
será carregado, pois uma das características de um DW é a redundância de dados,
no entanto, existem situações que isso não se faz necessário. O que definirá isso
será a arquitetura escolhida e, neste caso, pode haver variações conforme o tipo de
negócio que será abordado.
Existe uma arquitetura genérica que é proposta por [DALL, 99], onde esta
possui várias camadas. É importante ressaltar que esta arquitetura de várias
camadas não obrigatoriamente exige a implementação de todas elas. Além desta
arquitetura, [DALL, 99] também propõe outras arquiteturas como de duas ou três
camadas.
2.2.1 ARQUITETURA EM DUAS CAMADAS
Utilizando um computador de alto nível de performance no que se refere a
processamento como servidor e juntando aplicativos que são utilizados como front
end e componentes back end, é possível então se ter um data warehouse de duas
camadas, conforme a Figura 1.
Segundo [DALL, 99], nesta arquitetura, há uma redução significativa dos
custos, pois utiliza-se apenas de estruturas já existentes. O investimento em
hardware e software fica bastante reduzido, muito embora estas camadas não
possam ser escalonáveis e não podem suportar um grande número de usuários
acessando a aplicação em paralelo e, conforme o autor, uma parte do
processamento é levado para o lado do cliente.
13
Figura 1: Arquitetura em duas camadas [PANEGASSI, 2006]
As aplicações utilizadas pelos usuários ficam de forma transparente, ou
seja, o usuário não percebe o nível de complexidade do sistema, enquanto os
componentes do servidor fazem a verificação dos dados mesmo que estes estejam
dispostos em banco de dados diferentes. Com isso, é possível que exista
redundância de dados a partir de um servidor principal.
2.2.2 ARQUITETURA EM TRÊS CAMADAS
[KIMBALL, 98] afirma que arquitetura em camadas pode ser vista de duas
formas: a divisão de dados operacionais e analíticos e a divisão de funcionalidades
para acesso ao DW. A Figura 2 mostra este tipo de arquitetura.
Na divisão em três camadas, temos na primeira camada os aplicativos
que interagem com os usuários que, neste caso, podem ser web e com interface
bem amigável. Os aplicativos para processamento do negócio ficam na segunda
camada, já os aplicativos para gerenciamento do banco de dados, ficam na terceira
camada, que é responsável pelo compartilhamento de dados entre os sistemas On-
line Transaction Processing (OLTP) e os aplicativos da segunda camada.
A característica da segunda camada entende-se pela forma estática em
que os dados ficam armazenados, ou seja, nunca há alteração, apenas inserção de
dados, isso traz a possibilidade de fazer uma análise histórica do negócio, e com a
sua performance em alto nível por se tratar de sistema On-line Analytical Processing
(OLAP) .
14
Esta arquitetura é a mais usada atualmente, muito embora [DALL, 99]
afirme que não existe arquitetura ideal, o que se deve levar em consideração é a
necessidade do negócio.
2.2.3 ARQUITETURA EM VÁRIAS CAMADAS
[DALL, 99] propõe uma de arquitetura genérica para um DW o qual apenas
sistemiza papéis e, a partir dele, outras estruturas podem ser adaptadas conforme
as necessidades das organizações. Tal estrutura tem sua divisão em camadas que
são: camada de dados operacionais, camada de acesso aos dados, camada de
metadados, camada de gerenciamento de processos, camada de transporte,
camada de acesso à informação, camada do data warehouse. A Figura 3 ilustra esta
arquitetura.
Entende-se por camada de dados operacionais os dados utilizados nas
transações diárias da organização, estas transações podem ser sistemas OLTP, e
ou outras fontes de dados externas que se julgue necessário de acordo com cada
regra de negócio.
Figura 2: Arquitetura em três camadas [PANEGASSI, 2006]
15
A camada de acesso à informação já envolve o software e o hardware que
são utilizados para geração de relatórios que podem ser apresentadas conforme o
usuário deseja como gráficos, planilhas e etc. Nesta camada, há a interação do
usuário e o data warehouse, por meio de ferramentas que permitem o manuseio,
análise e apresentação dos dados, possibilitando inclusive o uso de ferramentas de
Data Mining.
Existe uma camada que faz a comunicação entre as ferramentas que
acessam a informação e os bancos de dados operacionais. Esta é a camada de
acesso aos dados. Permite se comunicar com vários bancos de dados ou sistemas
de arquivos mesmo que possuam protocolos de comunicação diferentes, sendo
conhecido como acesso universal de dados;
Figura 3: Arquitetura do projeto de DW (Ivairton Monteiro Santos adaptada de KIMBALL (1998))
16
Também conhecido como dicionário de dados, a camada de metadados
descreve os dados utilizados pela organização, envolvendo a descrição de registros,
estrutura das tabelas, diagramas, etc.
A camada de gerenciamento de processos faz com que o data warehouse
seja atualizado e que seus dados estejam consistentes, fazendo parte não somente
da construção, mas também da manutenção do DW.
A camada de transporte gerencia o tráfego das informações pela rede,
inclusive coletando mensagens e transações e disponibilizando em locais e tempos
que forem escalonados. Além disso, esta camada faz o isolamento aplicações
operacionais.
Por fim a camada do data warehouse, que representa os dados armazenados
em uma visão lógica de forma dimensional, de forma a facilitar todo o manuseio e
melhoria da performance da consulta dos dados.
2.3 MODELAGEM
A camada do data warehouse começa com a modelagem de dados que é
feita após analise das regras de negócio da organização, portando é considerado
uma passo crítico que vai determinar o sucesso de todo o projeto. Esta modelagem
é feita na forma dimensional que, segundo [Kimball, 96], o objetivo é definir uma
arquitetura que seja intuitiva e que permita executar consultas com alta performance.
Tais características são bem diferentes dos bancos de dados convencionais,
embora algumas ferramentas possam realizar consultas SQL que gerem alguns
tipos de relatórios, tendem a ter um nível de desempenho baixo, em virtude das
inúmeras junções que podem existir, além da falta de flexibilidade.
Os dados que serão persistidos no banco de dados dimensional já devem ter
sido passados pela fase de transformação e a partir destes dados pode ser
disponibilizada a informação em diferentes formatos. A desvantagem deste modelo é
a redundância dos dados, uma vez que um dado pode estar em mais de uma tabela.
Ao verificar as áreas de negócio que serão modeladas, é feito então o
estudo de como será o processo de implementação, para que o mesmo fique de
forma clara e seja especificado com riqueza de detalhes a entidades de dados,
objeto, interações e relacionamentos [INMON, 98; KIMBALL, 98].
17
O modelo dimensional tem três elementos que são os fatos, dimensão e
medidas. A partir deles é possível abstrair os dados na forma de um cubo onde o
fato tem seus contextos que são as dimensões e as medidas são a interseção entre
os fatos e suas dimensões, ou seja, a parte quantitativa dos dados. O conceito
matemático diz que o cubo possui três dimensões, no entanto, no data warehouse,
um cubo pode ter várias dimensões, sendo assim necessário contextualizar um fato
[MACHADO, 2000].
A tabela de fatos contém basicamente duas coisas: as medidas e dados
de contexto, esta pode ser entendida como um identificador da dimensão que
descreve a informação. O fato na realidade é uma transação ocorrida ou um evento
de negócio que ocorreu em certo contexto obtido pela interseção, ou seja, a medida
[KIMBALL, 98; MACHADO, 2000]. Portanto, o fato é uma ação ocorrida no negócio
da organização em determinado tempo e produtos ou serviços.
A tabela de dimensão é a descrição de um fato ocorrido tais como
unidade de tempo, produtos, serviços, clientes, etc, portanto são elementos que
descritivos de um determinado fato [HARRISON, 98; MACHADO, 2000].
2.3.1 MEDIDAS
As medidas, também chamadas de indicadores ou métricas, podem ser
entendidas como a parte mensurável dos dados que estão dispostos, ou seja, mede
o desempenho da organização e a partir delas é que se caracterizam as
informações. Elas não são na realidade uma tabela, mas uma unidade de uma
tabela que se agrega com as descrições da informação. A Figura 4 mostra um
exemplo disso na tabela Pedido com suas métricas de margem de custo, valor do
pedido, etc.
Na tabela de fatos, temos dados que representam os eventos do negócio, ou
seja, a quantificação do fato os quais têm representatividade nos relatórios e com
isso proporcionar suporte à decisão. Estes dados podem ser temporais e numéricos,
isto é, são bem definidos com relação ao tempo e quantifica o negócio. Com isso é
possível agregar os dados em vários níveis de detalhamento e para isso são
utilizadas funções matemáticas como adição, máximo, contagem, mínimo e etc.
18
2.3.2 GRANULARIDADE
A forma como os dados estão sumarizados no DW é determinado por níveis.
Estes níveis são determinados pela necessidade do negócio. Portanto, quanto maior
for a necessidade de detalhamento das informações, menor será o nível de
granularidade, portanto, esta característica é fundamental no data warehouse.
Quanto menor for o nível de granularidade, maior será o conjunto de dados que
estarão armazenados no data warehouse. [DALL, 99] afirma que, com níveis de
granularidade muito altos, exige-se um espaço menor em disco, além de exigir um
menor conjunto de índices, proporcionando mais desempenho para os recursos de
processamento de dados. A Figura 5 mostra exemplo desta granularidade.
Podemos colocar então os níveis de granularidade de duas formas: a
granularidade de forma mais resumidas em estruturas específicas e em outras com
maior detalhamento, neste caso é conhecido como nível dual de granularidade.
Figura 4: http://www.devmedia.com.br/post-5656-Artigo-SQL-Magazine-13-Modelagem-de-Data-
Warehouses-e-Data-Marts-Parte-1.html
Figura 5: Nível dual de granularidade [PANEGASSI, 2006]
19
Segundo [INMON, 97] a proporção que o nível de granularidade aumenta, a
possibilidade de detalhamento da informação diminui, entretanto em níveis mais
baixo possibilita efetuar consultas com bom nível de detalhamento.
A granularidade também deve ser definida neste momento, pois é a partir dele
que serão armazenados os níveis dimensionais. A granularidade pode ser definida a
partir do volume de dados que se deseja serem persistidos e obviamente que sejam
consistentes.
2.3.3 TABELA DE FATOS E DIMENSÕES
Os dados os quais se realizam operações matemáticas e estatísticas, ou
seja, as medidas ou métricas ficam persistidos na tabela de fatos e a partir deles
permite mensurar a informação de forma quantitativa, dando margem para medição
do desempenho do negócio. Portanto a tabela de fatos é uma medição das
interseções das dimensões. As dimensões da tabela de fatos determinam sua
granularidade e conseqüentemente o seu detalhamento. Na tabela fatos, uma tupla
corresponde a uma medição.
Além das medidas também compõem a tabela de fatos as chaves primárias
das tabelas de dimensão. A Figura 6 mostra a tabela de fatos com suas dimensões.
[INMON, 98] considera que os índices das tabelas de dimensão contidos na tabela
de fatos é na realidade um campo multi-key.
Figura 6: http://imasters.com.br/artigo/3836/modelo_dimensional_para_data_warehouse
20
Segundo [Machado, 2000], o fato representa uma transação ou evento de
negócio que ocorreu em um determinado contexto a partir das interseções das
dimensões. A tabela de fatos possui um número muito maior de tuplas que as
dimensões, portanto, exige que cuidados sejam tomados para não afetar a
performance da aplicação.
2.4 MODELAGEM DAS TABELAS
Um ponto importante é a estrutura das tabelas, as mais conhecidas são:
esquema estrela e esquema floco de neve.
No modelo estrela, nas tabelas de dimensão, não existem nenhum tipo de
normalização e de acordo com [KIMBALL, 98; MACHADO, 2000], estas tabelas tem
o objetivo de estruturar os dados de forma intuitiva e com muitos bons índices de
performance em consultas. A Figura 7 ilustra este modelo.
Esta denominação ocorre por que a tabela de fatos tem uma
característica "dominante" no centro do esquema e as tabelas de dimensões ao seu
redor, ou seja, ela está ligada a todas as tabelas por múltiplas junções e
conseqüentemente, as tabelas de dimensões se ligam unicamente à tabela de fatos.
Este modelo é o mais usado pelas organizações, portanto, torna-se
previsível e muitas ferramentas já se utilizam desta estrutura para deixar uma
interface mais amigável para o usuário final, além de processamento mais eficiente.
Outro ponto é a flexibilidade para inclusões de novos elementos.
Figura 7: http://mymsiad.blogspot.com/2007/09/o-modelo-dimensional-md-uma-tcnica-de.html
21
Na estrutura floco de neve, existe certa normalização entre dimensões
principal e as de extensão [HARRISON, 98 ; KIMBALL, 98]. As tabelas de extensão
armazenam descrições da dimensão principal, ou seja, ela é a decomposição da
dimensão principal. Isto ocorre quando as dimensões são muito grandes ou a
ferramenta que está se utilizando para modelagem exige uma hierarquia das
dimensões. Sua desvantagem é o aumento da complexidade em algumas consultas
por causa do uso de junção entre as dimensões principal e de extensão, reduzindo
conseqüentemente o desempenho [HARRISON, 98]. Esta estrutura faz com que a
quantidade de dados que são carregados para a memória seja bem menor, uma vez
que informações redundantes são reduzidas, em virtude das tabelas de extensão
que guarda a descrição da informação e, na tabela de dimensão fica apenas o
identificador desta informação. A Figura 8 ilustra este exemplo.
Este modelo tem como vantagem a redução de espaço de armazenamento
dos dados dimensionais, no entanto, acrescenta várias tabelas à sua estrutura,
deixando-a com um nível de complexidade maior, o que impacta na navegabilidade
pelos softwares que utilizarão o banco de dados. Com isso, a interface com o
usuário poderá ser menos amigável. Outro ponto que deve ser considerado é que
neste caso há junções entre a tabela de dimensão e suas extensões, o que tornará a
consulta menos performática.
Figura 8: http://www.shammas.eng.br/acad/sitesalunos1106/dw/mod_dime.htm
22
2.5 FASES PARA CONSTRUÇÃO DE DATA WAREHOUSE
A estrutura de um data warehouse exige que inicialmente seja feita uma
análise das regras de negócios para verificar os dados mais importantes da
organização. Após isso, passa-se a criar a modelagem dimensional o qual
[HARRISON, 98] afirmam que proporciona ao usuário percorrer pelo data warehouse
e fazendo combinações entre tabelas, especificando informações históricas em
níveis temporais, onde tais características encontram-se nas tabelas de dimensão.
Esta modelagem pode ser feita em um diagrama. Neste momento, são determinadas
as características da modelagem, como os fatos, dimensões e medidas, além da
determinação da granularidade. Após isso, cria-se essa estrutura em um banco de
dados, lembrando que a estrutura do banco de dados dimensional não é
normalizada.
Uma vez tendo a sua modelagem no banco de dados, se tem então uma nova
fase, que é a modelagem da estrutura dimensional para a ferramenta que
disponibilizará os dados para o usuário final. Esta modelagem pode ser feita em uma
estrutura XML, uma vez que esta estrutura facilita a comunicação entre interfaces.
Esta modelagem XML segue a mesma estrutura do banco de dados dimensional e
que a partir deles a consulta de dados pode ser feita de forma bem flexível. Por fim
este modelo será publicado em uma ferramenta, seja esta web ou desktop.
A terceira fase e mais importante dela é a fase do ETL(Extract, Transforme e
Load ) dos dados. Esta fase pode ser subdividida em três subfases. Segundo
[COLAÇO, 2004] esta fase representa aproximadamente 70% de todo o processo de
construção de um data warehouse.
A extração executa a parte de consulta no banco OLTP e verifica todos os
dados que são necessários para atualizar o banco de dados dimensional, sendo
necessárias consultas bem elaboradas, verificando-se a corretude das informações.
A transformação já é responsável pela análise dos dados. É importante
ressaltar que isto não pode ser confundido com data mining. Esta análise tem o
objetivo de padronizar informações para que dados que venham em formatos
diferentes, uma vez que os dados podem vir não apenas de aplicativos únicos e
23
como mesma estrutura, mas sim de qualquer fonte de dados e com qualquer
formato.
E por fim a carga, esta subfase é a atualização dos dados no banco de dados
dimensional, fazendo a carga necessária nas suas estruturas respectivas e, neste
caso, pode-se haver redundância dos dados. A a Figura 9 ilustra todas as atividades
acima mencionadas.
Segundo [COLAÇO, 2004], existem ainda a área de estágio e o ODS as quais
fazem parte da carga, estas são respectivamente a parte de integração e limpeza
dos dados. A análise dos dados obtidos fica em um tipo de quarentena para
verificação com o objetivo de garantir que os dados estão realmente corretos.
Podemos utilizar então um check list para guiar na construção do DW:
1 – Modelagem dimensional a partir da análise do negócio
2 – Gerar o modelo dimensional fisicamente em um SGBD
3 – Criar o ETL
4 - Gerar a bancada de trabalho
5 – Configurar a ferramenta de BI
6 – Efetuar testes de consistência de dados
Figura 9: http://www.infoescola.com/informatica/data-warehouse/
24
2.6 DATA MART
Segundo [INMON, 97], data mart é apenas um subconjunto de dados que
compõe um data warehouse, com a finalidade de prover informações de setores
específico dentro de uma organização.
[KIMBALL, 98] afirma que embora os data marts resolvam certas
necessidades em prover informação para a tomada de decisão de uma organização,
estes não podem substituir um data warehouse, ou seja, uma data mart não pode
ser considerado um pequeno DW.
Os projetos de data marts se justificam em poucos casos, basicamente
aqueles onde a alta gerência ainda não esta convencida quanto a viabilidade e
vantagens que a tecnologia do data warehouse pode prover às organizações. Neste
caso, os data marts são viáveis por apresentarem resultados mais rápidos, demoram
entre 4 a 12 meses para serem implementados e, em conseqüência, começam a dar
resultados mais rápidos. Os data warehouses têm prazos que variam entre 1 a 5
anos para implementação completa.
Os data warehouses possuem uma arquitetura centralizada, essa
uniformidade traz maior controle e maior segurança, no entanto é muito complexa
esta abordagem, pois exige uma metodologia rigorosa, além de ser necessário obter
a compreensão de todos os negócios da organização, por isso torna-se longa e com
o alto custo.
Os data marts (warehouse departamental) têm a característica de
descentralizar o armazenamento da informação, onde sua implementação pode ser
de duas maneiras:
- Top-down: uma vez a organização tendo um DW faz-se a divisão
do mesmo em componentes menores, implicando então em pequenos bancos
orientados à assuntos de um setor específico, conforme a Figura 10 exemplifica .
25
- Botton-up: nesta abordagem faz o inverso, geralmente esta
situação ocorre quando não se há confiabilidade na aplicação e, portanto faz a
implementação apenas em um setor, e gradativamente conforme as expectativas do
gestor vão sendo satisfeitas ele vai criando outros data marts setoriais, onde isso
implica em baixos custos, conforme podemos ver na Figura 11.
Todas as atividades executadas para a criação de um data warehouse
também são executadas no data mart e suas diferenças são basicamente em
volume de dados a serem armazenados e na complexidade do ETL. A principal
Figura 10: exemplo arquitetura top-down (BEVILACQUA, 2003; BITU 2003)
Figura 11: exemplo arquitetura bottom-up (BEVILACQUA, 2003; BITU 2003)
26
diferença é que o DW é orientado a assuntos de toda a organização enquanto o DM
orienta-se apenas a assuntos de um setor específico.
2.7 CONCLUSÃO
Ferramentas de apoio à decisão estão cada vez mais presentes nas
organizações, uma delas é o data warehouse, que, para sua construção, é
necessário a análise do negócio.
A estrutura desta ferramenta é diferente das arquiteturas de armazenamento
de dados convencionais, além disso, tem sua característica de melhoria de
flexibilidade e desempenho na extração de informação, contudo exige uma base de
dados bastante grande em virtude principalmente da redundância dos dados.
Na fase de construção, faz-se necessário a aplicação de ferramentas
auxiliares para gerar todo o conjunto de mapeamento, extração de carga dos dados,
quando as ferramentas contêm todo um pacote completo para todo o processo.
Tais ferramentas geralmente são ferramentas caras e que necessitam de
profissionais extremamente treinados e por isso há uma escassez deste tipo de
profissional no mercado. No entanto, existem ferramentas freeware que são de fácil
acesso tanto para a sua utilização bem como para os profissionais que desejam
conhecer e se aperfeiçoar nestes aplicativos.
No capítulo seguinte, vamos seguir o passo a passo definido neste capítulo,
apresentando um exemplo prático da criação de um DW.
27
ESTUDO DE CASO
3.1 DEFINIÇÃO DO ESTUDO DE CASO
O projeto Vila do Mar tem a finalidade de melhorar as condições de
moradia das famílias de Fortaleza que se encontram em áreas de risco. Para tanto,
foi feito o cadastramento destas famílias em um banco de dados e foi utilizada uma
ferramenta para apoio à decisão, para se permitir analisar as informações de forma
quantitativa e gerar relatórios gerencias. Desta forma, pode-se verificar as atividades
que devem ser feitas e a prioridades das mesmas.
Este projeto é de iniciativa da Prefeitura Municipal de Fortaleza e esta
instituição tem o objetivo de utilizar software livre. Portanto, a escolha da ferramenta
para apoio à decisão foi levada em consideração também neste quesito, além de
verificar a maturidade da ferramenta no mercado. Após esta análise, foi decidido o
uso do pentaho, além de outras ferramentas que também são freeware e que
complementam este trabalho.
Para fazer a aplicação, foi iniciado com a modelagem do data warehouse,
o qual foi feita na ferramenta power architect. Em seguida, foi feita a parte do ETL,
que para isso utilizou-se de uma ferramenta que também é disponibilizada pela
pentaho, o spoon. Logo após o esta etapa, foi feito o XML que é necessário para
que o pentaho utilize a modelagem dimensional feita no banco de dados postgresql.
Este XML foi feito utilizando a ferramenta schema workbench. Todas as ferramentas
utilizadas são extremamente produtivas, uma vez que as mesmas possibilitam a
construção de todas as etapas de forma gráfica, ou seja, sem a necessidade de
escrever códigos de baixo nível.
A etapa final é o deploy do XML no pentaho que é feita a partir do schema
workbench e também a configuração no pentaho de conexão com banco de dados,
usuários e divisão de diretórios para colocar relatórios pré-definidos para os
usuários, a fim de facilitar consultas que são feitas constantemente.
Após todas estas etapas, ainda são necessários os testes e a
homologação por parte do cliente sobre a aplicação.
28
A seguir vamos detalhar os passos do check list sugerido no capítulo 2
para criarmos a aplicação.
3.2 MODELAGEM
Para realizarmos a modelagem, é necessário inicialmente que seja feito
uma entrevista com o cliente e verificar suas necessidades de informação, junto a
isso é preciso verificar como os dados serão obtidos, ou seja, quais os bancos de
dados serão utilizados e como estes dados estão organizados. Após isso, iremos
então criar o modelo dimensional com a ferramenta power architect, onde a partir da
mesma será criada a modelagem lógica.
3.2.1 POWER ARCHITECT
Esta ferramenta ajuda na modelagem do data warehouse, uma vez que a
forma de visualização da estrutura que se está trabalhando facilita o entendimento
dos dados de forma a melhorar a produtividade do trabalho e a correta confecção do
modelo.
O power arquitect tem duas versões, a enterprise e a community. Neste
caso estamos utilizando a community que é freeware e um dos objetivos deste
trabalho é usar apenas soluções software livre.
A sua utilização basicamente é de uma ferramenta gráfica que ao clicar
na opção de adicionar uma tabela e clicar com o mouse na área de desenho
aparece a opção para colocar o nome da tabela, depois de colocar o nome desejado
e clicar em OK a tabela aparece na área de desenho. Se selecionarmos a tabela
podemos clicar então no ícone adicionar colunas e nesse caso iremos colocar o
nome do campo, o tipo, se vai ser chave primaria, se pode ser nulo e valor padrão.
Depois de colocarmos todos esses parâmetros para cada tabela, iremos dizer qual o
relacionamento, neste caso é importante lembrar que por padronização colocamos
as tabelas de fatos com nomenclatura inicial com a letra “F” e as tabelas de
dimensões com nomenclatura inicial com a letra “D”, para o relacionamento
29
devemos clicar no ícone relacionamento e clicar nas tabelas e dimensões e
seqüencialmente na tabela de fatos. A Figura 12 ilustra estes passos.
Após todos esses passos, temos então graficamente a nossa modelagem,
e teremos que passar este modelo para o banco de dados. Neste caso a ferramenta
vai nos auxiliar para não precisarmos criar e executar os comandos de SQL. Iremos
então configurar a conexão com banco de dados. Na barras de menus, iremos à
opção conexão e a partir dele no subitem gerenciar conexões, abrirá uma janela
onde vamos selecionar a opção nova conexão e será solicitados os dados para
realizar a conexão como o tipo de banco de dados, o host, a porta, o usuário e
senha.
Após os passos descritos acima, clicamos na opção comparar, ele nos
trará uma tela em que na opção projeto antigo iremos colocar a conexão que
criamos e a opção projeto atual o nome da nossa modelagem que foi salva, e por
conseguinte clicamos na opção iniciar onde nos mostrará uma janela com todos os
comandos SQL e nessa janela selecionamos a opção executar e com isso temos a
nossa modelagem dimensional persistida no banco de dado.
Figura 12: Power Arquitect modelagem dimensional
30
3.3 ETL
Esta etapa exige o maior esforço da atividade de criação, pois nela iremos
fazer as consultas no banco de dados operacionais, depois fazer o tratamento nos
dados com a finalidade de padronizar dados e por fim carregar os dados tratados
para o banco de dados dimensional. Utilizamos então a ferramenta spoon que
facilita este trabalho, permitindo executar estas três tarefas de forma gráfica.
3.3.1 SPOON
No quesito ETL, utilizamos então esta ferramenta que nos possibilita
executar esta tarefa de modo gráfico diferenciando dos convencionais scripts.
Basicamente precisamos de três tarefas, que são a extração dos dados em um
banco de dados, algum tratamento de dados que seja pertinente e a carga destes
dados. No menu lateral, temos o view e desing. O view tem a finalidade de navegar
nos projetos de transform, e o desing possui vários subitens como input, output, jobs
dentes outros. Os subitens input e output tem a finalidade de fazer a conexão e
executar comandos de consultas com bancos de dados transacionais, arquivos de
planilha eletrônica e outros, portanto, no subitem input arrastaremos a opção table
input para a área gráfica e depois iremos no output e arrastaremos a opção table
output também para a área gráfica, após isso clicando com o mouse no input e
arrastamos até o output, ambos que foram inseridos na área gráfica, criando assim
um step que significa a operação de transferência de dados, a Figura 13 nos mostra
o resultado desta atividade.
Em cada objeto colocada da área gráfica, ou seja, o input e output iremos
configurar as conexões com as base de dados, para isso daremos dois cliques com
o mouse em cima de cada objeto e com isso nos mostrará uma janela a qual iremos
na primeira colocar o nome do objeto e na segunda opção que é a conexão com o
banco de dados, o qual nos apresentará uma nova janela em que colocaremos os
dados de conexão, ou seja, host, banco, usuário e senha. Depois clicamos em ok e
voltamos para a tela anterior. Nesta tela temos então a opção de colocarmos a
consulta ao banco a qual nos iremos trazer os dados que desejamos.
31
Feita a parte de colocar todas as consultas necessárias para a extração
dos dados teremos que configurarmos o output também similar ao input dando dois
cliques com o mouse onde aparecerá uma janela para colocarmos o nome do objeto
a conexão, o schema e o nome da tabela.
Em cada seta do modelo gráfico podemos colocar as transformações que
forem necessárias assim sejam necessárias estas transformações são anexadas
aos steps e no menu lateral tem opções como javascript e outros tipos de opções
para efetuarmos esta atividade. Concluindo esta parte, clicamos então no botão
efetuar transformação, e neste momento os dados serão extraídos, tratados e
carregados no banco de dados dimensional.
3.4 GERAR BANCADA DE TRABALHO
Esta fase é basicamente criar um XML schema que permitirá ao pentaho
utilizar os dados que estão no banco de dados dimensional, ou seja, é um molde
para que os dados sejam manipulados pela ferramenta de forma flexível e seguindo
os conceitos de um data warehouse. Para isso, utilizamos o schema workbench que
Figura 13: Spoon ETL
32
permite gerar a bancada de forma bem simples, uma vez que o XML pode ser
gerado de forma gráfica.
3.4.1 SCHEMA WORKBENCH
Esta ferramenta é utilizada para gerar o XML que será importado para o
pentaho, como ponto mais positivo pode ser entendido a forma de edição deste XML
que é feito de forma totalmente gráfica permitindo então uma maior compreensão do
modelo dimensional, muito embora esta modelagem tenha sido feita pela ferramenta
power arquitect, a partir desta estrutura visualizaremos a forma como um cubo
estará disposto, conforme ilustra a Figura 14.
Inicialmente começamos configurando a conexão com o banco de dados
dimensional, uma vez que é pré-requisito o já termos o data warehouse, esta
configuração e feita a partir da barra de menus na opção ferramentas no subitem
conexão, e lá colocaremos os dados de host, porta, driver, usuário e senha.
Após este passo, iremos então clicar com o botão direito do mouse em
cima do ícone schema, e com isso será nos mostrado uma lista de itens que
Figura 14: Schema Workbench
33
poderemos inserir, como um cube, dimensões, medidas e até cubos virtuais.
Portanto após inserirmos todas as entidades que queremos para o cubo
faremos então o deploy para o pentaho, de forma que este arquivo esteja pronto
para o uso. Então no menu arquivo clicamos na opção publicação e nele
colocaremos os dados de endereço para o seu servidor do pentaho, após isso
clicamos em ok e nos apresentará uma nova janela a qual colocaremos o path onde
o xml será guardado e depois clicamos em ok.
3.5 FERRAMENTA DE BI
As ferramentas de BI permitem à gestão executar consultas de forma
macro, ou seja, de forma quantitativa. Um exemplo desta ferramenta é o pentaho.
Estas ferramentas possibilitam que consultas sejam feitas sem a necessidade de
solicitar a TI. Estas ferramentas permitem que o próprio usuário final construa suas
consultas sem exigir esforço. Basicamente, o usuário arrasta os parâmetros que,
neste caso são o fato e suas tabelas de dimensões, para uma área de consulta que
é gráfica e a ferramenta executa a tarefa.
3.5.1 CONFIGURANDO PENTAHO
Para esta fase o principal requisito é o conhecimento da ferramenta, pois
a partir dela temos a área de usuário final e a área de usuário administrador, estas
áreas são utilizadas em portas diferentes.
Existem duas versões para essa ferramenta que são a enterprise e a
community. Estamos usando a versão community, uma vez que um dos objetivos é
utilizar soluções freeware, conforme exemplificado na Figura 15.
A primeira coisa a ser feita é iniciar o serviço do pentaho, este serviço é
dividido em atividades de administração e atividades de consultas de usuário, as
quais são divididas em diretórios diferentes da aplicação, onde o primeiro é iniciado
a partir do arquivo executável “start-pac.sh” e o segundo a partir do arquivo
executável “start-pentaho.sh”. “Os arquivos executáveis com extensão “.sh“ são
usados quando o serviço está sendo utilizado em um sistema operacional Linux,
caso contrário esses arquivos são com a extensão “.bat” .
34
Após iniciar o serviço do pentaho poderemos acessá-los a partir das
portas 8099 para o serviço de administração e 8080 para o usuário, a Figura 15
mostra como . Na aplicação de administração iremos configurar a conexão com o
banco de dados, na aba database connections iremos informar nome da conexão,
usuário, senha, driver e endereço do banco de dados.
Na aplicação do usuário final temos três atividades:
New Report;
Manage Content;
- New Analylis View;
O new report tem a finalidade de gerar relatórios a nível operacional, ou
seja, gerar uma lista conforme o usuário modele informando os campos e layout
desejados. Para isso deve-se configurar a conexão com um banco de dados e um
usuário avançado que informe o SQL desejado.
O manage content tem a finalidade de gerenciar as atividades do pentaho,
tais como editar, compartilhar e principalmente fazer escalonamento de atividades,
com isso é possível automatizar a atualização dos relatórios.
Figura 15: Pentaho tela inical
35
O new analysis view vai nos permitir trabalhar com o cubo OLAP, ou seja,
com ele vamos pegar o nosso cubo e gerar relatórios gerenciais com os dados que o
usuário desejar. Com isso, ele pode graficamente executar consultas sem a
necessidade de conhecimento de linguagens de baixo nível, necessitando apenas
de ter conhecimento de manipulação da informação, portanto, é um usuário que
sabe ler a informação de forma quantitativa e com isso usar como suporte a decisão,
e ainda gera imediatamente um gráfico que pode ser personalizado para a
apresentação da consulta.
O cubo que utilizamos no analysis view fica disponível a partir do deploy
feito na ferramenta schema workbench, portanto quando clicamos nessa atividade a
opção que devemos escolher é o schema e a partir dele selecionamos os cubos
disponíveis para fazer a manipulação da informação.
Outras funcionalidades que podemos utilizar é deixar relatórios pré-
definidos evitando retrabalhos de montagem de relatórios. Podemos escalonar a
atualização do data warehouse, ou seja, o seu ETL. Além disso, ele nos disponibiliza
os dashboards, que são gráficos dinâmicos os quais permitem navegar dentro de
certo intervalo de dados. A Figura 16 mostra exemple de relatório gerados pelo cubo
OLAP, proporcionando uma visão por meio de gráficos ou dados quantitativos a
partir das métricas.
Figura 16: Relatório gerado a partir de um cubo OLAP
36
3.6 CONCLUSÃO
Ao fim desse projeto, foi possível ver os benefícios de um data
warehouse, pois a forma de apresentação dos dados com o uso de dashboards e
informações a nível gerenciais permitem um excelente suporte à decisão, além da
interface extremamente amigável ao usuário.
A complexidade de a aplicação dar-se principalmente pela necessidade
de conhecimento das regras de negócio, além da formas como os dados estão
dispostos no banco de dados relacional, pois no atividade de ETL é possível verificar
falhas de consistência dos dados.
Com relação às ferramentas, mostraram-se eficientes e de fácil uso,
possibilitando uma maior agilidade nos trabalhos e, portanto permitiu construir toda a
aplicação utilizando apenas ferramentas freeware.
37
CONCLUSÃO
Este trabalho proporcionou o desafio de entender os conceitos
necessários à construção de um data warehouse, o sucesso em conseguir
implementar esta estrutura, além de conhecer a real utilidade desta aplicação e
utilização pelo mercado atual, mostrando que não é apenas conceitual.
Os passos utilizados para fazer a implementação foram sugeridos a partir
de conceitos absolvidos de trabalhos de profissionais como Kimball, Inmon, etc.
Conseqüentemente a partir da prática, foi possível verificar alguns itens essenciais
para esta atividade, como a modelagem dimensional que se não for feita de forma
correta implica no insucesso do projeto.
Ao conhecer as ferramentas freeware foi possível verificar que existe um
grande número de profissionais que já usam estes aplicativos e que compartilham os
seus conhecimentos de utilização dos mesmos, e com isso podemos ver que tais
ferramentas já estão maduras no mercado.
As dificuldades encontradas foram principalmente em absolver os
diversos conceitos que englobam um data warehouse, pois embora tenhamos um
grande número de informações disponíveis, como em livros e sites, este assunto vai
além dos conceitos encontrados a respeitos de banco de dados convencionais.
O ponto de maior observação positiva é o grande aceite por parte dos
usuários finais. Tal projeto foi iniciado a fim de verificar a possibilidade de se usar um
aplicativo de apoio à decisão na prefeitura de Fortaleza e, após esta entrega, os
gestores decidiram expandir esta ferramenta para vários setores da prefeitura, em
virtude da satisfação do resultado do projeto.
O aprendizado deste assunto possibilitou observar que sua importância
nas faculdades ainda é pouco relevante, no entanto, o mercado atual mostra um
grande interesse na implementação de data warehouse nas organizações como um
ferramenta de apoio à decisão. Portanto, este trabalho busca trazer este assunto
para o meio acadêmico de forma mais enfática.
38
4.1 TRABALHOS FUTUROS
Após a realização deste trabalho e a conclusão do projeto de
implementação de um DW, podemos destacar os seguintes tópicos para trabalhos
futuros:
- Estudo da ferramenta de Pentaho para aprofunda-se sobre as
facilidades que a ferramenta possibilita e seus pontos negativos.
- Fazer comparação entre ferramentas freeware que sejam utilizadas para
construção de data warehouse.
- Estudo dos modelos dimensionais estrela e floco de neve para fazer
uma comparação e determinar as situações cabíveis para cada modelo.
- Estudo de junções de Data Mart para verificar como é o processo e
determinar quais os processos mais indicados.
39
REFERÊNCIAS BIBLIOGRÀFICAS
BEVILACQUA, José Francisco; BITU, Yuri Aguiar, Business Intelligence e a
abordagem de Gestão Balanced Scorecard na Organização. Monografia
(pós-graduação Latu Sensus em Informática) – MBA em Gestão de Sistemas de
Informação,Universidade Católica de Brasília, Brasília, 2003.
COLAÇO, Matias. Projetando Sistemas de Apoio à Decisão Baseados em Data
Warehouse. Axcel Books: Rio de Janeiro, 2004.
DALL, Adriano Alba. Um estudo sobre Data Warehouse. Disponível em:
http://www.oocities.com/siliconvalley/port/5072/. Acessado em: 25/09/2010.
HARRISON, T. Intranet Data Warehouse. São Paulo: Berkeley, 1998.
INMON, William Harvey. Como Construir o Data Warehouse. Editora Campus.
Rio de Janeiro, 1997.
INMON, William Harvey; HACKATHORN, Richard D.. Using the Data warehouse.
1a Ed. USA: Wiley, 1994.
INMON, William Harvey. Building the Data warehouse. 2a Ed. USA: Wiley, 1996.
INMON, William Harvey. Corporate Information Factory. With Claudia Imhoff and
Ryan Sousa. John Wiley and Sons, Wiley 1998
KIMBAL, Ralph. The Data Warehouse Toolkit. New York: John Wiley & Sons,
Wiley, 1996.
KIMBALL, Ralph. Data Warehouse toolkit. São Paulo: Makron Books, 1998.
KIMBALL, Ralph; ROSS, Margy. The Data Warehouse Tollkit. Tradução da 2ª
edição original. Rio de Janeiro: Campus, 2002.
40
KIMBALL, Ralph; ROSS, Margy. The Data Warehouse toolkit: The Complete
Guide to Dimensional Modeling. 2a Ed. USA: Wiley, 2002.
MACHADO, F. N. R. Projeto de data warehouse: uma visão multidimensional.
São Paulo: Érica, 2000
MICROSOFT Corporation. Extending OLAP Cube Services in Microsoft Project
Server. Disponível em: http://msdn.microsoft.com/en-us/library/aa188799.aspx.
Acessado em: 25/08/2008.
PANEGASSI, Luis Fernando. Data Warehouse. 2006. Monografia (graduação em
Ciência da Computação) – Curso de Ciência da Computação, Faculdade de
Jaguariúna, Jaguariúna, 2006.
PENTAHO Community. Latest Pentaho Data Integration (aka Kettle)
Documentation. Última documentação atualizada disponível sobre o aplicativo
Data Integration da Pentaho Open Source Business Intelligence. Disponível em
<http://wiki.pentaho.com/display/EAI/>. Acesso em: 12 mar 2010.
PENTAHO, Open Source Business Intelligence. Pentaho Reporting Home Page.
Pagina principal do projeto Pentaho Reporting da Pentaho Open Source Business
Intelligence. Disponível em <http://reporting.pentaho.org/>. Acesso em: 12 mar
2010.
SERRA, Laércio. A essência do Business Intelligence. São Paulo: Berkeley
Brasil, 2002.
SOURCEFORCE.Net. Documentação do PostgreSQL 8.0.0. Documentação
traduzida sobre PostgreSQL versão 8.0.0 pela comunidade Sourceforce.Net.
Disponível em <http://pgdocptbr.sourceforge.net/pg80/preface.html>. Acesso em: 30
out 2009.