Banco de Dados Gerenciais

Transcrição

1 ANA KARINA DE OLIVEIRA ROCHA ELMANO RAMALHO CAVALCANTI SÉRGIO CAVALCANTI DE PAIVA Banco de Dados Gerenciais Monografia submetida ao Professor Dr. Ulrich Schiel da disciplina de Modelos de Dados do Curso de Pós-Graduação em Informática da Universidade Federal de Campina Grande. Área de concentração: Ciência da Computação Linha de Pesquisa: Banco de Dados Campina Grande PB Maio de

2 SUMÁRIO 1. INTRODUÇÃO MOTIVAÇÃO FUNDAMENTAÇÃO TEÓRICA Conceitos Dado x Informação Sistemas de Informações Data Warehouse Data Mart Arquitetura do Data Warehouse Sistemas de Suporte à Decisão Business Intelligence Modelagem de Dados Banco de Dados Relacional Banco de Dados Multidimensional Análise Multidimensional OLTP OLAP Operações OLAP Modelagem Dimensional dos Dados Metadados Ferramentas CASE (Computer Aided Software Engineering) SQL Indexação XML XMLA Aspectos na construção de um Data Warehouse

3 Planejamento Necessidades das Empresas Tipos de Sistemas de Informações na Empresa Motivação da Empresa no Mercado Necessidades e Benefícios para o Usuário Perfil do Usuário na Empresa que Utiliza o Data Warehouse Análise do Ambiente Legado Equipe de Desenvolvedores Aspectos da Implementação Física (ROLAP/MOLAP) Performance APLICAÇÃO Informação Modelo Meta-Modelo Meta-meta Modelo Modelagem Interna Diagrama Entidade Relacionamento Relacionamento entre Entidades Tabela do Banco de Dados Relacional Tabelas (ou relações, ou entidades) Modelagem Externa Esquema estrela Cubo Recuperação da informação CONCLUSÃO REFERÊNCIAS Apêndice A A.1 Estrutura A.2 Consultas MDX

4 LISTA DE FIGURAS Figura 1: Arquitetura do sistema de DW Figura 2: Arquitetura em camadas Figura 3: Granularidade em camadas Figura 4: Exemplo de Drill-down e Roll-up Figura 5: Exemplo de Slice Figura 6: Exemplo de um Cubo Dimensional Figura 7: Exemplo de uma Estrutura Star Schema Figura 8: Exemplo de uma Estrutura Snow-Flake Figura 9: Tipos de Sistemas de Informação (Laudon e Laudon 1998) Figura 10: Arquitetura do servidor OLAP utilizada Figura 11: Diagrama de Objeto Figura 12: Diagrama de Classe Figura 13: Modelo Entidade Relacionamento Figura 14: Relacionamento entre Entidades Figura 15: Tabela no Banco de Dados Relacional Figura 16: Esboço do esquema estrela Figura 17: Esquema estrela da BD dimensional Figura 18: Povoamento do banco de dados Figura 19: Recuperação da informação Figura 20: Avaliação dos Projetos por Departamento

5 LISTA DE TABELAS Tabela 1: Comparação do Modelo OLTP com OLAP Tabela 2: Relatório dos projetos por área temática e tempo Tabela 3: Arquitetura ANSI/SPARQ

6 LISTA DE SIGLAS E ABREVIATURAS DSS EIS IDC DW OLAP SGBD MER DER SGBDR SQL OLTP ROLAP HOLAP MOLAP WOLAP DM RDBMS CASE DDL DML DCL ISO ANSI NIST Decision Support Systems Executive Information System International Data Corporation Data warehouse Online Analytical Processing Sistema Gerenciador de Banco de Dados Modelo Entidade-Relacionamento Diagrama Entidade-Relacionamento Sistema Gerenciador de Banco de Dados Relacional Structured Query Language Online Transaction Processing Relacional OLAP Híbrido OLAP Multidimensional OLAP Web OLAP Dimensional Modeling Relational Data Base Management System Computer Aided Software Engineering Data Definition Language Data Manipulation Language DIGITAL Command Language International Organization for Standardization American National Standards Institute National Institute of Standards and Technology 6

7 FIPS RPC IMS VSAM W3C SGML HTML DTDs XML XMLA MDX Federal Information Processing Standards Remote Procedure Call Information Management System Virtual Storage Access Method World Wide Web Consortium Standard Generalized Markup Language HyperText Markup Language Document Type Definitions extensible Markup Language XML for Analysis Multidimensional Expressions 7

8 1. INTRODUÇÃO A disseminação e o aperfeiçoamento dos produtos e metodologias para suporte dos bancos de dados gerenciais têm ocupado uma posição de destaque no cenário internacional, devido às pressões dos tempos modernos, as sucessivas reestruturações das organizações, e a necessidade cada vez maior de informações. Estes fatores tornam crítica a capacidade de gestão dos negócios, pois os métodos tradicionais de acesso e de análise dos dados, baseados na tecnologia de bancos de dados relacionais, embora consigam pesquisar e manipular grandes volumes de dados, ainda não permite analisar e entender, em tempo hábil, um imenso volume de dados [30]. Diante disto, surge o problema de supersaturação do mundo dos negócios, quando a obtenção de informações úteis sobre um grande volume de dados ultrapassa a capacidade de analisá-los. Assim, uma nova geração de técnicas, produtos e serviços que permitam a extração e manipulação automatizada de dados e descoberta de conhecimento, faz-se necessária. Neste contexto, vamos estudar um ambiente com informações consistentes e precisas, obtidas das mais variadas fontes de dados, representando uma nova maneira de visualizar a organização em âmbito estratégico e estrutural para suporte a decisão e compartilhamento de informações que é conhecido como Data warehouse. Na seção 4 realizaremos a modelagem de um sistema gerencial de acompanhamento de projetos acadêmicos, usando os conceitos de data warehouse. Em seguida, criaremos uma base de dados de teste e utilizaremos ferramentas OLAP para a verificação do sistema. 8

9 2. MOTIVAÇÃO O Data warehouse nasceu a partir do reconhecimento da importância do valor da informação nas organizações. Ele é um ambiente expansível e planejado para a análise de dados não voláteis. Estes dados são logicamente e fisicamente transformados, provenientes de múltiplas aplicações, atualizados e mantidos por um longo período de tempo, expressos em termos do negócio e resumidos para uma análise eficiente. Assim, um data warehouse é uma plataforma com dados integrados e qualidade melhorada para apoiar vários DSS (Sistema de Apoio de Decisão), aplicações de EIS (Sistema de Informação Executiva) e processos empresariais [15]. Em termos tecnológicos, um data warehouse é uma combinação de várias tecnologias, tendo como primeiro objetivo à integração efetiva de bases de dados operacionais em um ambiente que habilita o uso estratégico dos dados. Estas tecnologias incluem sistemas gerenciadores de banco de dados relacional e multidimensional, arquitetura cliente/servidor, modelagem de metadados e repositórios, interfaces gráficas para usuário, etc. Pode-se explicar a motivação para a construção de um data warehouse através de alguns pontos importantes citados pela IDC (International Data Corporation), que são [15]: A habilidade em focalizar processos empresariais e efetuar uma análise financeira completa destes processos, assim como permitir as organizações tomarem decisões baseadas na compreensão do sistema como um todo ao invés de fazer estimativas duvidosas fundadas sobre dados incompletos. A habilidade em racionalizar e automatizar o processo de construção de um repositório de informações integradas para uma empresa ao invés de desenvolver inúmeros sistemas de apoio à decisão e sua infraestrutura correspondente. O preço do hardware e do software, bem como os custos de armazenamentos relacionados ao desenvolvimento, organização (deployment), 9

10 e manutenção de grandes repositórios de dados estão continuamente diminuindo. Os benefícios de um data warehouse podem ser facilmente estendidos à tomada de decisões estratégicas, que podem trazer grandes e tangíveis benefícios. A habilidade em entender e administrar simultaneamente macro e micro perspectivas de uma organização, que pode economizar incontáveis horas de trabalho manual das organizações e pode ajudar a evitar cometer enganos dispendiosos, que podem ser o resultado de suposições feitas sobre dados incompletos ou incorretos. 10

11 3. FUNDAMENTAÇÃO TEÓRICA 3.1 Conceitos Dado x Informação Dado é um registro de fatos, conceitos ou instruções para a comunicação, recuperação e processamento por meios automáticos e apresentação na forma de informação compreensível para os seres humanos. Informações são dados que os seres humanos assimilam e validam para resolver problemas ou tomar decisões [13]. Dados são os componentes básicos, a partir dos quais a informação é criada. Informações são dados inseridos em um contexto. Contexto é a situação que está sendo analisada. A partir da informação vem o conhecimento, que permite tomar decisões adequadas, trazendo vantagem competitiva [18] Sistemas de Informações Segundo Mallack (2000), sistema de informações é um sistema que tem como propósito armazenar, processar e compartilhar informações. Lesca (1996) define sistema de informações como o conjunto interdependente das pessoas, da estrutura organizacional, das tecnologias de informação, dos procedimentos e métodos, que disponibilizam em tempo hábil, as organizações as informações necessárias para o seu funcionamento atual e para sua evolução. Já Laudon e Laudon (1998), definem sistema de informações como um conjunto de componentes inter-relacionados que coleta (ou recupera), processa, armazena e distribui informações para suporte ao controle e tomada de decisões nas organizações. Analisando-se as definições acima, conclui-se que o sistema de informações, na sua forma final, aborda todos os componentes da organização. 11

12 Neste sentido, busca-se um ambiente que forneça informações internas, informações externas, informações sobre as percepções do consumidor/cliente, que permite análises e simulações, enfim, um ambiente integrador das informações disponíveis e relevantes para o sucesso da empresa. [29]. Assim, o SI é um sistema a serviço da organização e de seus objetivos, devendo ser coerente e coordenado com todos os aspectos da organização Data Warehouse Data warehouse (armazém de dados) é um ambiente com informações consistentes e precisas, obtidas das mais variadas fontes de dados, representando uma nova maneira de visualizar a organização em âmbito estratégico e estrutural para suporte a decisão e compartilhamento de informações [2]. Ele apresenta as seguintes características básicas: Orientado por temas: Refere-se ao fato do DW armazenar informações sobre temas específicos importantes para o negocio da empresa. Exemplos típicos de temas são produtos, atividades contas, clientes, etc. Em contrapartida, o ambiente operacional é organizado por aplicações funcionais. Por exemplo, em uma organização bancária, estas aplicações incluem empréstimos, investimentos e seguros. [13]. Integrado: A integração mostra-se em muitas diferentes maneiras: na consistência e padronização de nomes, das unidades das variáveis, etc., no sentido de que os dados foram transformados até um estado uniforme. Por exemplo, considere-se sexo como um elemento de dado. Uma aplicação pode codificar sexo como M/F, outra como 1/0 e uma terceira como H/M. Conforme os dados são trazidos para o DW, eles são convertidos para um estado uniforme, ou seja, sexo é codificado apenas de uma forma. [13] Não Volátil: Atualizações (inclusão exclusão e alteração) são feitas regularmente no ambiente operacional de um registro básico. Mas a manipulação de dados básicos que ocorre no data warehouse é mais simples. Tem somente três espécies de operações que ocorrem no data warehouse: a carga inicial do dado, o acesso ao dado e atualização temporal (semanal, mensal) conforme necessidades do negócio [13]. 12

13 Histórico: Todo dado no data warehouse é exato em algum momento do tempo e em conseqüência desta informação, o dado criado no warehouse é dito ser "histórico". Os valores históricos dos dados no data warehouse são mostrados em várias maneiras. O modo mais simples é que o dado no data warehouse representa os dados sobre um horizonte de tempo distante - de 5 até 10 anos [13]. Uma coleção de bancos de dados integrados e orientados a assuntos projetados para apoiar as funções de um Sistema de Apoio de Decisão (Decision Support Systems); onde cada unidade de dados é importante em um momento no tempo. O data warehouse contém dados atômicos e muitas vezes sumarizados [13]. Data warehouse é uma arquitetura de banco de dados com informações de caráter gerencial voltado para: suporte à decisão, planejamento estratégico, análise do comportamento de clientes e análise da performance de vendas. Funciona como um provedor de informações de uma empresa ou instituição, pois concentra todas as informações estratégicas e históricas, extraídas dos sistemas transacionais relativos aos clientes e produtos. A proposta principal do data warehouse é a democratização das informações para a área de negócios, através do fácil acesso aos dados para análise [1] Data Mart Um data mart (mercado de dados) não é uma evolução de um data warehouse, mas sim parte das estratégias deste. Um data mart é um subconjunto de dados de um data warehouse, desenhado para suportar uma necessidade de negócio ou uma unidade organizacional específica. A estratégia correta é fazer o data mart incorporar-se à arquitetura de data warehouse, sem perder a visão de conjunto. Essa visão de conjunto é decorrência de um bom projeto de data warehouse [25]. O data mart é similar ao data warehouse com algumas exceções: O data mart opera um conjunto menor de dados. O data mart visualiza o dados com um enfoque departamental enquanto o data warehouse visualiza os dados com um enfoque corporativo. 13

