ESCOLA SUPERIOR ABERTA DO BRASIL ESAB CURSO DE ENGENHARIA DE SISTEMAS RACHEL TEREZA MENEGAZZO

Transcrição

1 ESCOLA SUPERIOR ABERTA DO BRASIL ESAB CURSO DE ENGENHARIA DE SISTEMAS RACHEL TEREZA MENEGAZZO IMPLEMENTANDO UMA SOLUÇÃO OLAP UTILIZANDO SOFTWARE LIVRE CURITIBA PR 2009

2 RACHEL TEREZA MENEGAZZO IMPLEMENANDO UMA SOLUÇÃO OLAP UTILIZANDO SOFTWARE LIVRE Monografia apresentada à ESAB Escola Superior Aberta do Brasil sob orientação da Professora Beatriz Christo Gobbi. CURITIBA PR 2009

3 RACHEL TEREZA MENEGAZZO IMPLEMENTANDO UMA SOLUÇÃO OLAP UTILIZANDO SOFTWARE LIVRE Aprovada em 06 de Abril de CURITIBA PR 2009

4 Á Deus pela vida. A meus pais pelo exemplo e sabedoria. Aos meus filhos Guilherme, Helena e Marcelo que sempre me apoiaram em todas as minhas iniciativas.

5 Só quem sonha o azul do vôo sabe o seu poder de pássaro. (Thiago de Mello)

6 RESUMO As técnicas de construção de data warehouse (DW) e uso ferramentas on-line analytical processing (OLAP) para permitir o armazenamento e consulta a informações estratégicas como apoio ao processo de tomada de decisão têm despertado o interesse de organizações desde os anos 90. De encontro a essa tendência, este estudo tem como objetivo conhecer e apresentar os conceitos necessários para implementação de uma solução OLAP com uso de ferramentas Open Source. Como etapas para alcançar este objetivo, inicialmente foi feita uma abordagem dos conceitos envolvidos e relacionados a OLAP e na sequência os softwares escolhidos para montagem do ambiente operacional foram apresentados conforme utilização específicas através de um estudo de caso. Os autores consultados destacam que OLAP é uma tecnologia recente que tem recebido desenvolvimentos significativos nos últimos 10 anos e que apresenta uma grande diversidade nas possibilidades de aplicação, ficando o sucesso do empreendimento a cargo das decisões a serem tomadas quanto a componentes, arquitetura e projeto. A pesquisa mostra também que existem opções de uso de software livre, possibilitando uma escolha por parte das empresas e órgãos do governo em adotar outras soluções tecnológicas além dos softwares proprietários, usufluindo desta forma de tecnologias de ponta a preços acessíveis para alavancar seu desenvolvimento. Conclui-se colocando que o trabalho contribui para o conhecimento da tecnologia de data warehouse e ferramentas OLAP e sua aplicação no processo de suporte a decisão, possibilitando ao usuário chegar a resultados significativos através de consultas complexas feitas de modo relativamente simples utilizando ferramentas Open Source.

7 LISTA DE FIGURAS Figura 1 - Integração dos dados...18 Figura 2 - Elementos básicos do data warehouse...20 Figura 3 - Implementação top-down...25 Figura 4 - Implementação botton up...25 Figura 5 - Modelo estrela...30 Figura 6 - Modelo Estrela visão relacional...30 Figura 7 - Modelo Floco de Neve ou Snowflake...31 Figura 8 Cubo...32 Figura 9 - Hierarquias...34 Figura 10 - Exemplo de arquivo XML definindo um schema mondrian...41 Figura 11 - Consulta MDX...42 Figura 12 - Resultado da consulta MDX da figura Figura 13 - Extração de dados...47 Figura 14 - Transformação de dados...48 Figura 15 - Script de transformação no Kettle...48 Figura 16 - Tipo de alta...51 Figura 17 - Composição da dimensão tempo...51 Figura 18 Transformação para gerar a dimensão tempo...52 Figura 19 - Cubo emergência1.no Schema Workbench...53 Figura 20 - Tela do Discoverer Cubo, medida, dimensões e montagem da consulta...54 Figura 21 - Navigator - Seleção de filtros Figura 22 - Table viewer Atendimento do mês de março/2008 por sexo e de 0 a 6 anos Figura 23 - Resultado de consulta em formato PDF...55 Figura 24 - Gráfico da consulta visualizada na figura Figura 25 - Operação drill through...57 Figura 26 - Operação slice and dice perspectiva.a...58 Figura 27 - Operação slice and dice perspectiva.b...58 Figura 28 - Operação slice and dice perspectiva.c...58

