Data Warehouse. Djenane Cristina Silveira dos Santos¹, Felipe Gomes do Prado¹, José Justino Neto¹, Márcia Taliene Alves de Paiva¹

Transcrição

1 Data Warehouse. Djenane Cristina Silveira dos Santos¹, Felipe Gomes do Prado¹, José Justino Neto¹, Márcia Taliene Alves de Paiva¹ ¹Ciência da Computação Universidade Federal de Itajubá (UNIFEI) MG Brasil Resumo. Este artigo aborda os aspectos fundamentais relativos à Data Warehouse. Inicialmente são apresentados as características, os conceitos, a arquitetura e a modelagem do Data Warehouse. Em seguida as ferramentas utilizadas. 1. Introdução Nestes últimos anos, algumas técnicas foram criadas com o proposito de tornar simples a retirada de informações nas bases de dados existentes nas organizações. De acordo com MACHADO (2012) uma análise de dados históricos pode nos apresentar indicadores de crescimento ou sinalizadores de perigo nos negócios, o sucesso de cada ação de negócio hoje em dia depende unicamente de como a organização utiliza seus dados, de forma que os dados possam contribuir para melhor tomada de decisão. A necessidade de oferecer uma visão ampla e unificada dos dados, uma gerencia eficiente das informações separando as regras de negócios das outras tecnologias de armazenamento, tornou-se um desafio a ser resolvido pelas organizações. Para auxiliar as organizações e assim atender a estas necessidades, que surgir a estratégia de criação de Data Warehouses (DW), que é um grande armazém de dados e tem por objetivo disponibilizar estes dados de forma rápida e de fácil entendimento para os usuários. 2. Data Warehouse Data Warehouse é uma técnica de integração dos dados de uma organização em um único repositório. É um ambiente de suporte à decisão que realiza um levantamento de dados armazenados em diferentes fontes e os organiza e então os entrega aos tomadores de decisões que podem facilmente executar consultas, gerar relatórios e fazer análises. No Data Warehouse, os tomadores de decisões não podem efetuar alterações no seu conteúdo, os repositórios são criados no formato de somente leitura. Resumindo, é uma tecnologia de gestão e análise de dados. Segundo MACHADO (2012) o Data Warehouse e um armazém de dados onde a historia da empresa, seus clientes, fornecedores e operações se mantem disponíveis e acessíveis para consultas e análise.

2 Já INMON (1997) considerado o pai do Data Warehouse define da seguinte maneira: Um Data Warehouse é um conjunto de dados orientado por assunto, integrado, variável com o tempo e não-volátil, que fornece suporte ao processo de tomada de decisão. Desta maneira os principais conceitos de Data Warehouse são: Orientado ao assunto: o armazenamento das informações é agrupado por assunto de interesse da organização que são mais importantes. Integrado: um DW armazena dados de várias fontes de dados, dentre diferentes sistemas, planilhas e arquivos, em padrões diferentes e diversas fontes de dados, logo o conceito mais importante aqui é a integração, pois é responsável por sincronizar os dados de todos os sistemas existentes, e assim coloca-los no mesmo padrão. Variável com o tempo: os dados referem-se a algum momento especifico, o dado carregado recebe, na sua chave, uma unidade de tempo e nunca mais e atualizado. Não-Volátil: os dados uma vez carregados nunca mais são alterados pelos usuários, apenas consultados, a não ser em novas cargas de dados, o Data Warehouse e somente de leitura. O Data Warehouse fornece uma plataforma sólida e integrada, que organiza e armazena os dados necessários para processamento informatizado e analítico sobre perspectivas históricas ao longo do tempo. Construir um Data Warehouse é uma tarefa cara e que consome tempo. Em vez de armazenar repetidamente os dados em vários sistemas proprietários, um Data Warehouse pode ser construído para ser acessível por múltiplos aplicativos que desta forma passam a compartilhar uma administração central aberta. A meta principal de um Data Warehouse é a criação de uma visualização lógica única dos dados que estão em diversos bancos de dados físicos, fornecendo aos usuários um modelo de trabalho único dos dados da organização. O acesso a esses dados melhora a qualidade dos serviços e o atendimento ao cliente, ajudando a organização a avaliar atividades do negócio. No Data Warehouse são excluídos os dados que não devem ser usados no processo de suporte à decisão, enquanto no ambiente do banco de dados relacional (BD relacional) as aplicações contêm dados para satisfazer imediatamente as requisições funcionais/processamento que podem ou não ser usadas para análise. Outra importante maneira na qual os dados do BD relacional diferem dos dados para Data Warehouse está no relacionamento dos dados. Dados do BD relacional mantêm relacionamentos entre duas ou mais tabelas baseadas nas regras de negócio que estão em efeito. Dados do Data Warehouse usam um espectro de tempo e os relacionamentos criados no Data Warehouse são muitos. A característica básica do dado em Data Warehouse é ter muitas fontes de dados diferentes. Todo dado no Data Warehouse é exato em algum momento do tempo. No BD relacional o dado é exato no momento do acesso, em outras palavras, quando você acessa uma unidade do dado, você espera que isto deva refletir os valores corretos no momento do acesso. No BD relacional são feitas inclusão, exclusão e alteração em um registro básico. Mas a manipulação de dados básicos que ocorre no Data Warehouse é mais simples. Tem somente duas espécies de operações que ocorre, a carga inicial do dado, e o acesso ao dado.

