Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
UNIVERSIDADE DO SUL DE SANTA CATARINA
GABRIEL KOERICH DUARTE
UMA PROPOSTA DE SOFTWARE PARA IMPLEMENTAÇÃO DE CUBO DE
DADOS PARA MONDRIAN
Palhoça
2013
GABRIEL KOERICH DUARTE
UMA PROPOSTA DE SOFTWARE PARA IMPLEMENTAÇÃO DE CUBO DE
DADOS PARA MONDRIAN
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Sistemas de Informação.
Orientador: Prof. Aran Bey Tcholakian Morales, Dr.
Palhoça
2013
RESUMO
O presente trabalho objetiva apresentar uma proposta de software para o desenvolvimento de
um cubo de dados, que é um conceito de análise do Business Intelligence, para integração
com o servidor de consultas OLAP Pentaho Mondrian. Desta forma, o software tem por
requisito gerar um arquivo, chamado Schema XML do Mondrian, o qual possui todas as
informações de metadados do cubo de dados para ser integrado ao servidor Mondrian, a fim
de executar consultas em um data mart. A empresa Pentaho disponibiliza um software,
nomeado de Mondrian Schema Workbench, para a criação deste arquivo, o qual é
implementado integralmente de forma textual e possui uma linguagem técnica para analistas
de sistemas. A proposta de software objetiva trazer uma visão de desenvolvimento para o
analista de negócio, que deve possuir a liberdade de customizar seu cubo de dados para
análise, de modo desenvolver com precisão os requisitos principais de análise para a área de
negócio, sendo este, o maior conhecedor do negócio. A proposta objetiva, ainda, apresentar
uma ferramenta gráfica para desenvolvimento, e com funcionalidades facilitadas a partir de
uma usabilidade aprimorada, para resultar em uma agilidade no processo de desenvolvimento
do cubo de dados. No decorrer do trabalho será explanado sobre os conceitos de BI e data
warehouse, e as ferramentas que estão relacionadas com o tema. O trabalho apresenta,
também, a documentação do software proposto, prevista no modelo Iconix de
desenvolvimento, e, por conseguinte, o desenvolvimento da proposta com apresentação e
validação do sistema.
Palavras-chave: Cubo de dados. Schema XML Mondrian. Proposta de software.
ABSTRACT
The paper presents a software proposal for a data cube's development, which is an analysis's
concept of Business Intelligence, for OLAP queries's server integration with Pentaho
Mondrian. Thus, the software has the requirement to generate a file called Mondrian XML
Schema, which has all the metadata information of the data cube to be integrated into the
Mondrian server in order to run queries in a data mart. The Pentaho company offers a
software, named Mondrian Schema Workbench, to create this file, which is implemented
entirely in a textual form and has a technical language for systems analysts. The proposed
software aims to bring a vision of development for the business analyst who should have the
freedom to customize his data cube for analysis, in order to develop accurate analysis of the
main requirements for the business area, which is the most knowledgeable of the business.
The proposal also aims to present a graphical tool for development, and facilitated
functionality from an enhanced usability, to result in agility in the development process of the
data cube. During the paper the concepts of BI and data warehousing are going to be
explained and the tools that are related to the topic. The paper also presents a documentation
of the proposed software, provided by Iconix model development, and therefore, the
development of the proposal with presentation and system validation.
Keywords: Cube data. Mondrian XML Schema. Software proposal.
LISTA DE ILUSTRAÇÕES
Figura 1 – Elementos básicos de um data warehouse ........................................................... 17
Figura 2 – Fato e dimensões na modelagem dimensional...................................................... 18
Figura 3 – Diagrama de um esquema estrela ........................................................................ 20
Figura 4 – Pilha BI Pentaho ................................................................................................. 23
Figura 5 – Schema Workbench ............................................................................................. 26
Figura 6 – Desenho da Solução ............................................................................................ 30
Figura 7 – Processo do Iconix .............................................................................................. 33
Figura 8 – Diagrama de Requisitos Funcionais ..................................................................... 35
Figura 9 – Diagrama de Requisitos Não Funcionais ............................................................. 36
Figura 10 – TEL001 – Implementação de Modelagem Dimensional ..................................... 38
Figura 11 – TEL002 – Definição da Entidade de Fato .......................................................... 38
Figura 12 – TEL003 – Definição da Unidade de Análise (Dimensão) ................................... 39
Figura 13 – TEL004 – Menu do Sistema .............................................................................. 39
Figura 14 – TEL005 – Menu de Ferramentas do Sistema ..................................................... 40
Figura 15 – TEL006 – Procurar Arquivo .............................................................................. 40
Figura 16 – TEL007 – Salvar Arquivo ................................................................................. 41
Figura 17 – TEL008 – Edição de Fato .................................................................................. 41
Figura 18 – TEL009 – Edição de Dimensão ......................................................................... 42
Figura 19 – Diagrama de Casos de Uso ................................................................................ 43
Figura 20 – Diagrama de Robustez....................................................................................... 50
Figura 21 – Diagrama de Domínio de Persistência do Projeto .............................................. 52
Figura 22 – Diagrama de Domínio de Persistência do Schema ............................................. 53
Figura 23 – Diagrama de Classes ......................................................................................... 54
Figura 24 – Diagrama de Sequência UC002 ......................................................................... 55
Figura 25 – Diagrama de Sequência UC003 ......................................................................... 56
Figura 26 – Diagrama de Sequência UC004 ......................................................................... 57
Figura 27 – Diagrama de Sequência UC006 ......................................................................... 58
Figura 28 – Diagrama de Sequência UC007 ......................................................................... 58
Figura 29 – Diagrama de Sequência UC008 ......................................................................... 59
Figura 30 – Exemplo de notação utilizada no framework Simple .......................................... 61
Figura 31 – Exemplo de grafo em uma GUI criada pelo JGraph .......................................... 61
Figura 32 – Exemplo da estrutura de um Schema XML do Mondrian ................................... 62
Figura 33 – Modelo Dimensional do exemplo de desenvolvimento ...................................... 63
Figura 34 – Tela do Mondrian Schema Workbench com proposta de modelo ....................... 64
Figura 35 – Tela principal do sistema ................................................................................... 65
Figura 36 – Tela com exemplo de modelagem dimensional .................................................. 66
Figura 37 – Tela de edição de entidade (Unid. de Análise, no exemplo) ............................... 67
Figura 38 – Tela com exemplo de modelagem dimensional .................................................. 67
Figura 39 – Tela de salvamento do projeto ........................................................................... 68
Figura 40 – Tela do arquivo XML do projeto salvo .............................................................. 69
Figura 41 – Tela do Schema XML do Mondrian gerado ....................................................... 70
Figura 42 – Validação do Schema XML do Mondrian na ferramenta Saiku .......................... 71
SUMÁRIO
1 INTRODUÇÃO ............................................................................................................................. 10
1.1 PROBLEMÁTICA .......................................................................................................................10
1.2 OBJETIVOS .................................................................................................................................12
1.2.1 Objetivo Geral ..........................................................................................................................12
1.2.2 Objetivos Específicos ...............................................................................................................12
1.3 JUSTIFICATIVA .........................................................................................................................13
1.4 ESTRUTURA DO TRABALHO .................................................................................................14
2 REVISÃO BIBLIOGRÁFICA ..................................................................................................... 15
2.1 SISTEMAS DE BI ........................................................................................................................15
2.1.1 Conceitos ...................................................................................................................................15
2.1.2 Arquitetura de um sistema de BI ...........................................................................................16
2.1.3 Modelagem Dimensional .........................................................................................................18
2.1.4 ETL ...........................................................................................................................................21
2.1.5 OLAP ........................................................................................................................................22
2.2 SUITE PENTAHO .......................................................................................................................22
2.2.1 Conceitos e Arquitetura ..........................................................................................................23
2.2.2 Pentaho Analysis Services (Mondrian) ..................................................................................24
2.2.3 Mondrian Schema Workbench ...............................................................................................25
2.3 CONSIDERAÇÕES FINAIS .......................................................................................................27
3 METODOLOGIA ......................................................................................................................... 28
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA .......................................................................28
3.2 ETAPAS METODOLÓGICAS ....................................................................................................29
3.3 DESENHO DA SOLUÇÃO .........................................................................................................30
3.4 DELIMITAÇÕES .........................................................................................................................30
4 FERRAMENTA DE MODELAGEM DIMENSIONAL ........................................................... 32
4.1 ICONIX ........................................................................................................................................32
4.2 MODELAGEM DA PROPOSTA ................................................................................................33
4.2.1 Requisitos ..................................................................................................................................34
4.2.2 Protótipos ..................................................................................................................................37
4.2.3 Diagrama de Casos de Uso ......................................................................................................42
4.2.3.1 UC001 – Implementa Modelagem Dimensional .................................................................... 44
4.2.3.2 UC002 – Define tabela de fato ............................................................................................... 44
4.2.3.3 UC003 – Define tabelas de dimensão .................................................................................... 45
4.2.3.4 UC004 – Define nomes dos elementos físicos ....................................................................... 46
4.2.3.5 UC005 – Define rótulos para entidades e atributos ................................................................ 46
4.2.3.6 UC006 – Novo/abre/salva projeto de Modelagem Dimensional ............................................ 47
4.2.3.7 UC007 – Gera Schema XML Mondrian da Modelagem Dimensional .................................. 48
4.2.3.8 UC008 – Relaciona entidade de fato com dimensões ............................................................ 49
4.2.4 Diagrama de Robustez .............................................................................................................50
4.2.5 Diagrama de Domínio ..............................................................................................................52
4.2.6 Diagrama de Classes ................................................................................................................53
4.2.7 Diagramas de Sequência..........................................................................................................55
5 DESENVOLVIMENTO ............................................................................................................... 60
5.1 FERRAMENTAS TECNOLÓGICAS ..........................................................................................60
5.2 APRESENTAÇÃO E VALIDAÇÃO DO SISTEMA ..................................................................62
5.3 CONSIDERAÇÕES FINAIS .......................................................................................................71
6 CONCLUSÕES ............................................................................................................................. 73
6.1 TRABALHOS FUTUROS ...........................................................................................................74
REFERÊNCIAS .................................................................................................................................. 75
10
1 INTRODUÇÃO
No mercado de tecnologia atual há um surgimento de diversos conceitos e
técnicas de manipulação de informação, e uma grande quantidade de informação tem sido
gerada também por parte de instituições e organizações de diversos tipos. Desta forma, um
conceito não tão recente tem sido valioso para que analistas de negócio executem análises
nessa grande massa de dados e bancos com estrutura big data. Esse conceito é conhecido
como BI (Business Intelligence), que proporciona uma estrutura de análise para esses bancos
de dados. Neste trabalho é abordado o tema BI, bem como um arsenal de conceitos que o
contemplam.
Um dos conceitos utilizados pelo BI é a estrutura de modelagem
multidimensional, que trata de uma forma de representação de dados em um banco de dados
específico para análise. Essa modelagem multidimensional, por sua vez, será a representação
de um cubo de dados, o qual armazena valores quantitativos ou medidas, que podem ser
vistos de diversos aspectos, ou seja, divididos em categorias de dados.
Para isso, é oferecido um conjunto de ferramentas computacionais para a análise
destes bancos de dados, entre diversas soluções existentes, destaca-se a Suíte Pentaho, que
proporciona uma diversidade de ferramentas para a construção de sistemas de BI, bem como
para a análise dos dados propriamente dita.
1.1 PROBLEMÁTICA
Considerando as estruturas de BI (Business Intelligence) existentes atualmente,
como data warehouse ou ferramentas OLAP (On-line Analytical Processing) e a grande
diversidade de casos de modelos de negócios na área de BI, conclui-se que o dinamismo e a
agilidade no processo de construção de cubos de dados é uma necessidade para determinados
ramos de negócio. Tratando-se de análise de dados para auxiliar no processo de tomada de
decisão, o BI é visto como solução para muitas organizações.
Quando um analista de negócio, habitualmente representando uma entidade de
nível estratégico de uma organização, tem a necessidade de analisar dados para auxiliar no
11
processo de tomada de decisão, os sistemas de BI fornecem diversos recursos que podem ser
utilizados. Um dos principais recursos é a estrutura chamada de cubo de dados, que nos
permite visualizar, analisar e extrair as informações necessárias de forma rápida e simples.
Na Suíte Pentaho, a solução apresentada para análise de dados é a ferramenta
PBA (Pentaho Business Analytics), a qual utiliza um recurso integrado de consulta aos dados,
o software Pentaho Mondrian, que, por sua vez, é um servidor de consultas OLAP.
O servidor OLAP Mondrian utiliza uma estrutura de publicação de cubo através
de um schema XML. Este arquivo está estruturado com as informações pertencentes ao cubo
de dados que se quer analisar na ferramenta PBA, ou outra ferramenta que utilize o Mondrian.
Nesse schema, em formato XML, está definida toda a estrutura de um cubo de
dados para se analisar com uma ferramenta que utilize o Mondrian. Desde as tabelas de
dimensões e fato relacionadas, até os labels (rótulos) que irão aparecer na ferramenta de
análise, estão mapeados nesse arquivo que é interpretado pelo Mondrian.
Para a criação desse arquivo XML, a Pentaho disponibiliza, juntamente com o
projeto Mondrian, uma ferramenta para a criação desse arquivo de forma mais inteligível do
que simplesmente a edição do arquivo XML em forma textual. Esta ferramenta, conhecida
como Mondrian Schema Workbench, faz o mapeamento no arquivo schema XML, em nível
técnico de banco de dados, de toda a estrutura proposta pelo conceito de modelagem
multidimensional para a criação de um cubo de dados.
O Workbench é uma ferramenta técnica para a criação e publicação dessa
estrutura mencionada. Essa ferramenta é direcionada a analistas de sistemas que
necessariamente desenvolvem o data mart (conjunto de cubos de dados armazenados em um
banco de dados) e disponibilizam o cubo para a visualização na Suíte Pentaho. Por ser uma
ferramenta técnica de banco de dado, é imprópria para analistas de negócio modelarem seus
próprios cubos de dados para a utilização. Desta forma os analistas de negócios dependem dos
analistas de sistemas para a construção do cubo de dados que pretendem analisar. Por sua vez,
os analistas de sistemas, para não ter que gerar uma infinidade de cubos de dados, geralmente
desenvolvem um único cubo com todas as medidas da tabela fato e todas as dimensões que
afetam tal medida. Muitas vezes, este cubo fica difícil de manipular e analisar pelas
ferramentas de análises, em função do número excessivo de medidas e dimensões.
Dessa forma, a pergunta de pesquisa seria:
Como construir uma ferramenta orientada para os analistas de negócios ou para os
próprios tomadores de decisão, de modo que não necessite de conhecimento técnico em
sistemas de informação para a construção do cubo de dados?
12
1.2 OBJETIVOS
A seguir, serão apresentados os objetivos do presente trabalho.
1.2.1 Objetivo Geral
Propor um sistema que permita aos analistas de negócios a construção de um cubo
de dados e sua publicação para análises pelas ferramentas que utilizem o servidor Pentaho
Mondrian.
1.2.2 Objetivos Específicos
• Oferecer uma ferramenta facilitadora ao analista de negócio/sistemas para a criação do
cubo de dados integrado ao Pentaho Mondrian;
• melhorar a forma de desenvolvimento de cubos de dados para utilização do servidor
de aplicação Pentaho Mondrian;
• aumentar a produtividade no desenvolvimento de cubos de dados para schemas do
Mondrian;
• propor integração com o sistema de análise PBA (Pentaho Business Analytics);
• definir os elementos necessários para a publicação do data warehouse no sistema de
análise, sendo eles rótulos e metadados;
• oferecer liberdade ao analista de negócio que, por sua vez, conhece a fundo o
ambiente de negócio a ser estudado, de modo que este faça a modelagem dos cubos de
dados conforme a necessidade real do negócio.
13
1.3 JUSTIFICATIVA
A Pentaho tem disponibilizado a ferramenta Mondrian Schema Workbench para a
criação do schema XML utilizado pelo Mondrian para a apresentação e consulta em um cubo
de dados. O Workbench nos oferece uma interface de definição dos elementos da modelagem
multidimensional, sendo medidas, dimensões, hierarquias, níveis, além das definições de
apresentação para a análise na ferramenta PBA. Esta ferramenta nos permite publicar o cubo
de dados no servidor Mondrian para as consultas.
A ferramenta desenvolvida pela Pentaho é totalmente direcionada a
desenvolvedores e a mantenedores de sistemas de BI utilizadoras do Mondrian, e não nos
fornece uma visão acessível da modelagem dimensional sem outros artefatos como a própria
modelagem ou as definições da modelagem no banco de dados.
Na elaboração deste trabalho, a ideia é criar uma ferramenta para analistas de
negócios ou para os próprios tomadores de decisão, de modo que não necessite de
conhecimento técnico em sistemas de informação para a construção do cubo de dados, muito
embora também possa, e deva ser utilizada por analistas de sistemas.
Nesta ferramenta poderá ser feita a criação de um cubo de dados conforme o
modelo de negócio para um data warehouse, ou seja, criação desde a parte de metadados do
cubo de dados até a parte de interface com o usuário para a utilização na ferramenta de
análise. Esta estrutura deverá gerar um schema XML do Mondrian com todas as
configurações necessárias para executar análises em um cubo de dados. Para que seja criado
este modelo de negócio, é necessário que exista um data mart, estrutura multidimensional de
BI em um banco de dados, previamente criado.
A ferramenta permitirá uma melhor visualização da modelagem
multidimensional, pois ela própria tem as definições dos elementos dessa modelagem, como
dimensões, hierarquias, níveis e medidas, devendo suportar o tipo de modelagem dimensional
estrela. Serão definidos todos os rótulos dos elementos de estatística (medidas e unidades de
análise) do cubo de dados. Logo, isso nos permitirá o controle de todos os metadados do data
warehouse e de sua implementação.
A ideia de criação do sistema, que, diferentemente do Workbench, é voltado tanto
para desenvolvedores e mantenedores de sistemas de BI, como para analistas de negócios.
Este sistema visa trazer para um nível de criação de modelagem, em que o analista criará o
14
cubo de dados em um nível mais abrangente. Isso resultará em agilidade no processo de
criação, bem como facilita a publicação do cubo de dados em ferramentas Pentaho.
Vale, ainda, ressaltar que o analista de negócio é o conhecedor do processo de
negócio da organização, e não necessariamente possui conhecimentos técnicos de
desenvolvimento de sistemas de BI. Dessa forma, uma etapa da construção dos sistemas de BI
está sendo facilitada e atribuída a este analista que saberá com precisão a necessidade do
negócio, além de oferecer liberdade para a customização dos cubos de dados ao analista.
A existência do software é justificada pela agilidade na construção de diversos
modelos diferentes de negócio de data warehouses que se pode trabalhar, além de oferecer ao
analista de negócio a liberdade de propor uma modelagem ao sistema de BI conforme sua
necessidade, bem como interface intuitiva oferecida para a criação deste, juntamente com a
redução de erros de script na hora de criar o schema XML do Mondrian.
O desenvolvimento deste sistema tem sua relevância, pois envolve todos os
artefatos de criação de um cubo de dados, os quais são citados: modelagem dimensional,
metadados, com uma interface amigável à análise de negócio.
1.4 ESTRUTURA DO TRABALHO
No decorrer do trabalho, o leitor encontrará cinco capítulos.
O primeiro capítulo possui a apresentação do tema, bem como os objetivos e a sua
justificativa. O segundo capítulo refere-se à revisão bibliográfica, que apresenta os conceitos
que envolvem o tema, isto é, explicativas sobre sistemas de BI, arquitetura dos sistemas de
BI, OLAP, Suite Pentaho e suas ferramentas que serão utilizadas. No terceiro capítulo, será
vista a metodologia utilizada. No quarto capítulo, é desenvolvida a proposta apresentada no
primeiro capítulo, a ferramenta de construção de um cubo de dados que é utilizada pelo
Pentaho Mondrian e, no capítulo cinco, são abordadas as conclusões do tema explanado.
15
2 REVISÃO BIBLIOGRÁFICA
Este capítulo serve de referencial teórico para a proposta deste trabalho, dando
suporte bibliográfico e conceitual para todo o seu desenvolvimento. No decorrer deste
capítulo serão abordados os conceitos sobre o tema proposto. São eles: BI, arquitetura dos
sistemas de BI, modelagem dimensional, ETL e OLAP. Ainda, nesse contexto, são
apresentadas as ferramentas computacionais que fazem relação direta com o tema, que são:
Suíte Pentaho, Pentaho Analysis Service (Mondrian) e Mondrian Schema Workbench.
2.1 SISTEMAS DE BI
Nesta seção, serão apresentados os conceitos de sistemas de BI e toda a sua
estrutura.
2.1.1 Conceitos
Quando falamos em sistema de BI (Business Intelligence) é muito comum vir à
mente a palavra “análise”. Para trazer uma solução que auxilia na tomada de decisões, foi
criado o conceito de Business Intelligence. De acordo com Sezões (2006), uma organização
gera uma quantidade ilimitada de informação, e não existe uma organização que não utilize da
tecnologia para geri-la. O mesmo autor dá a seguinte definição:
Business intelligence é um processo produtivo cuja matéria-prima é a informação e o produto final o conhecimento. Tudo se baseia, portanto, em planear, gerir e controlar a informação de forma a criar e a distribuir conhecimento de forma optimizada. No mundo actual (empresarial e não só), em que a informação é um recurso quase ilimitado, esta tarefa assume-se como essencial. E a pressão para a obtenção deste conhecimento oportuno e fiável já não é apenas endógena, mas também exógena, alargada ao meio envolvente da empresa. (SEZÕES, 2006, p. 5).
16
Sezões (2006) ainda afirma que business intelligence diz respeito a um campo de
análise de associação recíproca entre a gestão e a tecnologia.
Segundo Brackett (1996), as organizações têm acumulado uma considerável
quantidade de dados relacionados a seus negócios. Há uma dificuldade de fazer análises sobre
os dados em sistemas de operações, ou seja, sistemas transacionais, e o processo de tomada de
decisões é prejudicado. Executivos de negócio e gerentes precisam analisar tendência e
entender mais amplamente o seu dinâmico ambiente de negócio, além de antecipar mudanças
de mercado e responder mais rapidamente às demandas e manter-se competitivo no mercado.
Isso acaba sendo de extrema importância para a tomada de decisões aos gerentes e executivos
de negócio para manter sua organização na liderança.
Para Brackett (1996, p. 266, tradução nossa), “Apoio à decisão inclui quaisquer
ferramentas ou produtos que dão suporte a uma tomada de decisão mais informada, como
sistemas de informação executivos (EIS), sistemas de apoio à decisão (DSS), e capacidade de
processamento analítico on-line (OLAP)”.
Em um conceito voltado mais para a ciência da administração, por Sordi (2003),
sobre business intelligence:
O termo Business intelligence (BI), até pouco tempo atrás, era entendido como mais uma buzzword, utilizada para descrever uma enorme variedade de produtos e soluções. A inteligência de negócio, ou o BI de uma empresa, representa a capacidade desta em otimizar o uso de seus recursos de informação disponíveis, tantos internos quanto externos a fim de auxiliar nas tomadas de decisão e na condução de ações. (SORDI, 2003, p. 102).
Sordi (2003) mostra que, sendo uma organização geradora de grande quantidade
de informação, esta pode ser estruturada e criada uma estrutura de análise (BI) dessa massa de
dados, de modo a levar o analista de negócio à tomada de decisão que é fundamentada pela
análise dos dados disponibilizados por essa estrutura.
2.1.2 Arquitetura de um sistema de BI
Para falar da arquitetura de um sistema de BI, é necessário entender alguns
conceitos como: data warehouse, modelagem multidimensional, componentes de ETL e os
sistemas de análises (sistemas front-end). A Figura 1 ilustra os elementos que são parte da
17
arquitetura dos sistemas de BI, o que se resume em um data warehouse, conforme Kimball
(2002).
Figura 1 – Elementos básicos de um data warehouse
Fonte: Kimball (2002, p. 7, tradução nossa).
O termo data warehouse se refere a toda infraestrutura computacional que
sustentam os sistemas de apoio à decisão, ou seja, para se construir um sistema de BI e
sustenta-lo em execução se adota a arquitetura do data warehouse como padrão de utilização.
(KIMBALL, 2002).
Segundo Inmon (1997, p. 33), um “data warehouse é um conjunto de dados
baseado em assuntos, integrado, não-volátil, e variável em relação ao tempo, de apoio à
decisões gerenciais”.
Na Figura 1, são apresentados, primeiramente, os Sistemas de Operação, que
capturam o registro de transação do negócio. A Área de Estágio de Dados representa local de
armazenamento temporário, bem como um conjunto de processos conhecido como extract-
transformation-load (ETL), que obtém os dados do sistema de origem (Sistema Operativo) e
os extrai, transforma e carrega na Área de Apresentação de Dados. Esta Área de Apresentação
de Dados trata de uma estrutura de armazenamento de dados no qual serão feitas as consultas
pela ferramenta de análise de dados, também chamadas de data mart, conjunto de cubos de
dados armazenados em banco de dados. Esta área é caracterizada por ter uma estrutura
baseada em uma modelagem multidimensional. Por fim, o último elemento são as ferramentas
de acesso aos dados, sendo estas ferramentas de análise de dados. (KIMBALL, 2002).
18
2.1.3 Modelagem Dimensional
Para a compreensão do conceito de modelagem dimensional, faz-se necessário
entender o que é um modelo de dados. De acordo com Machado (2002), um meta-modelo de
banco de dados é uma técnica estruturada de representação de dados para o seu
armazenamento de forma única, não redundante e resumida.
O conceito de Modelagem Dimensional é um elemento do data warehouse, que
trata da forma de como são estruturados os dados na Área de Apresentação de Dados. Kimball
(2002) oferece a Modelagem Dimensional como uma técnica de construir uma base de dados
simples e inteligível, que separa uma ocorrência em módulos, ou seja, um fato pode ser
medido através de dimensões, sendo muito comum o dimensionamento por tempo. Desta
forma, surgem os conceitos de: fato, medida e dimensão. É um modelo que prevê redundância
de dados sendo também conhecido por trazer uma abordagem em que há uma denormalização
dos dados. O conceito, também chamado de Modelagem Multidimensional de Dados, é parte
do data warehouse e sua utilização é de exclusividade dos sistemas de análise.
Kimball (2008, p. 234, tradução nossa) afirma que “modelagem dimensional é
uma técnica de modelagem lógica para dados estruturados que é intuitivo para usuários de
negócio e permite acesso de alto desempenho”.
Para Kimball (2002) a estrutura da modelagem dimensional é composta por uma
tabela de fato, tabelas de dimensão, que se relacionam com o fato e medidas que mensuram o
fato, conforme apresentado na Figura 2.
Figura 2 – Fato e dimensões na modelagem dimensional
Fonte: Kimball (2002, p. 22).
Segundo Kimball (2002), uma tabela de fato representa um valor mensurado de
uma unidade de negócio. Um fato é considerado um valor numérico que faz a medição de
19
uma informação. Logo, percebemos que o conceito de medida associado ao fato é o próprio
fato. Kimball (2002, p. 17, tradução nossa) constata que “uma linha em uma tabela de fato
corresponde a uma medida. Uma medida é uma linha em uma tabela de fato. Todas as
medidas em um fato devem ter a mesma granularidade”.
Para apresentar o conceito de dimensões, Kimball (2002, p. 20, tradução nossa)
diz que “tabelas de dimensão são pontos de entrada em uma tabela de fato. Atributos robustos
de dimensões oferecem robustos resultados de interesse nos dados do fato. As dimensões
apresentam a interface do usuário com o data warehouse”.
Para Kimball (2008), dimensões são entendidas por um conjunto de atributos que
representam a forma textual do fato, que são características de coisas tangíveis no fato.
Outro conceito importante da modelagem dimensional é o de granularidade.
Inmon (1997) nos mostra que “a granularidade diz respeito ao nível de detalhe ou de resumo
contido nas unidades de dados existentes no data warehouse”. Desta forma, vemos que a
granularidade é uma das coisas mais importantes no data warehouse, ela deve ser estimada
com cuidado e sua estimativa deve ser feita baseada no nível de visualização que o usuário
quer ter da sua própria informação. A granularidade também definirá o volume de dados do
data warehouse.
Ainda, em se tratando de modelagem dimensional, outro conceito utilizado para
esta abordagem é o de esquema estrela. Bouman (2009, p. 147, tradução nossa) considera que
“o centro da estrela consiste de uma grande tabela de fato e as pontas da estrela são as tabelas
de dimensão”, conforme o exemplo da Figura 3.
20
Figura 3 – Diagrama de um esquema estrela
Fonte: Bouman (2009, p.148).
Para justificar o modelo em estrela, Bouman, comentando a Figura 3, faz a
seguinte consideração:
Essa é a técnica de modelagem em estrela que conta, não o número de dimensões usadas. Um dos objetivos óbvios de usar um esquema como esse é a simplicidade e a apreensibilidade para usuários finais. Muito frequentemente durante a fase de modelagem de um data warehouse, esquema estrela é utilizado para desenhar a primeira tradução das questões de negócio em diagramas lógicos de banco de dados. (BOUMAN, 2009, p. 148, tradução nossa).
A modelagem multidimensional em estrela é muito utilizada por ser uma estrutura
simples. Dessa forma, Bouman (2009) apresenta que o modelo estrela auxilia os primeiros
passos da construção da modelagem dimensional do data warehouse, sendo comparada à
modelagem lógica de banco de dados, facilitando a criação de estruturas mais complexas de
modelagens dimensionais.
21
2.1.4 ETL
Conforme visto, a ETL (extract, transform, and load) é um dos elementos da
arquitetura dos sistemas de BI, sendo conceitualmente uma Área de Estágio de Dados, em que
é feito o necessário para introduzir dados na Área de Apresentação de Dados.
Mundy (2011, p 31, tradução nossa) afirma que “um sistema de extração,
transformação e carga (ETL), é um conjunto de processos que limpam, transformam,
combinam, de-duplicam, agregam, arquivam, obedecem, e estruturam dados para o uso em
um data warehouse”.
Kimball (2002) a considera da seguinte forma:
A Área de Estágio de Dados do data warehouse é tanto uma área de armazenamento como um conjunto de processos comumente referido como extract-transformation-
load (ETL). A Área de Estágio de Dados é tudo que está entre o sistema operativo fonte e a Área de Apresentação de Dados [pertencente ao data warehouse]. (KIMBALL, 2002, p. 8, tradução nossa).
Para Inmon (2008, p. 215, tradução nossa), ”ETL é um processo que reúne, limpa,
e integra dados que entra no Setor Interativo ou que passa através do Setor Interativo ao Setor
Integrado”. Inmon (2008) afirma que ETL é um processo que faz parte do dia-a-dia
operacional do ambiente de data warehouse.
Bracket (1996) considera as três etapas do processo de ETL, muito embora não o
rotule. Extração (extract) consiste em uma forma de obter os dados da fonte de dados, ou seja,
o sistema de operação. Se os dados não forem extraídos de forma correta, ou se não houver
essa extração, não se pode dar continuidade à etapa de transformação dos dados. A
transformação (transformation) é a etapa em que ocorre a conversão dos dados para o formato
do data mart. Desta forma, a todo o dado que chega da extração é feito um tratamento para
assim seguir com a última etapa, a carga. A carga (load) é o momento em que os dados são
persistidos na Área de Apresentação dos dados (data marts, modelagem dimensional). Desta
forma, os dados devem chegar já tratados e convertidos para persistir no ambiente de consulta
do data warehouse.
É muito comum o termo ETL estar associado ao nome da organização Pentaho, a
qual oferece diversos softwares para o desenvolvimento e utilização de um data warehouse.
Para a integração de dados e todo o processo de ETL, a Pentaho disponibiliza o software
Pentaho Data Integration, o qual era antes conhecido como Kettle.
22
2.1.5 OLAP
Quando se fala de OLAP (On-line Analytical Processing), refere-se às
ferramentas de acesso a dados, ferramentas de consulta, ferramentas de análise, conforme
proposto na arquitetura de data warehouse por Kimball (2002).
Para Thomsen (2002), a pedra angular de toda a atividade de negócio é um
processamento de informação. Desta forma, Thomsen acredita que o processamento de
informação é essencial para a sobrevivência de uma organização e ressalta a importância da
qualidade da informação gerada pelo negócio em si. Essa qualidade impacta diretamente na
tomada de decisões, sendo decisões corretas ou decisões errôneas.
Segundo Thomsen, o processo decisório possui como requisito a informação
gerada na organização, e a análise dessa informação é executada através de sistemas OLAP
(On-line Analytical Processing). Esses sistemas devem proporcionar uma interface inteligível
e analisável para o usuário final, o analista de negócio. Os sistemas OLAP são baseados em
um data warehouse, cuja estrutura deve ser arquitetada de acordo com seus conceitos.
Produtos OLAP completos precisam incluir métodos de acesso, armazenamento e
compilação de dados e devem oferecer acesso rápido aos dados calculados que são usados
pelo Sistema de Apoio à Decisão (DSS, Decision Support Systems), procedente de um modelo
descritivo de dados. Sistemas OLAP tem por características propor medições em diversos
âmbitos de um contexto de negócio, o que é previsto em uma modelagem multidimensional, e
essas métricas servirão de suporte ao processo de tomada de decisão. (THOMSEN, 2002).
2.2 SUITE PENTAHO
Pentaho é uma organização que desenvolve softwares para a área de análises e
seu mercado abrange grande parte dos conceitos e estruturas do que diz respeito a BI e data
warehouse. Essa organização produz uma suíte de mesmo nome a qual Bouman (2009, p. 3,
tradução nossa) considera que “Pentaho é uma poderosa Suíte de Business Intelligence que
oferece muitas características: relatórios, tabelas dinâmicas OLAP, dashboards e muito
mais”.
23
2.2.1 Conceitos e Arquitetura
Conforme Bouman (2009), a Suíte Pentaho possui diversos componentes (coleção
de produtos ou softwares) que juntos o tornam uma solução de business intelligence. Desta
forma, alguns componentes desta plataforma são de funcionalidade simples e básica, como
uma simples conexão a um banco de dados, enquanto outros utilizam uma estrutura mais
complexa e de funcionalidade mais robusta e de alto nível, como a visualização de dados em
gráficos e dashboards.
Para Bouman (2009), muitas vezes, alguns dos componentes de funcionalidade de
alto nível dependem de outros componentes com funcionalidades de baixo nível. Assim, toda
a arquitetura de componentes pode ser visualizada como uma pilha, mostrando sua
dependência, conforme a Figura 4.
Figura 4 – Pilha BI Pentaho
Fonte: Bouman (2009, p.64).
24
Bouman (2009) propõe que a arquitetura da Suíte Pentaho pode ser vista de
diversas formas: por funcionalidade, por natureza de execução ou por visualização final.
Alguns componentes oferecem funcionalidades típicas de BI, como o desenvolvimento do
processo de ETL, OLAP e geração de relatórios, os quais geralmente representam uma
estrutura de baixo nível.
Em uma abordagem mais ampla, pode-se falar dos softwares da Suíte Pentaho
mais utilizados pelos desenvolvedores na implementação de data warehouse. Para
desenvolvimento e execução de ETL, é oferecida a ferramenta Pentaho Data Integration
(PDI), uma ferramenta desktop que permite a criação do processo, bem como a execução da
extração, transformação e carga dos dados na base de dados do data warehouse. Como
mecanismo de consulta OLAP, é oferecido o software Pentaho Analisys Mondrian, ou
somente Mondrian. (BOUMAN, 2009).
Existem ainda outros componentes da Suíte Pentaho para outras funcionalidades
de BI. Podem-se citar reporting engines com a utilização de softwares como JFreeReport
engine, JasperReports e BIRT. Para mecanismo de processamento de data mining pode-se
referenciar o software Weka, utilizado pela Suíte.
Além das estruturas acima, Bouman (2009) considera outros softwares de baixo
nível para desenvolvimento. Mondrian Schema Workbench é um software que auxilia na
criação de estruturas utilizadas pelo Mondrian. O software Spoon, que é integrado ao PDI,
para auxílio no desenvolvimento de ETL. Pentaho Metadata Editor (PME) é um software que
faz a abstração entre a modelagem relacional do banco de dados e o usuário final. E Pentaho
Design Studio (PDS) é utilizado como plataforma de BI.
2.2.2 Pentaho Analysis Services (Mondrian)
O Pentaho Analysis Services, mais conhecido como Mondrian Project, é um
mecanismo de consultas OLAP, ou seja, uma plataforma de baixo nível que executa as
consultas de análise no data warehouse e retorna ao sistema OLAP. Hyde (2006, tradução
nossa) considera que “Mondrian é uma engine escrita na linguagem Java. Ele executa
25
consultas na linguagem MDX, lê os dados do banco relacional (RDBMS) e apresenta os
resultados em um formato multidimensional, via API Java”.
Bouman (2009, p. 72, tradução nossa) vê o Mondrian como uma “engine OLAP e
traduz consultas MDX para SQL, baseado em modelos multidimensionais. Mondrian é muito
mais que um tradutor de uma linguagem de consulta para outras; ele também cuida do cache e
do buffer intermediário e prevê resultados para otimizar o desempenho”.
Hyde (2006) apresenta a arquitetura do Mondrian que é composta por quatro
camadas. Na primeira camada, encontram-se as aplicações OLAP que consultam o Mondrian
e este retorna os dados às aplicações. A segunda camada faz a conversão, a validação e a
execução de consultas MDX. Nesta fase, é achado toda a estrutura da modelagem dimensional
em formato de metadados que é armazenado em um arquivo XML conhecido como schema
do Mondrian. A terceira camada é responsável por manter um cache agregado, o que otimiza
o desempenho das consultas. A quarta camada é a camada de armazenamento, responsável
por obter os dados do RDBMS e consistir no cache agregado do Mondrian. O autor
mencionado, ainda, conceitua que MDX é uma linguagem de consulta em bancos de dados
multidimensionais.
2.2.3 Mondrian Schema Workbench
Considerando que o servidor OLAP Mondrian faz consultas em um modelo
multidimensional, ele necessita conhecer a estrutura dimensional criada para o cubo de dados.
Desta forma, a Pentaho criou o que é chamado de schema do Mondrian, exatamente onde está
expresso toda a estrutura do modelo dimensional e os metadados deste modelo, ou seja, a
apresentação do cubo ao usuário final (rótulos dos elementos, sendo dimensões ou medidas).
Hyde (2009, tradução nossa) considera que “um schema define um banco de dados
multidimensional. Nele contêm-se um modelo lógico, consistência do cubo, hierarquias, e
membros, e um mapeamento desta estrutura para o modelo físico”.
Conforme Hyde (2009), o Mondrian, conhecendo esta estrutura (schema), faz as
consultas no banco de dados, baseando-se nela, e apresenta os resultados ao usuário. O
Mondrian utiliza o schema para apresentar o cubo de dados ao usuário.
26
Esse schema é um arquivo XML que contém toda esta estrutura. Para fazer a
criação deste schema, a Pentaho disponibiliza um software, chamado Mondrian Schema
Workbench, uma interface que proporciona de forma estruturada e intuitiva de
desenvolvimento, sem a necessidade a edição direta do arquivo XML.
Figura 5 – Schema Workbench
Fonte: Hyde (2009).
Wood (2007, tradução nossa) define o Schema Workbench como “uma aplicação
desktop em Java que permite: criar visualmente e testar schemas de cubos para Mondrian
OLAP, validar o schema do cubo no banco de dados; executar consultas MDX de exemplo,
usando o schema e o banco de dados; navegar pelo cubo no banco de dados”.
Infante (2009) faz a explicativa do funcionamento do Workbench. Seu
funcionamento ocorre nos seguintes passos: configura-se a conexão com o banco de dados,
cria-se e schema e publica-o no Mondrian OLAP. No schema criado, define-se o cubo,
dimensões, hierarquias, níveis, medidas e, para cada um destes elementos, define seus
respectivos rótulos e o objeto no banco de dados, na interface que é representada pela Figura
5.
27
2.3 CONSIDERAÇÕES FINAIS
Neste capítulo, foram apresentadas as teorias que sustentam o conteúdo deste
trabalho, ou seja, todo o referencial teórico sobre os assuntos em questão. Sua apresentação se
dá de modo que são referenciados os principais autores que possuem propriedade para abordar
os assuntos apresentados, seja na área de data warehouse, ETL, modelagem dimensional,
OLAP ou suíte Pentaho.
28
3 METODOLOGIA
No presente capítulo, será abordada a metodologia de pesquisa utilizada para a
concepção deste trabalho, sendo feita a classificação de acordo com a metodologia de
pesquisa exposta na bibliografia da área de conhecimento. Para isso, são apresentados os
tópicos referentes à caracterização do tipo de pesquisa, ou seja, a conceituação da
metodologia utilizada; as etapas de metodologia, o desenho da proposta e as delimitações do
trabalho, isto é, quais são os limites da abordagem proposta.
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA
Para conceituar o termo “pesquisa” no âmbito científico, utiliza-se o autor Gil
(2002):
Pode-se definir pesquisa como o procedimento racional e sistemático que tem como objetivo proporcionar respostas os problemas que são propostos. A pesquisa é requerida quando não se dispõe de informação suficiente para responder ao problema, ou então quando a informação disponível se encontra em tal estado de desordem que não possa ser adequadamente relacionada ao problema. (GIL, 2002, p. 17).
Neste trabalho, será realizada uma pesquisa cuja natureza é classificada de acordo
com a aplicação prática para a exploração do problema, a qual Silva e Menezes (2001, p. 20)
chamam de pesquisa aplicada, explicando que este tipo de pesquisa “objetiva gerar
conhecimento para aplicação prática dirigidos à solução de problemas específicos. Envolve
verdades e interesses locais”.
Quanto ao método de abordagem, classificado como pesquisa qualitativa,
utilizado na problemática da presente, conceituam Silva e Menezes (2001):
[Na pesquisa qualitativa] Há uma relação dinâmica entre o mundo real e o sujeito, isto é, um vínculo indissociável entre o mundo objetivo e a subjetividade do sujeito que não pode ser traduzido em números. A interpretação dos fenômenos e a atribuição de significados são básicas no processo de pesquisa qualitativa. Não requer o uso de métodos e técnicas estatísticas. O ambiente natural é a fonte direta para coleta de dados e o pesquisador é o instrumento-chave. É descritiva. Os pesquisadores tendem a analisar seus dados indutivamente. O processo e seu significado são os focos principais de abordagem. (SILVA, 2001, p. 20).
29
No que diz respeito à classificação dos objetivos, esta se caracteriza como
exploratória, tendo em vista que a presente pesquisa tem como objetivos propor estudo de
caso e revisão bibliográfica para o problema. Para Silva e Menezes (2001), este tipo de
pesquisa assume um caráter exploratório por se tratar de casos reais com uma exploração
prática da problemática.
O presente trabalho, também, está caracterizado como pesquisa bibliográfica, no
que diz respeito à classificação do ponto de vista de procedimentos técnicos por explanar toda
uma revisão bibliográfica dos principais temas que estão aqui apresentados. Ainda, neste
quesito, este trabalho está classificado também como pesquisa experimental, uma vez que este
apresenta um objeto de estudo e será feita a manipulação de suas variáveis, executando-se a
experimentação da solução de software para o contexto proposto.
3.2 ETAPAS METODOLÓGICAS
Abaixo estão apresentadas as etapas metodológicas para a execução deste
trabalho, ou seja, todas as atividades relacionadas ao seu desenvolvimento, que são:
• Definição do tema e desenvolvimento da problemática;
• pesquisa bibliográfica;
• caracterização da metodologia;
• levantamento de requisitos para o projeto de software;
• modelagem utilizando a metodologia ICONIX;
• desenvolvimento do software;
• validação e testes;
• apresentação do trabalho à banca;
• correções do trabalho;
• explanação de trabalhos futuros.
30
3.3 DESENHO DA SOLUÇÃO
A solução proposta é composta por três elementos: ator, a ferramenta em si e a
saída dos resultados, que são dados estruturados para determinados fins, gerados pela
ferramenta, conforme mostra a figura 6.
Figura 6 – Desenho da Solução
Fonte: Elaboração do autor, 2012.
O primeiro componente do escopo apresentado na ilustração é o analista de
sistemas ou analista de negócios, que é o usuário que utiliza a ferramenta. A ferramenta deve
propor um ambiente de modelagem dimensional para o usuário de forma gráfica e intuitiva e,
a partir disso, tem-se a visualização do seu modelo de negócio em dimensões para consultas
estatísticas. Uma vez tendo seu modelo pronto, pode, então, ser gerado o schema do
Mondrian em XML para a publicação na ferramenta de análise da Pentaho.
3.4 DELIMITAÇÕES
O desenvolvimento dar-se-á conforme apresentado na seção anterior. Aqui serão
vistas quais as especificações que não serão contempladas pelo projeto.
31
Em um primeiro plano, a ferramenta deve gerar o schema XML para o servidor
OLAP Mondrian. Em se tratando do schema XML, será gerado um schema que contemple o
modelo estrela da modelagem dimensional, ou seja, modelos como snowflake e outros mais
complexos não devem entrar em princípio. O schema pode contemplar, também, o conceito
de dimensões degeneradas no fato. Dessa forma, os elementos multidimensionais gerados no
schema são: tabela de fato, medidas de fato, dimensões simples (que não utilizam o modelo
snowflake), hierarquias e níveis. A proposta está delimitada, ainda, de modo que o modelo de
data mart possui apenas um cubo de dados, ou seja, apenas uma tabela de fato.
Será considerado que uma hierarquia corresponde a uma única dimensão, não
suportando mais de uma hierarquia por dimensão, o que corresponde ao conceito de
agrupamentos de níveis em uma dimensão.
Em um primeiro momento, a ferramenta não deve implementar a conexão com o
banco para a criação direta da modelagem dimensional de data warehouse no banco de dados
nem para conhecimento dos metadados do data mart proposto.
32
4 FERRAMENTA DE MODELAGEM DIMENSIONAL
Neste capítulo, será apresentada a documentação para o desenvolvimento da
ferramenta de modelagem dimensional geradora de schemas Mondrian.
4.1 ICONIX
Para o desenvolvimento do software, será utilizado o modelo de desenvolvimento
de software Iconix, de modo que toda a documentação gerada, na proposta, será a mínima
requerida pela metodologia.
Para Tancredo (2010), “ICONIX é um modelo de processo para desenvolvimento
de software iterativo incremental que possui como objetivo ser uma metodologia prática e
intermediária entre a complexidade do RUP (Rational Unified Process) e a simplicidade do
XP (Extreme Programming), sem que a documentação do projeto seja esquecida”.
Esta metodologia faz uso de uma documentação simples e mínima para o
entendimento da arquitetura do software, isso sem que o projeto se torne desgastante ou que
seja interrompido para questões burocráticas de documentação. O Iconix oferece as
características de uma metodologia de desenvolvimento de software ágil, o que torna a
análise, o desenho e a implementação bem eficaz.
Para a criação da arquitetura do software (também chamada de design do
software), o Iconix divide sua documentação em duas visões: visão dinâmica e visão estática.
A visão dinâmica é composta pelos diagramas de casos de uso, sequências e robustez. Na
visão estática, estão os diagramas de domínio e de classes, conforme é apresentado na Figura
7.
33
Figura 7 – Processo do Iconix
Fonte: ICONIX Process (tradução nossa, adaptado).
O Iconix tem por característica ser uma metodologia iterativa e incremental, ou
seja, o processo será repetido diversas vezes e a cada nova iteração novas funcionalidades são
acrescentadas e são feitos aperfeiçoamentos no projeto. Além disso, o modelo prevê sua
arquitetura moldada com a notação UML (Unified Modeling Language), muito embora, por
ser um modelo flexível, pode-se utilizar outros diagramas da UML, além dos mínimos
exigidos. É também exigido pelo Iconix o conceito de rastreabilidade, que representa as
relações entre os artefatos dos diferentes diagramas, identificando o real impacto de uma
eventual mudança no desenho do projeto. (CARDOZO, 2011).
4.2 MODELAGEM DA PROPOSTA
Neste item, dar-se-á uma etapa prevista pelo Iconix e outras metodologias de
desenvolvimento conhecida como design do software ou modelagem do software.
Quando se inicia o processo, são extraídos os protótipos de tela do sistema, que
servirão de base para a montagem da arquitetura do software. A metodologia Iconix prevê
34
uma fase de análise e especificação de requisitos. Nesta etapa, são definidos os requisitos,
construídos os diagramas de casos de uso e diagrama de domínio, que suportarão as próximas
etapas do design de software e, consequentemente, a codificação em si. (ICONIX Process,
2007).
Uma segunda etapa do processo de modelagem de software idealizado pelo Iconix
é a de análise e design preliminar, onde se revisa e evolui o diagrama de domínio e há a
criação do diagrama de robustez. Após esta etapa inicia-se a criação do design detalhado, que
é a arquitetura base do software. Aqui serão realizados o desenvolvimento dos diagramas de
sequência e o de classes. É importante lembrar que, por ser uma metodologia de
desenvolvimento de software iterativa e incremental, todas estas etapas do Iconix serão
executadas mais de uma vez durante o desenvolvimento. A última é a fase de implementação
do software, que é a codificação propriamente dita e testes. (ICONIX Process, 2007).
Nos próximos itens deste trabalho, será apresentada toda a documentação exposta
acima para o software de modelagem dimensional integrado ao Pentaho Mondrian proposto.
4.2.1 Requisitos
Os requisitos de software são descrições breves que expressam o que o software
deve fazer. São divididos em requisitos funcionais e não funcionais. O requisito funcional é
identificado por uma funcionalidade do sistema, ou seja, o que o sistema deve fazer. O
requisito não funcional contempla a característica que a funcionalidade deve ter no sistema,
ou seja, como deve ser contemplada aquela funcionalidade. (ICONIX Process, 2007).
Para o sistema de modelagem dimensional proposto, as Figuras 8 e 9 apresentam a
estrutura dos requisitos identificados.
35
Figura 8 – Diagrama de Requisitos Funcionais
Fonte: Elaboração do autor, 2012.
36
Figura 9 – Diagrama de Requisitos Não Funcionais
Fonte: Elaboração do autor, 2012.
Os Quadros 1 e 2 apresentam os requisitos funcionais e não funcionais
estruturados nas Figuras 8 e 9.
Quadro 1 – Requisitos Funcionais Nº do Requisito Requisito funcional
RF001 O sistema deve permitir a modelagem de negócio de um cubo de dados.
RF002 O sistema deve permitir a definição de um fato e suas medidas, bem
como as dimensões (unidades de análise) e seus níveis de hierarquia.
RF003 O sistema deve permitir a criação de rótulos para as entidades da
modelagem dimensional criada.
RF004 O sistema deve permitir a definição dos atributos físicos de banco de
dados para cada uma das entidades.
RF005 O sistema deve permitir, após a modelagem criada, a geração do Schema
XML para Mondrian Pentaho.
RF006 O sistema deverá gerar de forma automática, numérica e sequencial os
nomes físicos dos elementos de banco de dados caso não seja
37
especificado pelo usuário.
RF007 O sistema deve permitir o salvamento do projeto corrente no computador
do usuário.
RF008 O sistema deve permitir o relacionamento entre as entidades da
Modelagem Dimensional.
Fonte: Elaboração do autor, 2012.
Quadro 2 – Requisitos Não Funcionais Nº do Requisito Requisito não funcional
RNF001 O sistema deve permitir a visualização da modelagem de negócio de
forma gráfica.
RNF002 O sistema deve permitir a ação drag-and-drop (arrastar e soltar) para
cada um dos elementos da modelagem dimensional a ser criada.
RNF003 O sistema deve permitir relacionar graficamente os elementos da
modelagem dimensional a ser criada.
RNF004 O sistema deve ser desenvolvido para execução em Desktop.
Fonte: Elaboração do autor, 2012.
Acima foram apresentados os requisitos funcionais e não funcionais do sistema,
que servem como primeira impressão para o funcionamento do mesmo.
4.2.2 Protótipos
A primeira etapa da metodologia de desenvolvimento de software proposta pelo
Iconix, é identificada como prototipação ou storyboard. É aqui que são feitos os protótipos de
tela que demonstram a ideia do software e pouco do seu funcionamento. (ICONIX Process,
2007).
Para o sistema de modelagem dimensional com integração com Mondrian, estão
nas imagens, a seguir, os protótipos criados e utilizados nos casos de uso das próximas seções.
38
Figura 10 – TEL001 – Implementação de Modelagem Dimensional
Fonte: Elaboração do autor, 2012.
Figura 11 – TEL002 – Definição da Entidade de Fato
Fonte: Elaboração do autor, 2012.
39
Figura 12 – TEL003 – Definição da Unidade de Análise (Dimensão)
Fonte: Elaboração do autor, 2012.
Figura 13 – TEL004 – Menu do Sistema
Fonte: Elaboração do autor, 2012.
40
Figura 14 – TEL005 – Menu de Ferramentas do Sistema
Fonte: Elaboração do autor, 2012.
Figura 15 – TEL006 – Procurar Arquivo
Fonte: Elaboração do autor, 2012.
41
Figura 16 – TEL007 – Salvar Arquivo
Fonte: Elaboração do autor, 2012.
Figura 17 – TEL008 – Edição de Fato
Fonte: Elaboração do autor, 2012.
42
Figura 18 – TEL009 – Edição de Dimensão
Fonte: Elaboração do autor, 2012.
Acima, foram apresentados os protótipos de tela do sistema, identificando as
formas gráficas de apresentação do sistema para o usuário.
4.2.3 Diagrama de Casos de Uso
O diagrama de caso de uso é um diagrama da UML, utilizado no Iconix, que tem
por função representar a interação do usuário com o sistema através de ações. O caso de uso
identifica qual e como determinado requisito do sistema deverá ser contemplado em
determinado momento da execução do software. (ICONIX Process, 2007).
Esse diagrama utiliza dois artefatos: atores (elemento externo ao sistema que se
comunica com ele) o conjunto de ações. É, também, de sua competência documentar o fluxo
de interação que será feito para determinado requisito. (ICONIX Process, 2007).
43
Representado pela Figura 19, estão os relacionamentos entre os casos de uso do
sistema em formato de diagrama de casos de uso para a proposta do software de modelagem
dimensional.
Figura 19 – Diagrama de Casos de Uso
Fonte: Elaboração do autor, 2012.
Nas próximas subseções, será apresentado cada um dos casos de uso com seus
respectivos fluxos.
44
4.2.3.1 UC001 – Implementa Modelagem Dimensional
Para o caso de uso UC001 – Implementa Modelagem Dimensional – temos as
seguintes restrições:
• Precondição: novo projeto criado ou projeto existe já aberto;
• pós-condição: modelagem dimensional criada.
No Quadro 3, está exposto fluxo de interação (cenário) do caso de uso UC001 –
Implementa Modelagem Dimensional.
Quadro 3 – Fluxos de interação do caso de uso UC001 – Implementa Modelagem Dimensional 0. Fluxo Principal
1. “UC006 – Novo/abre/salva projeto de Modelagem Dimensional”
2. Sistema libera “TEL001 – Implementação de Modelagem Dimensional” de implementação
de modelagem dimensional
3. “UC002 – Define tabela de fato” ou “UC003 – Define tabelas de dimensão”
Fonte: Elaboração do autor, 2012.
4.2.3.2 UC002 – Define tabela de fato
Para o caso de uso UC002 – Define tabela de fato – temos as seguintes restrições:
• Precondição: projeto (novo ou existente) na memória para o início da modelagem;
• pós-condição: entidade de fato criada com suas medidas.
No Quadro 4, está exposto fluxo de interação (cenário) do caso de uso UC002 –
Define tabela de fato.
Quadro 4 – Fluxos de interação do caso de uso UC002 – Define tabela de fato 0. Fluxo Principal
1. Usuário clica e arrasta (drag-and-drop) uma entidade de fato para a área de desenho
45
conforme “TEL002 – Definição da Entidade de Fato”
2. “UC004 – Define nomes dos elementos físicos”
3. “UC005 – Define rótulos para entidades e atributos”
4. Usuário executa clique duplo sobre entidade de fato para definição das unidades de medida
5. Sistema apresenta “TEL008 - Definição de Medidas” de definição de unidades de medida
Fonte: Elaboração do autor, 2012.
4.2.3.3 UC003 – Define tabelas de dimensão
Para o caso de uso UC003 – Define tabelas de dimensão – temos as seguintes
restrições:
• Precondição: projeto (novo ou existente) na memória para o início da modelagem;
• pós-condição: dimensão da modelagem dimensão criada.
No Quadro 5, está exposto fluxo de interação (cenário) do caso de uso UC003 –
Define tabelas de dimensão.
Quadro 5 – Fluxos de interação do caso de uso UC003 – Define tabelas de dimensão 0. Fluxo Principal
1. Usuário clica e arrasta (drag-and-drop) uma entidade de dimensão para a área de desenho
conforme “TEL003 – Definição da Unidade de Análise (Dimensão)”
2. “UC004 - Define Nomes dos Atributos Físicos”
3. “UC005 - Define rótulos para entidades e atributos”
Fonte: Elaboração do autor, 2012.
46
4.2.3.4 UC004 – Define nomes dos elementos físicos
Para o caso de uso UC004 – Define nomes dos elementos físicos – temos as
seguintes restrições:
• Precondição: entidade da modelagem dimensional criada;
• pós-condição: nome físico de banco de dados de determinada entidade da modelagem
dimensional definido.
No Quadro 6, está exposto fluxo de interação (cenário) do caso de uso UC004 –
Define nomes dos elementos físicos.
Quadro 6 – Fluxos de interação do caso de uso UC004 – Define nomes dos elementos físicos 0. Fluxo Principal
1. Usuário define entidade ou atributo
2. Sistema cria nome físico do elemento de forma automática, sequencial, numérica e única
3. Usuário escolhe alterar nome físico de banco de dados e clica duas vezes sobre o elemento
4. Sistema abre tela de edição de entidade (TEL008 ou TEL009) para edição da entidade
5. Usuário informa novo nome físico
6. Sistema atribui o nome físico ao elemento
6a. Nome físico já existente (Fluxo de Exceção)
1. Sistema informa que já existe rótulo para outro elemento e retorna ao passo 4 do fluxo
principal
Fonte: Elaboração do autor, 2012.
4.2.3.5 UC005 – Define rótulos para entidades e atributos
Para o caso de uso UC005 – Define rótulos para entidades e atributos – temos as
seguintes restrições:
• Precondição: entidade da modelagem dimensional criada;
• pós-condição: rótulo de determinada entidade da modelagem dimensional definido.
47
No Quadro 7, está exposto fluxo de interação (cenário) do caso de uso UC005 –
Define rótulos para entidades e atributos.
Quadro 7 – Fluxos de interação do caso de uso UC005 – Define rótulos para entidades e atributos 0. Fluxo Principal
1. Usuário define entidade ou atributo
2. Sistema solicita rótulo para o elemento
3. Usuário coloca rótulo para o elemento
4. Sistema atribui o rótulo ao elemento
4a. Nome já existente (Fluxo de Exceção)
1. Sistema informa que já existe rótulo para outro elemento e retorna ao passo 2 do fluxo
principal
Fonte: Elaboração do autor, 2012.
4.2.3.6 UC006 – Novo/abre/salva projeto de Modelagem Dimensional
Para o caso de uso UC006 – Novo/abre/salva projeto de Modelagem Dimensional
– temos as seguintes restrições:
• Precondição: sistema em execução;
• pós-condição: projeto criado/aberto/salvo.
No Quadro 8, está exposto fluxo de interação (cenário) do caso de uso UC006 –
Novo/abre/salva projeto de Modelagem Dimensional.
Quadro 8 – Fluxos de interação do caso de uso UC006 – Novo/abre/salva projeto de Modelagem Dimensional 0. Fluxo Principal
1. Usuário abre Sistema
2. Sistema abre com opções de menu conforme “TEL004 – Menu do Sistema”
3. Usuário escolhe a opção desejada
3a. Novo projeto de Modelagem Dimensional (Fluxo de Alternativo)
48
1. Usuário seleciona a opção “Novo Projeto” no menu
2. Sistema cria novo projeto na memória
3b. Abrir projeto existente de Modelagem Dimensional (Fluxo de Alternativo)
1. Usuário seleciona a opção “Abrir Projeto” no menu
2. Sistema abre “TEL006 – Procurar Arquivo” para selecionar o projeto no computador
3. Usuário seleciona o projeto a ser utilizado
4. Sistema abre projeto
3c. Salvar projeto de Modelagem Dimensional no computador (Fluxo de Alternativo)
1. Usuário seleciona a opção “Salvar Projeto” no menu
2. Sistema abre “TEL007 – Salvar Arquivo” para salvar o projeto no computador
3. Usuário seleciona local de salvamento
4. Sistema salva projeto de Modelagem Dimensional no computador
Fonte: Elaboração do autor, 2012.
4.2.3.7 UC007 – Gera Schema XML Mondrian da Modelagem Dimensional
Para o caso de uso UC007 – Gera Schema XML Mondrian da Modelagem
Dimensional – temos as seguintes restrições:
• Precondição: modelagem dimensional criada;
• pós-condição: gerado o Schema XML do Pentaho Mondrian da modelagem
dimensional criada.
No Quadro 9, está exposto fluxo de interação (cenário) do caso de uso UC007 –
Gera Schema XML Mondrian da Modelagem Dimensional.
Quadro 9 – Fluxos de interação do caso de uso UC007 – Gera Schema XML Mondrian da Modelagem Dimensional 0. Fluxo Principal
1. Usuário clica no menu "Ferramentas"
2. Sistema mostra “TEL005 – Menu de Ferramentas do Sistema” com menu opções de
ferramentas
49
3. Usuário clica na menu “Gerar Schema XML Mondrian”
4. Sistema abre “TEL007 – Salvar Arquivo” de salvamento de arquivo
5. Usuário seleciona o diretório desejado
6. Sistema salva o arquivo no computador
Fonte: Elaboração do autor, 2012.
4.2.3.8 UC008 – Relaciona entidade de fato com dimensões
Para o caso de uso UC008 – Relaciona entidade de fato com dimensões – temos
as seguintes restrições:
• Precondição: entidades da Modelagem Dimensional criadas;
• pós-condição: definida a relação entre as entidades da Modelagem Dimensional.
No Quadro 10, está exposto fluxo de interação (cenário) do caso de uso UC008 –
Relaciona entidade de fato com dimensões.
Quadro 10 – Fluxos de interação do caso de uso UC008 – Relaciona entidade de fato com dimensões 0. Fluxo Principal
1. Usuário seleciona duas entidades (fato e dimensão)
2. Usuário clica com botão direito sobre uma das entidades e clica em "Relacionar"
3. Sistema relaciona as duas entidades, colocando uma linha reta entre as duas
Fonte: Elaboração do autor, 2012.
Dessa forma, todo o comportamento do sistema através da interação do usuário
com o sistema, fica representado, pelo diagrama de casos de uso e seu detalhamento.
50
4.2.4 Diagrama de Robustez
O Diagrama de Robustez é caracterizado por ser a lacuna entre os casos de uso
(“o que fazer”) e os Diagramas de Sequencias (“como fazer”). Dessa forma, este diagrama
apresenta a interação do usuário com as telas do sistema (views) e faz a relação destas com as
entidades do sistema que são detalhadas no Diagrama de Domínio, por intermédio de um
controlador.
Figura 20 – Diagrama de Robustez
51
Fonte: Elaboração do autor, 2012.
A Figura 20 apresenta o Diagrama de Robustez para o sistema proposto. Cada
entidade do sistema é relacionada com os controladores das telas que disparam as
funcionalidades de persistência do modelo. O padrão de desenvolvimento utilizado foi o MVP
(model–view–presenter), o qual é muito semelhante ao MVC (model–view–controller) que
utiliza uma classe controladora entre as entidades e as casses de views.
52
4.2.5 Diagrama de Domínio
O diagrama de domínio está dividido em duas partes: diagrama de domínio de
persistência do projeto e diagrama de domínio de persistência do schema, conforme Figura 21
e Figura 22, respectivamente. Este diagrama possui os elementos básicos da modelagem
dimensional e que está inclusa na ferramenta para a geração do schema XML do Mondrian.
Figura 21 – Diagrama de Domínio de Persistência do Projeto
Fonte: Elaboração do autor, 2012.
O diagrama exposto, na Figura 21, intitulado como Diagrama de Domínio de
Persistência do Projeto, possui os elementos para salvar um projeto de modelagem com o
software proposto para que possa ser aberto novamente em um segundo momento.
53
Figura 22 – Diagrama de Domínio de Persistência do Schema
Fonte: Elaboração do autor, 2012.
O diagrama exposto, na Figura 22, intitulado como Diagrama de Domínio de
Persistência do Projeto, possui os elementos para geração de um schema XML para utilização
no servidor OLAP Mondrian.
4.2.6 Diagrama de Classes
O Diagrama de Classes é o diagrama que possui todas as classes (da programação
de computadores orientada a objetos) do projeto. Este diagrama oferece uma visão sistêmica
54
da estrutura de classes do sistema, e as dependências, associações, agrupamentos, e todos os
tipos de relações entre classes que um modelo de classes pode possuir.
Para o projeto deste trabalho, o diagrama de classes está representado pela Figura
23. Neste diagrama de classes foram suprimidas as classes que já estão inclusas no diagrama
de domínio.
Figura 23 – Diagrama de Classes
Fonte: Elaboração do autor, 2013.
O diagrama de classes representado pela Figura 23 apresentam as relações das
classes do sistema, incluindo classes de interface gráfica e classes de persistência do modelo.
55
4.2.7 Diagramas de Sequência
O modelo de desenvolvimento de software Iconix prevê, ainda, o diagrama de
sequência. O diagrama de sequência apresenta a sequência dos processos do sistema, ou seja,
esse diagrama deve mostrar as mensagens trocadas entre os objetos do programa. Esse
diagrama é criado baseado no diagrama de casos de uso do sistema, e representa a interação
dos objetos que implementam cada caso de uso.
No sistema de modelagem dimensional proposto foram representados seis
diagramas de sequência. Foi suprimido nesta implementação o caso de uso UC001, pois este é
a composição dos casos de uso UC002 e UC003, os quais já estão diagramados. Também não
necessitou a implementação para o caso de uso UC005, pois este faz uso do mesmo modelo
utilizado no caso de uso UC006.
Figura 24 – Diagrama de Sequência UC002
Fonte: Elaboração do autor, 2013.
56
Figura 25 – Diagrama de Sequência UC003
Fonte: Elaboração do autor, 2013.
57
Figura 26 – Diagrama de Sequência UC004
Fonte: Elaboração do autor, 2013.
58
Figura 27 – Diagrama de Sequência UC006
Fonte: Elaboração do autor, 2013.
Figura 28 – Diagrama de Sequência UC007
Fonte: Elaboração do autor, 2013.
59
Figura 29 – Diagrama de Sequência UC008
Fonte: Elaboração do autor, 2013.
As Figuras de 24 a 29 apresentam os diagramas de sequência dos casos de uso
UC002, UC003, UC004, UC006, UC007 e UC008 respectivamente. Para uma compreensão
mais acertiva, os métodos ativados pelo ator Usuário representam os métodos de invocação de
uma ação na interface gráfica, seja por um botão, ou por um evento drop (drag-and-drop)
oferecido pela GUI (graphical user interface). Os métodos partem do ator Usuário e avançam
até o objeto mais externo de interação para efetuar a operação desejada, prevista no caso de
uso.
60
5 DESENVOLVIMENTO
Neste capítulo será abordado sobre o desenvolvimento da proposta de software
para desenvolvimento de cubo de dados para Mondrian. O software desenvolvido possui a
implementação de toda a documentação que foi descrita no capítulo anterior, cujo objetivo
final é a integração deste sistema com o Mondrian, através da geração de um schema XML.
5.1 FERRAMENTAS TECNOLÓGICAS
A ferramenta Mondrian Schema Workbench, que é utilizada para a criação do
schema XML do Mondrian, foi criada pela empresa Pentaho e foi desenvolvida na linguagem
de programação Java. Java é uma linguagem de programação criada pela empresa Sun
Microsystems, a qual foi comprada pela empresa Oracle Corporation posteriormente. Esta
linguagem é uma das mais utilizadas no mundo e possui uma arquitetura desenvolvida para
diversos tipos de aplicações diferentes (desktop, web, webservice, embarcados e outras).
O sistema proposto neste trabalho tem um objetivo de apresentar uma forma de
implementação de um schema XML do Mondrian, de modo que seja uma alternativa ao
Mondrian Schema Workbench. Pelo fato de o Workbench ser desenvolvido em Java, preferiu-
se, também, o desenvolvimento do sistema na mesma linguagem, pelas facilidades que o Java
oferece em relação a frameworks disponíveis para geração de arquivos XML, interface gráfica
com o usuário, linguagem orientada a objetos e simplicidade de código computacional.
Foram utilizadas duas bibliotecas (frameworks) de Java para a implementação das
funcionalidades: Simple e JGraph.
O framework Simple é um projeto disponível em sourceforge.net, cujo objetivo é
a serialização de objetos para a geração de scripts XML. Esta serialização é feita por
intermédio de notações que são interpretadas pelo framework para fazer a serialização dos
objetos e, posteriormente, a persistência destes em um arquivo XML.
61
Figura 30 – Exemplo de notação utilizada no framework Simple
Fonte: Elaboração do autor, 2013.
A Figura 30 apresenta um exemplo da utilização da notação requerida pelo
framework Simple para a serialização do objeto. Cada tipo de notação utilizada representa
uma notação estrutural do XML (elementos, atributos, etc).
O JGraph é uma biblioteca de Java, cujo projeto é desenvolvido e mantido pela
empresa JGraph Ltd. A biblioteca JGraph oferece um ambiente para desenvolvimento de
interface gráfica com o usuário em formato de esquemas gráficos (grafos) com
relacionamentos entre vértices.
Figura 31 – Exemplo de grafo em uma GUI criada pelo JGraph
Fonte: Elaboração do autor, 2013.
Na Figura 31 está exposto um exemplo de GUI (graphical user interface) criada a
partir da biblioteca JGraph. Através de uma classe genérica que representa uma célula no
gráfico é possível manipular os componentes e determinar o tipo de entidade no grafo, se é
um vértice ou uma aresta, por exemplo.
O sistema de geração do XML proposto neste trabalho deverá gerar um schema
XML do Mondrian, e para isso deverá conhecer a toda a estrutura de XML utilizada no
62
Mondrian para gerar exatamente como é esperado pela plataforma. A estrutura do XML do
schema do Mondrian carrega todas as informações de metadados de banco de dados da
estrutura de um cubo de dados e as informações de apresentação no sistema front-end que
utiliza o Mondrian. O Mondrian conhece toda a estrutura do cubo de dados e deverá utiliza-
los para gerar e executar as consultas SQL (structured query language) no banco de dados
relacional que consiste o datamart.
Figura 32 – Exemplo da estrutura de um Schema XML do Mondrian
Fonte: Elaboração do autor, 2013.
O Schema XML do Mondrian possui entidades e atributos da linguagem XML
que representam os conceitos utilizados na modelagem dimensional que persiste um cubo de
dados, conforme é visto na Figura 32.
5.2 APRESENTAÇÃO E VALIDAÇÃO DO SISTEMA
Nesta seção do capítulo será feita a apresentação juntamente com a validação do
sistema proposto de modelagem dimensional com integração ao Pentaho Mondrian.
63
Para exemplificar a utilização do sistema foi escolhido um exemplo de
modelagem dimensional simples, contendo uma entidade fato de vendas, e três dimensões:
tempo (período ou data), produto e vendedor.
Figura 33 – Modelo Dimensional do exemplo de desenvolvimento
Fonte: Elaboração do autor, 2013.
O modelo dimensional, apresentado na Figura 33, oferece uma visão do modelo
de banco de dados exemplo que será utilizado como exemplo para a demonstração do sistema.
O desenvolvimento de um schema XML do Mondrian pode ser feito de duas
formas: pelo software Workbench ou via edição de arquivo XML simplesmente. O software
Mondrian Schema Workbench da empresa Pentaho foi desenvolvido para a criação e geração
do schema XML do Mondrian de forma textual e não de esquema gráfico, além de possuir
uma linguagem de desenvolvimento demasiadamente técnica, a qual exige um alto nível de
conhecimento técnico para a implementação de um cubo de dados.
64
Figura 34 – Tela do Mondrian Schema Workbench com proposta de modelo
Fonte: Elaboração do autor, 2013.
O modelo de banco de dados de exemplo feito para a apresentação e validação
deste trabalho foi implementado, também, na ferramenta Workbench, conforme é apresentado
na Figura 34, a fim de fazer uma comparação de usabilidade e desenvolvimento de um projeto
nas duas ferramentas.
O sistema proposto por este trabalho foi desenvolvido para suportar os requisitos
funcionais descritos na seção 4.2.1 deste trabalho, sendo o principal deles o RF005 – O
sistema deve permitir, após a modelagem criada, a geração do Schema XML para Mondrian
Pentaho.
65
Figura 35 – Tela principal do sistema
Fonte: Elaboração do autor, 2013.
A Figura 35 apresenta a tela principal do sistema desenvolvido, que acompanha a
representação do protótipo de tela TEL001 – Implementação de Modelagem Dimensional.
Abaixo é apresentado o desenvolvimento do exemplo de cubo de dados de vendas na
ferramenta proposta para demonstração, conforme Figura 36.
66
Figura 36 – Tela com exemplo de modelagem dimensional
Fonte: Elaboração do autor, 2013.
O modelo dimensional proposto como exemplo foi implementado na ferramenta
desenvolvida e está representado pela Figura 36. Este modelo OLAP de vendas possui
medições de quantidade de produtos por data, vendedor e produto, e os valores totais contados
por estas dimensões. Uma vez que o usuário executa um duplo clique em uma das entidades
do modelo (fato ou dimensão), é apresentada tela de edição de medidas ou níveis, conforme o
tipo de entidade escolhida para edição.
67
Figura 37 – Tela de edição de entidade (Unid. de Análise, no exemplo)
Fonte: Elaboração do autor, 2013.
A Tela de Edição de Unidade de Análise, proposto pelo protótipo de tela
“TEL009 – Edição de Dimensão” e apresentada pela Figura 37, possui as informações
pertinentes aos níveis da dimensão da modelagem dimensional e à dimensão propriamente
dita.
Com este modelo dimensional desenvolvido na ferramenta e feito seus devidos
relacionamentos, o próximo passo é gerar os arquivos pertinentes ao projeto e o schema XML
do Mondrian, conforme requisitos RF007 e RF005 respectivamente.
Figura 38 – Tela com exemplo de modelagem dimensional
Fonte: Elaboração do autor, 2013.
68
Figura 39 – Tela de salvamento do projeto
Fonte: Elaboração do autor, 2013.
As Figuras 38 e 39 apresentam as telas correspondente ao salvamento do projeto,
procedimento tal, que também é utilizado para o salvamento do XML, apesar do último
utilizar o menu “Ferramentas” e “Gerar Schema XML do Mondrian”.
69
Figura 40 – Tela do arquivo XML do projeto salvo
Fonte: Elaboração do autor, 2013.
O arquivo XML do projeto, mostrado na Figura 40, possui informações e estrutura
diferentes do schema XML do Mondrian. As informações adicionais são os atributos
positionX e positionY que armazenam a posição do objeto relacional do grafo no gráfico do
sistema.
70
Figura 41 – Tela do Schema XML do Mondrian gerado
Fonte: Elaboração do autor, 2013.
Com uma estrutura compatível com a interpretação do Mondrian, o schema XML
gerado, conforme Figura 41, é construído para que o Mondrian interprete e gere as consultas
no cubo de dados, conforme é apresentado na validação.
A validação do sistema é feita a partir da visualização do schema XML gerado
aplicado a um sistema front-end, que faz uso do servidor de consultas Mondrian. Para fazer a
validação foi utilizado o sistema Saiku da Pentaho, que utiliza o Mondrian como servidor de
consultas.
O schema XML do Mondrian exposto pela Figura 41 foi integrado na ferramenta
Saiku para executar consultas em um banco de dados que faz implementação do fato e das
dimensões apresentadas por este schema.
71
Figura 42 – Validação do Schema XML do Mondrian na ferramenta Saiku
Fonte: Elaboração do autor, 2013.
A Figura 42 mostra uma consulta feita na ferramenta Saiku com o modelo
dimensional proposto e desenvolvido no sistema de modelagem dimensional sugerido por este
trabalho. Foram utilizados alguns dados fictícios para teste da consulta que estão apresentadas
na área tabelada da imagem.
Pode-se verificar, através do teste executado na ferramenta OLAP Saiku, que o
schema XML do Mondrian gerado pelo sistema de modelagem proposto, está sendo
construído de forma satisfatória, e que é integrado ao Mondrian, o qual faz o uso correto do
arquivo XML.
5.3 CONSIDERAÇÕES FINAIS
Neste capítulo foi apresentado e validado o sistema proposto neste trabalho. O
sistema possui todos os requisitos especificados em sua documentação (explicitada no
capítulo 4), e foi validado pelo software Saiku, da empresa Pentaho, que é uma ferramenta de
72
OLAP front-end para consultas em cubos de dados que utiliza o Mondrian. Também, foi feita
a comparação entre o sistema proposto com o Workbench, para analisar as diferenças de
usabilidade e linguagem, implementando nos dois sistemas um modelo dimensional de banco
de dados de exemplo.
73
6 CONCLUSÕES
O sistema desenvolvido no decorrer deste trabalho se apresenta como uma
alternativa simplificada ao software Mondrian Schema Workbench da empresa Pentaho, e
possui características de usabilidade aprimoradas se comparada a este.
O analista de negócio, uma vez conhecendo a estrutura de metadados do modelo
de data mart, pode facilmente criar um cubo de dados, e implementar a estrutura de análise de
negócio conforme a visão mais especialista do negócio propriamente dito. O analista de
sistemas, por sua vez, com a ferramenta implementada, possui uma visão mais sistêmica do
cubo de dados e os relacionamentos de modelagem que o envolvem, bem como é facilitado o
seu desenvolvimento do cubo de dados, aumentando, ainda, a produtividade desta atividade.
A visão gráfica da modelagem dimensional em desenvolvimento na ferramenta
proposta é uma característica facilitadora para o entendimento geral da modelagem e do
negócio. Para a geração de um Schema XML do Mondrian, são necessários dois passos para o
usuário executar esta atividade, e o sistema por si só faz a geração precisa das informações do
cubo, que pode de imediato ser incorporado ao Mondrian para o início das análises no cubo, e
desta forma o objetivo principal da ferramenta é satisfeito.
Neste trabalho, pôde-se abranger uma largueza de conceitos de data warehouse,
bem como muitos recursos de linguagem de computadores e conceitos do BI em si. Isto é
compreendido como de grande valor e ganho para o trabalho e sua obra. Foi possível
identificar, também, o valor de uma interface gráfica com usuário na forma de esquemas de
visualização em grafos, bem como, a importância de características de usabilidade
simplificada e facilitadora, para sistemas de computadores. Isto não somente para sistemas
para usuários finais (como no caso de ferramentas front-end), mas também para ferramentas
de desenvolvimento de outros sistemas.
Ferramentas de desenvolvimento de sistemas são muito importante para o
mercado de TI atual. Uma ferramenta bem projetada e consistente agrega grande valor para
desenvolvedores de sistemas, pois oferecem desempenho na execução de atividades destes, e
proporcionam uma redução considerável de erros de desenvolvimento.
74
6.1 TRABALHOS FUTUROS
A criação dos requisitos do sistema proposto neste trabalho foi feita pensando nos
requisitos mais importantes em relação ao tempo disponível para se obter resultados até a
conclusão deste trabalho. Desta forma, é possível, ainda, imaginar muitos outros requisitos,
ou funcionalidade, para a proposta, que poderiam expandir muito a ferramenta e agregar um
grande valor ao trabalho.
Num primeiro momento, o sistema poderia estender sua funcionalidade
possibilitando a criação de cubos de dados no modelo snowflake, que trata-se de um tipo de
modelagem multidimensional envolvendo tabelas externas às dimensões, além de poder
comportar um data mart com mais de um cubo de dados no modelo (mais de uma tabela de
fato por modelagem dimensional e schema XML). Ainda, uma vez conhecendo o metadados
do data mart, uma funcionalidade interessante à proposta seria a geração dos scripts de DDL
(Data Definition Language) do modelo, para a criação das tabela.
Quando é tratado sobre documentação, é considerado um problema muito comum
na área de TI a falta desta, o que causa muito transtorno numa posterior manutenção de um
sistema. O sistema de modelagem dimensional proposto pode haver um requisito de geração
automática de documentação, estruturando um documento de comentários para a modelagem
dimensional atribuindo todos os campos e seus respectivos labels ao documento e um espaço
para possíveis comentários, facilitando assim, a manutenção da modelagem dimensional
representada.
75
REFERÊNCIAS
BOUMAN, Roland; DONGEN, Jos van. Pentaho Solutions: Business Intelligence and Data Warehousing with Pentaho and MySQL. Indianapolis: Wiley Publishing, 2009. BRACKETT, Michael H.. The Data Warehouse Challenge: Taming Data Chaos. New York: Wiley Computer Publishing, 1996. CARDOZO, José Ricardo Ferreira. ICONIX. 2011. Disponível em: <http://www.jricardo.net/wordpress/?p=20>. Acesso em: 05 nov. 2012. GIL, Antonio Carlos. Como Elaborar Projetos de Pesquisa: 4ª Edição. São Paulo: Atlas, 2002. HYDE, Julian. Pentaho Mondrian Documentation: Mondrian and OLAP. 2006. Disponível em: <http://mondrian.pentaho.com/documentation/olap.php>. Acesso em: 27 set. 2012. HYDE, Julian. Pentaho Mondrian Documentation: Architecture. 2006. Disponível em: <http://mondrian.pentaho.com/documentation/architecture.php>. Acesso em: 27 set. 2012. HYDE, Julian. Pentaho Mondrian Documentation: How to Design a Mondrian Schema. 2009. Disponível em: <http://mondrian.pentaho.com/documentation/schema.php>. Acesso em: 01 out. 2012. ICONIX PROCESS. ICONIX Process Overview. 2007. Disponível em: <http://iconixprocess.com/iconix-process/>. Acesso em: 05 nov. 2012. ICONIX PROCESS. ICONIX Process Roadmap. 2007. Disponível em: <http://iconixprocess.com/iconix-process/roadmap/>. Acesso em: 25 nov. 2012. INFANTE, Dennis Alba; DARIO, Bernabeu Ricardo. Passos para crear Cubos con Mondrian Schema Workbench. 2009. Disponível em: <http://openbi.ning.com/group/mondrianschemaworkbench/forum/attachment/download?id=2400100%3AUploadedFi38%3A11113>. Acesso em: 01 out. 2012. INMON, W. H.. Building the data warehouse. Indianapolis: Wiley Publishing, 2005.
76
INMON, W. H.. Como construir o data warehouse. Rio de Janeiro: Campus, 1997. INMON, W. H.. DW 2.0: The Architecture for the Next Generation of Data Warehousing. Burlington: Morgan Kaufmann Publishers, 2008. KIMBALL, Ralph; ROSS, Margy. The Data Warehouse Toolkit. New York: Wiley Publishing, 2002. KIMBALL, Ralph; REEVES, Laura; ROSS, Margy; THORNTHWAITE, Warren. The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing Data Warehouses. Indianapolis: Wiley Publishing, 2008. MACHADO, Felipe Nery Rodrigues; ABREU, Maurício Pereira de. Projeto de Banco de Dados: Uma Visão Prática. São Paulo: Érica, 2002. MUNDY, Joy; THORNTHWAITE, Warren; KIMBALL, Ralph. The Microsoft Data Warehouse Toolkit: With SQL Server 2008 R2 and the Microsoft Business Intelligence Toolset, Second Edition. Indianapolis: Wiley Publishing, 2011. SEZÕES, Carlos; OLIVEIRA, José; BAPTISTA, Miguel. Business Intelligence. Portugal: Spi – Sociedade Portuguesa de Inovação, 2006. SILVA, Edna Lúcia da; MENEZES, Estera Muszkat. Metodologia da Pesquisa e Elaboração de Dissertação: 3ª Edição revisada e atualizada. Florianópolis: Laboratório de Ensino a Distância da UFSC, 2001. SORDI, José Osvaldo de. Tecnologia da Informação Aplicada aos Negócios. São Paulo: Atlas, 2003. TANCREDO, Levi Corrêa; CESCONETO, Thiago. Metodologia de desenvolvimento de software com ICONIX. 2010. 7 f. Artigo (Especialização em Engenharia de Projetos de Software) – Universidade do Sul de Santa Catarina, Florianópolis, 2010. THOMSEN, Erik. OLAP Solutions: Building Multidimensional Information Systems, Second Edition. Indianapolis: Wiley Publishing, 2002. WOOD, Sherman. Mondrian Schema Workbench Release Notes. 2007. Disponível em: <http://sourceforge.net/project/shownotes.php?release_id=507816>. Acesso em: 01 out. 2012.