8 LISTA DE QUADROS Quadro 1 - Faixa etária de sete anos Quadro 2 -Faixa etária de dez anos Quadro 3 - Tempo de permanência...49 Quadro 4 - Descrição dos capítulos do CID Quadro 5 - Motivo e tipo de alta...51

9 LISTA DE SIGLAS OLAP On-Line Analytical Processing OLTP On-Line Transaction Processing HOSPUB Sistema de Gestão Hospitalar DM Data Mart DW Data Warehouse ETC Extração, Transformação e Carga de Dados HOLAP Hybrid On-Line Analytical Processing MOLAP Multidimensional On-Line Analytical Processing MS Microsoft ROLAP Relational On-Line Analytical Processing SGBD Sistema de Gerenciamento de Banco de Dados SGBDR Sistema de Gerenciamento de Banco de Dados Relacional SQL Structured Query Language (Linguagem de Consulta Estruturada) XML extensible Markup Language MDX Multidimensional Expression (Expressão Multidimensional) API Application Programming Interface (Interface de Programação de Aplicativos) JDBC Java Data Base Conector. CID10 Classificação Estatística Internacional de Doenças e Problemas Relacionados à Saúde Décima revisão.

10 SUMÁRIO 1 INTRODUÇÃO DATA WAREHOUSE CARACTERÍSTICAS Orientação por Assunto Variação no tempo Não volatilidade Integração COMPONENTES E ARQUITETURAS DE IMPLEMENTAÇÃO Componentes Sistemas operacionais de origem Data staging area Área de apresentação de dados Ferramentas de acesso a dados Papeis Arquiteturas GRANULARIDADE DE DADOS METADADOS MODELAGEM PARA DATA WAREHOUSE MODELAGEM MULTIDIMENSIONAL OU DIMENSIONAL Modelo Estrela ou Star Modelo floco de neve ou snowflake Cubos Fatos Dimensões Medidas Hierarquias ON-LINE ANALYTICAL PROCESSING ARQUITETURAS OPERAÇÕES BÁSICAS OLAP Slice-and-Dice Drill Down e Roll Up...37

11 4.2.3 Drill Across Drill Through TECNOLOGIAS Kettle Mondrian Camada de apresentação Camada Dimensional Camada Estrela Camada de armazenamento Mondrian Schema Workbench Mdx (Multidimensional Expressions) Jrubik MySql ESTUDO DE CASO NECESSIDADE IDENTIFICANDO A FONTE DOS DADOS: EXTRAÇÃO, TRANSFORMAÇÃO E CARGA - ETC IMPLEMENTANDO OS CUBOS OLAP CONSULTAS CONCLUSÃO...59

12 12 1 INTRODUÇÃO Data Warehouse Modelagem Multidimensional On-Line Analytical Processing Trabalhar a informação, do nível operacional ao estratégico, é um aspecto relevante para alcançar o sucesso em todas as áreas de atuação. A necessidade de respostas confiáveis, em tempo hábil, que retratem a realidade ou apontem caminhos futuros tem movimentado profissionais de tecnologia da informação na busca de novas soluções tecnológicas. Na área da saúde, especificamente falando do Sistema Único de Saúde, onde são utilizados uma variedade de sistemas de informação atendendo aos níveis Federal, Estadual e Municipal, encontramos sistemas que em sua maioria utilizam diferentes bancos de dados, transacionais, atendendo basicamente o nível operacional e administrativo. A decisão de escrever este trabalho foi a partir da constatação da grande dificuldade quem encontrei como profissional da área de tecnologia da informação, diante da necessidade de extrair dados gerenciais de bancos de dados transacionais. É comum nesta área de atuação, Sistema Único de Saúde, encontrar em um único ambiente operacional vários sistemas informatizados, quase sempre não integrados, atendendo basicamente as necessidades operacionais diárias e imediatas de informação. A integração dos sistemas fica difícil e trabalhosa, visto a diversidade de soluções implementadas ao longo do tempo, sendo muitas vezes inviabilizada por barreiras tecnológicas e a forma como se encontram pulverizados os sistemas nas esferas municipal, estadual e federal. Então, um simples relatório gerencial, para ser realizado em tempo hábil mobiliza um exército de pessoas, utilizando recursos rudimentares e deixando no ar a incerteza dos resultados. Por isso, o processo de extração, tratamento e armazenamento de dados, bem como o processo de modelagem multidimensional para permitir a maximização de consultas com o uso de ferramentas OLAP despertou grande curiosidade e interesse.