3 Características BD relacional DW Proposito Processamento Operacional Processamento Informacional Orientado a Transações Análises Funções Operação do dia a dia Somente a decisão Banco de Dados Orientado a aplicação Orientado a assunto Dados Correntes, detalhados Consolidados, históricos Unidade de trabalho Transação Consultas complexas Acesso Leitura, exclusão e inclusão. Leitura Foco Entrada de dados Saída de informações Numero de registros Dezenas Milhares Medidas de performance Tempo processamento de Tempo de processamento de transação consulta Tabela 1 Principais diferenças entre Banco de Dados Relacional e Data Warehouse. Uma das principais diferenças entre Data Warehouse e BD relacional são seus objetivos e a interação entre eles. O BD relacional vem com o intuito básico de relacionar as operações diárias de negócios de uma instituição ou empresa com foco no operacional e com atualizações continuas. Já o Data Warehouse é gerado e alimentado pelas bases de dados relacionais através de processos de coleta, transformação e carga de dados e seu objetivo se dá no âmbito gerencial, e sua atualização é temporal (em lote). E juntamente com ferramentas apropriadas essas bases de dados geram gráficos, planilhas que ajudam na tomada de decisões estratégicas para a empresa. 3. Arquitetura A arquitetura do Data Warehouse varia com a necessidade para que ele é feito. 3.1 Data Mart (DM) O Data Mart representa uma subconjunto do Data Warehouse, pois permite o acesso descentralizado e serve de fonte para os dados que comporão os banco de dados individuais. Os dados do DM são direcionados a um departamento ou uma área específica de processos de negócio. Normalmente é modelado em um esquema estrela de acordo com as necessidades específicas do usuário final. Uma de suas vantagens é a possibilidade de retorno rápido, garantindo um maior envolvimento do usuário final, capaz de avaliar os benefícios extraídos de seu investimento. Figura 1 Representação do Data Mart.

4 3.2 Arquitetura genérica A arquitetura genérica compreende a camada dos dados operacionais que serão acessados pela camada de acesso a dados. As camadas de gerenciamento de processos, transporte e data warehouse são responsáveis por distribuir os dados e estão no centro da arquitetura. A camada de acesso à informação possibilita a extração das informações do DW utilizando um conjunto de ferramentas. Figura 2 - Representação da arquitetura genérica de um Data Warehouse

5 3.3 Arquitetura Global É a arquitetura que suporta a maior parte dos requerimentos ou necessidades de um DW integrado com grande grau de acesso e utilização das informações para todos os departamentos de uma empresa. O termo global reflete o escopo de acesso de utilização das informações na empresa. Essa arquitetura pode ser fisicamente centralizada ou distribuída. A centralização física é utilizada quando determinada empresa existe em um único local e o Data Warehouse é administrado por um departamento de Tecnologia da Informação. No caso da distribuição física de um DW global é utilizada quando a empresa possui diversos locais físicos e os dados em múltiplas instalações físicas com a administração também por um departamento de TI. É comum que a administração e a implementação de um DW seja de responsabilidades de um departamento e de profissionais específicos para o trabalho. Figura 3 - Representação da arquitetura global