14 O data mart visualiza os dados em uma base muito mais previsível enquanto o data warehouse freqüentemente faz exploração na base de dados. Características comuns ao data warehouse e data mart são: informação estrutural, fonte de informação e outras informações encontradas ao longo do ambiente [13]. Obedece aos mesmos conceitos do data warehouse, diferenciando-se somente no conteúdo, ou seja, os dados são organizados por assunto, permitindo maior independência, agilidade e ganhos de performance [26] Arquitetura do Data Warehouse Podemos definir duas formas de apresentação da arquitetura de DWs, uma conceitual e outra física do modelo relacional que representa o sistema Visão Conceitual Figura 1: Arquitetura do sistema de DW Além do DW podem existir vários Data Marts (DMs), que separam os dados por setor dentro da organização. 14

15 Os dados contidos no DW e nos DMs são gerenciados por um ou mais servidores de warehouse, os quais apresenta visões multidimensionais dos dados para uma variedade de ferramentas front end. A visão multidimensional em forma de cubo de dados indica que as informações são visualizadas em linhas e colunas como o formato tradicional das planilhas, porém existem mais dimensões, sendo que o cubo teria apenas mais uma dimensão. Esta característica organiza e facilita a consulta aos dados de maneira que se pode ter, por exemplo, numa dimensão do cubo os meses do ano, na segunda dimensão estariam as cidades de origem dos clientes e na terceira dimensão o médico que encaminhou o cliente para o hospital [42] Visão em Camadas Camada de Bancos de Dados Operacionais e Fontes Externas: contém as bases de dados operacionais e também pode ser composta de informações de fontes externas, estes dados recebem um tratamento especial para poderem ser incorporados ao DW [42]. 15

16 Figura 2: Arquitetura em camadas Camada de Acesso aos Dados: compõe o elo de ligação entre as ferramentas de acesso à informação e os bancos de dados operacionais, comunicando-se com diversos Sistemas de Gerenciamento de Banco de Dados (SGBDs) e sistemas de arquivos, sendo que a este conjunto de características dá-se o nome de acesso universal de dados [42]. Camada de Transporte ou Middleware: tem a função de gerenciar a transmissão das informações pelo ambiente de rede que serve de suporte para o sistema como um todo, separando as aplicações operacionais do formato real dos dados, realiza ainda a coleta de mensagens e transações e se encarrega de entregá-las nos locais e nos tempos determinados [42]. Camada do Data Warehouse: constitui-se do armazenamento físico dos dados oriundos dos sistemas operacionais da empresa e externos, permitindo um acesso mais rápido e seguro aos dados do DW, além de prover maior flexibilidade de tratamento e facilidade manipulação [42]. Camada de Acesso à Informação: proporciona a interação com os usuários finais através de ferramentas visuais tradicionais, tais como sistemas de planilhas de cálculo, browsers, entre outras [42]. 16

17 Camada de Metadados (Dicionário de Dados): os metadados descrevem os dados e a organização do sistema, podem ser ainda fórmulas utilizadas para cálculo, descrições das tabelas disponíveis aos usuários, descrições dos campos das tabelas, permissões de acesso, informações sobre os administradores do sistema, entre outras [42]. Camada de Gerenciamento de Processos: faz o controle destas tarefas que mantêm o sistema atualizado e consistente, gerenciando as diversas tarefas que são realizadas durante a construção e a manutenção dos componentes de um sistema de DW [42]. Camada de Gerenciamento de Replicação: serve para selecionar, editar, resumir, combinar e carregar no DW as informações a partir das bases operacionais e das fontes externas, envolvendo programação bastante complexa, sendo que existem ferramentas poderosas que permitem processos sejam gerenciados de forma mais amigável, além do controle da qualidade dos dados que serão carregados [42] Estrutura Física dos Dados do DW A respeito da disposição física dos dados, o DW pode ter uma estrutura centralizada em um único local ou então ser implementado de forma distribuída. Se optarmos pelo primeiro modelo, o centralizado, teremos um warehouse consolidado e o Banco de Dados (BD) formará um DW integrado. Definindo o projeto desta forma pode-se maximizar o poder de processamento e acelerar os processos de busca por informações analíticas. Definindo-se uma arquitetura federativa, pode-se distribuir a informação por função, separando os dados do setor financeiro em um servidor, os dados de marketing em outro local, e dados de manufatura em um terceiro lugar. Existe ainda uma terceira metodologia, na qual considera-se uma arquitetura de DW separada por camadas, armazenando os dados mais resumidos em um servidor, dispondo os dados um pouco mais detalhados, em nível de detalhe intermediário, em um segundo servidor, e por fim colocamos os dados mais detalhados (atômicos) em um terceiro servidor. A figura 3 exemplifica esta metodologia [42]. 17

18 Figura 3: Granularidade em camadas O primeiro servidor geralmente atende à maior parte das consultas, sendo que teremos um menor número de pedidos de acesso solicitados para a camada 2 e camada 3. O dimensionamento dos servidores é o seguinte: na primeira camada podemos ter uma configuração para suportar um grande número de usuários que farão diversas consultas, as quais trabalharão com um volume relativamente pequeno de dados. Já os servidores das outras duas camadas devem ser configurados para permitir processar grandes volumes de dados, porém não é necessária uma preocupação em configurar o sistema para suportar o acesso de um número maior de usuários. Isto se explica pelo fato de que a maioria dos usuários terá suas perguntas respondidas pelas consultas iniciais da camada 1. Se algum usuário não se satisfizer com o nível de detalhe das respostas da camada 1, pode buscar maiores informações na camada 2 e até mesmo na camada 3. Concluímos então que poucos usuários farão acessos regulares à última camada, sendo que alguns nunca o farão além do nível inicial [42] Sistemas de Suporte à Decisão Um sistema utilizado para gerenciar decisões. Usualmente envolve a análise de muitos dados. Como regra, não envolve a atualização dos dados, 18

19 somente efetua consultas. Sistemas projetados para os executivos que se caracterizam pela análise de tendências. Enquanto o resultado de um data warehouse é a possibilidade de auxiliar no suporte a decisões, um DSS pode existir independentemente da arquitetura de data warehouse. Além disso, um DSS é uma solução isolada e que não inclui necessariamente uma arquitetura, uma infra-estrutura e nem mesmo ferramentas de administração ou auditoria, ao contrário de um data warehouse, que deve incluir todos esses componentes [25]. Contudo Mallack (2000) afirma que quando necessária uma arquitetura para sistemas de suporte a decisão, ou qualquer outro tipo de sistema de informação, esta deve contemplar: interoperabilidade dos sistemas, de forma que as informações possam ser acessadas, fácil e rapidamente; compatibilidade dos sistemas, permitindo que os recursos possam ser facilmente compartilhados e distribuídos através da organização; expansibilidade dos sistemas, garantido que limitações em componentes de funções simples não criem obstáculos para o crescimento da organização. Dependendo da arquitetura que se pretende utilizar, existem diversas metodologias para a sua construção Business Intelligence É um processo de coleta, transformação, análise e distribuição de dados para melhorar a decisão de negócios; sua infra-estrutura tecnológica é composta de data warehouses ou data marts, ferramentas OLAP, EIS, data mining, consultas e relatórios e software de visualização dos dados; os bancos de dados são a infra-estruturas básica de qualquer sistema de business intelligence. São neles que vão estar armazenados os dados que serão transformados em informações competitivas [17]. 19

20 Modelagem de Dados Modelagem de dados é uma atividade na qual procuramos construir uma estrutura de dados que reflita a realidade e ao mesmo tempo seja facilmente manuseada por computadores para que os sistemas construídos a partir dela sejam estáveis e sofram o mínimo de manutenção possível. A modelagem é dividida em três etapas ou níveis: Conceitual, Lógico e Físico. Modelo Conceitual: É desenvolvido sem levar em consideração nenhum aspecto de representação lógica ou física dos dados, seja software, hardware ou visão particular de um usuário. É baseado em como funciona o negócio do cliente e ignora detalhes de implementação e performance [28]. Modelo Lógico: É desenvolvido levando-se em consideração a arquitetura de dados suportada pelo sistema gerenciador de banco de dados. Exemplo: Em Rede, Hierárquico, Relacional. Há a definição das tabelas, colunas e chaves. A meta é a redução de redundâncias para simplificação do gerenciamento e aumento da integridade [28]. Modelo Físico: O mapeamento físico leva em consideração características de hardware e software (SGBD) e estimativas de espaço e tempo (performance) [28]. O inicio para o plano de migração é um modelo de dados. O modelo de dados representa as necessidades de informação da corporação. Representa o que a corporação necessita não necessariamente o que a corporação atualmente possui. É construído sem consideração de tecnologia [12]. O Modelo Entidade-Relacionamento (MER) será a técnica de modelagem de dados utilizada para criação do Modelo Conceitual de Dados [9]. Esta técnica é usada para descrever o mundo real com alto grau de abstração, em termos de entidades (objetos de interesse), relacionamentos (forma como as entidades estão interligadas) e atributos (características das entidades e relacionamentos) [9]. O MER é composto por uma representação gráfica, o chamado Diagrama Entidade-Relacionamento (DER) e um conjunto de informações escritas sobre cada conceito representado (entidades, relacionamentos e atributos) [9]. 20

21 Apesar de ter surgido junto com a Análise Estruturada, o MER, por sua flexibilidade, foi evoluindo com o aparecimento de novas abordagens de desenvolvimento de sistemas (Engenharia da Informação, Análise Essencial, Análise Orientada a Objetos), e é considerada uma linguagem universal para a representação da realidade dos negócios de uma empresa [9]. Modelo de Dados: Estruturas de dados lógicas, providas por um sistema gerenciador de banco de dados utilizado para a representação dos dados [13]. Entidade: Armazena os dados de uma pessoa, lugar ou objeto de interesse em um alto nível de abstração [13]. Todo o objeto, coisa que tem alguma existência no negócio, na vida real. Não são tabelas, são implantadas como tabelas [23]. Relacionamentos: As ações ou fatos que integram as entidades no mundo real [23]. Modelo Entidade-Relacionamento (MER): Um modelo de dados que define entidades, o relacionamento entre entidades e os atributos que tem valores para descreverem as propriedades das entidades e/ou relacionamentos [13]. Diagrama de Entidade-Relacionamento (DER): Um modelo de dados de alto nível que demonstra, esquematicamente, todas as entidades dentro do âmbito de integração e a relação direta entre essas entidades [13]. Chave: Um item de dado ou combinação de itens de dados utilizados para identificar ou localizar uma instância de um registro ou algum agrupamento de dados similares [13]. Elas podem ser: Chave Primária: Um atributo único utilizado para identificar um registro em um banco de dados. Uma ou mais colunas que unicamente identificam uma linha da tabela. Chaves primárias devem ser únicas e não nulas. Chave Estrangeira: Uma ou mais colunas que referenciam à chave primária de outra tabela. Chave Comum: Uma ou mais colunas que são freqüentemente utilizadas para relacionar tabelas. 21

22 Chaves não são o mesmo que índices. Uma chave pode ou não ser um índice. As chaves são definidas no projeto lógico enquanto índices são definidos no projeto físico para garantir performance e outras razões [6] Banco de Dados Relacional Um Sistema Gerenciador de Banco de Dados Relacional (SGBDR) mantém tabelas que são compostas por colunas que descrevem linhas de dados. Uma base ou banco de dados é uma coleção de dados relacionados e armazenados (freqüentemente com redundância controlada e limitada) de acordo com um esquema. Um banco de dados pode servir única ou múltiplas aplicações. Os atuais Sistemas Gerenciadores de Bancos de Dados Relacionais oferecem uma solução poderosa e eficiente para o processamento de grandes volumes de transações de uma grande variedade de aplicações comerciais e científicas [8] Tabelas Tabela é uma relação que consiste em um conjunto de colunas com um título e um conjunto de linhas. Coluna é uma tabela vertical onde são selecionados valores do mesmo domínio. Uma linha é composta de uma ou mais colunas. Em um banco de dados relacional, todos os dados estão em tabelas. Uma tabela mantém dados relacionados com uma classe particular de objetos (uma entidade). Tabelas são compostas por linhas e colunas. Existe exatamente um conteúdo de dado em cada coluna de cada linha [31] Banco de Dados Multidimensional Um sistema gerenciador de banco de dados especificamente projetado para suportar várias dimensões de dados em uma arquitetura três camadas. 22