13 13 Pode-se dizer que a situação encontrada no Sistema Único de Saúde é bastante similar a descrita por Machado (2008,p.26), como justificativa para a aplicação de tecnologia de Data Warehouse, a seguir: Várias plataformas de hardware e software. Constantes alterações nos sistemas transacionais corporativos. Dificuldade acentuada na recuperação de dados históricos em períodos superiores ao ano atual de operações. Existência de sistemas pacotes de fornecedores diferentes. Falta de padronização e integração dos dados existentes nos diversos sistemas. Carência de documentação e segurança no armazenamento dos dados. Dificuldade de aplicação de sistemas EIS ou DSS devido a dependências múltiplas de sistemas corporativos. Tomando como base o modelo de montagem de Data Warehouse apresentado, a empresa pode optar por construí-lo em uma base global ou em bases teoricamente locais de acordo com as áreas de negócios. Isso implica na utilização de arquiteturas específicas para a construção de um Data Warehouse, as quais têm evoluído desde o princípio dos conceitos de Data Warehouse até o momento atual sempre em busca do sucesso de sua utilização. Frente a este cenário, o presente trabalho tem como objetivo geral conhecer conceitos e um conjunto de ferramentas para implementação de uma solução OLAP (On-Line Analytical Processing), utilizando software livre. Como etapas para alcançar este objetivo, inicialmente é feita abordagem dos conceitos envolvidos e relacionados a OLAP e na sequência os softwares escolhidos para montagem do ambiente operacional são apresentados conforme utilização específicas de cada um e demonstrados os exemplos de um estudo de caso. Como escopo do trabalho os processos de um Data Warehouse e ferramentas OLAP. Como processos a extração dos dados dos sistemas legados, a organização e integração desses dados para compor o data warehouse e o acesso aos dados para consultas de forma rápida e extremamente flexível, auxiliando como ferramenta de apoio a tomada de decisão. Para exemplificar a utilização das ferramentas é apresentado um estudo de caso sobre um hospital público, limitando o escopo de aplicação e demonstração de uso das ferramentas ao setor de atendimento de emergência hospitalar. Por questões de segurança das informações é utilizado uma base de dados onde os dados pessoais

14 14 dos pacientes, como nomes e endereços, são omitidos. O hospital em questão é o Hospital do Trabalhador, referência em atendimentos ao trauma na região de Curitiba, estado do Paraná, que nos últimos cinco anos vem se informatizando e fazendo uso de um sistema de gestão hospitalar, HOSPUB, desenvolvido e disponibilizado pelo Ministério da Saúde. Para possibilitar consultas que atendam a níveis estratégicos da administração e prover a direção do hospital de respostas hoje não disponíveis nos sistemas tradicionais em tempo real, também conhecidos como On-Line Transaction Processing (OLTP), a construção de um ambiente de data warehouse tornou-se uma opção viável técnica e financeiramente, considerando a opção do uso de software Open Source. Os softwares utilizados para compor o ambiente com o propósito de demonstrar a utilização da técnica Olap são independentes de plataforma e são: Para o processo de extração, transformação e carga dos dados é utilizado ferramentas do Projeto Kettle, onde Kettle é um acrônimo para "Extraction, Transformation, Transportation and a Loading Data Enviroment". Como banco de dados é utilizado o MySql e como ferramentas para modelagem e apresentação dos dados são utilizados o Mondrian Workbench e Jrubik, respectivamente. A escolha desse conjunto de ferramentas é unicamente para possibilitar a construção de um ambiente teste para o propósito da pesquisa e possível de implementação dado o escasso período de tempo disponível para a sua conclusão. Entretanto, vale ressaltar que outras opções de softwares podem ser compostas, como por exemplo a utilização combinada do servidor Mondrian com o jpivot. Este trabalho é realizado através de uma combinação do Método de pesquisa exploratória bibliográfica e estudo de caso, o qual representa mais do que uma exemplificação da aplicação dos conceitos na utilização de algumas ferramentas. Representa também as necessidades de informação que dão sentido a construção de um data warehouse como ambiente de apoio ao planejamento estratégico e