6 3.4 Data Mart Independente É a arquitetura preferida de fornecedores de software para consulta de informações de Data Warehouse, onde implica em Data Marts stand alone controlados por um grupo específico de usuários e que atende somente às necessidades específicas e departamentais, sem nenhum foco corporativo. Não existe nenhum tipo de conexão com outros DM. Em caso de necessidade da utilização de dados externos, a área de TI é responsável para adequar layouts de arquivos e necessidade técnicas. 3.5 Data Mart Integrado Nesse tipo de arquitetura os Data Marts são implementados separadamente, entretanto, eles são interconectados, provendo uma maior visão corporativa dos dados. A diferença entre a arquitetura global está no fato de que aqui os dados de um DM podem ser acessados por outro departamento. Essa integração implica que o nível de complexidade é maior que no caso da arquitetura independente e o departamento de TI tem uma atuação maior nesse cenário, ficando sobre sua responsabilidade o controle e administração. 3.6 TIPOS DE IMPLEMENTAÇÃO Implementação Top Down É conhecido como o padrão inicial do conceito de DW. Esse tipo de implementação requer um planejamento muito grande e trabalhos de definições conceituais de tecnologia completos antes de se iniciar o projeto propriamente dito. O processo se inicia com a extração, a transformação e a integração das informações dos sistemas operativos e dados externos para um ODS, e só então os dados e matadados são transferidos para DW. A partir do DW são extraídos dados e metadados para os DM. Vantagens: força a empresa a definir regras de negócio de forma corporativa e integrada antes do início do projeto. Outra vantagem é a herança da arquitetura, pois como os Data Marts são originados de um Data Warehouse, a sua manutenção é fácil. Desvantagens: implementação muito longa, custo alto e alta taxa de risco, uma vez que não existem garantiaspara o investimento nesse tipo de ambiente Implementação Bottom Up Esse tipo de implementação permite que o planejamento e o desenho dos DM possam ser realizados sem esperar a conclusão da construção do DW. É uma alternativa bastante escolhida pelos executivos por possuir um retorno do investimento bastante rápido. O propósito dessa implementação é a construção de um DW incremental a partir do desenvolvimento de DM independentes. O processo dessa implementação começa com a extração, transformação e integração dos dados para um ou mais DM, os quais são modelados com base em um modelo dimensional.

7 Vantagens: possui implementação rápida e menos custoso, além de retorno financeiro rápido. Desvantagens: dificuldade de padronização, risco de redundânciasm e inconsistências entre DM Implementação Combinada Tem o propósito de integrar a arquitetura top down e bottom up. Possuem a visão macro, sendo o passo seguinte à implementação de partes desse modelo. Os DM são gerados a partir de macromodelos de dados do DW e integrado ao modelo físico do Data Warehouse. A sua principal vantagem é a garantia da consistênca dos dados, obtida em virtude de o modelo de dados para os Data Marts ser único, possibilitando realizar o mapeamento e controle dos dados. 4. Modelagem OLAP (On-Line Analytical Processing) é um conjunto de tecnologias projetadas para suportar análise e consultas ad hoc. Com a ajuda desses sistemas, analistas e executivos podem sintetizar informações sobre a empresa, por meio de comparações, visões personalizadas, análise histórica e projeção de dados em vários cenários de "e se...". Ambientes multi-usuário e arquitetura cliente-servidor implementam estes tipos de sistema que oferecem respostas rápidas e consistentes às consultas executadas pelos analistas, independente do tamanho e complexidade do banco de dados. A visão conceitual multidimensional dos dados de uma empresa é a principal característica dos sistemas OLAP. Ao contrário da visão tabular utilizada nos sistemas de processamento de transação, a visão multidimensional é muito mais útil para os analistas pois ela é mais natural, fácil e intuitiva, permitindo a visão em diferentes perspectivas dos negócios da empresa e desta forma fazendo com que o analista se torne um explorador da informação. Para representar o OLAP, podemos considerar três abordagens diferentes: ROLAP (Relacional OLAP) MOLAP (Multidimensional OLAP) HOLAP (Híbrido OLAP) A representação ROLAP dá ao banco de dados relacional características dimensionais. As tabelas de sumário são criadas no SGBD relacional e nenhum dado é movido para o servidor OLAP. Os índices das tabelas de sumário são criados automaticamente e possui um baixo desempenho em consultas apesar de poder usar o padrão SQL. A representação MOLAP é um banco de dados multidimensional que utiliza tecnologia proprietária num conjunto de interfaces de usuário, aplicações e bancos de dados. Os dados são armazenados em um cubo de diversas dimensões. Os dados são trazidos para o servidor OLAP e sua organização em arranjos permite alta granularidade e consultas mais rápidas em relação ao método relacional. Pelo fato de serem sistemas proprietários, o