23 Tipicamente não suportam SQL (Structured Query Language) diretamente e, atualmente, suportam um volume de dados significantemente menor que um Sistema Gerenciador de Banco de Dados Relacional. Entretanto, esse tipo de gerenciador de banco de dados pode ser uma excelente opção para uma implementação departamental se a funcionalidade que ele provê atende à demanda do usuário referente às informações do negócio [13]. As pessoas falam da necessidade de separar a captura dos dados do acesso aos dados, em termos de bases separadas, movendo informações entre si, ao menos desde o início dos anos 80, testemunha o especialista da IDC em data warehouse Henry Morris. O que mudou foi a maturação de várias tecnologias-chave: agora não é mais só o banco de dado relacional; mas SGBDR multidimensional, com características especiais para aumento de performance, como indexação bitmap, e novos esquemas para organizar e representar os dados, visando não somente a inserção rápida de novas transações, mas análise e consultas complexas [3] Análise Multidimensional Análise multidimensional é a habilidade em manipular dados que foram agregados em várias categorias ou dimensões. A proposta da análise multidimensional é auxiliar o usuário a sintetizar a informação da empresa através de uma visão comparativa, personalizada e projetada para a análise de dados históricos [13]. Algumas ferramentas de análise multidimensional possuem a habilidade em acessar dados em um sistema gerenciador de banco de dados relacional; outras requerem um esquema estrela ( star schema ) para facilitar o processamento multidimensional [13]. A visão multidimensional é muito mais útil para os analistas do que a tradicional visão tabular utilizada nos sistemas de processamento de transação. Ela é mais natural, fácil e intuitiva, permitindo a visão dos negócios da empresa em diferentes perspectivas e, assim, transformando o analista num explorador da informação [7]. 23

24 OLTP O Processamento Transacional Online registra todas as transações contidas em uma determinada operação organizacional. Por exemplo: sistema de transações bancárias registra todas as operações efetuadas em um banco. Transação OLTP consome poucos recursos; pesquisa quantidade reduzida de dados. Como resultado desta disciplina, o tempo de resposta de uma transação é bom (dois a três segundos são o normal) [13]. De maneira geral, um sistema aplicativo está focado na precisão dos processos operacionais [33] OLAP Processamento Analítico Online é um importante método na arquitetura do data warehouse na qual os dados podem ser transformados em informação. OLAP é uma categoria de tecnologia de software que permite a analistas, gerentes e executivos a obterem perspicácia em dados de uma forma rápida, consistente e com acesso interativo para uma grande variedade de possíveis visões da informação na empresa. Mais sucintamente, OLAP é um conjunto de funcionalidades que tem, como principal objetivo, facilitar a análise multidimensional [13]. OLAP representa um conjunto de tecnologias projetadas para suportar análise e consultas ad hoc (consultas efetuadas pelo usuário de acordo com sua necessidade momentânea). A característica principal dos sistemas OLAP é permitir uma visão conceitual multidimensional dos dados de uma empresa [7]. A criação do OLAP foi em decorrência da forte necessidade de análises dos dados de forma fácil e flexibilidade, mas ao mesmo tempo, analisando múltiplas visões do negócio em diferentes níveis de detalhes. Os bancos de dados multidimensionais foram a resposta para atender a essas necessidades analíticas. No início dos anos 90 começaram a surgir os primeiros protótipos de bancos de dados multidimensionais. Após alguns anos de aprimoramento da tecnologia, os bancos de dados multidimensionais foram 24

25 submetidos à análise de E. F. Codd e sua equipe em Codd então definiu 12 regras, padrões, homologou a tecnologia, e batizou os bancos de dados multidimensionais com o nome de OLAP (derivado do termo OLTP - que foi atribuído aos Bancos de Dados Relacionais no início da década de 1970, quando Codd definiu os padrões para modelo Relacional). A partir da homologação de Codd, a tecnologia começou a ser utilizada e conhecida em 1994, e os fornecedores da tecnologia criaram produtos com cada vez mais capacidade de armazenamento, bem como vários outros recursos para facilitar as análises. Começou então a utilização de Banco de Dados Multidimensionais como Data Marts entre 1995/96 e a tecnologia evoluiu a passos largos [5]. As bases OLAP podem ser acessadas/manipuladas através de aplicações personalizadas ou ainda via Internet/Intranet e aplicações pré-definidas para se fazer análises diversas. Abaixo há uma tabela comparativa: OLTP OLAP Operação típica Transação Análise Granularidade Atômico Agregado Temporalidade dos dados Presente Histórico, atual e projetado. Recuperação Poucos registros Muitos registros Usuários Muitos Poucos Orientação Registros Arrays Consulta Predefinida Ad-hoc Tabela 1: Comparação do Modelo OLTP com OLAP Essa tabela é apenas para dar uma idéia geral e será detalhada abaixo: Operação típica: No modelo OLTP são efetuadas transações, que podem ser, por exemplo, uma atualização de um registro, uma remoção, uma recuperação ou uma criação. Já no modelo OLAP os dados servem para ser analisados, por exemplo, saber qual foi o produto mais vendido há dois meses. [34] 25

26 Granularidade: No modelo OLTP os dados são tratados com o máximo de detalhamento, já no OLAP os dados estão agregados, ou seja, há um resumo dos dados. Esse resumo é o necessário para que sejam feitas análises. [34] Temporalidade dos dados: No OLTP o que importa são os dados atuais, por exemplo, se o preço de um produto passa de x para y então x é apagado e substituído por y. No OLAP o passado importa, pois os dados são utilizados para análise e previsões futuras, ambas atividades que necessitam de informações sobre o passado. Logo o modelo OLAP considera as informações atuais e também as informações anteriores, as quais no OLTP poderiam não mais existir. [34] Recuperação: No modelo OLTP geralmente poucos registros são recuperados em uma consulta. Por exemplo, o preço de um produto, os dados de um cliente. No OLAP vários registros são recuperados, por exemplo, a quantidade vendida de um dado produto em cada um dos últimos sete meses agrupados por cidade. [34] Usuários: No modelo OLTP existem muitos usuários utilizando o sistema ao mesmo tempo, porém com consultas mais simples. No OLAP existem poucos usuários com consultas mais complexas. [34] Orientação: O modelo OLTP é orientado a registros, termo que é muito comum em informática e geralmente significa uma linha em uma tabela de um banco de dados relacional. O modelo OLAP utiliza arrays, os quais são bons para representar dimensões, como, por exemplo, a dimensão tempo ou a dimensão lugar. [34] Consulta: No modelo OLTP os tipos de consultas que podem ser realizadas já são predefinidos, por exemplo, consultar o preço de um produto ou consultar o débito de um cliente. No OLAP as consultas são ad-hoc, ou seja, são definidas de acordo com os interesses de quem realiza a consulta, por exemplo, qual o total de vendas de um dado produto em cada um dos últimos três meses por cidade. [34] A tecnologia OLAP hoje é largamente utilizada na elaboração de Data Marts com desdobramentos para ROLAP/modelagem NxN no Relacional e HOLAP (Híbrido OLAP que combina OLAP com ROLAP) [5]. 26

27 A utilização de OLAP híbrido, o H-OLAP só é necessária quando se trata de bases muito grandes, de grande ocorrência em Varejo, Banco e Seguradoras [5] ROLAP Nos sistemas ROLAP (Relacional OLAP) temos uma base de dados relacional que será analisada de maneira multidimensional. A base de um desenho físico ROLAP é, tipicamente, uma combinação de dados apropriadamente normalizados em uma ou mais técnicas star schema [13].Esse trabalho poderá ser feito de duas maneiras: Todo o processamento sendo feito no servidor do banco de dados. Esses servidores OLAP geram os comandos SQL em diversos passos e as tabelas necessárias para o processamento das consultas. Todo o processamento dos dados sendo feito no servidor OLAP, mas o servidor dos dados executando os comandos SQL, inclusive os joins e agregações. Algumas outras características dos servidores ROLAP: Uso de metadados que descrevem o modelo e servem também para o auxílio na construção de consultas. Com o uso dos metadados, um analista é capaz de executar consultas de maneira mais personalizada, buscando os dados e usando os critérios que achar mais conveniente. [43] Capacidade de criar comandos SQL mais otimizados para o banco de dados com o qual trabalha. [43] A maior vantagem da adoção da tecnologia ROLAP está no fato de ser uma tecnologia já estabelecida e cuja arquitetura é aberta e padronizada, já que é relacional. Isso faz com que possa utilizar diversas plataformas, escalabilidade e paralelismo de hardware. [43] 27

28 MOLAP É qualquer análise multidimensional efetuada em um sistema gerenciador de banco de dados multidimensional [13]. MOLAP (Multidimensional OLAP) é uma classe de sistemas que permite a execução de análises bastante sofisticadas usando como gerenciador de dados um banco de dados multidimensional [7] HOLAP É um produto de OLAP híbrido que pode prover análise multidimensional simultaneamente de dados armazenados em um banco de dados multidimensional e em um banco de dados relacional [17] WOLAP Representa a migração da tecnologia OLAP para o ambiente da Internet (Web OLAP). Tem havido uma grande divulgação sobre o uso de Web browsers para acesso à OLAP, mas ainda são poucos os sites em funcionamento com o uso de OLAP. Segundo alguns institutos de pesquisa o OLAP baseado na Web será a chave para aplicações na Intranet e deverá oferecer um caminho simples e barato no acesso ao data warehouse [17] Operações OLAP Operações OLAP são as operações de pesquisa e exploração da informação no cubo de dados. São elas: Slice and Dice: São operações de fatiamento do cubo de dados, permitindo sua visualização em segmentos, assim como a rotação do cubo buscando novas perspectivas de visão de dados. Drill Down e Roll UP: É a capacidade de navegação aprofundando o nível de detalhamento dos dados, ou subindo este nível de detalhe conforme a hierarquia. 28

29 Figura 4: Exemplo de Drill-down e Roll-up Figura 5: Exemplo de Slice Modelagem Dimensional dos Dados A modelagem dimensional é a técnica utilizada para se ter uma visão multidimensional dos dados. Nessa técnica, os dados são modelados em uma estrutura dimensional conhecida por cubo. As dimensões do cubo representam os componentes dos negócios da empresa, tais como cliente, produto, fornecedor e tempo. A célula resultante da intersecção das dimensões é chamada de medida e geralmente representa dados numéricos como unidades vendidas, lucro e total de venda [7]. Além dos componentes dimensão e medida, outro importante aspecto do modelo multidimensional é a consolidação dos dados, uma vez que para a tarefa de análise são mais úteis e significativos à agregação (ou sumarização) dos valores indicativos dos negócios [7]. O próprio desenho do data warehouse leva a novas perspectivas de projeto. Não há necessidade de modelagem na terceira forma normal. Na 29

30 prática, redundância de dados é bem-vinda nesse ambiente. Para muitos projetistas, é uma maneira diferente de modelar dados [33]. Modelagem Dimensional é um nome novo para uma técnica antiga usada para criar bancos de dados simples e compreensíveis. Quando um banco de dados pode ser visualizado como um cubo contendo até três, quatro, cinco ou mais dimensões, as pessoas conseguem visualizar este cubo em qualquer de suas dimensões. Outro nome para modelo dimensional é star join schema. Os projetistas de bancos de dados têm utilizado esse nome já há algum tempo para descrever modelos dimensionais porque o diagrama é semelhante a uma estrela com uma tabela no centro rodeada por tabelas auxiliares exibidas em um padrão radial [19]. Dimensional Modeling (DM) é uma técnica lógica de projeto muito utilizada nos data warehouses, diferente e oposta ao entity-relation modeling (ER). O DM é a única técnica viável para os bancos de dados projetados para suportar as consultas de usuário final de um data warehouse. O ER é muito útil na captura de transações e nas fases de administração de dados da construção de um data warehouse, mas deve ser evitado para o usuário final [4]. O DM é uma técnica lógica de projeto que busca apresentar os dados dentro de uma estrutura padrão e intuitiva, permitindo ainda o acesso de alto desempenho. Ele é inerentemente dimensional e adota a disciplina com algumas restrições importantes. Todo modelo dimensional é composto por uma tabela com uma chave de várias partes, denominado tabela de fatos e um conjunto de tabelas menores chamadas tabelas de dimensão. Cada tabela de dimensão possui uma chave de uma única parte, que corresponde exatamente a um dos componentes da chave de várias partes da tabela de fatos. Essa característica de estrutura de estrela também é chamada de star join. Este termo remonta os primeiros dias dos bancos de dados relacionais [4]. 30