15 operacional de uma empresa ou organização. 15

16 16 2 DATA WAREHOUSE Segundo Inmon (1997, p. 33, p.37), Data Warehouse é uma coleção de dados baseada em assuntos, integrados, variáveis com o tempo e não voláteis, para dar suporte ao processo de tomada de decisão. Data Warehouse também pode ser entendido como um conjunto de tabelas (banco de dados) contendo dados extraídos dos sistemas de operação ou transacionais da empresa, podendo ter adicionado a este contexto informações provenientes de documentos, planilhas eletrônicas e outras fontes objetivando fornecer e apresentar um repositório único, consolidado, como representação do negócio da empresa para processamento de consultas que apoiam o processo de tomada de decisão. Machado (2008,pag.27) contextualizando o Data Warehouse afirma que: [...], o Data Warehouse proporciona uma sólida e concisa integração dos dados da empresa, para a realização de análises gerenciais estratégicas de seus principais processos de negócio. Ele se preocupa em integrar e consolidar as informações de fontes internas, na maioria das vezes heterogêneas, e fontes externas, sumarizando, filtrando e limpando esses dados, preparando-os para análise e suporte à decisão. Como subconjuntos lógicos de um data warehouse, tem-se os data marts, contextualizado na Wikipedia (2008) como: O Data Warehouse é normalmente acessado através de Data Marts, que são pontos específicos de acesso a subconjuntos do Data Warehouse. Os Data Marts são construídos para responder prováveis perguntas de um tipo específico de usuário. Por exemplo: um Data Mart financeiro poderia armazenar informações consolidadas dia-a-dia para um usuário gerencial e em periodicidades maiores (semana, mês, ano) para um usuário no nível diretoria. 2.1 CARACTERÍSTICAS Em Machado (2008,pag.27) pode-se encontrar as características que diferenciam um Data Warehouse de sistemas convencionais: Extração de dados de fontes heterogêneas (existentes ou externas);

17 17 Transformação e integração dos dados antes de sua carga final; Normalmente requer máquina e suporte próprio; Visualização dos dados em diferentes níveis. Os dados do Data Warehouse podem ou não ser extraídos para um nível mais específico, os Data Marts, e a partir deste para um banco de dados individual; Utilização de ferramentas voltadas para acesso com diferentes níveis de apresentação; Dados somente são inseridos, não existindo atualização, ou melhor, updates. Outras características de um data warehouse podem ser citadas como orientação por assunto, variação no tempo, não volatilidade e integração Orientação por Assunto Um data warehouse armazena os dados obedecendo uma orientação por assunto. Isto indica sua derivação dos principais processos de negócio da organização. No modelo de dados corporativo é onde pode-se encontrar as representações dos principais processos de negócios de uma empresa. E por esse motivo Inmon (2000) afirma que o modelo corporativo de dados é um lugar muito bom para iniciar o processo de construção do Data Warehouse. Para Machado (2008, p.29) enquanto o projetista de sistemas transacionais tem o foco em projeto de banco de dados, projeto dos processos transacionais e suas atividades e controles operacionais, o projetista de data warehouse tem o foco em modelagem dos dados e projeto de banco de dados. No data warehouse [...] somente interessam dados que sejam importantes para a tomada de decisões, que sejam relativos à análise e desempenho de processos ou atividades críticas [...]. (MACHADO,2008, p.29) Variação no tempo Os dados de um Data Warehouse representam resultados operacionais de um

18 18 momento de tempo, o momento em que foram capturados. É um conjunto estático de registros referentes a um período de tempo, onde a data é elemento essencial e componente chave, que norteia a organização do armazenamento e da pesquisa. Esse elemento é obrigatoriamente trabalhado na composição dos dados de um data warehouse Não volatilidade Basicamente um Data Warehouse tem duas operações de dados: carga (inicial + incremental) e consulta aos dados. Desse modo difere de um sistema transacional, pois não tem operações como atualizações registro a registro ou bloqueio por concorrência no acesso. O acesso a seus dados é apenas como leitura Integração A Integração proporciona a unicidade de informações. É no processo de extração, filtragem e agregação que os dados provenientes de diferentes fontes são integrados, proporcionando conformidade ao Data Warehouse considerando também os aspectos de padronização e granularidade dos dados. (fig. 1). Figura 1 - Integração dos dados.