8 MOLAP não utiliza o padrão básico de banco de dados, as mudanças que possam ocorrer acarretam a reorganização de todo banco, pouca escalabilidade e a criação ad-hoc não é suportada para visões multidimensionais. A representação HOLAP combina as principais características das duas representações anteriores. É uma nova tecnologia que tem por objetivo resolver os problemas descritos nas outras abordagens. Os bancos de dados retêm os dados e as agregações ficam no MOLAP, com a desvantagem de que torna-se mais lento que a abordagem MOLAP quando a consulta é feita sobre dados básicos. O modelo dimensional para construção de banco de dados para Data Warehouse é uma forma de modelagem onde as informações se relacionam de forma que pode ser representada como um cubo. Sendo assim podemos fatiar este cubo e aprofundar em cada dimensão ou eixo para extrair mais detalhes sobre os processos internos que ocorrem na empresa que em um modelo relacional torna-se muito complicados de serem extraídos e muitas vezes até impossíveis de serem analisadas. O modelo dimensional permite visualizar dados abstratos de forma simples e relacionar informações de diferentes setores da empresa de maneira muito eficaz. O que torna o Data Warehouse mais poderoso é que informações que se situam em vários sistemas, planilhas e arquivos espalhados por todos os setores da empresa, são reunidos em um banco de dados de forma dimensional, sendo assim tendo informações unificadas e padronizadas em um mesmo local. O objetivo é buscar um padrão de apresentação de dados que seja facilmente visualizado pelo usuário final e que possua um bom desempenho para consultas. O modelo dimensional é formado por uma tabela central (tabela de fatos) e várias outras a ela interligadas (tabelas de dimensão), sempre por meio de chaves especiais, que associam o fato a uma dimensão do cubo. Vejamos um exemplo de uma empresa que possui diversas lojas, e que precisa acompanhar o desempenho de suas vendas ao longo do tempo. O cubo visualizado abaixo pode ser descrito com três dimensões principais: Tempo Loja Produto

9 Figura 4 - Exemplo de um cubo Neste modelo cada cubo menor representa uma quantidade de um produto que foi vendido em uma determinada loja em uma data especifica. Um modelo dimensional pode ter quantas dimensões forem necessárias. Por exemplo, se quisermos saber se determinados produtos vendidos estavam em promoção, teríamos que ter mais uma dimensão chamada promoção. Quando há muitas dimensões, não é possível desenhar graficamente, mas o conceito de cubo é o mesmo, pois é possível navegar, aprofundar-se, detalhar e acompanhar os desempenhos destas dimensões ao longo do tempo. Abaixo, encontram-se alguns conceitos importantes sobre a modelagem multidimensional: Dimensões: Estabelecem a organização dos dados, determinam as consultas e cruzamentos. Por exemplo: região, tempo, produtos,... Cada dimensão pode ter elementos, chamados membros, organizados em diferentes níveis hierárquicos. Por exemplo, a dimensão produto pode ter duas hierarquias: estoque (com os níveis quantidade e preço de custo) e vendidos (com os níveis quantidade vendida e preço de venda). Medidas: São os valores a serem analisados, como médias, totais e quantidades. Fatos: Dados que serão agrupados, que contém os valores das medidas para cada combinação das dimensões existentes. Agregações: Totalizações calculadas nos diversos níveis hierárquicos. 4.1 Tipos de Modelos Dimensionais Modelo Estrela (Star Schema) O esquema estrela é um tipo de abordagem para desenvolvimento da modelagem dimensional de um Data Warehouse. A baixa quantidade de tabelas e relacionamentos resulta em uma