31 Fatos São as medidas básicas de informações do negócio. Representa as quantidades e valores dos dados que podem ser agregados sem perderem seu significado. A tabela fato ou fact table armazena as medidas básicas objetos de análise do negócio. O dado na tabela fato é composto de elementos de dados organizados em um nível estruturado. Os valores destes elementos de dados podem ser sumarizados em uma variedade de formas sem por em risco a integridade dos dados [13]. A chave de uma tabela fato é a composição das chaves das tabelas dimensão. O resultado é que existirá uma linha na tabela fato para cada combinação única dos domínios de todas as chaves de todas as tabelas dimensão. Características: Quantifica o dado que foi descrito nas tabelas dimensão. Chave composta de combinação única de valores das chaves das dimensões. Os valores da tabela fato são somente aditivos. Sempre contém uma data Dimensões de um Cubo Descrevem ou caracterizam os dados relacionados e organizados na tabela fatos. As tabelas dimensão circundam a tabela fato. Representam as possíveis formas de visualizar e consultar os dados. Características: Chave deve ser única. Permitir gerenciar número de níveis de agregações. Dimensão não precisa ser uma hierarquia, pode ser uma combinação de atributos. 31

32 Figura 6: Exemplo de um Cubo Dimensional Agregações Agregações são sumarizações de dados com o objetivo principal de melhorar a performance de acesso. Geralmente armazenadas em tabelas fatos separadas [13]. Abstração de dados que, aplicada à modelagem conceitual de dados, permite que objetos venham a formar um novo objeto de mais alto nível. [28]. Agregações fornecem níveis múltiplos de detalhes do fato. Os resultados das queries (ou seus valores intermediários) são précalculados, o que melhora muito a performance [18]. As agregações podem ser acumuladas através de agrupamentos diferentes, freqüentemente através de várias dimensões ou combinação de dimensões [18]. O único aspecto mais importante de design de um data warehouse é o assunto da granularidade. Granularidade se refere ao nível de detalhe contido as unidades de dados no data warehouse. Quanto mais detalhamento há, mais baixo será o nível de granularidade. Quanto menos detalhamento há, mais alto o nível de granularidade. A razão por que granularidade é o assunto de design principal no ambiente de data warehouse é que afeta profundamente o volume de dados residente no data warehouse e ao mesmo tempo afeta o tipo de questão que pode ser respondida [12]. 32

33 Técnica Star Schema (Esquema Estrela) A técnica star schema pré-processa os dados em uma tabela fatos central com tabelas de dimensão relacionadas. As únicas chaves de cada tabela dimensão compõem uma chave combinação na tabela fatos. Os benefícios desta técnica são que os dados estão pré-processados em dimensões conhecidas e caracterizadas em um conjunto específico de necessidades de informação do negócio, tornando o acesso pelo usuário mais eficiente. Figura 7: Exemplo de uma Estrutura Star Schema Este modelo é composto por uma tabela com chave de múltiplas partes (dimensões) chamadas de tabela fato e de um conjunto de tabelas pequenas chamadas de dimensões, que formam as pontas das estrelas. Cada tabela de dimensão tem uma chave primária simples que corresponde a um dos componentes da chave múltipla da tabela fato. A princípio parece um modelo muito simples de ser construído, porém a determinação das dimensões e do fato tem necessidade de excelente entendimento conceitual para que se obtenha sucesso em uma implantação de data warehouse [23]. 33

34 Técnica Snow Flake (Floco de Neve) A técnica snow flake é uma variante do star schema com as tabelas dimensões normalizadas [23]. Figura 8: Exemplo de uma Estrutura Snow-Flake As hierarquias têm significado e importância dentro da análise multidimensional. No modelo star, elas estão todas em vista da desnormalização das entidades, um dos conceitos básicos de modelagem multidimensional. Um esquema alternativo é o esquema snow flake, onde normalizando as hierarquias encadeamos relacionamentos e entidades a partir das dimensões. A utilização de esquema snow flake depende da necessidade de otimizações no projeto físico ou nas queries realizadas. Lembramos que sempre um data warehouse tem como objetivo sistemas de apoio à decisão, que necessitam das mais variadas consultas [23]. Um esquema snow flake em nosso entendimento é somente uma alternativa de construção do modelo de dados multidimensional. Todo modelo snow flake pode rapidamente ser transformado em um star, bastando para isto relacionarmos as hierarquias diretamente às tabelas fato, desnormalizando-as completamente [23]. 34

35 Metadados São dados sobre dados. Descrição dos dados: estrutura, conteúdo, chaves, índices, detalhes, etc. Sem os metadados, o data warehouse e seus componentes associados seriam meramente componentes não integrados trabalhando independentemente e com objetivos distintos [13]. Para alcançar harmonia e unidade entre os diferentes componentes do ambiente projetado, deve haver uma técnica bem definida e rigorosa para desenvolver os metadados. Existem metadados para: O ambiente operacional. A camada de integração e transformação. Porções detalhadas do data warehouse. Depósitos de dados operacionais. Data mart s. Ambiente de desenvolvimento. Modelo do negócio da Empresa. Para atingir um grau de segurança na confiabilidade dos dados, o primeiro passo é catalogar os metadados com RDBMS (Relational Data Base Management System), plataforma, fontes de dados, tabelas, campos, índices, chaves primárias, chaves estrangeiras, stored procedures, parâmetros, programas ou seja, o metadados contém todas as informações que explicam o funcionamento da base de dados [24]. Com os metadados catalogados, as estruturas de dados de todo o ambiente estarão sempre sendo verificadas. Portanto, a cada mudança que ocorra nas bases de dados transacionais, o administrador estará sempre sendo alertado, o que aumenta sua confiança na informação que estará sendo disponibilizada aos tomadores de decisão [24]. Importante utilizar metadados para descrever o modelo dos dados e para auxiliar na construção das consultas. Dessa maneira, um analista pode executar suas análises utilizando seus próprios termos [7]. 35

36 O Metadado é um dado sobre um determinado dado. Por exemplo: os metadados poderiam indicar se uma base de dados existe na corporação, quais atributos formam uma determinada tabela, características físicas de um determinado atributo, tais como: tamanho e formato, onde ele é utilizado, etc. As informações do metadado podem ser sobre os dados do legado, dados armazenados em data warehouse ou informações pertinentes a um catálogo. Estas informações são armazenadas em um repositório que tem o objetivo de documentar e administrar estes metadados e fornecer informações para reuso destes dados, melhorando a qualidade e produtividade da empresa [16]. Metadados é a mais importante regra no data warehouse e, é usado em vários aspectos: É direcionado para ajudar na localização analítica do conteúdo no data warehouse para o DSS [13]. É um guia para mapear os dados, como o dado é transformado do ambiente operacional para o ambiente do data warehouse [13]. É um guia para o algoritmo usado para a sumarização entre dado corrente detalhado e o dado lightly sumarizado e o dado highly sumarizado, etc [13] Ferramentas CASE (Computer Aided Software Engineering) São ferramentas individuais que auxiliam o desenvolvedor de software ou gerente de projeto durante uma ou mais fases do desenvolvimento de software (ou manutenção). Uma combinação de ferramentas de software e metodologias de desenvolvimento estruturado. CASE pode auxiliar diretamente no projeto e suporte do desenvolvimento de sistemas e também provê gerenciamento da informação, documentação e controle de como desenvolver um projeto [11]. Alguns benefícios do CASE: Reduz custos, especialmente manutenção. Melhora a qualidade de software. 36

37 Acelera o processo de desenvolvimento. Incrementa a produtividade. Tornam práticas as técnicas estruturadas SQL A Structured Query Language é uma linguagem padrão de acesso aos dados em bancos de dados relacionais independente de fornecedor. É dividida em três partes: linguagem de definição de dados (DDL), linguagem de manipulação de dados (DML) e linguagem de controle de dados (DCL). O padrão internacional é estabelecido pela ISO (International Organization for Standardization). A primeira normatização do SQL foi feita pela ANSI (American National Standards Institute) em O SQL/86 foi um subconjunto das implementações de SQL da IBM. A primeira norma da ISO saiu em A norma internacional vigente é a versão de 1992 (ISO/IEC 9075:1992(E), também conhecida como SQL92 ou SQL2). Ela se subdivide em 3 partes: Entry Level, Intermediate Level e Full Level. A maioria dos sistemas gerenciadores de banco de dados só implementa o Entry Level completamente. [28] Já existem trabalhos para o SQL/3 e SQL/MM (Multimídia) que devem implementar alguns conceitos da tecnologia de orientação à objeto. Um dos órgãos de certificação de conformidade dos produtos com a norma é o NIST (National Institute of Standards and Technology) que publica o FIPS (Federal Information Processing Standards) que contém uma lista de sistemas gerenciadores de banco de dados que tem conformidade com o padrão e em qual plataforma [28]. Uma linguagem que habilita o usuário a interagir diretamente com o sistema gerenciador de banco de dados para recuperar e/ou modificar dados gerenciados pelo mesmo. Características: É uma forma padrão de especificar conjuntos de dados. É uma forma de recuperar e manipular dados em um banco de dados relacional. 37

38 É utilizada para todas as funções de bancos de dados, incluindo administração, criação de esquemas e recuperação. Pode ser utilizada na forma de SQL embutida em um programa de aplicativo Stored Procedure Stored Procedure (SP) é uma técnica de projeto que permite que um conjunto de instruções SQL sejam compiladas e armazenadas no gerenciador de banco de dados. São rotinas chamadas por aplicações cliente de modo semelhante a RPC (Remote Procedure Call) e são armazenadas e executadas no servidor. A stored procedure fornece uma significante melhora de performance sobre o SQL utilizado diretamente na aplicação [28]. Uma stored procedure é uma coleção de comandos SQL armazenados no banco de dados e que pode ser executada pelo nome. Características: Podem aceitar e retornar parâmetros e podem chamar outras procedures. Processam mais rapidamente que os mesmos comandos SQL executados interativamente. Reduzem o tráfego de dados na rede. A primeira vez que uma stored procedure é executada, um plano de acesso é produzido no banco de dados. Garantem a consistência do banco de dados. Provêem um nível extra de segurança. Sugerem o desenvolvimento de uma aplicação modular. Reduz erro de operação. 38

39 Indexação É o conceito de índices de acesso. São estruturas de indexação destinadas a otimizar o acesso aos dados. É importante lembrar que em bancos de dados relacionais, uma chave nem sempre tem um índice associado a ela. Chaves são definições de nível lógico e os índices são estruturas físicas para melhorar a performance no acesso aos dados. Há dois tipos de índices: clustered index e nonclustered index. No clustered index os dados de uma tabela são ordenados fisicamente pelo índice. Ele tem um nível a menos de acesso em relação ao nonclustered. O índice nonclustered armazena os valores das chaves e ponteiros para as páginas de dados onde as linhas estão armazenadas [28]. Índice: Porção da estrutura de armazenamento de dados mantida para prover acesso eficiente a um registro quando seu conteúdo chave é conhecido. Índice Invertido: Uma estrutura de índice organizada por meio de uma chave não única que aumenta a velocidade de pesquisa aos dados [13]. Características dos Índices: São utilizados para melhorar a performance. (se nenhum índice é definido a uma tabela, a tabela inteira deverá ser pesquisada para satisfazer uma condição de consulta) [6]. Provêem um mecanismo para garantir a unicidade. Clustered: O dado é classificado na ordem do índice. Somente pode existir um único índice clusterizado por tabela (geralmente é a chave primária). Determina a ordem física do dado na tabela [6]. NonClustered: O dado não é classificado na ordem da chave. Podem existir vários índices associados à tabela (geralmente são as chaves estrangeiras) [6] XML A extensible Markup Language tem como propósito principal a facilidade de compartilhamento de informações através da Internet. 39

40 Estimulado pela insatisfação com os formatos existentes (padronizados ou não), um grupo de empresas e organizações que se autodenominou World Wide Web Consortium (W3C) começou a trabalhar em meados da década de 1990 em uma linguagem de marcação que combinasse a flexibilidade da SGML com a simplicidade da HTML. O principio do projeto era criar uma linguagem que pudesse ser lida por software, e integrar-se com as demais linguagens [36]. Sua filosofia seria incorporada por vários princípios importantes: Separação do conteúdo da formatação. Simplicidade e Legibilidade, tanto para humanos quanto para computadores. Possibilidade de criação de tags sem limitação. Criação de arquivos para validação de estrutura (Chamados DTDs). Interligação de bancos de dados distintos. Concentração na estrutura da informação, e não na sua aparência. O XML é considerado um bom formato para a criação de documentos com dados organizados de forma hierárquica, como se vê frequentemente em documentos de texto formatados, imagens vetoriais ou bancos de dados[36]. Pela sua portabilidade, um banco de dados pode através de uma aplicação escrever em um arquivo XML, e um outro banco distinto podem ler então estes mesmos dados [36] XMLA XML for Analysis é o padrão da indústria para acesso aos dados em sistemas analíticos, tais com OLAP e Data Mining. XMLA é baseado em outros padrões da indústria tais como XML, SOAP e HTTP.[37] Produtos que suportam XMLA são de duas categorias: XMLA Providers: esses produtos XMLA provêem serviços. Tipicamente esses são servidores ou produtos meios. [37] 40