19 COMPONENTES E ARQUITETURAS DE IMPLEMENTAÇÃO Componentes A arquitetura de um data warehouse apresenta um conjunto de componentes, onde cada um assume uma função específica no ambiente como mecanismos de armazenamento e comunicação de dados, ferramentas de extração, carga, consulta e apresentação de dados. Conforme a figura 2, um modelo padrão de ambiente de DW considera quatro componentes separados e distintos: sistemas operacionais de origem, data staging area, área de apresentação de dados e ferramentas de acesso a dados.

20 20 Figura 2 - Elementos básicos do data warehouse Fonte: Adaptado de Kimball e Ross (2002). Como descrito pelos autores Kimball e Ross (2002, p.7), Cada componente do data warehouse atende a uma função específica. E precisamos aprender a importância estratégica de cada um deles e como controlá-los de modo eficiente para obtermos êxito com o data warehouse Sistemas operacionais de origem São os sistema onde são gravadas as transações dos negócios da empresa e a origem dos dados que povoarão o data warehouse. Os sistemas de origem estão fora do data warehouse e geralmente as pessoas responsáveis pelo data warehouse tem pouco ou nenhum controle sobre o conteúdo ou formato dos dados nos sistemas de origem. Mesmo assim é interessante considerar e aproveitar o estudo e discussão realizada durante o processo de modelagem do data warehouse sobre a origem dos dados como possibilidade de reengenharia dos sistemas transacionais visando facilitar o desenvolvimento do data warehouse.

21 21 Segundo Inmon (2000), o modelo corporativo de dados é um lugar muito bom para iniciar o processo de construção do Data Warehouse, devido a facilitar a identificação das tabelas de fatos. Portanto, caso o modelo de dados corporativo não exista deve ser construído considerando principalmente os tópicos: Em particular, o modelo corporativo de dados deve ter identificado e estruturado - pelo menos - o seguinte: os principais assuntos da empresa; as relações entre os assuntos; a criação de um ERD (diagrama entidade relacionamento); para cada área temática: as chaves (s) do sujeito, os atributos do sujeito, os subtipos do sujeito, os conectores de um tema para a próxima, o agrupamento dos atributos Data staging area Este componente compreende uma área de armazenamento de dados e os processos de extração, transformação e carga (ETC). Essa área de armazenamento de dados representa um repositório intermediário para armazenamento e processamento dos dados extraídos dos sistemas de origem dos dados, transacionais, e outras fontes, onde os dados poderão receber o tratamento necessário antes de ser realizada a carga para o data warehouse. A partir do modelo de dados corporativo, Inmon(2000) estabelece alguns passos para iniciar a transformação dos dados, sendo : a remoção de dados de natureza puramente operacional; a adição de um elemento de tempo para as principais estruturas do Data Warehouse; adição apropriada de dados derivados; a transformação de dados de relacionamentos em dados de artefatos;

22 22 acomodação de diferentes níveis de granularidade; fusão de dados de diferentes tabelas; criação de matrizes de dados; separação de atributos de dados de acordo com características de estabilidade. Kimball (2002,p.8) ressalta que Um requisito arquitetural chave para um data staging area é estar fora do limite dos usuários e não fornecer serviços de consulta. Comparativamente, Kimball descreve um data staging área como uma cozinha de um restaurante, onde os alimentos crus vão ser preparados e transformados em um prato palatável para o cliente, assim como os dados também o serão para os usuários Área de apresentação de dados Área de apresentação de dados é a área onde os dados estão armazenados, sendo o próprio repositório de dados do data warehouse e data marts, de forma organizada e disponíveis para consultas de usuários através de softwares geradores de relatórios e ferramentas analíticas de dados. O data warehouse é a espinha dorsal do ambiente, constituindo uma enorme base de dados históricos sobre assuntos de negócios institucionais de períodos que são geralmente acima de três anos, permitido desta forma análises onde possam ser identificadas indicadores e tendências. Os data marts representam um subconjunto lógico de dados do DW. Seus dados são direcionados a uma área específica de negócios da empresa e tem como principal vantagem permitir uma rápida implementação, como maior envolvimento do usuário final e menor tempo de retorno de resultados Ferramentas de acesso a dados.