10 estrutura simples que diminui sua complexidade e aumenta seu desempenho. Devido a simplicidade do esquema podemos ressaltar que a construção de consultas torna-se mais fácil além de consumir menos recursos de banco de dados. Em contra-partida, devido a integração das informações em poucas tabelas para que o usuário possa realizar consultas analíticas é necessário utilizar ferramentas desenvolvidas especificamente para este tipo de modelo. Figura 5 - Estrutura de uma Modelagem utilizando o Esquema Estrela A Figura acima apresenta a estrutura do esquema estrela. Este modelo é chamado de estrela porque a tabela de fatos fica ao centro cercado das tabelas dimensionais assemelhado a uma estrela. Mas o ponto forte a fixar é que as dimensões não são normalizadas, então os campos das tabelas de dimensões contêm suas descrições repetidas em cada registro, aumentando o tamanho das tabelas por repetir estas descrições de forma textual em todos os registros. Podemos notar que ao centro temos uma tabela composta pelas chaves de ligação entre as dimensões e os dados consolidados, e a sua volta estão as tabelas dimensão compostas pelas demais informações que complementam o fato. Este tipo de esquema não está restrito a apenas uma tabela fato, ou seja, é possível que haja mais de uma tabela fato se relacionando através de dimensões, porém é mais comum visualizar o esquema separado por fato devido a sua baixa complexidade na visualização.

11 4.1.2 Modelo Floco de Neve (Snow Flake) Figura 6 - Exemplo de Modelagem utilizando o Esquema Floco de Neve O Modelo Floco (Snow Flake) reduz o espaço de armazenamento dos dados dimensionais mas acrescenta várias tabelas ao modelo, deixando-o mais complexo, tornando mais difícil a navegação pelos softwares que utilizarão o banco de dados. Outro fator é que mais tabelas serão utilizadas para executar uma consulta, então mais JOINS de instrução SQL serão feitos, tornando o acesso aos dados mais lento do que no modelo estrela. O Modelo Estrela (Star Schema) é mais simples e mais fácil de navegação pelos softwares, porém desperdiça espaço repetindo as mesmas descrições ao longo de toda a tabela, porém análises feitas mostram que o ganho de espaço normalizando este esquema resulta em um ganho menor que 1% do espaço total no banco de dados, sendo assim existem outros fatores mais importantes para serem avaliados para redução do espaço em disco como a adição de agregados e alteração na granularidade dos dados.

12 Portanto o mais recomendado é o modelo estrela, pois fornece um acesso mas rápido aos dados possui uma navegação mais, criando tabelas auxiliares somente para dimensões especificas quando for estritamente necessário ou quando demonstrar um beneficio que justifique a perda de desempenho nas consultas, que não é tão grande dependendo da forma como estas tabelas são construídas e a quantidade de registros que elas mantém. 5. Ferramentas 5.1 Plataforma Pentaho O software Pentaho é uma plataforma open source utilizada para criação de soluções de Business Inteligence (BI), que inclui recursos de geração de relatórios, integração e armazenamento de dados (datawarehousing), análise de informações (OLAP), painéis (dashboards) para controle gerencial e mineração de dados (Data Mining). BI refere-se ao processo de coleta, organização, análise, compartilhamento e monitoramento de informações que oferecem suporte a gestão de negócios. O Pentaho apresenta arquitetura do tipo cliente-servidor. O Pentaho BI Server é responsável por toda a camada servidora da plataforma do Pentaho e fornece a arquitetura e infraestrutura necessária para a construção de soluções para BI. Entre os serviços essenciais encontramos: autenticação, logs, auditoria, serviços web, motores de regras de negócio, mecanismo para integração com relatórios, mecanismo para integração de análises, mecanismo para integração com dashboards e mecanismo para integração com mineração de dados. Sua arquitetura é baseada em plug-in permitindo que a totalidade ou parte da plataforma seja incorporada a aplicações de terceiros; é composto por diversos outros aplicativos open source, entre eles: Apache TomCat, Hibernate, Spring Security, etc. Do lado cliente encontramos as ferramentas: PDI (Pentaho Data Integration), PRD (Pentaho Report Designer), PME (Pentaho Metadata Editor), PSW (Pentaho Schema Workbench), entre outras. Na figura abaixo podemos observar um processo simplificado de BI e onde as ferramentas Pentaho atuam dentro do processo.