41 XMLA Consumers: esses produtos podem conectar ao XMLA Providers e consumir XMLA. Tipicamente esses são clientes. [37] 3.2 Aspectos na construção de um Data Warehouse Planejamento Um problema sério em projetos de data warehouse é um planejamento defeituoso. O fato de todos concordarem que o projeto de um data warehouse não se baseia em requisitos bem delimitados não significa que os projetistas não devam planejar minuciosamente cada atividade do processo. E mais, tal planejamento deve levar em consideração o fato de se tratar de um data warehousing mais que um data warehouse: um processo sem fim para todos os efeitos práticos. Deve ser considerado o longo prazo geralmente envolvido. Não se estará projetando uma aplicação operacional, mas sim um repositório de informações gerenciais [10]. A operação do negócio tende a uma estabilidade grande. Um aplicativo voltado para gerir essas atividades tende, portanto, a ser bastante estável, pelo menos quando comparado às necessidades de informação para a tomada de decisão. É aqui que a competitividade do mercado se faz sentir. As perguntas que os executivos precisam ver respondidas hoje para tomarem suas decisões podem ser substancialmente as de amanhã. Desse modo, um planejamento consistente deve prever liberações parciais de dados, em curtos intervalos, de maneira que o usuário cedo possa interagir com o ambiente, facilitando essa mudança inevitável de requisitos. Os planejadores devem identificar muito cedo os alvos do projeto e seus benefícios [10]. Recomenda-se que o data warehouse não comece muito ambiciosamente. O primeiro projeto não deve levar mais que nove meses para estar operacional e deve atingir basicamente as áreas de negócio mais importantes e que tragam retorno direto e tangível. Com o tempo, ele será refinado e aumentado em sua abrangência [32]. Um projeto de data warehouse deve ser conduzido com enfoque diferente de um projeto de aplicações tradicional. A primeira etapa é identificar os 41

42 objetivos da organização, sob a óptica de seus executivos. A empresa pretende crescer dentro de seu segmento de negócio? Ou pretende expandir seu market-share? Depois, são identificados os processos de negócio diretamente relacionados com esses objetivos. A seguir, definem-se as informações que são necessárias para suportar esses processos de decisão. Onde essas informações serão obtidas? As especificações técnicas aparecem no final, quando então se desenham as alternativas tecnológicas para a sua total implementação [33] Necessidades das Empresas No princípio havia sistemas simples de automação. Então vieram sistemas de banco de dados e sistemas on-line. Em um tempo muito pequeno o computador tinha achado seu modo de incorporar-se ao cotidiano das empresas. De quase nenhum computador nos anos cinqüenta para milhões de computadores de todo tipo e tamanho nos anos oitenta, o mundo da tecnologia explodiu além de qualquer previsão a uma taxa de crescimento que parecia ser impossível acreditar. Os sistemas de computação iniciais foram projetados para processar as transações diárias da corporação. Decisões imediatas eram o enfoque destes sistemas pioneiros. Com o advento dos primeiros sistemas, veio um subproduto de dados. Estes dados refletiam as atividades que estavam acontecendo e cresceram à medida que o tempo passava e de como o negócio era administrado [13]. Logo, a quantidade de trabalho exigiu manter as aplicações ao ponto em que 95% do trabalho era dedicado à manutenção de programas. Ao mesmo tempo em que o fardo de manutenção estava crescendo, os usuários finais estavam ficando frustrados com a inabilidade dos sistemas de informação da organização em responder às necessidades de informação. Caso após caso, os usuários finais sabiam que os dados de que eles precisavam estavam disponíveis, mas difíceis de serem obtidos. Ainda, em cada caso, o departamento de sistemas de informação dava uma ou outra justificativa do 42

43 porquê dos dados não poderem ser acessados. Usuários finais sentiam-se abandonados e frustrados [13]. Então, o data warehouse foi criado para transferir os dados do ambiente transacional, armazenando-os e organizando-os de forma que o usuário final poderia obter a informação pela qual tanto ansiava. Afinal, os dados estavam disponíveis em uma base para que o usuário processasse suas próprias consultas [13]. O data warehouse representou uma troca fundamental na concepção de sistemas de informação e introduziu alguns conceitos novos importantes: Dados devem ser integrados através da empresa. Dados sumarizados tem um grande valor para a organização. Dados históricos são a chave para compreender os dados ao longo do tempo. Metadados representam um papel muito importante na infra-estrutura do data warehouse. Muito importante manter a precisão dos dados históricos com o passar do tempo. Além de resolver alguns problemas muito importantes para a corporação, a criação do data warehouse aliviou o fardo do programador de aplicação em tentar transformar o ambiente de sistemas legado em um sistema para a tomada de decisão. As solicitações dos usuários e a manutenção das aplicações, pela primeira vez, tornaram-se gerenciáveis [13]. O objetivo básico do data warehouse deve ser adicionar valor ao negócio. À medida que as regras do negócio são incorporadas às aplicações, exige-se rapidez cada vez maior nas respostas. O ambiente de negócios é crescentemente dinâmico. Responder com rapidez ao como, quando e quanto passa a ser decisivo para a empresa sobreviver e crescer nesse cenário [33]. As organizações hoje em dia estão enfrentando enormes pressões para prever informações de melhor qualidade para tomada de decisões, em formatos de fácil acesso e manipulação. Em poucas palavras, as empresas 43

44 precisam se tornar mais ágeis em sua capacidade de utilizar as enormes quantidades de dados no esforço de proporcionar melhor suporte ao cliente. Um data warehouse reconhece o valor estratégico do gerenciamento intencional do bem corporativo de dados. A ênfase no data warehouse reflete o reconhecimento de que a exploração de dados é o caminho para vantagem competitiva, novas oportunidades de negócios, e melhoria no serviço ao cliente. Ela também reconhece que os sistemas tradicionais de gerenciamento de base de dados estão geralmente assoberbados pelo enorme volume de dados que lhes são confiados. Como resultado, os sistemas de extração de informações que trabalham com a totalidade das bases de dados geralmente funcionam mal [35]. O data warehouse e a arquitetura associada a ele providencia o objetivo para lutar contra os mais variados desafios confrontados nos sistemas de informações gerenciais de hoje [13]. Em outras palavras, o data warehouse permite o gerenciamento para considerar resultados no contexto. Sem a armação do data warehouse e sua arquitetura associada é uma tarefa quase impossível formar sentido para os diversos resultados obtidos [13]. Os sistemas de informações (IS) gerenciáveis encontram a noção da arquitetura indispensável no movimento da corporação dentro de um mundo de processamento de informação efetiva. Em particular, o IS gerenciável usa a arquitetura como um guia para o gerenciamento, como o seguinte: uso da armazenagem e aquisição. tecnologia adequada com processamento necessário. gerenciamento de orçamento. mudança de tecnologia e plataforma. informações derivadas do ambiente de produção. determinação das responsabilidades organizacionais. desenvolvimento de relatórios da arquitetura. definição da interface entre as diferentes unidades organizacionais. 44

45 gerenciamento de gráficos organizacionais como a responsabilidade no processamento da informação concernida. gerenciamento do impacto na arquitetura no desenvolvimento do processo. Afinal, é antigo o enfoque por trás da idéias do depósito, galpão ou armazém de dados extraídos dos muitos sistemas de produção geralmente legacy systems das companhias: transformar o dado cru em informação, para obtenção de vantagem competitiva. [3] Data warehouse é entendido como uma enabling technology ; uma tecnologia-meio, que favorece a tomada de decisões ao separar sistemas de informações para decisão dos dados de produção. Essa divisão dos dados permite, dizem os entusiastas, melhor alocação e administração de recursos; enquanto que a proliferação de ferramentas sofisticadas de acesso possibilita combinar várias fontes de dados de estruturas distintas e concretiza, assim, antigas promessas de gerência participativa e menor concentração de poder decisório [3] Tipos de Sistemas de Informações na Empresa Segundo Laudon e Laudon (1998), os sistemas de informações são classificados em quatro tipos, dependendo do tipo de problema organizacional que solucionam, conforme a figura abaixo. Figura 9: Tipos de Sistemas de Informação (Laudon e Laudon 1998) 45

46 Pirâmide com três níveis: [38] 1º Nível é o Nível Estratégico: ESS Sistema de Suporte aos Executivos: ajuda a gerencia sênior no planejamento das atividades de longo prazo. 2º Nível é o Nível Tático: DSS Sistema de Suporte a Decisão e MIS Sistemas de Administração das Informações: suporta o monitoramento, controle, tomadas de decisão e avaliação das atividades da gerência intermediária. 3º Nível é o Nível de Conhecimento: KWS Sistema de Controle de Conhecimento e OAS Sistema de Automação de Escritório: permite aos funcionários de escritórios a criação de produtos, racionalização de serviços e acompanhamento de fluxo de documentos na organização. 4º Nível é o Nível Operacional: TPS Sistemas de processamentos Transacionais: responde questões rotineiras e acompanha o fluxo das transações através da organização Motivação da Empresa no Mercado O verdadeiro impulso para a utilização da tecnologia de data warehouse começou quando as pessoas perceberam que as informações disponíveis no data warehouse poderiam ser utilizadas para a obtenção de vantagem competitiva. Esta informação apoiou a habilidade da corporação em atrair e manter parte do mercado, reduzir despesas e aumentar as vendas. Estes atributos elevaram o data warehouse para a vanguarda de sistemas de informação, tornando-o promissor tanto para o profissional técnico da informação quanto para o profissional da área de negócios [13]. Estamos vivendo o início da era da informação. Nela os grandes desafios são as integrações dos processos operacionais entre as empresas e o gerenciamento do negócio através da análise dos fatos para identificação de oportunidades [26]. 46

47 3.2.5 Necessidades e Benefícios para o Usuário A necessidade principal do usuário é a transformação dos dados em informações. Embora o seu uso ainda seja incipiente, alguns resultados positivos parecem demonstrar que realmente o data warehouse produz um alto retorno sobre o investimento. A grande vantagem de um data warehouse é permitir a tomada de decisões baseadas em fatos. Na verdade, ele busca disponibilizar à organização o grande volume de dados que foram e estão sendo armazenados em bases de dados operacionais, espalhadas por toda a empresa [32]. O principal resultado de um data warehouse é, indiscutivelmente, a facilidade dos gestores da empresa poderem tomar decisões rápidas, baseados em informações mais consistentes [32]. Levantamentos realizados junto a usuários em âmbito mundial e local atestam o sucesso dos projetos já implantados, nos quais os primeiros resultados apontaram para: aumento do tempo dos tomadores de decisão (decision makers) para a análise e tomada de decisão; eliminação de tarefas operacionais como pesquisa e identificação dos dados necessários ao processo decisório; melhor confiabilidade das informações devido à implantação de um elo integrador dos dados transacionais; racionalização do fluxo de informações da empresa; padronização dos conceitos de negócio e democratização das informações sobre o desempenho do negócio [24] Perfil do Usuário na Empresa que Utiliza o Data Warehouse O usuário, o formulador de perguntas, é o ponto mais crítico nos projetos de data warehouse. Idealmente, os usuários devem ser membros da equipe de projeto, desde o seu nascimento [10]. Os usuários finais do data warehouse tem alguns papéis específicos a cumprir. Estes geralmente dividem-se em duas categorias: Suporte aos Papéis e Tipos de Usuário [13]. Suporte aos Papéis: 47

48 Cada interação do data warehouse deve ter um Patrocinador Executivo da área de negócios da comunidade usuária que serão os primeiros beneficiários da funcionalidade destas interações. O Patrocinador Executivo é especialmente importante para o data warehouse. Ele define o escopo e requisitos do negócio e analisa as necessidades de informação da organização para a tomada de decisão. Existem, também, dois importantes papéis adicionais na comunidade de usuários finais: Especialista do Assunto e Técnico de Apoio ao Usuário [13]. O Especialista do Assunto é quem facilita a comunicação entre os usuários finais e a equipe técnica do data warehouse. Provê as informações para definir o escopo de uma interação do data warehouse. Participa no projeto e revisão da aquisição e capacidade de acesso aos dados. Assiste o treinamento de outros usuários em seus grupos funcionais. Atua como suporte a outros usuários em suas áreas [13]. O Técnico de Apoio ao Usuário provê apoio técnico global para os usuários do seu departamento, grupo, linha de negócio, etc. Ele entende o ambiente técnico de uma área específica do data warehouse, presta apoio como administrador de banco de dados local e apoio técnico aos usuários locais [13]. Tipos de Usuário: São categorizados como: Usuários de Aplicações Pré-definidas, Usuários com Acesso Limitado e Usuários com Acesso Ilimitado [13]. Os Usuários de Aplicações Pré-definidas não possuem um nível alto de experiência técnica, mas estão, tipicamente, em um nível relativamente alto dentro da estrutura de administração de uma organização. Eles também são, freqüentemente, assistentes administrativos. Acessam o data warehouse através de consultas pré-definidas que atendem aos seus requisitos de negócio [13]. Os Usuários com Acesso Limitado são a maioria dos usuários analíticos. Requerem caminhos pré-definidos de acesso ao data warehouse como, por exemplo, uma ferramenta OLAP para facilitar o acesso e tem conhecimento em 48