23 23 Ferramentas de acesso a dados são todas as ferramentas que podem ser oferecidas aos usuários do data warehouse ou data mart para uso na realização de consultas a essas bases. Variam de simples ferramentas para realização de consultas ad hoc até sofisticadas ferramentas de modelagem e aplicações para realização de data mining Papeis No ambiente de data warehouse um dos aspectos importantes a se observar é o conjunto de usuários envolvidos no processo de construção e manutenção do DW e que podem ser agrupados conforme a função específica de cada um, conforme a seguir: Analistas responsáveis pela carga dos dados conhecem o mapeamento entre os sistemas de origem dos dados e o DW além das transformações necessárias para filtragem e integração dos dados; usuários finais são os usuários que conhecem os termos de negócios da organização e irão explorar os dados do DW para resolução de problemas apresentados. São os especialistas, gerentes e administradores; analistas responsáveis pelo desenvolvimento e manutenção do data warehouse e data marts profissional responsável pelas arquiteturas de armazenamento e dados e metadados; administradores de dados - tem o papel de integrador dos ambientes transacional e dimensional garantindo a integridade e qualidade dos dados nos processos de manutenção de extração, transformação e carga do DW Arquiteturas Machado (2008,p.50) apresenta três tipos de arquitetura para data warehouse: arquitetura global, arquitetura de data marts independentes e arquitetura de data marts integrados.

24 24 Na arquitetura global, o data warehouse trata a empresa como um todo, com foco em visões corporativas. Consequentemente tem-se menor redundância, maior consistência e integração dos dados. Sua implementação é bastante demorada e de elevado custo. Na arquitetura de data marts independentes, as bases são construídas sem foco corporativo, atendendo as necessidades específicas e departamentais de seus usuários. Cada departamento ou área da empresa constroi e gerencia o seu data mart, o que pode resultar em maior redundância e menor integração dos dados. Este tipo de implementação não tem grande impacto financeiro e é rápidamente implementado. A arquitetura de data marts integrados é uma combinação das duas anteriormente citadas como coloca Machado (2008,p.51): A arquitetura de Data Marts integrados é basicamente uma distribuição de implementação. Apesar de os Data Marts serem implementados separadamente por grupos de trabalho ou departamentos, eles são integrados ou interconectados, provendo uma visão corporativa maior dos dados e informações. De fato o alto nível de integração é similar ao da arquitetura global. Por outro lado, os usuários de um departamento podem acessar e utilizar os dados de um Data Mart de outro departamento. No processo de implementação de uma arquitetura de data warehouse, pode-se adotar uma das seguintes abordagens: top down, botton up ou intermediária. Na implementação top down a empresa é forçada a definir regras de negócio de forma corporativa antes de iniciar o projeto de data warehouse, o que torna o processo de implementação longo e difícil porque as decisões são tomadas em conjunto por todos os departamentos envolvidos. Em contrapartida os data marts resultantes utilizarão a arquitetura e os dados do data warehouse facilitando a manutenção (fig. 3).

25 25 Origem 1 Data Mart 1 Origem 2 Origem 3 Data Warehouse Data Mart 2 Data Mart 3 Figura 3 - Implementação top-down. Na implementação botton up a contrução de um data warehouse é incremental a partir de data marts independentes. Segundo Machado (2008,p.54) Um dos grandes problemas dessa implementação é a falta de um gerenciador que garanta padrões únicos de metadados, mesmo com a independência dos Data Marts. Caso não seja adotada forma de controlar esse problema, podem ocorrer falhas no processo de padronização, ocasionando redundâncias e inconsistências entre os data marts. (fig. 4). Origem 1 Data Mart 1 Origem 2 Data Mart 2 Data Warehouse Origem 3 Data Mart 3 Figura 4 - Implementação botton up Na implementação intermediária ocorre uma combinação entre as duas abordagens anteriormente citadas. Inicialmente faz-se uma macro modelagem de dados do data warehouse e no momento seguinte a escolha das partes mais importantes para iniciar a implementação dos data marts. Dessa forma tem-se a garantia da consistência e integração dos dados. 2.3 GRANULARIDADE DE DADOS Para Machado (2006, p. 59), granularidade de dados refere-se [...] ao nível de

