UNIVERSIDADE DO SUL DE SANTA CATARINA GABRIEL KOERICH …

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 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


36

Figura 9 – Diagrama de Requisitos Não Funcionais


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.


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.


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


Figura 11 – TEL002 – Definição da Entidade de Fato


39

Figura 12 – TEL003 – Definição da Unidade de Análise (Dimensão)


Figura 13 – TEL004 – Menu do Sistema


40

Figura 14 – TEL005 – Menu de Ferramentas do Sistema


Figura 15 – TEL006 – Procurar Arquivo


41

Figura 16 – TEL007 – Salvar Arquivo


Figura 17 – TEL008 – Edição de Fato


42

Figura 18 – TEL009 – Edição de Dimensão


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


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”


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.


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


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.


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”


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


• 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.


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


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


• Precondição: entidade da modelagem dimensional criada;

• pós-condição: rótulo de determinada entidade da modelagem dimensional definido.

47


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


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.


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


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.


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


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.


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


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


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


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


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


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


56



57



58





59



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


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


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


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


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


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


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


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)


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


68

Figura 39 – Tela de salvamento do projeto


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


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


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


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.

UNIVERSIDADE DO SUL DE SANTA CATARINA GABRIEL KOERICH …

Documents

Transcript of UNIVERSIDADE DO SUL DE SANTA CATARINA GABRIEL KOERICH …