49 drill-up/down. Tipicamente oferecem apoio aos pedidos de informação da administração superior [13]. Os Usuários com Acesso Ilimitado são os exploradores, altamente habilitados tecnicamente no acesso aos dados, precisam de ferramentas poderosas, procedurais e não ferramentas simples e limitadas. Freqüentemente desenvolvem aplicações para uso por outros tipos de usuários e, tipicamente, possui um número pequeno de usuários. Oferecem apoio às exigências organizacionais para relatórios complexos [13]. Pode parecer desnecessário identificar os papéis chaves que os usuários executam no desenvolvimento e gerenciamento de um data warehouse. Entretanto, muitas organizações não têm reconhecido a importância que os usuários exercem durante esse desenvolvimento e, conseqüentemente, perderam a visão da importância em conduzir a evolução do data warehouse através das necessidades de negócio do usuário. O resultado é normalmente um enfoque tecnológico ao data warehouse e não um enfoque do usuário, resultando em um ambiente de informação que não atinge as necessidades da organização para a análise e suporte à decisão [13]. De patrocinador da funcionalidade de negócio para um executivo que precisa monitorar as tendências em uma métrica importante do negócio; de perito de assunto para um usuário técnico altamente qualificado para a obtenção ocasional da informação, usuários têm papéis distintos e importantes a executar na evolução do data warehouse de forma que podem continuar satisfazendo suas exigências de informação sobre o negócio. Os usuários também tem uma responsabilidade significativa como bons cidadãos corporativos para trabalhar com a equipe do data warehouse para assegurarse de que o data warehouse continuará agregando valor à organização através de uma importante ferramenta tática e estratégica de análise e acesso à informação [13]. Um ingrediente essencial para o sucesso do ambiente do data warehouse é o fator humano. O melhor projeto e a melhor arquitetura no mundo não são bem usadas se não existirem pessoas capazes e preparadas para colocarem os planos em ação. 49

50 O ambiente do data warehouse é administrado por uma unidade organizacional chamada grupo de arquitetura de dados. O grupo de arquitetura de dados algumas vezes faz parte da administração de dados. [13]. Em outros casos, o grupo de arquitetura de dados permanece sozinho. Ele está próximo do grupo de sistemas ou do grupo de aplicações [13] Análise do Ambiente Legado Situada entre o ambiente operacional, o data warehouse e o depósito de dados operacionais está a interface de integração e transformação dos dados. Esta interface é o local onde o dados não integrados do ambiente operacional são integrados e enviados ao data warehouse [13]. As tecnologias de sistemas gerenciadores de bancos de dados que normalmente alojam as aplicações do legado mais antigas, usualmente requerem que os dados sejam acessados na forma de um registro por vez. Esta abordagem requer lógica de programa que é familiarizada com a maneira com que os dados são armazenados. Em muitos casos, o dados provenientes de muitas áreas de assunto diferentes são amarrados e controlados pelas aplicações. A execução da integração e transformação dos dados torna-se um problema complexo decorrente do grande volume de dados armazenados no ambiente de aplicações do legado. A integração e transformação dos dados a serem carregados no data warehouse são um dos aspectos mais importantes e devem ser cuidadosamente gerenciados [13]. Como todo o data warehouse depende dos dados disponíveis nas bases de dados operacionais da empresa, o primeiro passo para sua construção é o mapeamento dessas bases, sua limpeza e sincronização com as demais camadas. Para isso, é extremamente necessário conciliar em um único ambiente a administração de todas as bases de dados operacionais que são fonte de alimentação para o data warehouse com a administração do data warehouse em si [24]. Criar um data warehouse não é uma simples questão de escolha de banco de dados ou ferramentas, mas envolve planejamento e modelagem (aspectos que garantem a qualidade dos dados, fator crítico para o sucesso do 50

51 projeto), escolha de ferramentas e atualização e refinamento contínuos. É, de fato, uma arquitetura completa e que se compõe dos seguintes elementos principais: bases de dados operacionais, que são as fontes primárias das informações; processos de extração e conversão de dados; bancos de dados específicos para data warehouse; recursos de administração e ferramentas de inteligência de negócios, que facilitam o acesso, manipulação e análise dos dados contidos no data warehouse [25]. Um armazém de dados é composto de três áreas funcionais distintas, cada uma das quais deve ser customizada para satisfazer as necessidades do negócio. O primeiro componente é a aquisição de dados, podendo ser de sistemas legados ou de outras fontes quaisquer. Lá o dado é identificado, copiado, formatado e preparado para ser carregado no armazém. O segundo componente do armazém é o espaço de armazenamento e o terceiro é a área de acesso aos dados [27]. A busca pelas informações espalhadas pelas diversas aplicações e plataformas tecnológicas, pode ser um problema muito sério. Mesmo que as informações que vão preencher o data warehouse venham apenas de sistemas legados baseados em mainframes, o que nem sempre ocorre, a diversidade de tecnologias envolvidas é grande. Uma recente pesquisa mostrou que apenas 25% das informações desses sistemas estão em bancos de dados relacionais, como o DB2. A grande maioria está espalhada por bancos de dados não relacionais, arquivos VSAM, etc [32]. Um armazém de dados se propõe a compatibilizar um número grande de sistemas desintegrados oriundos do legado a uma coleção igualmente diversa de tipos de estações de trabalho de usuário final. Os ambientes existentes normalmente se compõem de um conjunto de hardware sortido, software e sistemas operacionais incompatíveis e com características únicas a cada organização [27]. A maioria dos armazéns de armazenamento está sendo administrada por bancos de dados relacionais sob plataformas Unix. De acordo com o Meta Group Inc., Oracle, Sybase Inc., IBM Corp. e Informix controlam 65% do mercado de armazéns de armazenamento ; os vendedores de outros bancos 51

52 de dados relacionais e bancos de dados especializados são secundários nesse contexto [27]. Uma questão relevante será como integrar as diversas fontes de dados legadas ou não, arquivos VSAM, DB2, CA-IDMS, CA-DATACOM, OpenIngres, Oracle, Informix, Sybase e mais uma infinidade de outras fontes. A resposta: utilizando gateways que tenham as características de transparência e confiabilidade para sustentar o ambiente de data warehouse [20]. O assunto mais óbvio relativo à interface de integração e transformação refere-se às tecnologias utilizadas pelos sistemas transacionais encontradas no ambiente legado (às vezes chamado de ambiente fonte) como, por exemplo, as tecnologias que são, na maioria dos casos antigas, orientadas à transações e complexas: IMS (Information Management System) um sistema gerenciador de banco de dados hierárquico desenvolvido pela IBM para ambientes mainframe, VSAM (Virtual Storage Access Method) arquivo indexado desenvolvido pela IBM para ambientes mainframe, IDMS, Adabas, Oracle, Sybase, Informix, Arquivos Seqüenciais, etc [13] Equipe de Desenvolvedores O crescimento do data warehouse criou a necessidade de disciplinar o gerenciamento do mesmo que é o papel do administrador do data warehouse (DWA). O DWA é parte administrador de dados, parte administrador de banco de dados, deve posicionar-se um pouco como usuário final, um pouco programador de sistemas e muito de programador e projetista de aplicação [13]. O administrador do data warehouse é um disciplinador organizacional que apareceu com o advento do data warehouse e dos sistemas de apoio à decisão. Ele é o principal responsável pelo sucesso contínuo do armazém de dados [13]. O administrador do data warehouse deve conhecer as várias habilidades abaixo descritas: Projetista da Base de Dados: projeta e constrói o data warehouse. 52

53 Modelador de Dados: integra um novo data warehouse em um já existente. Desenvolvedor: que mantém, nos programas, novas integrações e transformações de dados. Político: solicita e negocia os recursos necessários para a construção do data warehouse. Programador de Sistemas: capacidade de planejamento e refinamento do data warehouse. Usuário final: deve entender as necessidades das áreas de negócio da empresa como, por exemplo, financeira, gerência de vendas, atuarial, engenharia, etc. Em alguns casos, o administrador do data warehouse não somente deve possuir as habilidades acima, mas estar apto a executá-las. Em suma, o administrador do data warehouse é responsável por um ambiente inteiro de suporte à decisão que é o fator crucial para o sucesso da corporação [13]. O Administrador de Data warehouse (DWA) é o responsável pelo data warehouse, envolvendo obter, agendar e coordenar o trabalho entre os recursos humanos, preparando relatórios de situação, orientando revisões de design, garantindo que membros de equipes de trabalho e usuários finais estão sendo efetivamente treinados, e gerenciando outras atividades relacionadas ao Data warehouse como especificado pela gerência da organização [13]. O Administrador de Banco de Dados é essencial na organização da equipe de data warehouse, em número suficiente e dedicados em tempo integral. As diferenças entre os sistemas de informação e operacional da empresa devem ser acompanhadas pelo Administrador de Banco de Dados [13]. O Gerenciador de Metadados deve assegurar que os metadados no Subdiretório de Informações está sincronizado com a produção de recursos, regras de negócio na obtenção de dados, e regras de negócio norteando o acesso dos dados, bem como fontes de conceito de metadados como ferramentas CASE e novas aplicações em desenvolvimento [13]. 53

54 3.2.9 Aspectos da Implementação Física (ROLAP/MOLAP) Quanto à localização dos dados a serem utilizados na análise, atualmente existem duas abordagens: Um banco de dados multidimensional especializado. Um data warehouse implementado com a tecnologia de banco de dados relacional, mas otimizado para a tarefa de análise: Nesse caso, os dados são modelados utilizando um esquema projetado para balancear desempenho e volume de dados. Normalmente é utilizada uma representação desnormalizada da conhecida por esquema estrela. Sistemas OLAP que implementam a primeira abordagem são chamados de MOLAP (Multidimensional OLAP) e aqueles que implementam a segunda são chamados de ROLAP (Relacional OLAP). Em um banco de dados MOLAP, os dados são mantidos em arranjos e indexados de maneira a prover um ótimo desempenho no acesso a qualquer elemento. O indexamento, a antecipação da maneira como os dados serão acessados e o alto grau de agregação dos dados fazem com que sistemas MOLAP tenham um excelente desempenho. Além de serem rápidos, outra grande vantagem desses sistemas é o rico e complexo conjunto de funções de análise que oferecem [7]. Existem algumas limitações nos sistemas MOLAP. Bancos de dados multidimensionais são sistemas proprietários que não seguem padrões (linguagem, Application Program Interface, etc.) estabelecidos pela indústria de banco de dados. Isso se torna uma desvantagem para tais sistemas, uma vez que a arquitetura não é aberta. A utilização das estruturas dimensionais adotadas também traz algumas desvantagens. Mudanças do modelo dimensional requerem uma reorganização do banco de dados, e a estrutura de cubos não suporta a criação ad hoc de visões multidimensionais. Além dessa falta de flexibilidade, sistemas MOLAP enfrentam problemas quanto à escalabilidade porque um dos recursos para garantir o excelente desempenho é manter os índices dos arranjos na memória e isso acaba limitando banco de dados multidimensionais a 20 ou 30 gigabytes de dados, tornando-se, dessa 54

55 maneira, mais apropriados para data marts ou organizações com pequenos data warehouses [7]. Sistemas ROLAP fornecem análise multidimensional de dados armazenados em uma base de dados relacional. A principal vantagem de se adotar uma solução ROLAP reside na utilização de uma tecnologia estabelecida, de arquitetura aberta e padronizada como é a relacional, beneficiando-se da diversidade de plataformas, escalabilidade e paralelismo de hardware [7]. Quanto às limitações, podemos citar o pobre conjunto de funções para análise, a inadequação do esquema estrela para atualização dos dados e as soluções proprietárias para metadados que acaba por anular muitas das vantagens da tecnologia relacional [7]. MOLAP ou ROLAP? Qual escolher? Atualmente existe um grande debate sobre essa questão e, se possível, esse debate deve ser deixado para os fornecedores. Para quem utilizará a tecnologia, o mais importante é entender os negócios da empresa para então decidir pela solução que melhor atende o volume de dados e as necessidades de análise da empresa. Provavelmente esse debate não terá um vencedor. Já se percebe que existe uma convergência dessas duas tecnologias. Fornecedores MOLAP têm adicionado funcionalidade ROLAP nos seus produtos e, igualmente, fornecedores ROLAP têm enriquecido a funcionalidade e desempenho de seus servidores Performance A duração de tempo desde o momento em que um pedido é emitido até o primeiro resultado recebido. A maioria das consultas dos usuários precisa ser processada rápida e eficientemente. O administrador do data warehouse é responsável pela performance de carga de dados, criação de índices e manutenção de metadados, itens importantes ao analisar a performance. 55