26 26 sumarização dos elementos e de detalhes disponíveis nos dados, considerado o mais importante aspecto do projeto de um Data Warehouse.. A granularidade dos dados é considerada importante porque afeta diretamente o volume de dados no Data Warehouse e também porque determina o nível de detalhe que uma consulta poderá atingir. Outro aspecto importante referente à granularidade é a performance que poderá variar devido ao volume de dados. Quanto mais detalhes, mais baixo o nível de granularidade. Quanto menos detalhes maior o nível de granularidade. Um aspecto importante destacado por Machado (2008, p.60) é que Quando a granularidade de um Data Warehouse ou de um Data Mart é estabelecida, o projeto tem seu desenvolvimento com foco e irá fluir com mais tranquilidade. Enquanto não for visualizado o nível de granularidade, torna-se muito difícil a modelagem do Data Mart. Outro aspecto é a utilização da mesma granularidade definida para um determinado assunto de negócio em todos os DM ou DW onde se faça referência a este assunto como forma de garantir a integração dos dados e permitir análises de negócios comparativas. Desta forma tem-se dois fatores a serem considerados na definição da granularidade: tempo e forma de agrupamento das informações. 2.4 METADADOS Os metadados são dados sobre os dados de um banco de dados e estão organizados em dicionário digital de dados, para facilitar a documentação, estruturação e manutenção dessas informações. Na definição da enciclopédia Wikipédia (2008) metadados [...], ou Metainformação, são dados sobre outros dados. Um item de um metadado pode dizer do que se trata aquele dado, geralmente uma informação inteligível por um computador.

27 27 Em Machado (2008,p.299) metadados é definido como um repositório do DW onde [...] dados de mais alto nível descrevem os dados de níveis inferiores que compõem a estrutura do Data Warehouse. Os metadados, organizados em um dicionário de informações, descrevem informações não somente dos dados armazenados no DW como formato, tamanho, tipo, nome e alias como o dado é conhecido, mas também guardam informações sobre fontes geradoras e o destino dos dados; as regras de transformação aplicadas no processo de extração, limpeza e agrupamento de dados dos sistemas origem; os níveis de acesso dos usuário; as informações referentes a atualização dos dados, possibilitando ao usuário conhecer a atualidade dos dados e periodicidade de atualização dos dados.

28 28 3 MODELAGEM PARA DATA WAREHOUSE Kimball (1997), afirma que modelagem multidimensional é uma técnica de modelagem de dados viável para suportar consultas de usuários a um data warehouse, e que embora a modelagem entidade relacionamento seja muito útil na captura de transações e administração de dados na fase de construção de um data warehouse, deve-se evitar repassar este modelo ao usuário final. Modelagem entidade e relacionamento é uma técnica de modelagem lógica que busca remover redundâncias de dados. Como conseqüência, no processo de implementação temos consistência e agilidade nos processamentos transacionais. Entretanto, na busca do modelo relacional perfeito, cria-se bases de dados onde as consultas para serem realizadas necessitam de uma quantidades de junções entre tabelas que muitas vezes são inviáveis de serem realizadas devido ao grande número de tabelas originadas no processo de normalização. Kimball (1997) afirma que essa situação é muito mais do que um incômodo, e aponta três motivos porque não se pode usar diretamente a modelagem entidade relacionamento em Data Warehouse: 1) Usuários finais podem não entender ou relembrar sobre modelo entidade relacionamento e não conseguir navegar completamente por um modelo entidade e relacionamento. 2)Não existe uma interface gráfica para usuário finais que disponibilize o modelo entidade relacionamento como um todo para uso; 3)O uso da técnica de modelagem entidade relacionamento coloca por terra as principais atrações de um data warehouse, a saber recuperação de dados de forma intuitiva e de alta-performance. 3.1 MODELAGEM MULTIDIMENSIONAL OU DIMENSIONAL Em Machado (2008), modelagem multidimensional é definida como sendo : [...] uma técnica de concepção e visualização de um modelo de dados de um conjunto de medidas que descrevem aspectos comuns de negócios. É utilizada especialmente para sumarizar e reestruturar dados e apresentá-los