UNIOESTE Universidade Estadual do Oeste do Paraná CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado de Ciência da Computação Curso de Bacharelado em Ciência da Computação Desenvolvimento de um Sistema Web para Gerenciamento de Programas de Pós-Graduação Stricto Sensu da UNIOESTE Lucas da Silva Inácio CASCAVEL 2011
LUCAS DA SILVA INÁCIO Desenvolvimento de um Sistema Web para Gerenciamento de Programas de Pós-Graduação Stricto Sensu da UNIOESTE Monografia apresentada como requisito parcial para obtenção do grau de Bacharel em Ciência da Computação, do Centro de Ciências Exatas e Tecnológicas da Universidade Estadual do Oeste do Paraná - Campus de Cascavel Orientador: Prof. Dr. Clodis Boscarioli CASCAVEL 2011
LUCAS DA SILVA INÁCIO Desenvolvimento de um Sistema Web para Gerenciamento de Programas de Pós-Graduação Stricto Sensu da UNIOESTE Monografia apresentada como requisito parcial para obtenção do Título de Bacharel em Ciência da Computação, pela Universidade Estadual do Oeste do Paraná, Campus de Cascavel, aprovada pela Comissão formada pelos professores: Prof. Dr. Clodis Boscarioli (Orientador) Colegiado de Ciência da Computação, UNIOESTE Prof. Dr. Marcio Seiji Oyamada Colegiado de Ciência da Computação, UNIOESTE Prof. MSc. Anibal Mantovani Diniz Colegiado de Ciência da Computação, UNIOESTE Cascavel, 07 de Novembro de 2011.
DEDICATÓRIA Dedico à minha família, meus professores e meus amigos que sempre me dão força e motivação, proporcionando a realização deste e outros trabalhos. Sem eles, este momento não seria possível.
Lista de Figuras Figura 1 - Cubo com as dimensões produto, tempo e região [5]... 13 Figura 2 Data warehouse no contexto do sistema [15]... 17 Figura 3 - Star Schema [10]... 19 Figura 4 - Snowflake Schema [10]... 20 Figura 5 - Modelo SD (Dependências Estratégicas)... 25 Figura 6 Diagrama de Requisitos Não-Funcionais... 26 Figura 7 - Diagrama de Casos de Uso... 28 Figura 8 - Diagrama de Funções dos Atores do Sistema... 29 Figura 9 - Diagrama de Processo da Gerência de Cronograma e Etapa... 31 Figura 10 - Diagrama de Processo da Gerência de Programa, Nível e Disciplina... 32 Figura 11 - Diagrama de Processo da Gerência de Áreas e Linha de Pesquisa... 33 Figura 12 - Diagrama de Processo da Gerência de Oferta de Disciplina... 33 Figura 13 - Diagrama de Processo da Gerência das Inscrições Regulares... 34 Figura 14 - Diagrama de Processo da Gerência das Inscrições Especiais... 35 Figura 15 - Diagrama de Processo da Gerência Matrícula em Disciplina... 35 Figura 16 - Diagrama de Processo do Lançamento de Notas e Frequência... 36 Figura 17 - Camadas do Sistema... 37 Figura 18 - Diagrama de Classe organizado em camadas e pacotes do sistema... 38 Figura 19 - Diagrama Relacional... 41 Figura 20 - Modelo de Classe da Camada de Aplicação... 43 Figura 21 - Arquitetura dos Componentes Ext JS... 44 Figura 22 - Página principal do sistema... 44 Figura 23 - Star Schema do Sistema Proposto... 46 Figura 24 - Interface JPalo para o Cubo... 47 v
Lista de Abreviaturas e Siglas OLAP IBM APL MOLAP ROLAP HOLAP DOLAP WOLAP MDX PGEAGRI PRPPG SGBD UML SD NFR SQL MR RF RNF MVC ETL OLTP KDD API PAT On-Line Analytical Processing International Business Machines A Programming Language Multidimensional On-Line Analytical Processing Relational On-Line Processing Hybrid On-Line Analytical Processing Desktop On-Line Analytical Processing Web On-Line Analytical Processing Multi-Dimensional Expressions Programa de Pós-Graduação de Engenharia Agrícola Pró-Reitoria de Pesquisa e Pós-Graduação Sistema Gerenciador de Banco de Dados Unified Modeling Language Strategic Dependency Non-Functional Requirements in Software Engineering Structured Query Language Modelo Relacional Requisito Funcional Requisito Não-Funcional Model-View-Controller Extraction Transformation Loading On-Line Transaction Processing Knowledge Discovery in Databases Application Programming Interface Pentaho Analysis Tool vi
Sumário LISTA DE FIGURAS... V LISTA DE ABREVIATURAS E SIGLAS... VI RESUMO... VIII CAPÍTULO 1... 9 INTRODUÇÃO... 9 CAPÍTULO 2... 11 OLAP E VISUALIZAÇÃO DE DADOS... 11 2.1 Conceitos... 11 2.2 Operações multidimensionais OLAP... 13 2.3 Arquiteturas... 14 2.4 Data Warehouse... 16 2.4.1 Data Mart... 18 2.4.2 Estrutura de Armazenamento... 18 2.5 Ferramentas... 21 CAPÍTULO 3... 22 PLANEJAMENTO DO SISTEMA... 22 3.1 Resumo do Processo Atual... 22 3.2 A Solução Proposta... 23 CAPÍTULO 4... 37 ESTRUTURA DO SISTEMA... 37 4.1 Camada de Dados... 39 4.2 Camada de Aplicação... 42 4.3 Camada de Apresentação... 43 4.4 Módulo OLAP... 45 CAPÍTULO 5... 49 CONSIDERAÇÕES FINAIS... 49 APÊNDICE A... 50 REQUISITOS FUNCIONAIS... 50 APÊNDICE B... 68 REQUISITOS NÃO-FUNCIONAIS... 68 APÊNDICE C... 70 CASOS DE USO... 70 REFERÊNCIAS BIBLIOGRÁFICAS... 127 vii
Resumo Este documento faz um descritivo dos requisitos para o desenvolvimento de um sistema que tem por finalidade gerenciar e otimizar os processos gerenciais dos Programas de Pós-Graduação Stricto Sensu, utilizados atualmente pela Universidade Estadual do Oeste do Paraná (UNIOESTE). O sistema inclui também um módulo preliminar para gerenciar relatórios, trazendo uma opção de front-end para os usuários modelarem de forma dinâmica suas visões de relatório, por meio de OLAP (On-Line Analytical Processing). O trabalho apresenta também, as etapas do processo de desenvolvimento, iniciado pelo levantamento de requisitos, passando pela modelagem e posteriormente à implementação, onde se discute o estado atual do sistema e suas perspectivas. Palavras-chave: Processo de Desenvolvimento de Software, Relatórios Dinâmicos, OLAP. viii
Capítulo 1 Introdução Todas as organizações demandam gerenciamento e informação. Quando o domínio em questão é grande e envolve diversos processos e pessoas, os processos manuais tornam-se complexos de serem gerenciados, necessitando de Sistemas de Informação, que são fundamentais para agilizar as rotinas e auxiliar gestores em suas tarefas de controle e tomada de decisão. A Universidade Estadual do Oeste do Paraná UNIOESTE, uma universidade composta por cinco campi e com diversos sistemas para atender as necessidades da comunidade universitária, necessita, para auxílio em seus processos, realizar a junção das áreas de Sistemas de Informação e Tecnologia da Informação, para com isso, gerenciar com dinamismo e organização as suas questões gerenciais. Na UNIOESTE, há o Núcleo de Tecnologia da Informação (NTI), responsável pela produção das dezenas de sistemas utilizados pela instituição e outros a serem projetados, de demanda já confirmada. Um desses sistemas a serem projetados é o de gerenciamento dos Programas de Pós-Graduação Stricto Sensu da Universidade, objeto de investigação desse estudo. Atualmente, o gerenciamento de candidatos e acadêmicos de Programas de Pós- Graduação Stricto Sensu da UNIOESTE é realizado de forma manual, sem um padrão institucional, demandando muito tempo dos colaboradores da Universidade no processo de inscrição, seleção, matrícula e gerenciamento dos alunos. A obtenção de dados referentes aos cursos é prejudicada por esses processos manuais que tornam as respostas lentas. Essas são algumas das características que evidenciam a necessidade da implantação de um sistema informatizado para o seu controle e gerenciamento. 9
A UNIOESTE contém diversos Programas de Pós-Graduação Stricto Sensu, espalhados pelos diversos Campi da Universidade, o que dificulta a gestão e padronização dos processos relacionados aos Programas. Este projeto tem por finalidade o início do desenvolvimento de uma aplicação web que gerencie as transações e atividades que envolvam os processos organizacionais do sistema supracitado. Também, o estudo e desenvolvido de um módulo que gere relatórios dinâmicos, mais interativos ao usuário final, para que este tenha uma maior facilidade em manipular os dados do sistema, usufruindo da dinâmica de filtrar informações para análise sem a necessidade de recorrer ao programador do sistema toda vez que necessite gerar um relatório diferente. OLAP (On-Line Analytical Processing), que são aplicações onde o usuário final tem acesso as informações da base de dados para construir relatórios capazes de responder ou apoiar as suas questões gerenciais e proporcionam condições de análise de dados necessárias para auxiliar a tomada de decisão dos analistas ou gerentes que utilizam o sistema [1], será investigado e utilizado neste contexto. Este documento está organizado como segue: O Capítulo 2 aborda conceitos e características de uma aplicação OLAP, bem como apresenta a ferramenta OLAP a ser utilizada. No Capítulo 3 é apresentado o domínio do sistema, descrevendo a forma manual de execução atualmente vigente e o sistema proposto, com todos os requisitos funcionais e não funcionais levantados. No Capítulo 4 são apresentadas as camadas do sistema e a forma como foi desenvolvida abrangendo as camadas de dados, aplicação e visão, também, um descritivo das etapas realizadas para a construção do módulo OLAP do sistema, da camada de dados à visão. O Capítulo 5 traz as considerações finais do trabalho desenvolvido, comentando sobre as dificuldades encontradas e de trabalhos futuros. O Apêndice A traz a descrição dos requisitos funcionais e os respectivos usuários de cada requisito. No Apêndice B são descritos os requisitos não-funcionais do sistema. No Apêndice C são listados os Casos de Uso do sistema, descrevendo os passos para a sua implementação. 10
Capítulo 2 OLAP e Visualização de Dados Neste capítulo, OLAP será abordado, de forma a descrever sua origem, seus conceitos, as arquiteturas de armazenamento utilizadas e, como este provê apoio ao usuário final na tomada de decisão por meio de seus relatórios dinâmicos. 2.1 Conceitos A IBM desenvolveu e implementou a primeira linguagem com análise multidimensional no final da década de 60 chamada de APL (A Programming Language). Definida matematicamente, baseada em símbolos gregos, foi amplamente utilizada na década de 80 e 90 em aplicações de negócio. Antes disso, existiam somente aplicações OLTP (On- Line Transaction Processing), cujo foco é proporcionar, de forma planar, aos usuários a criação, atualização e recuperação das informações sobre registros individuais. Na década de 90 introduziu-se então uma nova classe de ferramentas, batizada de OLAP, possuindo a maioria dos conceitos introduzidos pala linguagem APL, e com maior integridade na utilização dos dados fontes. O termo OLAP foi usado pela primeira vez por Edgar Frank Codd, o qual definiu doze regras que caracterizam uma aplicação OLAP [2]. 1. Conceito de visão multidimensional: tornou-se a característica fundamental no desenvolvimento destas aplicações [4]. Nele, os dados são modelados em diversas dimensões, podendo haver cruzamento de todos os tipos de informações. 2. Transparência: define-se que OLAP deve atender a todas as solicitações do analista, não importando de onde os dados virão. Todas as implicações devem ser transparentes para os usuários finais. 11
3. Acessibilidade: diz-se que as ferramentas OLAP devem permitir conexão com todas as bases de dados legadas. A distribuição de informações deve ser mapeada para permitir o acesso a qualquer base de dados. 4. Desempenho consistente de relatório: refere-se a não degradação de desempenho do sistema a medida com que o número de dimensões ou a base de dados vão crescendo. É fundamental para manter a facilidade de uso para o usuário final. 5. Arquitetura cliente/servidor: OLAP deve ser construída em arquitetura clienteservidor para que possa atender a qualquer usuário em qualquer ambiente operacional. 6. Dimensionamento genérico: diz respeito à capacidade de tratar informações em qualquer quantidade de dimensões. 7. Tratamento dinâmico de matrizes esparsas: Para conseguir operações de cruzamento dimensional irrestritas é necessário tratar a esparsidade 1 dos dados. Devido ao grande volume de informações armazenadas nas diversas dimensões de um modelo multidimensional, a esparsidade se torna comum, e então essas células nulas devem ser tratadas para evitar custos com memória. 8. Suporte a multiusuários: nas grandes organizações é comum vários analistas trabalharem com a mesma base de dados. 9. Operações de cruzamento dimensional irrestritas: as ferramentas OLAP devem ser capazes de navegar nas diversas dimensões existentes. 10. Manipulação intuitiva de dados: os usuários devem ser capazes de manipular os dados livremente, sem necessitar de qualquer tipo de ajuda. 11. Relatórios flexíveis: O usuário deve ter a flexibilidade na geração de relatórios, para efetuar qualquer tipo de consulta. 12. Níveis de dimensões e agregações ilimitados: diz respeito ao número de dimensões simultâneas de dados que podem ser cruzadas. A recomendação é de pelo menos quinze, devendo haver vários níveis de agregação dos dados. 1 Esparsidade: uma base de dados com grande proporção de elementos nulos. 12
OLAP é uma das tecnologias que compõem Business Intelligence, 2 com capacidade para manipular e analisar um grande volume de dados sob múltiplas perspectivas, utilizada para apoiar as empresas na análise de suas informações, visando obter análises (novos conhecimentos) a serem empregadas na tomada de decisão. 2.2 Operações multidimensionais OLAP A multidimensionalidade é um conceito chave da análise feita por ferramentas OLAP. Neste tipo de análise os dados são modelados em uma estrutura conhecida como cubo e envolve conceitos como: dimensão, hierarquia, membro e medida para representar a visão multidimensional. Figura 1 - Cubo com as dimensões produto, tempo e região [5] Na Figura 1, o cubo nos fornece a idéia de navegação em vários assuntos (dimensões), são elas: produto, tempo e região, para uma mesma base de dados, ou seja, é uma estrutura onde armazenam os dados de negócio em formato multidimensional. A dimensão é uma unidade de análise que agrupa dados de negócio relacionados. Uma dimensão pode ser definida como uma característica ou um atributo de um conjunto de dados. Cada dimensão contém membros que compartilham características comuns e os membros são frequentemente organizados hierarquicamente dentro da dimensão [6]. Uma hierarquia é composta por todos os níveis de uma dimensão e medida é uma dimensão especial utilizada para realizar comparações [4]. Considerando os dados em um cubo multidimensional, cada célula de um cubo poderia conter dados para um objeto específico e os dados podem ser consultados em 2 Business Intelligence pode ser definido como um conjunto de modelos matemáticos e metodologias de análise que exploram os dados disponíveis para gerar informações e conhecimentos úteis para o complexo processo decisório [3]. 13
qualquer combinação das dimensões. A mudança de uma hierarquia dimensional (orientação) para outra é realizada em um cubo de dados pela técnica chamada de pivoteamento ou rotação, como se houvesse uma rotação no cubo para mostrar uma orientação diferente dos eixos. Também há flexibilidade de fazer roll-up e drill-down. Apresentações roll-up se movem para cima na hierarquia de uma dimensão, agrupando dados, como se estivesse percorrendo uma dimensão do seu detalhamento para a generalização. Já drill-down é a capacidade oposta, fornecendo uma visão de granularidade mais fina [8]. Como exemplo, considere um relatório por região: fazendo drill-up é como se estivesse passando da visão cidade para estado, e assim sucessivamente. Para drill-down é o inverso, detalhando mais os dados, passando de estado para cidade, de cidade para bairro, e assim sucessivamente. Existem ferramentas para a visualização dos dados que permitem aplicação dos conceitos acima, de acordo com a escolha das dimensões. Ferramentas dessa natureza serão utilizadas neste trabalho para a implantação destas funcionalidades no sistema proposto. 2.3 Arquiteturas Existem várias maneiras de classificar uma ferramenta OLAP quanto a sua arquitetura. Vamos dividir essa análise de arquiteturas em relação ao tipo de dado acessado e ao processamento desses dados. Todas elas provêm acesso cliente-servidor e à visão multidimensional dos dados, independente de onde os dados foram extraídos (INMON, 1997) apud [1]. Os dados podem ser armazenados de diferentes formas conforme a seguinte taxonomia: MOLAP (Multidimensional On-Line Analytical processing): acessam bases de dados multidimensionais, elas extraem informação de estruturas de dados pré-processadas, geralmente em forma de cubos, onde estes cubos contêm todas as informações desejadas e pré-estipuladas. Sua implementação varia de acordo com a ferramenta OLAP, podendo ser implementado em um banco de dados relacional, porém não na terceira forma normal. Sua vantagem está na predeterminação dos dados, pois a estrutura fica calculada e otimizada para as consultas. Uma de suas limitações é a possibilidade dos dados serem esparsos (nem todo cruzamento das dimensões contém dados), ocorrendo a chamada explosão de armazenamento de dados, ou seja, um imenso banco de dados multidimensional contendo poucos dados 14
armazenados [1]. Outras limitações dessa ferramenta estão relacionadas ao fato dos bancos multidimensionais serem sistemas proprietários que não seguem padrões, ou seja, cada desenvolvedor cria a sua própria estrutura para o banco e as próprias ferramentas de suporte (CARVALHO, 2004) apud [1]. ROLAP (Relational On-Line Processing): não utilizam os cubos pré-calculados, atendem melhor usuários que não tem um escopo de análise bem definido. A medida que o usuário monta uma consulta, a ferramenta faz a consulta em uma base de dados relacional. A principal característica é a flexibilidade de fazer qualquer consulta, mas há desvantagens no tempo de resposta, pois dependendo do tamanho da consulta, o tempo de resposta pode ser muito longo. Ao comparar as duas arquiteturas em termos de desenvolvimento, a MOLAP se torna mais fácil de construir, pois a ferramenta já realiza as agregações e não requer tuning 3 específico de um banco de dados multidimensional. Já a arquitetura ROLAP requer a criação de um projeto lógico específico, tuning do banco de dados relacional e a criação e manutenção das tabelas sumarizadas [9]. HOLAP (Hybrid On-Line Analytical Processing): é a integração das duas arquiteturas acima, oferecendo escolha entre um banco de dados relacional e multidimensional, carregando resultados de consultas relacionais em bancos de dados multidimensionais. Utiliza um banco de dados multidimensional para fazer um cache dos dados com um nível maior de agregação e usar um banco de dados relacional para fazer um acesso dinâmico aos dados detalhados [9]. DOLAP (Desktop On-Line Analytical Processing): seu foco é a utilização em desktops, é uma ferramenta de baixo custo que acessam os dados localmente através de uma base de dados local multidimensional ou um repositório local. A vantagem é a redução da sobrecarga do servidor de banco de dados, uma vez que todos os processos OLAP ocorrem na máquina cliente. A desvantagem é no tamanho do cubo, o qual não pode ser muito grande, caso contrário sobrecarregaria a máquina local e a máquina não suportaria [1]. WOLAP (Web On-Line Analytical Processing): é a utilização de uma ferramenta OLAP em um browser (navegador web). A diferença desta ferramenta para as outras é sua abrangência, facilitando a distribuição e o acesso remoto dos dados aos usuários. 3 Tuning: afinação, otimização ou personalização da base de dados. 15
Neste trabalho será utilizada a arquitetura WOLAP juntamente com uma base de dados relacional, pois sua implementação será disponibiliza on-line, oferecendo escalabilidade e facilidade de acesso ao usuário do sistema. Ao usar uma base de dados relacional para a montagem do cubo ganha-se flexibilidade ao poder fazer qualquer consulta na parte relacional. O fato de ser uma base de dados relacional o funcionamento de uma ferramenta com características OLAP exigirá a criação de um projeto lógico específico que será adotado na Seção 2.4.2. 2.4 Data Warehouse Data warehouse, segundo (INMON, 2005) apud [14], é uma coleção de dados orientada por assuntos, integrada, variante no tempo e não volátil, que tem por objetivo dar suporte aos processos de tomada de decisão. Pode ser traduzido como depósito de dados e seu objetivo é trabalhar com uma grande quantidade de informação e principalmente dados históricos. Analisando bem, são os acontecimentos históricos que levam a uma melhor tomada de decisão e à prevenção de eventos futuros. Um data warehouse é orientado a assunto, diferente dos sistemas transacionais existentes que são orientados por processos comuns. Em uma companhia de seguros, por exemplo, as aplicações transacionais poderiam estar divididas em automóvel, vida, saúde, e perdas. Já as áreas de assunto para essa companhia poderiam, por exemplo, estar divididas em cliente, apólice, prêmio e indenização [14]. Já a integração dos dados quer dizer que as inconsistências encontradas em dados provenientes de diversos sistemas são desfeitas. Um exemplo é o caso da codificação do gênero, onde podem existir diversas formas de representação entre os sistemas, porém, ao serem incorporados ao data warehouse, estes dados necessitam representar o mesmo fato, independente da sua codificação inicial [14]. A característica do data warehouse de ser não volátil, está ligada primeiramente a atualização dos dados, que geralmente não ocorre neste ambiente. Os dados são carregados e acessados normalmente em grandes quantidades. E as operações de processamento neste ambiente se restringem a inclusão de novos registros e consulta aos registros existentes, [14]. 16
O fato de ser variável em relação ao tempo quer dizer que os dados do data warehouse representam resultados operacionais em um determinado momento de tempo, o momento em que foram capturados da base de dados operacional. Como estes dados representam um estado da organização em um período de tempo eles não podem ser atualizados [14]. A seguir, uma figura ilustrando onde o data warehouse se enquadra no contexto dos sistemas. Figura 2 Data warehouse no contexto do sistema [15] A Figura 2 demonstra claramente onde o data warehouse encaixa-se no sistema. Primeiramente, são coletados dados de sistemas transacionais OLTP (On-Line Transaction Processing), arquivos etc., reunindo-os por meio de uma ferramenta ETL (Extraction Transformation Loading Extração, Transformação e Carga) fazendo todo o tratamento necessário nos dados para garantir sua padronização para posterior inserção na base de dados do data warehouse. O processo ETL é dividido em etapas e é responsável pela integridade, qualidade e consolidação das informações provenientes das fontes de dados até o armazenamento no data warehouse. Assim, o usuário poderá acessar os dados do data warehouse por meio de uma ferramenta Olap Analysis, onde fazem a leitura das informações do data warehouse e apresentam em front-end com a funcionalidade de manipular dimensões e hierarquias. 17
O objetivo deste trabalho não é a modelagem de um data warehouse completo para o sistema proposto no Capítulo 3, mas sim para dar sustentação ao subconjunto de dados necessários para a montagem de um data mart, para validar a hipótese do uso de OLAP no domínio da aplicação estudada. 2.4.1 Data Mart Conforme (INMON, 2005) apud [14], um data mart é uma estrutura de dados dedicada em servir as necessidades de análise de um grupo de pessoas. Segundo (LAUDON, 2007) apud [14], data mart é um subconjunto de um data warehouse, no qual uma porção resumida ou altamente focalizada dos dados da organização é colocada em um banco separado destinado a uma população específica de usuários. Neste trabalho, será realizada a modelagem de um data mart, que será o servidor de dados para alimentar um cubo OLAP, destinado para análise de um grupo de usuários do sistema. 2.4.2 Estrutura de Armazenamento Os cubos possuem suas características e elementos, assim como possuem a modelagem de suas estruturas ditando basicamente sua forma de organização e suas dimensões. Os dois modelos mais utilizados são Star Schema (esquema estrela) e Snowflake Schema (esquema flocos de neve). O modelo Star é uma representação genérica de um modelo dimensional em um banco de dados relacional em que uma tabela de fatos contendo métricas usadas para medir o desempenho do negócio e com chaves compostas é unida a várias tabelas de dimensão. É altamente desnormalizado com o intuito de reduzir o número de junções (joins) envolvido nas consultas [15]. A Figura 3 representa a estrutura da modelagem do Star Schema, este modelo está representando o armazenamento de dados em tabelas, relacionando o fato da venda com suas dimensões produto, cliente, revenda e tempo. 18
Figura 3 - Star Schema [10] O modelo Snowflake possui a diferença que as dimensões e as respectivas tabelas de dimensões são normalizadas. Esta característica garante maior organização nos dados manipulados. Segundo [15], s tipos de medidas ou métricas são aditivas, semi aditivas ou não aditivas: - Aditivas: são as mais frequentes, podem ser somadas cruzando-se qualquer uma de suas dimensões. Exemplo: lucro líquido. - Semi aditivas: podem ser somadas através de apenas uma parte de suas dimensões. Exemplo: quantidade em estoque (não faz sentido somá-la através da dimensão tempo) - Não aditivas: medidas não aditivas não podem ser somadas por nenhuma de suas dimensões. O exemplo mais comum desse tipo de medidas são valores percentuais. O modelo Snowflake é uma extensão do modelo Star, sendo o resultado da decomposição (normalização) de uma ou mais dimensões, formando hierarquias nessas dimensões. Esse tipo de modelo é usado quando há dimensões muito grandes, estáticas ou semi-estáticas. A vantagem do seu uso está na diminuição do volume de dados trazido para a memória. No entanto, caso a navegação dentro da hierarquia da dimensão seja inevitável, a maior quantidade de joins torna a consulta mais complexa [15]. A Figura 4 representa a estrutura da modelagem do Snowflake Schema, representando o armazenamento de dados em tabelas. As dimensões Revenda e Cliente estão normalizadas em relação às informações de Logradouro, Bairro, Cidade, Estado e Região. 19
Figura 4 - Snowflake Schema [10] Outro conceito importante a ser considerado ao se fazer um modelo é o da granularidade. Granularidade é o nível no qual os dados do data warehouse ou data mart estão sumarizados. O grão é o nível mais detalhado do dado. Se definir o grão num nível muito detalhado, o usuário poderá ver a informação em qualquer nível de agregação. No entanto, a escolha de um nível baixo demais pode acarretar um aumento muito grande do volume de dados armazenado e, consequentemente, o prejuízo do desempenho. Por outro lado, se a granularidade definida for muito alta, o usuário ficará impossibilitado de realizar consultas mais detalhadas, como afirma [15]. Com o objetivo de ganhar desempenho nas operações de consulta ao manipular as dimensões e hierarquias em uma ferramenta OLAP, optou-se por implementar a estrutura Star, com um conjunto de dados desnormalizados mas com um ganho de desempenho. Como as dimensões não serão grandes, não faz sentido utilizar o esquema Snowflake. 20
2.5 Ferramentas Atualmente existem no mercado diversos produtos OLAP (Analysis Services da Microsoft [17], o Cognos da IBM [18], OLAP da Oracle [19] e Pentaho [20]), os quais se diferenciam em funcionalidades, arquitetura, interfaces e impacto sobre a organização, o que pode dificultar a escolha da ferramenta OLAP mais adequada às necessidades de uma organização. Como um dos objetivos deste trabalho é não ter gastos com compra de produtos, optou-se por utilizar o pacote Pentaho, uma aplicação open source bastante utilizada na área de Business Intelligence open source, como destaca [10]. Pentaho possui um módulo chamado Pentaho Analysis, que incorpora o servidor OLAP Mondrian e o cliente OLAP JPivot. Mondrian executa consultas escritas na linguagem MDX (Multi-Dimensional Expressions), lendo dados de um banco de dados relacional, e os apresenta em um formato multidimensional utilizando-se de uma API (Application Programming Interface) Java. Além do cliente JPivot do Pentaho, existem outros clientes que interagem com o módulo servidor do Pentaho. Como exemplo, além do JPivot tem-se o JPalo [21] e PAT (Pentaho Analysis Tool) [22]. Por uma questão de usabilidade neste trabalho, ao invés de utilizar o cliente JPivot, será utilizado JPalo, que traz ao usuário final uma interface gráfica mais rica 4 e com maior facilidades na manipulação dos dados. Em [16], é apresentada uma comparação entre ferramentas Business Intelligence e constatou-se que JPalo possui vantagem nesse sentido. 4 Aplicações de Internet Rica (da sigla em inglês RIA - Rich Internet Application): são Aplicações Web que tem características e funcionalidades de softwares tradicionais do tipo Desktop. RIA típicos transferem todo o processamento da interface para o navegador da internet, porém mantém a maior parte dos dados (por exemplo, o estado do Programa, dados do banco) no servidor de aplicação. 21
Capítulo 3 Planejamento do Sistema Este capítulo tem por finalidade apresentar o levantamento de todos os requisitos que deram origem ao desenvolvimento de uma aplicação web para gerenciar as transações e atividades que envolvam os processos organizacionais do sistema de Pós-Graduação Stricto Sensu da UNIOESTE. Um dos primeiros Programas de Pós-Graduações Stricto Sensu da Unioeste, o PGEAGRI (Programa de Pós-Graduação de Engenharia Agrícola), foi utilizado para o levantamento e modelagem dos requisitos do sistema; além disso, também foram coletados requisitos com a PRPPG (Pró-Reitoria de Pesquisa e Pós-Graduação), com analistas do NTI e usuários da Secretaria Acadêmica da Universidade. A modelagem destes foi realizada de maneira a tentar atender a todos os Programas de Pós-Graduações Stricto Sensu da universidade, e também, foram criados procedimentos gerais únicos, baseados nos requisitos elicitados e validados com os usuários requerentes e especialistas no domínio da aplicação. 3.1 Resumo do Processo Atual Os processos resumem-se em inscrição, seleção, matrícula, gerência dos processos dos alunos e defesas de qualificação e defesa final. O processo se inicia com a divulgação do edital de abertura do Programa, que define as datas e prazos para as etapas de seleção do candidato. Na sequência, são realizadas as inscrições dos candidatos, os quais comparecem na Coordenação do Programa para a realização da mesma munidos dos documentos necessários para a efetivação da inscrição juntamente com o formulário de inscrição de aluno regular, formulário de carta de apresentação e formulário de anteprojeto de dissertação e tese, respectivamente preenchidos 22
(disponíveis no site de cada Programa de Pós-Graduação 5 ). De posse destes documentos, a Coordenação efetua a avaliação do candidato para ingresso no Programa de acordo com pontuações especificadas em itens de avaliação do Programa disponível no site. A Coordenação divulga a pontuação do candidato, referente ao processo de seleção. Os candidatos aprovados são convocados para realizar a matrícula junto a Secretaria Acadêmica da Universidade. Posteriormente, a matrícula é encaminhada a Coordenação para análise e homologação e retorna para a Secretaria Acadêmica. Após a efetivação da matrícula o acadêmico realiza, juntamente com um Orientador estipulado pela Coordenação, o cronograma do projeto e tarefas a serem compridas durante o Curso. A Secretaria Acadêmica tem a função de realizar a matrícula dos acadêmicos e arquivar os documentos recebidos, atender localmente requerimentos, fazer cancelamento de matrícula, emissão dos diários de classe, lançamento de notas e outros. A Coordenação realiza a inscrição, seleção e homologação da matrícula dos candidatos, organização do cronograma do acadêmico e todos os processos posteriores à etapa do processo seletivo do candidato que é a ministração de aulas pelos professores do Programa de Pós-Graduação, e todos os processos que envolvam o candidato até sua formação, passando pela qualificação e dissertação final. O problema vivenciado hoje é a demora na comunicação entre as Coordenações e a Secretaria Acadêmica no encaminhamento de formulários e declarações entre eles. Também a falta de flexibilidade para que os candidatos realizem suas inscrições, as quais são feitas somente presencialmente. Outro fator é o atendimento local de acadêmicos, que sobrecarrega a Secretaria Acadêmica. Neste contexto, propõe-se a construção de um sistema web para atender todos os usuários do sistema e a centralização dos dados em um SGBD (Sistema Gerenciador de Banco de Dados), facilitando o acesso e comunicação por todos os usuários. 3.2 A Solução Proposta O sistema proposto tem por finalidade otimizar a comunicação entre seus usuários, fazendo este um meio onde todos os usuários possam ter acesso centralizado às informações 5 Vide, por exemplo, o site do PGEAGRI: www.unioeste.br/pgeagri/ 23
do sistema. Uma solução é a implantação de um sistema web para a gerência dos processos das Pós-Graduações Stricto Sensu. A seguir, nas Figuras 5 e 6, são apresentados e detalhados os Requisitos Funcionais e Não-Funcionais do sistema proposto. Também, na Figura 7, os Casos de Uso utilizando o padrão UML (Unified Modeling Language) que facilita a visualização no processo de Engenharia de Requisitos e auxilia em um melhor planejamento do projeto em geral. Os requisitos funcionais de um sistema descrevem diversas funções que a instituição e usuários do sistema almejam que o software ofereça. Nesta primeira parte são descritos os requisitos funcionais do sistema de forma geral, e posteriormente, são detalhados nos Casos de Uso do sistema. O sistema envolve os seguintes tipos de usuário: Coordenação, Secretaria Acadêmica, Acadêmico, PRPPG, Professor, Orientador e Candidato, onde cada um terá um nível de acesso delimitado de acordo com as características que cada usuário necessita para trabalhar no sistema. Quando o requisito é nomeado como gerenciar, refere-se à inclusão, edição, exclusão e pesquisa no sistema. Os requisitos funcionais são listados no Apêndice A. A Figura 5 ilustra os requisitos funcionais do sistema através da técnica i*, utilizando o modelo SD (Modelo de Dependências Estratégicas), onde pode-se visualizar as interações que ocorrem a partir de um ator que tem uma meta e espera um resultado. O diagrama SD ilustra os oito atores do sistema interagindo, o Coordenador, o Sistema, o Orientador, o Acadêmico, o Candidato, a Secretaria Acadêmica, a PRPPG (Pró-Reitoria de Pesquisa e Pós- Graduação) e o Professor. Destes, o Sistema é o ator que gerencia todas as metas. 24
Figura 5 - Modelo SD (Dependências Estratégicas) 25
Os requisitos não-funcionais referem-se a aspectos não-funcionais do sistema, como restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. O sistema está dividido nos seguintes requisitos não-funcionais: desempenho, segurança, usabilidade e custo. No Apêndice B esses requisitos são listados. A seguir, o Diagrama NFR (Non- Functional Requirements in Software Engineering) ilustra os requisitos não-funcionais. Figura 6 Diagrama de Requisitos Não-Funcionais Os estados marcados com os símbolos de aceitação como ilustra a legenda da figura, serão garantidos ou atendidos na implementação do sistema, já os rejeitados, marcados com um X, talvez não possam ser garantidos na implementação do sistema. O desempenho será garantido pela velocidade da rede, aplicação Java web e sistema gerenciador de banco de dados SQL Server, onde os três itens supracitados estão disponíveis na Universidade. A estrutura de rede hoje disponível na UNIOESTE é nova e já atende adequadamente a outros sistemas em funcionamento. Por se utilizar Java web, o custo do sistema fica reduzido e, como a Universidade já possui licença do SGBD (Sistema Gerenciador de Banco de Dados) SQL Server [23], o seu uso não acarretará custos extras. 26
Quanto ao espaço disponível para a aplicação também é garantido pela base de dados SQL Server escalonável. Quanto à segurança, tem-se a disponibilidade, integridade e confidencialidade, que serão todas garantidas. O acesso a qualquer hora é possível pela boa estrutura de rede disponível atualmente juntamente com os novos servidores e o sistema será web, facilitando a disponibilidade da aplicação para vários usuários. Para garantir integridade será utilizado um SGBD SQL Server, concentrando os dados da aplicação em uma única base de dados. Já a confidencialidade será garantida através da autenticação dos usuários que terão acesso ao sistema através de uma senha previamente criptografada. Quanto a usabilidade, o sistema terá interfaces padrões para que o usuário tenha maior facilidade no entendimento dos comandos do sistema. Para o desenvolvimento do sistema, foram elaborados previamente os casos de uso para cada funcionalidade pertencente ao sistema. O caso de uso descreve os passos necessários que os atores necessitam para cumprir uma determinada função no sistema. Os casos de uso são listados no Apêndice C. A seguir, será apresentado o Diagrama de Casos de Uso onde ilustra os atores do sistema com suas respectivas funções. Um Diagrama de Caso de Uso descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. É nele que o cliente vê as principais funcionalidades de seu sistema. Na Figura 7, os bonecos estão representando os atores do sistema, as elipses o caso de uso, e entre o ator e a elipse a uma ligação representando as funções do ator no sistema. 27
Figura 7 - Diagrama de Casos de Uso 28
Para melhor compreensão de todos estes requisitos, foram elaborados diagramas no padrão BPMN (Business Process Modeling Notation) [24], uma notação da metodologia de gerenciamento de processos de negócio. Trata-se de uma série de ícones para o desenho de processos, o que facilita o entendimento do usuário. A seguir são apresentados os Diagramas de Processos do sistema proposto. Figura 8 - Diagrama de Funções dos Atores do Sistema 29
No diagrama apresentado na Figura 8, cada ator tem suas funções específicas e, através de uma gerencia de login pode-se identificar qual o tipo de usuário que está acessando o sistema e disponibilizar as funções que lhe são designadas. Se o estado realizar login for bem sucedido, o usuário tem acesso às funções do sistema. Se o usuário for do tipo PRPPG ele terá acesso às opções de cadastro de Programa, nível, disciplina, área de concentração e linha de pesquisa. Caso seja do tipo Acadêmico terá acesso a consultar nota e frequência em disciplina, realizar plano de estudo, realizar matrícula e matricular-se em disciplina. Caso o usuário seja do tipo Coordenação, terá acesso a cadastro de cronograma, etapa, gerência de inscrições e disciplinas. Se o usuário for do tipo Professor, poderá lançar nota e frequência das disciplinas do Acadêmico. Se for do tipo Orientador, terá acesso a validação do plano de estudo do Acadêmico. E por último, caso o usuário seja do tipo Secretaria Acadêmica, poderá realizar a gerência de matrículas, acompanhar o estado do acadêmico no curso e emitir relatórios e declarações. Para realizar inscrição não é preciso fazer login no sistema e esta opção é realizada apenas pelo usuário Candidato. A seguir, são apresentados diagramas com a especificação das funções dos atores. O diagrama da Figura 9 ilustra a representação da gerência de cronograma e as etapas de cada cronograma que são gerenciadas pelo ator Coordenação. É possível realizar o cadastro, edição, exclusão e pesquisa de cronogramas e para cada cronograma pode-se adicionar etapas, onde cada etapa pode ser cadastrada, editada e excluída. 30
Figura 9 - Diagrama de Processo da Gerência de Cronograma e Etapa No diagrama da Figura 10, ilustra a representação da gerência de Programa, nível e disciplina pelo usuário PRPPG. É possível realizar o cadastro, edição, exclusão e pesquisa de programas e para cada Programa pode-se adicionar níveis (mestrado ou doutorado) e disciplinas, podendo também cadastrar, editar e excluir níveis e disciplinas. 31
Figura 10 - Diagrama de Processo da Gerência de Programa, Nível e Disciplina No diagrama da Figura 11, é ilustrada a representação da gerência de Área de Concentração e Linha de Pesquisa pelo usuário PRPPG. É possível realizar o cadastro, edição, exclusão e pesquisa de Área de Concentração e, para cada Área de Concentração, pode-se adicionar Linha de Pesquisa, com as opções de cadastrar, editar e excluir Linha de Pesquisa. 32
Figura 11 - Diagrama de Processo da Gerência de Áreas e Linha de Pesquisa O diagrama da Figura 12 ilustra a representação da gerência de oferta de disciplinas pelo usuário Coordenação. Seleciona-se um Programa, um nível pertencente ao Programa, um cronograma do nível e uma etapa do tipo matrícula em disciplina. Posteriormente, escolhe-se disciplinas para serem ofertadas e estipula-se o número de vagas. Também pode ser realizada a exclusão de uma oferta de disciplina. Figura 12 - Diagrama de Processo da Gerência de Oferta de Disciplina 33
O diagrama da Figura 13 ilustra a representação da gerência de inscrição regular pelo usuário Coordenação e Candidato. Seleciona-se um Programa, um nível pertencente a este, um cronograma do nível e uma etapa do tipo inscrição regular. Posteriormente, no caso do usuário Candidato, é preenchido o formulário com dados solicitados e realizada a inscrição. No caso do usuário Coordenação, seleciona-se um candidato e o classifica ou edita os seus dados cadastrais. Figura 13 - Diagrama de Processo da Gerência das Inscrições Regulares O diagrama da Figura 14 traz a representação da gerência de inscrição especial pelo usuário Coordenação e Candidato. Seleciona-se um Programa, um nível, um cronograma do nível e uma etapa do tipo inscrição especial. Posteriormente, no caso do usuário Candidato, preenche-se o formulário com dados solicitados e realiza a inscrição. No caso do usuário Coordenação, seleciona-se um candidato e o classifica ou edita seus dados cadastrais. 34
Figura 14 - Diagrama de Processo da Gerência das Inscrições Especiais No diagrama da Figura 15, a representação da matrícula em disciplina pelo usuário Acadêmico é apresentada. Seleciona-se um cronograma e o Acadêmico efetua matricula em uma disciplina. Também é possível fazer o cancelamento da matrícula. Figura 15 - Diagrama de Processo da Gerência Matrícula em Disciplina No diagrama da Figura 16, a representação do lançamento de notas e frequência pelo usuário Professor é exibida. Seleciona-se uma disciplina ofertada, após, um Acadêmico nela matriculado e faz-se o lançamento da nota e frequência. 35
Figura 16 - Diagrama de Processo do Lançamento de Notas e Frequência O próximo capítulo abarca uma descrição de como o sistema foi planejado e implementado, explicitando algumas decisões de projeto, além das tecnologias utilizadas para a implementação de parte dos requisitos documentados. Aborda também a descrição da proposta inicial de um módulo OLAP integrado ao sistema. 36
Capítulo 4 Estrutura do Sistema Com o aumento da complexidade das aplicações, torna-se relevante a separação entre os dados e a apresentação das aplicações, de forma que alterações feitas no layout não afetem a manipulação de dados, o que se torna possível dividindo a implementação em camadas. Estas camadas do sistema serão abordadas em tópicos para sua melhor divisão e compreensão. Também nesse capítulo, há a descrição do módulo OLAP integrado ao sistema. A Figura 17 ilustra as camadas do sistema. A primeira é a camada de dados, onde está a base de dados. Já a camada intermediária, a camada de aplicação, concentra-se as regras de negócio do sistema, fazendo a comunicação entre as solicitações da camada de apresentação e busca de informações na camada de dados. A terceira camada, de apresentação, comporta as interfaces gráficas do sistema, ou seja, o nível de interação com o usuário final com o sistema. Figura 17 - Camadas do Sistema A título de ilustração a Figura 18 apresenta um Diagrama de Classes (parcial) do sistema, demonstrando que o seu desenvolvimento foi estruturado em camadas, divididas em pacotes. 37
Figura 18 - Diagrama de Classe organizado em camadas e pacotes do sistema 38
No Diagrama de Casses da Figura 18 estão representados os pacotes, separando fisicamente os códigos-fonte de cada camada. Cada pacote comporta as suas respectivas classes. Este diagrama de classes ilustra um subconjunto de classes do projeto completo, pois neste há a representação de somente dois tipos de objetos, o objeto Programa e Cronograma, onde um Programa pode conter diversos Cronogramas por meio do relacionamento um para muitos representado no diagrama. O pacote Model, armazena todas as representações orientadas a objeto das tabelas do Modelo Relacional, em seguida, no pacote Dao, é armazenada toda a lógica de acesso a base de dados, como consultas de inserção, edição, exclusão e pesquisa de dados. As classes do pacote Dao, estendem a classe GenericDao, do pacote Sharedev, fazendo com que a classes do pacote Dao, contenham os métodos da classe GenercDao. O pacote Controller, diz quais métodos estão disponíveis para acesso da interface gráfica, que está representada através dos pacotes Tela de Cadastro e Tela de Pesquisa, onde cada classe destes pacotes estendem de classes do pacote Util, que são componentes de interface gráfica que podem ser reaproveitados através da extensão. A construção do software baseou-se nos casos de uso. Foram implementados os casos de uso de 1 a 37, de 73 a 90, 107 e 108. A seguir, é dada a descrição das camadas do sistema. 4.1 Camada de Dados A camada de dados é usada para definir e gerenciar o domínio da informação e notificar observadores sobre mudanças nos dados. Ele é uma representação detalhada da informação que a aplicação opera. Utilizou-se para o mapeamento do projeto uma estrutura de base de dados relacional, o MR (Modelo Relacional), que traz em sua modelagem a view, uma maneira alternativa de observação de dados de uma ou mais entidades, e que está sendo utilizada para acesso a informações de outras bases de dados como a tabela Pessoa Física que está localizada em outra base de dados, necessitando assim uma view da tabela Pessoa Física para acesso às informações da mesma. Com isso, consegue-se acesso às tabelas das bases de dados da Universidade, quando necessário. A Figura 19 exibe o MR representando a lógica relacional do SGBD, com suas tabelas e ligações entre elas, fazendo as regras de cardinalidade, que são tratadas pelo SGBD na 39
forma de chaves primárias e estrangeiras. As tabelas representadas como view estão destacadas em tom de cinza no diagrama. Este modelo relacional foi criado fisicamente no SQL Server, SGBD adotado pela Universidade. Camadas de mapeamento objeto-relacionais são alternativas bastante utilizadas quando da utilização de SGBDs Relacionais em aplicações orientadas a objetos. Como a camada de aplicação utiliza linguagem de programação orientada a objetos, optou-se por utilizar o framework hibernate [27] para o mapeamento das tabelas da base de dados para a camada de aplicação de forma a trabalhar com orientação a objetos na camada de aplicação e, também, com a separação da camada de dados com a de aplicação. 40
Figura 19 - Diagrama Relacional 41
4.2 Camada de Aplicação É na camada de aplicação que as regras de negócio são inseridas e tratadas. Esta camada se comunica com a camada de apresentação e de dados. Faz a comunicação entre uma solicitação da camada de apresentação, acessa a informação na camada de dado e retorna o objeto para a camada solicitante. Para esta comunicação utiliza-se o VRaptor [26], um framework que faz a comunicação entre a camada de aplicação e apresentação. Tarefas como salvar, remover, buscar e atualizar ou ainda, funcionalidades que costumam ser mais complexas como upload e download de arquivos, resultados em formatos diferentes (xml, json, xhtml, etc), são feitas através de funcionalidades do VRaptor, que encapsulam classes HttpServletRequest, Response, Session e toda a API do javax.servlet, facilitando a chamada de métodos e a interceptação dos mesmos. As classes com o rótulo Controller em seu nome contém a lógica de negócio do sistema. A Figura 20 traz um exemplo de uma classe na camada de aplicação utilizando o VRaptor. 42
Figura 20 - Modelo de Classe da Camada de Aplicação A Figura 20 mostra que o VRaptor faz várias associações para as URI (Uniform Resource Identifier) e, por padrão, a chamada /Programa/adiciona(parâmetro) irá invocar o método adiciona() da classe ProgramaController, passando por parâmetro no método o objeto Programa. Desta forma, VRaptor auxilia a comunicação entre as camadas do sistema, fazendo a interação entre elas. 4.3 Camada de Apresentação Esta camada é onde se implementa a visão do sistema, onde o usuário final poderá interagir com o software. Para apoiar este desenvolvimento utiliza-se o framework Ext JS 6, baseado em JavaScript com componentes para interfaces gráficas. Uma vantagem do Ext JS é 6 http://www.sencha.com/products/extjs 43
como está organizada sua estrutura, podendo facilmente estender um componente padrão para atender às necessidades e extensões. Na Figura 21 é ilustrado um exemplo de como são organizados os componentes do Ext JS. A estrutura funciona da seguinte forma: Panel estende Component e Tab Panel estende Panel e assim, consecutivamente. Desta forma, pode-se criar outros componentes e estender de qualquer outro Componente da biblioteca Ext JS. Figura 21 - Arquitetura dos Componentes Ext JS Ext JS conta com uma interface rica, trazendo para o usuário final requisitos nãofuncionais como a usabilidade. A Figura 22 exibe a página principal do sistema desenvolvido. Figura 22 - Página principal do sistema 44
Através da página principal do sistema, pode-se acessar o módulo OLAP (explicado a seguir), abrindo uma nova janela no browser do usuário. 4.4 Módulo OLAP O módulo OLAP iniciado tem por objetivo disponibilizar ao usuário final acesso as informações da base de dados para construir relatórios capazes de responder ou apoiar a suas questões gerenciais e proporcionando condições de análise para auxiliar a tomada de decisão. Traz a dinâmica de poder filtrar dados e dá a possibilidade da observação em múltiplas dimensões. No contexto do sistema em questão, a tomada de decisão está centrada na análise das disciplinas matriculadas pelos acadêmicos, viabilizando análise da situação do acadêmico perante a nota e frequência na disciplina, realizando filtros por Programas e níveis. Um exemplo de análise poderia ser a comparação do conceito do Programa em um determinado período com as notas em disciplinas de seus alunos no mesmo período. A base de dados comporta a modelagem star schema, onde terão seus dados carregados pela modelagem relacional do sistema através de ferramentas ETL, responsável pela carga inicial e pelas atualizações periódicas dos dados no data warehouse, sendo que a periodicidade das atualizações deverá considerar o volume de dados e de processamento envolvido. Esta modelagem se constitui basicamente de dois tipos de tabela, fato e dimensão, categorizando o esquema estrela. Como mencionado no Capítulo 2, no star schema a representação do modelo dimensional é em bancos de dados relacionais. Neste esquema existe uma tabela dominante no centro do esquema, a tabela fato. Esta é a única tabela com múltiplos relacionamentos para as outras tabelas. As outras tabelas possuem um único relacionamento para a tabela central, e são as tabelas que caracterizam as dimensões. A Figura 23 ilustra o star schema do sistema proposto. 45
Figura 23 - Star Schema do Sistema Proposto A Figura 23 apresenta a tabela fato PerfilAcademico com suas medidas MediaNotas e MediaFrequencia. Traz também, chaves estrangeiras, que são os relacionamentos entre as tabelas dimensões. As dimensões Acadêmico, Disciplina e Programa contêm os dados da base de dados relacional. Para a importação dos dados para esta estrutura, utilizou-se da ferramenta Kettle [25] pertencente ao pacote Pentaho, com a qual se pode realizar diversas regras em SQL para a busca de informações na base de dados relacional e a persistência dos dados no modelo star schema. Neste caso, as importações foram realizadas de uma base de dados relacional, necessitando somente o carregamento dos dados para o modelo estrela. Este é apenas um caso pequeno, mostrando como é possível realizar a montagem da base dos cubos e o carregamento de dados do Modelo Relacional para o star schema. Contudo futuramente o sistema poderá haver vários cubos (cenários), cada um representando um data mart. Para trabalhar com um modelo de dados customizado no Pentaho é necessário criar um arquivo de configuração do Cubo para o servidor de aplicação Mondrian, chamado Mondrian Cube Schema File, que conterá as definições do cubo OLAP. Este arquivo descreve as estruturas das dimensões, hierarquias e fato, e os mapeia com o modelo relacional. 46
O Mondrian Cube Schema é um arquivo XML, que pode ser criado manualmente. Porém, por esta tarefa ser demorada, recomenda-se a utilização de uma ferramenta para isto, como a Mondrian Schema Workbench, que permite criar e testar o mapeamento de um cubo visualmente. O motor do Mondrian é o responsável por processar consultas MDX baseandose no modelo do arquivo Mondrian Cube Schema gerado pelo Mondrian Schema Workbench. A comunicação entre as camadas do módulo OLAP se faz por meio de consultas MDX, onde o servidor Mondrian se encarrega de interpretá-las, carregar os dados da base star schema e encaminha-las para a camada de apresentação. O módulo OLAP é responsável por comunicar-se com a base de dados do data warehouse e disponibilizar ao usuário final a dinamicidade de manipulação dos dados histórico do sistema. Para isso, é necessário, metadados e ferramentas de acesso aos dados, possibilitando consultas ad hoc e relatórios específicos. Consultas ad hoc são consultas circunstanciais, não programadas, pertinentes a um determinado momento da análise. Para alcançar este objetivo utilizou-se a ferramenta JPalo, responsável pela comunicação com o servidor Mondrian do Pentaho e a interpretação das consultas multidimensionais MDX para apresentar na interface gráfica as dimensões e funcionalidade de manipulação das dimensões. A Figura 24 ilustra a interface do JPalo. Figura 24 - Interface JPalo para o Cubo 47