56 A maioria dos projetos de data warehouse reside em um sistema gerenciador de banco de dados separado do ambiente OLTP, com um processador dedicado, disco e memória. Esta separação é o melhor ambiente porque, certamente, alivia o processamento e proporciona, ao administrador do data warehouse, liberdade para projetar as bases de dados e suporta uma estrutura de acesso específica para um ambiente de data warehouse onde as consultas são variadas [13]. 56

57 4. APLICAÇÃO Esta seção descreve a modelagem e implementação de um Sistema de Informações Gerenciais sobre Projetos de Pesquisa acadêmicos no âmbito da Universidade Federal de Campina Grande. Utilizamos o Mondrian, um servidor OLAP/WOLAP open source feito em Java [48]. Além disso, para testarmos o modelo dimensional que criamos, utilizamos uma pequena aplicação cliente que vem junto com o Mondrian. A seguir detalhamos a arquitetura do Mondrian e as funcionalidades da aplicação cliente. O Mondrian consiste de quatro camadas. Numa visão top-down temos: a camada de apresentação, a camada dimensional, a camada estrela, e a camada de armazenamento. A camada de apresentação determina o que o usuário final vê na tela do seu computador, e como ele pode interagir para fazer perguntas à aplicação. Há muitos modos para apresentar datasets multidimensional, inclusive tabelas pivot, gráficos de barra, linha ou pizza, e ferramentas avançadas de visualização como mapas interativos e gráficos dinâmicos. Estes poderiam ser escritos em Swing ou JSP, gráficos transformados em JPEG ou GIF, ou transmitiu a uma aplicação remota por XML. [48] A segunda camada é a camada dimensional. A camada dimensional realiza o parser, a validação e a execução das consultas em MDX. Uma consulta é avaliada em múltiplas fases. Os eixos são computados primeiro, em seguida os valores das células de cada eixo. Por questões de eficiência, a camada dimensional envia cell-requests em lotes para a camada estrela. Um transformador de consultas permite à aplicação manipular consultas existentes, em vez de construir uma declaração MDX para cada request. E o metadata descreve o modelo dimensional, e como ele é mapeado para o modelo relational. [48] A terceira camada é a camada estrela, que é responsável por manter um cache agregado. Aqui uma agregação é um conjunto de valores das medidas 57

