GABRIEL KOERICH DUARTE
UMA PROPOSTA DE SOFTWARE PARA IMPLEMENTAÇÃO DE CUBO DE DADOS PARA MONDRIAN
Palhoça 2013
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
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.
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.
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 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
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.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
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
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?
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.
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
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.
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).
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
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).
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
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.
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.
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.
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”.
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
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
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.
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.
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.
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).
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;
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.
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.
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.
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ê
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.
Figura 8 – Diagrama de Requisitos Funcionais
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
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.
Figura 10 – TEL001 – Implementação de Modelagem Dimensional
Fonte: Elaboração do autor, 2012.
Figura 11 – TEL002 – Definição da Entidade de Fato
Figura 12 – TEL003 – Definição da Unidade de Análise (Dimensão)
Fonte: Elaboração do autor, 2012.
Figura 13 – TEL004 – Menu do Sistema
Figura 14 – TEL005 – Menu de Ferramentas do Sistema
Fonte: Elaboração do autor, 2012.
Figura 15 – TEL006 – Procurar Arquivo
Figura 16 – TEL007 – Salvar Arquivo
Fonte: Elaboração do autor, 2012.
Figura 17 – TEL008 – Edição de Fato
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).
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.
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
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.
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;
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
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
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.
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.
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.
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.
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
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.
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
Figura 25 – Diagrama de Sequência UC003
Figura 26 – Diagrama de Sequência UC004