13 Figura 7 Processo Simplificado de BI. Disponível em [10] OLTP (Online Transaction Processing ou Processamento de Transações em Tempo Real) são sistemas que se encarregam de registrar todas as transações contidas em uma determinada operação organizacional. Por exemplo: sistema de transações bancárias que registra todas as operações efetuadas em um banco, caixas de multibanco, reservas de viagens ou hotel on-line, cartões de crédito. Já ETL, do inglês Extraction, Transformation and Load (Extração, Transformação e Carga), são ferramentas de software cuja função é a extração de dados de diversos sistemas, transformação desses dados conforme regras de negócios e por fim a carga dos dados geralmente em um Data Mart (DM) e um Data Warehouse (DW). Os projetos de DW consolidam dados de diferentes fontes. A maioria dessas fontes tendem a ser bancos de dados relacionais ou arquivo de texto (texto plano), mas podem existir outras fontes. Um sistema ETL tem que ser capaz de se comunicar com as bases de dados e ler diversos formatos de arquivos utilizados por toda a organização. Essa pode ser uma tarefa não trivial, e muitas fontes de dados podem não ser acessadas com facilidade. 5.2 PDI e Data Warehouse A ferramenta utilizada para fazer o processo de ETL é a Pentaho Data Integration - PDI, mais conhecida como Kettle. É uma ferramenta de código fonte aberto e sob a licença LGPL. Sendo uma ferramenta de ETL, ela foi construída para coletar dados de várias fontes distintas (Extract), mover e modificar dados (Transform) e carregar estes dados (Load) no destino final, que geralmente é um data warehouse. O PDI pode ser dividido conforme abaixo: Spoon: É uma ferramenta gráfica usada para modelar as transformações e os jobs; Transformation: modelo que captura o fluxo de dados de entrada e faz uma transformação até atingir o destino final.

14 Job: modelo que tem entradas como transformações (transformations), downloads FTP, etc., e saídas como envio de s, por exemplo. Pan: Ferramenta de linha de comando usada para executar transformations. Kitchen: Ferramenta de linha de comando usada para executar jobs. O PDI pode funcionar diretamente integrado a um repositório (um SGBD) ou utilizando arquivos. Se conectado a um SGBD não será necessário se preocupar com o armazenamento das transformações e jobs criados, pois isso será feito automaticamente pela ferramenta no banco de dados Transformações O objetivo de uma transformação é pegar um dado, sobre esse dado realizar algum ajuste e passar esse dado para outro lugar. A origem e o destino podem ser uma tabela de um banco de dados, uma planilha do excel, um arquivo texto, entre outros. Nas transformações todos os passos são executados ao mesmo tempo. Transformações não aceitam laços (loops) e não tomam decisões (IF) Jobs Figura 8 Exemplo de Transformação. Disponível em [2] O job é um recurso do PDI útil para automação de rotinas de carga; com ele é possível criar e controlar uma sequencia de passos, que podem ser chamadas para transformações existentes.

15 Figura 9 Job do PDI. Disponível em [2] As setas que definem o fluxo de execução recebem cores. A cor verde indica o caminho que deve ser seguido caso seja verdadeiro. A cor vermelha indica o caminho a ser seguido caso seja falso e a cor preta indica o caminho que deve ser seguido incondicionalmente. Jobs executa o serviço alto nível: disparam transformações, movem arquivos, se comunicam com administrador humano, executam laços simples e tomam decisões. O PDI oferece uma interface amigável para criação e execução de transformações e jobs, mas é possível via linha de comando executá-los. A principal diferença entre transformações e jobs é que o job executa cada etapa antes de passar para a próxima (ou seja, é sequencial), enquanto que a transformação executa todas as etapas ao mesmo tempo. 5.3 Pentaho e Mondrian O Mondrian é um servidor OLAP feito em Java. Pentaho embutiu o Mondrian (OLAP Server) em sua atual solução de BI. Com um servidor OLAP é possível criar cubos OLAP. A funcionalidade OLAP é inicialmente caracterizada pela análise dinâmica e multidimensional dos dados consolidados de uma organização permitindo que as atividades do usuário final sejam tanto analíticas quanto navegacionais. As ferramentas OLAP (do inglês, Online Analytical Processing) são geralmente desenvolvidas para trabalhar com banco de dados desnormalizados. Essas ferramentas são capazes de navegar pelos dados de um Data Warehouse, possuindo uma estrutura adequada tanto para a realização de pesquisas como para a apresentação de informações; possibilita efetuar a exploração dos dados de um Data Warehouse.