58 ('células ) em memória, separadas por colunas das dimensões do cubo. A camada dimensional envia requests para conjuntos de células. Se as células pedidas não estão em cache, ou se são deriváveis através de operações rollup, a camada estrela envia um pedido à camada de armazenamento. A camada de armazenamento é um RDBMS (Relational Database Management System). É responsável por prover dados agregados das células, e membros das tabelas dimensionais. [48] Todas estas quatro camadas podem existir na mesma máquina, ou então podem ser distribuídas entre máquinas. As camadas 2 e 3, que incluem o servidor Mondrian, devem estar na mesma máquina. A camada de armazenamento pode estar em outra máquina, acessada por conexão de JDBC remota. Em um sistema multi-usuário, a camada de apresentação existiria na máquina de cada usuário final (menos no caso de páginas de JSP geradas no servidor). [48] Na nossa aplicação, por questões de simplicidade, colocamos todas as quatro camadas do Mondrian em uma máquina. O gerenciador de banco de dados escolhido foi o MySQL 5, que possui integração com XML. Uma exemplo de aplicação cliente para o servidor Mondrian é a ferramenta JPivot, que baseado em JSP (Java Server Pages). No JPivot o usuário pode realizar operações OLAP típicas, como drill-down, roll-up, slice, e dice. A comunicação com o servidor dar-se-á por XMLA. [47] Resumindo, utilizamos as seguintes tecnologias/ferramentas/modelos no nosso projeto: Ambiente de Banco de Dados Gerenciais: Data Warehouse; Servidor OLAP: Mondrian. [48] Modelo Multidimensional: esquema estrela (star scheme); Método OLAP: ROLAP, utilizando o MySQL 5; Interface OLAP: WOLAP, através da ferramenta web-client que vem junto com o Mondrian; Padrão de acesso OLAP: XMLA; Linguagem de Recuperação de Informação: MDX; 58

59 A seguir temos uma figura que mostra toda a arquitetura do servidor Mondrian, destacando suas camadas e componentes. Figura 10: Arquitetura do servidor OLAP utilizada. 59

60 O controle de acesso ao banco de dados dimensional no servidor Mondrian é definido em um arquivo XML. Os elementos que definem as regras de acesso são os seguintes <SchemaGrant> - define o acesso padrão a objetos em um esquema. O atributo de acesso pode ser "all" ou "none"; este acesso pode ser sobrescrito para usuários específicos. Um <CubeGrant> define o acesso a um cubo particular. Como para <SchemaGrant>, o atributo de acesso pode ser "all" ou "none", e pode ser sobrescrito para sub-objetos específicos no cubo. Um <HierarchyGrant> define acesso a uma hierarquia. O atributo de acesso pode ser "all", significando que todos os membros são visíveis; "none", significando que a existência da hierarquia é escondida do usuário; e "custom". Com acesso customizado, pode usar você definir regras de acesso toplevel e bottomlevel, limitando o usuário de realizar as operações roll-up e drill-down no cubo. 4.1 Modelagem Conceitual Informação O diagrama de objetos modela as instâncias das classes contidas no diagrama de classes, isto é, o diagrama de objetos mostra um conjunto de objetos e seus relacionamentos no tempo. Estes diagramas são importantes para construir os aspectos estáticos do sistema. Normalmente, são compostos por: objetos e vínculos. Na figura 10, temos o diagrama de objetos para a classe projeto na modelagem tradicional. 60

61 Figura 11: Diagrama de Objeto Modelo Os diagramas de Classe mostram as diferentes classes que fazem um sistema e como elas se relacionam. Os Diagramas de Classe são chamados diagramas estáticos porque mostram as classes, com seus métodos e atributos bem como os relacionamentos estáticos entre elas: quais classes conhecem quais classes ou quais classes são partes de outras classes, mas não mostram a troca de mensagens entre elas. Na figura 11, temos o diagrama de classe para o nosso projeto. 61

62 Figura 12: Diagrama de Classe 62

63 4.1.3 Meta-Modelo Os meta-modelos da modelagem conceitual do nosso projeto equivalem as linguagens UML e OCL, que são explicados a seguir UML A Linguagem de Modelagem Unificada (Unified Modelling Language - UML) é uma linguagem de diagramação ou notação para especificar, visualizar e documentar modelos de sistemas de software Orientados à Objeto. A UML não é um método de desenvolvimento, o que significa que ela não diz para você o que fazer primeiro e em seguida ou como desenhar seu sistema, mas ele lhe auxilia a visualizar seu desenho e a comunicação entre objetos. A UML é controlada pelo Grupo de Gerenciamento de Objeto (Object Management Group - OMG) [40]. A UML é voltada para o desenho de software Orientado à Objeto e tem um uso limitado para outros paradigmas de programação. Ela é composta por muitos elementos de modelo que representam as diferentes partes de um sistema de software. Os elementos UML são usados para criar diagramas, que representam uma determinada parte, ou um ponto de vista do sistema. A seguir temos a descrição dos principais diagramas UML [40]: Diagrama de Caso de Uso - mostra atores (pessoas ou outros usuários do sistema), casos de uso (os cenários onde eles usam o sistema), e seus relacionamentos. Diagrama de Classe - mostra classes e os relacionamentos entre elas. Diagrama de Seqüência - mostra objetos e uma seqüência das chamadas do método feitas para outros objetos Diagrama de Objeto - modela as instâncias das classes contidas no diagrama de classes. Diagrama de Colaboração - mostra objetos e seus relacionamentos, colocando ênfase nos objetos que participam na troca de mensagens. 63

64 Diagrama de Estado - mostra estados, mudanças de estado e eventos num objeto ou uma parte do sistema. Diagrama de Atividade - mostra atividades e as mudanças de uma atividade para outra com os eventos ocorridos em alguma parte do sistema. Diagrama de Componente - mostra os componentes de programação de alto nível. Diagrama de Distribuição - mostra as instâncias dos componentes e seus relacionamentos OCL A primeira versão da UML foi submetida ao Object Management Group (OMG), organizador do processo de padronização dos modelos e linguagens. A revisão desse modelo mostrou uma grande deficiência na clareza e consistência das definições da UML. Em particular, uma dificuldade encontrada foi que a semânitica da UML poderia ser interpretada em formas ambígüas. O problema foi minimizado com a elaboração de uma nova versão da Unified Modeling Language (UML) a qual foi publicada em O mais importante incremento nesta versão foi a criação da Object Constraint Language (OCL). [41] A OCL é uma linguagem de expressões para especificar restrições sobre modelos orientados a objetos ou outros artefatos da linguagem UML. É uma linguagem precisa, textual e formal. Essa formalidade garante a não existência de interpretações ambígüas para as mesmas restrições, fato que ocorria antes da sua criação. Uma das suas principais características é que seu uso não exige um forte conhecimento matemático para ser utilizada corretamente, como ocorre nos modelos Z e VDM. [41] Na linguagem OCL toda expressão é declarativa no sentido de que expressa o quê a restrição representa no sistema e não como essa restrição é implementada. A avaliação de uma expressão sempre resulta em um valor booleano e nunca muda o estado do sistema no modelo [41]. 64

65 As expressões OCL são utilizadas para definir condições invariantes nas classes representadas em um modelo e também são utilizadas para especificar as pré e pós-condições em operações aplicadas a classes deste modelo. Elas também podem ser utilizadas para fazer consultas a um modelo de classes da UML. Essas consultas podem ser úteis para validar modelos de classes na fase de projeto. A avaliação dessa expressão não devolve um valor booleano, e sim valores de um tipo específico da OCL [41] Regras OCL Regra 1: a área de uma sala deve ser maior que 2m 2 ; Context Sala inv: self.areasala > 2; Regra 2: Um laboratório deve estar sendo usado por pelo menos um projeto. Context Laboratorio inv: self.numprojetos > 0; Regra 3: Cada projeto sempre deve ter um único coordenador. Caso o coordenador saia, outra pessoa deve entrar no lugar. Context Projeto inv: if self.temcoordenador then self.coordenador->count = 1; else then self.coordenador->includes(pessoa); 65

66 Regra 4: Todo professor que for coordenador de um projeto deve participar deste projeto. Context Professor inv: self.coordenaprojeto->iterator(i; i: Projeto; if not i.participaprojeto->including(self) then i.participaprojeto->includes(self); else; Regra 5: Um laboratório deve possuir uma única sala. Context Laboratorio inv: self.sala -> count = Meta-meta Modelo O Meta-meta-Modelo utilizado para modelar o modelo conceitual deste projeto foi o MOF (Meta-Object Facility), um padrão sugerido pela OMG (Object Management Group) que define a estratégia de meta-meta-modelagem do OMG, baseada na orientação a objetos. O MOF é uma meta-meta-modelo para nível de meta-modelos UML (UnifiedModeling Language) que está estruturado em torno de uma hierarquia de múltiplas camadas. O modelo MOF tem uma sintaxe abstrata definida por ele e emprega diagramas de classes UML em sua sintaxe concreta. Para isso, o MOF e UML possuem um núcleo comum alinhado de forma que qualquer meta-modelo oriundo do MOF é passível de representação através de ferramentas CASE que sigam o padrão UML. No MOF a linguagem de meta-modelagem é independente da tecnologia de dados, ou seja, podem ser usada com XML ou modelo relacional, por exemplo. Ele também é independente da linguagem de programação e outras plataformas de tecnologia Data warehouse e MOF No data warehouse a extração e os processos de integração dependem do administrador de banco de dados que cria um mapeamento de esquemas de um banco de dados tradicional para o esquema de um data warehouse [39]. 66

67 A meta-informação para vários bancos de dados é representada usando tecnologia MOF, logo é possível criar ferramentas sofisticadas para ajudar o administrador de banco de dados neste processo [39]. O Meta dados é descrito freqüentemente como o coração e alma do data warehouse. O MOF é usado para automatizar a administração dos meta dados no data warehouse. Atualmente, repositórios de meta dados que administram data warehouse usam meta dados estáticos que usam grupos de arquivos baseados em meta dados que se comunicam [39]. A interface do MOF e o modelo do MOF podem ser usados para definir meta-modelos específicos para banco de dados tradicionais e para o data warehouse. A integração entre estes modelos é feita em tempo real entre o ambiente de desenvolvimento do data warehouse (que possuem o modelo de dados) e os modelos UML (que descrevem os modelos incorporados dos dados e as bases de dados operacionais) este é um uso típico do MOF [39]. 4.2 Modelagem Interna Esta seção mostra os aspectos da modelagem interna, segundo a arquitetura ANSI/SPARC, aplicada ao nosso projeto Diagrama Entidade Relacionamento O diagrama entidade relacionamento é um modelo diagramático que descreve o modelo de dados de um sistema com alto nível de abstração. A sua principal aplicação é para visualizar o relacionamento entre tabelas de uma banco de dados, no qual as relações são construídas através da associação de um ou mais atributos destas tabelas. A Figura 12 mostra o diagrama entidade relacionamento do banco de dados tradicional do nosso projeto. 67

68 Figura 13: Modelo Entidade Relacionamento Relacionamento entre Entidades Existem quatro tipos de multiplicidade no relacionamento entre duas entidades:1-1, 1-N, N-1 e N-N. A figura 13 mostra o relacionamento entre a entidade bloco e a entidade sala do nosso projeto. 68

69 Figura 14: Relacionamento entre Entidades Tabela do Banco de Dados Relacional Um Banco de Dados Relacional é um conceito abstrato que define maneiras de armazenar, manipular e recuperar dados estruturados unicamente na forma de tabelas, construindo assim um banco de dados Tabelas (ou relações, ou entidades) Todos os dados de um banco de dados relacional (BDR) são armazenados em tabelas. Uma tabela é uma simples estrutura de linhas e colunas. Em uma tabela, cada linha contém um mesmo conjunto de colunas, e estas linhas devem seguir a ordem que foi especificada pelo projetista do BDR. Em um banco de dados podem existir uma ou centenas de tabelas, sendo que o limite pode ser imposto tanto pela ferramenta de software utilizada, quanto pelos recursos de hardware disponíveis no equipamento. As tabelas associam-se entre si através de regras de relacionamentos, estas regras consistem em associar um atributo de uma tabela com um conjunto de registros de outra tabela. A Figura 14 mostra uma tabela do banco de dados relacional do nosso projeto que foi criada utilizando o programa MySQL. 69

70 Figura 15: Tabela no Banco de Dados Relacional 4.3 Modelagem Externa Após feita a modelagem conceitual através de UML e seguindo a arquitetura do data warehouse, o próximo passo é realizar a modelagem dimensional. Escolhemos utilizar o esquema estrela como modelo conceitual do banco de dados dimensional. A seguir será descrita as etapas para construção desse esquema a partir do esquema relacional definido na seção 4.2, e a posterior construção do cubo Esquema estrela Como visto anteriormente, no esquema estrela temos uma tabela de fato, que representa o dado mais importante da aplicação, e as tabelas dimensionais. No caso do banco de dados gerenciais de projetos de pesquisa fica fácil perceber que a tabela de fato conterá dados de projetos. A questão agora é definir quantas e quais serão as tabelas dimensionais. Pensando nas principais perguntas que descrevem os atores envolvidos em 70

71 um projeto acadêmico, conseguimos definir as tabelas de dimensões. Abaixo está o esboço do esquema estrela. Figura 16: Esboço do esquema estrela A tabela de fato sabe o o quê é o centro da aplicação, que é justamente os projetos. Cada tabela dimensional reponde uma pergunta crucial. São elas: quem ganha com o projeto?; Quem paga os custos?; Quem realiza o projeto?; Onde será feito o projeto?; Quando será feito?; Qual a categoria do projeto? Ou seja, quais são os discriminadores dos projetos. Com base nessas perguntas, e aproveitando a já definição das tabelas no modelo relacional, chegamos ao modelo dimensional abaixo, mantendo a estrutura estrela: 71

72 Figura 17: Esquema estrela da BD dimensional É interessante relembrar aqui que um das características do modelo dimensional é a não normalização das tabelas. Por exemplo, a tabela Laboratório possui informações sobre a sala, o bloco e o departamento. No modelo relacional precisaríamos de três tabelas para modelar isso, para deixar tudo normalizado. Porém essa normalização aqui não tem necessidade, pois 72

73 essas tabelas do esquema estrela, que faz parte do data warehouse, possuirão os valores contidos nas tabelas do banco de dados operacional, e não serão alterados depois. Essa simplificação facilitará justamente o que se quer com o data warehouse: analisar os dados de forma rápida e simples Cubo Com o modelo estrela construído, podemos construir o modelo lógico do data warehouse, que é chamado de cubo. O modelo estrela é considerado como um modelo físico, enquanto que o cubo um modelo lógico. Isso porque não é necessariamente um cubo propriamente dito, mas uma estrutura de dados que, no contexto da nossa aplicação, permiti a navegação pelos projetos nas dimensões de lugar, tempo, pessoas, etc. Um cubo possui métricas, dimensões, hierarquias e níveis. As métricas das tabelas de fatos são usadas para medir o desempenho do negócio. Hierarquias são estruturas em forma de árvore contendo informações do domínio de uma característica. Para a construção do cubo foi utilizada a ferramenta open-source Pentaho Cube Designer (44). A construção foi feita por uma interface gráfica amigável. Após esta etapa o cubo está pronto, estando descrito em XML. Abaixo um trecho do código do cubo da nossa aplicação, destacando os seus elementos: <?xml version="1.0" encoding="utf-8"?> <Schema name="projetos"> <Cube name="projetos"> <Table name="projeto"/> <Dimension name="local" foreignkey="id_local"> <Hierarchy name="local" hasall="true" allmembername="all local" primarykey="id_local"> <Table name="local"/> <Level name="departamento" table="local" column="departamento" uniquemembers="false"/> <Level name="bloco" table="local" column="bloco" uniquemembers="false"/> <Level name="sala" table="local" column="sala" uniquemembers="false"/> <Property name="area" column="area_sala" type="numeric"/> </Hierarchy> </Dimension>... <Measure name="quantidadeprojetos" column="idprojeto" aggregator="count" datatype="integer" formatstring="#"/> 73

74 <Measure name="mediaavaliacoescliente" column="avaliacaocliente" aggregator="avg" datatype="numeric" formatstring="#,##"/> <Schema> é a raiz do xml. Dentro de um schema pode haver muitos cubos. Na nossa aplicação criamos apenas um: Projetos. Dentro da tag <Cubo> definimos as seguintes dimensões: Local contendo os níveis nessa ordem: departamento, bloco e sala. Dessa forma, o usuário do sistema poderá navegar no sentido departamento -> bloco -> sala. Também definimos uma propriedade dessa dimensão no nível de sala, que é a área da sala. AreaTematica contém os níveis do tema de um projeto: grande área, área e subárea. Equipe contém um único nível, que é o coodenador, e as propriedades referentes a quantidade de estudantes da graduação, mestrado e doutorado e a quantidade de professores envolvidos no projeto. Favorecido dimensão que permitir visualizar os dados do favorecido do projeto. No nosso projeto consideramos apenas o atributo nome. Financiador dimensão que possui o nível setor (público/privado) e o nome do financiador do projeto. Assim, será possível separar os projetos oriundos de verba pública e de verba privada. Cronograma permitirá ao usuário do sistema navegar no sentido ano -> mês nas datas Situação essa dimensão foi acrescenta para que possamos separar os projetos já finalizados dos que estão em andamento. Após a construção do cubo, instalamos um servidor ROLAP chamado Mondrian, também da organização Pentaho, em uma máquina e configuramos o banco de dados que o servidor usaria para extrair os dados. Inserimos dados fictícios no banco de dados diretamente no esquema estrela ao invés do normal que seria inserir no banco de dados operacional criado na seção 4.2. O objetivo deste projeto não era criar toda a infraestrutura de data warehouse, 74

75 mas sim o mínimo necessário para executar consultar MDX em uma base de dados dimensional, construído sobre o esquema estrela. Na etapa de povoamento do bando de dados em estrela, inserimos um total de quinze projetos, dos quais nove representam projetos já finalizados e seis projetos em andamento. Abaixo está o total de linhas (rows) inseridas na base de dados: Figura 18: Povoamento do banco de dados Recuperação da informação A recuperação da informação em um banco de dados dimensional dá-se através de consultas com a linguagem MDX. No nosso projeto, a aplicação cliente é executada no browser, o que caracteriza que nossa solução é ROLAP na camada de persistência, e WOLAP na camada cliente [47], pois realiza as operações OLAP via web. A seguir mostraremos um exemplo de consulta na base de dados criados acima Consultas MDX O MDX é uma linguagem de consulta para banco de dados OLAP, assim como SQL para bancos relacionais. Sua sintaxe possui semelhanças com fórmulas de planilhas eletrônicas. Foi desenvolvida pela Microsoft, e após a invenção do XML para análise (XMLA) a MDX foi padronizada com a linguagem de consulta multidimensional. [45] Uma importante vantagem dessa linguagem é que ela funciona independente da localização do cliente e do servidor dentro dos cubos do 75

76 OLAP. Se eles são localizados na mesma máquina, a comunicação ocorrerá localmente, senão, ela se realizará através da rede. [46] Abaixo está um exemplo de consulta MDX no nosso projeto. Ela cria uma medida virtual (MediaGeral) e a formata. A medida [MediaGeral] não existe fisicamente, sendo assim uma métrica virtual, que é o resultado de uma operação matemática de duas ou mais medidas reais. Nesta consulta, a formatação da string dessa medida virtual terá um estilo (cor de background) vermelho se a média geral for menor que sete, e verde caso contrário. O select selecionará as métricas da tabela Projetos, colocando-os nas colunas da tabela resultado, e os departamentos da dimensão Local estarão nas linhas do lado esquerdo da tabela. A cláusula where executa a operação slice, fatiando o cubo projetos selecionando apenas os projetos finalizados. O resultado da consulta é enviado à ferramenta olap cliente. WITH MEMBER [Measures].[MediaGeral] AS '( ([Measures].[MediaAvaliacoesCliente] + [MediaAvaliacoesComissao]) / 2)', FORMAT_STRING = Iif([Measures].[MediaGeral] < 7.0, ' #.## style=red', ' #.## style=green') SELECT { [Measures].[QuantidadeProjetos], [Measures].[MediaAvaliacoesCliente], [Measures].[MediaAvaliacoesComissao], [Measures].[MediaGeral], [Measures].[OrcamentoProjetos] } on columns, { ([Local].[Departamento].Members) } ON rows FROM Projetos WHERE [Projeto.Situacao].[All situacao].[finalizado] Após executarmos a consulta acima aparecerá no browser a seguinte tabela. No eixo vertical temos a dimensão Local, com os filhos de primeiro nível, que são os departamentos (DEAG, DEE, DEMA e DSC). No eixo horizontal temos as métricas provenientes da tabela fato Projetos. 76

77 Figura 19: Recuperação da informação Relatórios e gráficos A ferramenta possui integração com o Microsoft Excel, possibilitando a exportação do resultado das consultas e navegações para uma planilha do Excel que poderá servir de relatório para o gerente. Abaixo temos um relatório Excel que separa os projetos em área temática e por período de tempo (ano e mês do início), mostrando as métricas consideramos importantes para o usuário do software (o gerente de projetos de P&D da universidade): quantidade de projetos, avaliação média do cliente e da comissão acadêmica, e o orçamento final do projeto. Área Temática Cronograma QtdeProj MAvalCliente MAvalComissao Orcamento (R$) Ciências Biológicas All cronograma Ciências Exatas e All da Terra cronograma ,4 Ciências da All Computação cronograma ,15 All cronograma , , 1998 Banco de Dados , , , , Redes de All Computadores cronograma ,15 Engenharia Agrícola All cronograma ,5 77

78 Engenharia de Materiais Física Matemática Ciências Humanas História Teologia Ciências Sociais Aplicadas All cronograma All cronograma All cronograma All cronograma All cronograma All cronograma All cronograma , , , , ,32 Tabela 2: Relatório dos projetos por área temática e tempo A métrica MediaGeral foi criada nessa consulta, não existindo fisicamente na tabela. Isso permitiu criarmos visões específicas para os usuários. Além disso, na consulta nós formatamos essa medida, para destacar projetos que tiveram boas avaliações e os que tiveram más avaliações. A aplicação possui muitas funcionalidades. Uma delas é a montagem de gráficos a partir dos dados resultantes mostrado na consulta da Figura 18. A seguir temos o gráfico que relaciona os departamentos com e as médias gerais dos projetos realizados neles, contidos na figura acima. Figura 20: Avaliação dos Projetos por Departamento 78