16 DW e OLAP são complementares. Para explorar o DW completamente, você precisa do OLAP para extrair e alavancar totalmente as informações que ele contém. O Mondrian necessita de um esquema para gerar os cubos. É necessário criar o schema para identificação do cubo OLAP, pois o modelo do banco dimensional não é suficiente para o Pentaho identificar os cubos e dimensões. É necessário criar um arquivo XML descrevendo quais são os cubos e dimensões e suas respectivas tabelas associadas. Além disso, a partir desse XML, gerar um XACTION, que é o arquivo que irá ser identificado pelo Pentaho. O PSW (Pentaho Schema Workbench) realiza o processo de gerar o esquema OLAP e faz a publicação do xml automaticamente. Dentre as funcionalidades do PSW temos: Editor de esquema integrado Testes das consultas MDX (Multi-dimensional Expressions - Linguagem criada pela Microsoft para definir consultas multi-dimensionais) nos esquemas e nas bases de dados. Visualização da estrutura de bases de dados. Figura 10 Criação do Cubo no Schema-Workbench. Disponível em [8] Figura 11 Criando dimensões e hierarquias no cubo. Disponível em [8]

17 Figura 12 Preenchendo informações da dimensão. Disponível em [8] Figura 13 Versão final do cubo. Disponível em [8] 6. Conclusão O Data Warehouse e uma ferramenta que permite aos tomadores de decisões acesso aos dados de forma integrada, rápida e precisa, proporcionando uma melhora na qualidade dos serviços. A implementação do Data Warehouse pode ser feita tanto localmente quanto distribuída. Também é possível utilizar apenas parte do DW, como Data Marts, entretanto, nesse caso a implementação é mais simples e muitas vezes não atinge o propósito de possuir um foco coorporativo. Vale ressaltar que a implementação pode ser de formas diferentes, onde na forma top down o produto final é de melhor qualidade, mas muito custoso e demorado, enquanto que se utilizando da forma bottom up, é mais barato e rápido, mas muito mais passível de erros e redundâncias.

18 Percebemos que o sistema OLAP no modelo multidimensional pode ser dividido em três abordagens, cada uma com suas peculiaridades e que o modelo multidimensional permite uma visualização simples dos dados abstratos. Todas as informações são unificadas e padronizadas e que o modelo estrela possui certa vantagem em relação ao modelo floco de neve. Referências [1] BERNARDO, Luís; FERREIRA, Manuele; MAIOR, Bruno; RAMOS, Gustavo; SILVA, Robson. Plataforma Pentaho de Business Intelligence Manual de Utilização. Universidade Federal da Bahia. Departamento de Ciência da Computação. Disponível em Acessado em 15 de Novembro de [2] COELHO, Bruno J. I. Pentaho Data Integration (PDI). Disponível em Acessado em 15 de Novembro de [3] FERREIRA, Rafael; Data Warehouse na Prática: Fundamentos e Implantação. Universidade Federal do Rio Grande do Sul. Instituto de Informática. Disponível em Acessado em 17 Novembro [4] HORITA, Flavio; Modelagem Dimensional. delagem-dimensional&catid=43:business-intelligence&itemid=57 Acessado em 11 de Novembro de [5] INMON, Willian H. Como Construir o Data Warehouse. Tradução: Ana Maria Neto Guz. Rio de Janeiro: Campus, [6] MACHADO, Felipe N. R. - Tecnologia e Projeots de Data Warehouse. 5. edição, São Paulo, [7] MOREIRA, Eduardo; Modelo Dimensional para Data Warehouse. Acessado em 11 de Novembro de [8] Professor Coruja Business and Open Source Technology. Entendendo o Mondrian OLAP Server. Disponível em Acessado em 15 de Novembro de [9] ROHDEN, Rafael B; Banco de Dados Relacional x Multidimensional. Universidade Regional do Noroeste do Estado do Rio Grande do Sul. Departamento de Tecnologia. Disponível em Multidimensional. Acessado em 12 de Novembro de [10] SOUZA, Vanessa. Data Warehouse. Universidade Federal de Itajubá. Instituto de Ciências Exatas. Departamento de Matemática e Computação. Disponível em Acessado em 15 de Novembro de 2013.