André Leonardo Pires Gonçalves
Propaganda
Universidade Católica de Brasília PRÓ-REITORIA DE GRADUAÇÃO TRABALHO DE CONCLUSÃO DE CURSO Bacharelado em Ciência da Computação SIGED – Sistema de Gestão Educacional – Data Warehouse Alunos: André Leonardo Pires Gonçalves Sylvia Sayuri Shibata Orientador: MSc. Milton Pombo da Paz BRASÍLIA 2008 ANDRÉ L.P. GONÇALVES SYLVIA SAYURI SHIBATA SISTEMA DE GESTÃO EDUCACIONAL – SIGED DATA WAREHOUSE Monografia apresentada para obtenção do título de bacharel no Curso de Ciência da Computação pela Universidade Católica de Brasília, sob a orientação do professor Milton Pombo. Brasília – DF 2008 i Projeto Final de Graduação, sob a Orientação do Msc. Milton Pombo da Paz, avaliado por uma Banca Examinadora do Curso de BCC da UCB e constituiu requisito para obtenção do Título de Bacharel em Ciências da Computação. ii AGRADECIMENTOS Agradeço aos meus pais e minhas irmãs por sempre me apoiaram e incentivarem os meus estudos e trabalho. Agradeço ao André Leonardo, parceiro de projeto final pela paciência, bom humor e força de vontade para conclusão do projeto. Agradeço também ao professor Milton P. Paz pela atenção dada ao nosso grupo e pelo incentivo e aos nossos demais colegas de projeto final. Sou grata também as pessoas que me ajudaram na minha conquista profissional, em especial o coordenador da equipe ao qual faço parte, Nobuo que me transmitiu sua constante preocupação com qualidade e praticidade, ensinando-me diversos caminhos para alcançá-la e Jean-Frédéric pela confiança e oportunidade de aprendizado logo no início da minha vida profissional. Por fim, agradeço a Deus por tudo de bom e maravilhoso que Ele me deu e, sem dúvida nenhuma, o maior presente que é a vida. Sylvia Sayuri Shibata iii Primeiramente agradeço a Deus pela vida, por tudo que possuo e o que sou. Agradeço aos meus Pais e minha Irmã Vanessa pelo apoio intensivo e amor que sempre me deram em todos os momentos da minha vida, e que de certa forma fizeram o possível para que este momento se realizasse. Agradeço a minha namorada Helaine Castro por ser forte e também por sua paciência, compreensão e suporte oferecido principalmente nos momentos mais difíceis que passo. Agradeço ao Professor Milton Paz pela orientação e incentivo que nos deu ao longo do semestre. Agradeço a Sylvia Shibata, pela paciência e apoio durante o desenvolvimento deste projeto final. Agradeço a todos os que me apoiaram sempre, e neste momento gostaria de citar de modo especial o senhor Alberto Mizuki pela oportunidade ímpar que me proporcionou no início da minha carreira profissional, ao professor Mário Braga pela chance e confiança depositada em mim. Finalmente agradeço a todos os colegas de trabalho, de faculdade, amigos, familiares e professores que de alguma maneira contribuíram com este momento. André Leonardo Pires Gonçalves iv Resumo A tecnologia Data Warehouse (DW) tem sido cada vez mais difundida nas corporações principalmente pelo diferencial que estes sistemas representam como ferramenta para análise de informações gerenciais e estratégicas. Neste cenário, o DW auxilia a alta cúpula da empresa na medida em que capta informações a partir das bases de dados transacionais e as armazena em repositórios construídos com o propósito exclusivo de análise. A visão do dia-a-dia, as micro-operações, os registros de transação, enfim, os dados dos sistemas transacionais tradicionais, são transformados em informações no contexto do Data Warehouse por meio de visões que oferecem a seus usuários informações globais que possibilitam que os tomadores de decisão tenham uma visão ampla sobre o seu negócio. Com base nisto, percebe-se uma crescente demanda por profissionais críticos que sejam capazes de atender a este mercado. Por isso, entender e conhecer os conceitos sobre esta tecnologia tem feito diferença para alguns profissionais do ramo da Tecnologia da Informação. O objetivo do presente trabalho é elucidar os principais conceitos sobre a Tecnologia Data Warehouse e ao fim apresentar um protótipo para aplicação dos conceitos apresentados. Palavras chave: Data Warehouse, Sistema de Apoio a decisão, Data Mart. v Abstract The Data Warehouse technology has been used and widespread inside corporations mainly because its differential as an information analysis tool. On that way, this technology aids the decision makers of one company to view information from specific databases constructed with the data from multiples transactional sources. These repositories have the specific goal of analysis. The daily view, the micro operations, the transaction rows and finally the traditional data from transactional systems are transformed in information in Data Warehouse context using views that offer global information and insights to its users in the way that offer to that professionals a broad view of their business. Based on that facts, the demand for critic professionals is rising, and the ability to understand and know the concepts about this technology make the difference for some Information Technology professionals and companies. The main goal of this work is elucidate the main concepts about the Data Warehouse Technology and at the end present one prototype for application of the main concepts presented in this work. Keywords – Data Warehouse, Decision Support System, Data Mart. vi Lista de figuras Figura 1 – Organograma do Centro Educacional Tangran. ................................ 6 Figura 2 – Evolução dos Sistemas de Apoio à Decisão [INMON, 2005] .......... 20 Figura 1 – Cronograma no MS Project. ............................................................ 34 Figura 4 – Exemplo de Modelo Relacional [DSPACE,2008] ............................ 36 Figura 5 – Exemplo de Esquema de Modelo Multidimensional [DEVMEDIA, 2008] ................................................................................................................ 36 Figura 6 – Exemplo de Modelo Multidimensional.[MICROSOFT, 2008] ........... 37 Figura 7 – Exemplo de Estrutura Multidimensional [DEVMEDIA, 2008] ........... 39 Figura 8 – Abordagem de implementação Top-Down [MACHADO, 2007] ....... 47 Figura 9 – Abordagem de implementação Botton-Up [MACHADO, 2007] ....... 49 Figura 10 – Tabela de ferramentas segundo [OLIVEIRA, 2002] ...................... 56 Figura 11 – O Ciclo de Vida do desenvolvimento de sistemas [INMON, 2005] 64 Figura 12– Modelo mostrando o modelo dimensional macro baseado em informações coletadas. .................................................................................... 75 Figura 13 – Modelo de dados dimensional utilizado para no Data Mart Escolar. ......................................................................................................................... 76 Figura 14 – Modelo Físico do Sistema OLTP com as principais tabelas a serem utilizadas no DW.. ............................................................................................ 80 vii Lista de tabelas Tabela 1 – Cronograma geral do projeto...................................................... 29 Tabela 2 – Documentos do projeto .............................................................. 30 Tabela 3 – Quadro de funcionários necessários para desenvolvimento de um DW. .......................................................................................................... 30 Tabela 4 - Recursos Financeiros ................................................................. 33 Tabela 1 – Quadro de funcionários sugeridos para desenvolvimento inicial de um DW [INMON, 1999] ............................................................................... 69 Tabela 2 – Quadro de Funcionários de SI sugerido para Gerenciamento Contínuo de DW[INMON 1999] ................................................................... 71 viii SUMÁRIO AGRADECIMENTOS ........................................................................................ iii Resumo .............................................................................................................. v Abstract ............................................................................................................. vi Lista de figuras ................................................................................................. vii Lista de tabelas ................................................................................................viii SUMÁRIO.......................................................................................................... ix 1. 2. 3. Introdução ................................................................................................... 1 1.1 Motivação ............................................................................................. 4 1.2 Histórico ............................................................................................... 4 1.3 Problemas Diagnosticados .................................................................. 5 1.4 Surgimento das Necessidades da Pesquisa ........................................ 5 1.5 Usuários Beneficiados ......................................................................... 5 1.6 Organograma ....................................................................................... 5 1.7 Empresa Interessada ........................................................................... 7 Objetivos da Pesquisa................................................................................. 8 2.1 Objetivo Geral ...................................................................................... 8 2.2 Objetivo Específico .............................................................................. 9 Proposta de Pesquisa ............................................................................... 10 3.1 Descrição da Proposta de Pesquisa .................................................. 10 3.2 Resultados Esperados ....................................................................... 10 3.3 Restrições da Pesquisa ..................................................................... 11 3.4 Recursos necessários para a execução do novo Software................ 11 3.4.1 Descrição de Recursos de Hardware Ideal .................................... 12 3.4.2 Descrição de Recursos de Hardware Mínimo ................................ 12 3.4.3 Descrição de Recursos de Software .............................................. 13 3.4.4 Descrição de Recursos Humanos .................................................. 13 ix 3.5 Relação Custo x Benefício ................................................................. 14 3.6 Áreas afetadas pela pesquisa ............................................................ 14 4. Metodologia da pesquisa .......................................................................... 14 5. Detalhamento da pesquisa – Estudo Teórico............................................ 15 5.1. Introdução .......................................................................................... 15 5.1.1. Conceito ......................................................................................... 16 5.1.2. Objetivo .......................................................................................... 17 5.1.3. Evolução dos Sistemas de Suporte à Decisão ............................... 18 5.1.4. Público Alvo .................................................................................... 21 5.1.5. Características................................................................................ 21 5.1.6. Papéis ............................................................................................ 24 5.2. PLANEJAMENTO DO PROJETO ...................................................... 25 5.2.1. Planejamento ................................................................................. 25 5.2.2. Plano do Processo de Desenvolvimento ........................................ 26 5.2.3. Ciclo de vida do projeto .................................................................. 26 5.2.4. Métodos de Desenvolvimento e ferramentas CASE....................... 27 5.2.5. Ambiente de hardware para o desenvolvimento............................. 27 5.3. Plano de Organização........................................................................ 27 5.3.1. Equipe de Gerência ........................................................................ 27 5.3.2. Equipe de Desenvolvimento ........................................................... 28 5.4. Plano de Acompanhamento ............................................................... 28 5.4.1. Marcos e Pontos de Controle ......................................................... 28 5.4.2. Métodos de acompanhamento e controle ...................................... 29 5.4.3. Análise e Gerência de Riscos ........................................................ 30 5.5. 5.5.1. 5.6. Plano de Documentação .................................................................... 30 Documentos do projeto .................................................................. 30 Plano de Recursos e Produtos .......................................................... 30 x 5.6.1. Recursos Humanos ........................................................................ 30 5.6.2. Recursos de Hardware ................................................................... 32 5.6.3. Recursos de Software .................................................................... 32 5.6.4. Recursos Financeiros ..................................................................... 33 5.7. Cronograma ....................................................................................... 34 5.8. Modelagem de Dados ........................................................................ 34 5.8.1. Modelagem Multidimensional ......................................................... 37 5.8.2. Modelo Star Schema (Modelo Estrela) ........................................... 40 5.8.3. Modelo Snowflake (Floco de Neve) ................................................ 42 5.9. Arquitetura ......................................................................................... 42 5.9.1. Conceito ......................................................................................... 43 5.9.2. Arquitetura Global........................................................................... 44 5.9.3. Arquitetura Data Mart Independente .............................................. 45 5.9.4. Arquitetura Data Mart Integrado ..................................................... 46 5.10. Abordagem de Implementação ...................................................... 47 5.10.1. Top-Down ................................................................................... 47 5.10.2. Botton-Up .................................................................................... 48 5.11. Extração, Transformação e Carga.................................................. 50 5.11.1. Melhores Práticas ....................................................................... 51 5.11.2. Extração ...................................................................................... 52 5.11.3. Transformação ............................................................................ 53 5.11.4. Carga .......................................................................................... 54 5.11.5. Ferramentas................................................................................ 55 5.12. OLAP .............................................................................................. 56 5.12.1. Características das ferramentas OLAP ....................................... 57 5.12.2. Operações Básicas OLAP .......................................................... 58 5.13. Metadados ...................................................................................... 60 xi 5.13.1. O Data Warehouse e o modelo de dados ................................... 61 5.13.2. Padrões para Metadados ............................................................ 61 5.13.3. Dublin Core ................................................................................. 62 5.13.4. TEI .............................................................................................. 63 5.13.5. METS .......................................................................................... 63 5.13.6. EAD ............................................................................................ 63 5.13.7. RDF ............................................................................................ 63 5.14. 6. 7. Ciclo de Vida de Desenvolvimento ................................................. 64 5.14.1. Fases para um projeto Data Warehouse .................................... 65 5.14.1.1. Levantamento das Necessidades ............................................... 65 5.14.1.2. Modelagem ................................................................................. 66 5.14.1.3. Projeto Físico .............................................................................. 66 5.14.1.4. Projeto ETL ................................................................................. 66 5.14.1.5. Desenvolvimento das Aplicações ............................................... 67 5.14.1.6. Validação e Teste ....................................................................... 67 5.14.1.7. Treinamento ................................................................................ 67 5.14.1.8. Implantação ................................................................................ 67 5.14.2. Problemas Comuns de Desenvolvimento ................................... 67 5.14.3. Recursos Humanos .................................................................... 69 Protótipo – Validação da Pesquisa ........................................................... 73 6.1. Planejamento ..................................................................................... 73 6.2. Levantamento de Necessidades ........................................................ 74 6.3. Modelagem Dimensional.................................................................... 75 6.4. Projeto físico do banco de dados ....................................................... 76 6.5. Projeto de extração, transformação e carga ...................................... 79 6.6. Desenvolvimento de aplicações ......................................................... 84 Conclusão ................................................................................................. 85 xii Referência Bibliográfica ................................................................................... 86 Apêndice A ....................................................................................................... 88 Apêndice B ....................................................................................................... 92 SCRIPT DE GERAÇÃO DO BANCO DE DADOS ........................................ 92 Apêndice C ....................................................................................................... 96 TELAS DO PROTÓTIPO .............................................................................. 96 xiii 1. Introdução Segundo Inmon (1997) no começo dos anos sessenta o mundo da computação consistia basicamente na construção de aplicações individuais que resolviam problemas bastante específicos. Daquela época para cá o cenário mudou bastante. Desde a difusão dos computadores pessoais, dos primeiros sistemas operacionais até o advento da Internet, o mundo tem passado por diversas transformações. O conhecimento é um fator chave para estas mudanças e constitui a base para a evolução das sociedades. É notável que o conhecimento sempre influenciou o avanço da humanidade utilizando para isso a tecnologia. Quem detém o conhecimento e tecnologia possui o domínio. Isto é fato que pode ser facilmente observado, por exemplo, quando se visualiza o atual ranking de países desenvolvidos. Quem alia o conhecimento à tecnologia tende a estar na frente. Entretanto para que seja possível adquirir o conhecimento, é necessário ter informação. As informações ajudam a moldar o conhecimento e muitas vezes são determinantes para que se saiba construir um equipamento complexo ou até mesmo para que se consiga tomar uma decisão da forma mais assertiva possível. O conhecimento têm se acumulado ao longo da história e a quantidade de informação recebida por um cidadão atual é espantosamente grande quando comparada ao passado. Machado (2006) cita que “Em uma única edição do jornal The New York Times existe mais informação do que uma pessoa poderia receber durante toda sua existência na Inglaterra do século XVII”. Isso se deve principalmente pela difusão dos meios de comunicação que surgiram no século XX. A difusão da energia elétrica, do rádio, do telefone, da televisão e por último da Internet possibilitaram que uma grande quantidade de pessoas tivessem acesso à informação. Neste sentido, é fato que a evolução está intimamente ligada a questão da competição. Trazendo o contexto exposto para dentro do mundo corporativo, a necessidade de obter informações qualificadas referentes às operações de uma empresa faz com que a utilização de sistemas computacionais seja cada vez mais difundida no mundo corporativo. O uso intensivo destes sistemas vem facilitando a execução de processos dentro das 1 corporações e auxiliando profissionais a executarem suas tarefas cotidianas. A informação é a base para um negócio bem sucedido. O foco do produto de software também tem evoluído. Além do seu papel básico de resolver problemas do dia-a-dia por meio de sistemas transacionais, ele tem sido utilizado para transformação de dados em informações dentro das corporações por meio de tecnologias de apoio a decisão. A necessidade por informações empresariais sempre existiu, no entanto a evolução da Tecnologia da Informação (TI) tem possibilitado a criação de meios eficientes para a transformação de dados em informações. Neste cenário o surgimento de sistemas de apoio à decisão (SAD) tem auxiliado empresas e pessoas a colherem informações a partir deste tipo de sistemas, de forma a auxiliá-los na tomada de decisões estratégicas. Visto que a necessidade de informações para a tomada de decisões foi aumentando e o que haviam eram apenas dados estruturados sendo armazenados historicamente. Além disso, existe o problema de consultas em base de dados estruturados consumir muito tempo devido aos relacionamentos existentes entre as tabelas, inviabilizando o uso deste tipo de estrutura, o que exigiu a criação de uma nova tecnologia para tratar os dados de forma que gerassem consultas a informações, surgindo o Data Warehouse para prover as informações de maneira rápida e simples. Os ambientes transacionais tradicionais ou ambientes OLTP (Online Transaction Processing) têm cumprido seu papel dentro das empresas. No entanto percebeu-se que este tipo de sistema apresenta algumas deficiências quando utilizados como ferramenta para auxilio na tomada de decisões estratégicas de alto nível. O grande problema nessa situação, é que os ambientes transacionais não foram projetados para suportar análise de informação de forma maciça. Quando um gestor questiona dados de sua empresa, ele geralmente deseja saber informações de maneira macro e abrangente, como por exemplo, questionar qual a margem de lucro de um produto nos últimos cinco anos. Pode até existir sistema OLTP que consigam responder a este tipo de pergunta, mas pelo alto volume de transações dentro do ambiente operacional 2 (e por outros fatores) estas informações podem estar guardadas em diversos meios que impossibilitem uma pesquisa imediata ou em um tempo aceitável. Além de outras desvantagens relacionadas, esta consulta poderia requerer uma grande quantidade de processamento nos sistemas transacionais, que talvez fosse proibitivo de ser executada em uma determinada ocasião justamente por causa da brusca queda de desempenho neste sistema. As tecnologias de análise de informações, ou tecnologias OLAP (Online Analytical Processing) trazem solução para esta questão e oferecem um ambiente projetado para análise de informações. Sintetizando suas diferenças essenciais, a mais marcante, é que os sistemas OLAP permitem e são projetados para a extração (consulta) de informações de forma maciça e satisfatória em relação aos ambientes OLTP. Na maioria das vezes o OLTP manipula uma grande massa de pequenas operações, enquanto o ambiente OLAP, uma pequena quantidade de grandes operações. Estes ambientes de análise surgem para auxiliar gestores e alta gerência das companhias a tomarem decisões baseadas nos fatos armazenados em seus sistemas transacionais. Muitas vezes estas decisões são tomadas com base em informações temporais. A visualização de informações de meses, anos e décadas são bem freqüentes e o volume de dados armazenados neste tipo de ambiente é altíssimo, pois devem armazenar informação durante os períodos citados. Dentro do mundo de apoio a decisão existe a categoria de sistemas Data Warehouse (DW). De forma muito geral, estes sistemas funcionam de forma que, a partir das necessidades da alta gerência, extrai-se e tratam-se os dados dos ambientes transacionais tradicionais por meio de processos especiais, e após esta etapa, os dados são carregados em ambientes especializados de análise. Em seguida ficam disponíveis em um repositório dedicado para servir de base para consultas a informações gerencias de uma determinada corporação. Geralmente estas informações servem de base histórica e ficam armazenados nestes repositórios por anos. Em mais detalhes, esta pesquisa tem o objetivo de descrever detalhadamente a estrutura de um Data Warehouse, e mostrar suas principais características e também como este tipo de solução auxilia a alta gerência no processo de tomada de decisão. 3 1.1 Motivação A necessidade de obter informações qualificadas referentes às operações de uma empresa faz com que o uso de sistemas Data Warehouse seja cada vez mais difundido no mercado corporativo. Além de outras vantagens, o uso intensivo destes sistemas vem melhorando cada vez mais a capacidade do ajuste interno dos processos das empresas, na medida em que proporcionam uma visão macro das operações executadas e auxilia os gestores a tomarem decisões baseadas nas informações adquiridas dentro de seus próprios sistemas produtivos. O produto final de um trabalho de implementação de Data Warehouse pode oferecer também, uma visão posicional do referido negócio em relação ao mercado externo, servindo como uma ferramenta para o estudo da melhor estratégia a ser aplicada em um segmento visando à melhora da capacidade de competição da empresa. Segundo Silberschatz e Sudarshan (1999), um Data Warehouse é um repositório de informações coletadas em diversas fontes – tais como Sistema de Recursos Humanos, Contabilidade, Logística - que são armazenadas sob um repositório único, que tem uma interface única e consolidada de dados e que são armazenadas durante longo período de tempo. Isso significa que, ao centralizar as informações, estes sistemas oferecem facilidade de acesso às informações (que antes eram mineradas por meio de relatórios esparsos de cada área de negócio) além de oferecer uma análise histórica destas informações. Nesse sentido, este trabalho de pesquisa tem como propósito propor uma solução baseada em tecnologia Data Warehouse. 1.2 Histórico Desde a fundação do Centro Educacional Tangran não se tinha a preocupação de automatização e informatização dos dados da escola. Todos os processos eram manuais até a pouco tempo, e com o aumento do quadro de funcionários e alunos, iniciou a preocupação de armazenamento de dados sobre a situação acadêmica dos alunos, visto que as informações eram guardadas em armários de arquivos físicos. 4 Desta forma, com a quantidade de informações sendo armazenados, por vezes, tornava-se difícil o acesso a estas informações. Neste sentido foram adquiridos sistemas para controle acadêmico, totalizando-se três sistemas de “prateleira”. Cada um com modelos de dados próprio, banco de dados próprio e código-fonte inacessível. 1.3 Problemas Diagnosticados Devido ao armazenamento de documentos físicos referentes aos alunos e funcionários, estava gerando demora na pesquisa de determinados arquivos e também ao grande risco da perda destes em caso de um acidente. Neste sentido, também não existia nenhum sistema de apoio a decisões, que seria muito importante para a análise estratégica dos dados. Desta forma, não existem meios de extração de dados para a geração de informações históricas da entidade para futura expansão e análise da questão financeira dos alunos de forma a prover algum tipo de atrativo para novos alunos ou criação de política de descontos a fim de manter os alunos já matriculados. 1.4 Surgimento das Necessidades da Pesquisa Assim como nos demais setores tais como telecomunicações, indústria e logística, a área educacional tem a sua própria necessidade de buscar informações gerenciais dentro de suas bases de dados transacionais para que se consiga responder a perguntas essenciais para a estratégia do negócio. Com base no cenário apresentado, o presente trabalho de pesquisa tem como intuito responder a questões estratégicas referentes a um ambiente escolar específico por meio da construção de um sistema computacional de Data Warehouse. 1.5 Usuários Beneficiados Após a construção do sistema de Data Warehouse, os usuários beneficiados serão: Presidente, Diretores e Supervisores das instituições e Coordenadores Educacionais. 1.6 Organograma A seguir, será apresentado o organograma do Centro Educacional Tangran, no qual está sendo baseada a pesquisa presente. 5 A escola é composta por uma alta Diretoria Executiva, onde, estão ligados a ele, as diretorias Administrativa, Financeira e Educacional. A coordenação Pedagógica está diretamente ligado à diretoria educacional, de onde vêm as informações para a análise da Diretoria Educacional e consequentemente, dados de tomada de decisão para a diretoria executiva. Figura 1 – Organograma do Centro Educacional Tangran. 6 1.7 Empresa Interessada O projeto se destina ao cenário atual do Centro Educacional Tangran, instituição de ensino infantil, localizada em Brasília. Hoje a instituição possui aproximadamente 100 alunos e deseja ampliar a sua estrutura para a educação fundamental. O principal objetivo do Centro.Educacional Tangran é promover uma educação de qualidade, buscando sempre a transparência com os pais e responsáveis, porém a instituição enfrenta barreiras por não contar com um sistema para extrair relatórios estratégicos. Atualmente, toda a documentação é preenchida manualmente o que gera uma baixa produtividade e falta de informações confiáveis para as tomadas de decisões. 7 2. Objetivos da Pesquisa O objetivo é desenvolver uma pesquisa sobre Data Warehouse e validá- lo em um estudo de caso para uma escola com o desenvolvimento de um DW para provimento de relatórios gerenciais para tomada de decisão pela alta gerência. O qual possibilita a consulta de várias informações do processo de negócio da área acadêmica. 2.1 Objetivo Geral O presente trabalho tem como objetivo desenvolver uma pesquisa bibliográfica sobre sistemas computacionais de Suporte à Decisão Data Warehouse (SSD/DW) a fim de fornecer à escola citada, uma ferramenta de análise gerencial de informações. 8 2.2 Objetivo Específico Desenvolver um protótipo em computador para atender os principais processos da Instituição de Ensino utilizando SOA para a modelagem destes processos e construção de um sistema transacional. Com base nos dados gerados neste sistema, e só após sua conclusão, será utilizado um sistema de Data Warehouse para responder questões específicas do negócio. Os objetivos específicos identificados para se atingir o objetivo geral são os seguintes: Levantar, junto aos interessados pelo sistema, o conjunto de consultas gerenciais que se deseja obter a partir do Data Warehouse; Mapear os Dados que serão transformados em Informações do ambiente OLTP (Online Transaction Processing) para o ambiente OLAP (On-Line Analytical Processing), em conformidade com o que foi levantado com os interessados pelo sistema; Extrair dados específicos do ambiente transacional OLTP para a criação de um ambiente de análise OLAP utilizando técnicas de ETL (Extract Transform and Load); e Com base nas informações armazenadas neste último repositório, criar consultas gerenciais a partir das questões analíticas levantadas pelos analistas de sistema aos interessados pela construção do sistema para apoio a tomada de decisão na empresa e, após isso, disponibilizar estas consultas aos usuários. 9 3. Proposta de Pesquisa Desenvolver uma pesquisa bibliográfica sobre Data Warehouse em busca de informações importantes de maneira que auxilie na tomada de decisões oferecendo diversidade de cenários de acordo com o histórico da escola. 3.1 Descrição da Proposta de Pesquisa Elucidar de forma descritiva os principais conceitos relacionados à tecnologia Data Warehouse, o importante papel histórico e evolução das tecnologias de Suporte a Decisão, as principais características ligadas à arquitetura, à forma de implementação, questões de modelagem, entre outros conceitos relacionados à tecnologia citada. Feito isso, desenvolver um protótipo para comprovar a viabilidade da aplicação dos conceitos aqui referidos. 3.2 Resultados Esperados Com a conclusão da pesquisa planeja-se implementar um protótipo para aplicação dos conceitos e demonstração de viabilidade da construção de um sistema Data Warehouse engajado nas necessidades da instituição de ensino citada conforme os conceitos elucidados nesta pesquisa. 10 3.3 Restrições da Pesquisa Para realização desta pesquisa é imprescindível: Ciência de que o foco deste trabalho de pesquisa é a construção de um protótipo focado nas questões gerenciais dos usuários do sistema, e não um sistema DSS robusto; Obter junto aos usuários do futuro sistema, o escopo do protótipo a ser desenvolvido; A existência de uma base de dados transacional (OLTP) para mapeamento das necessidades dos usuários; 3.4 Recursos necessários para a execução do novo Software O servidor de banco de dados para armazenamento dos dados relativos à escola será o Oracle Database 9.2.0.1. O software que servirá como ferramenta de ETL (Extração, Transformação e Carga) será o OWB (Oracle Warehouse Builder) na versão 10.1.0.4. Já a aplicação onde os usuários finais poderão criar consultas e acessar as já existentes é o Oracle Discoverer 10.1.2.1. No lado servidor para instalação do banco de dados e do OWB, o hardware ideal para suporte ao software e ao problema da escola específico seria uma máquina com processador de velocidade 2 GHz e 2 GB de memória RAM. O hardware mínino para instalação do banco de dados e OWB seria uma máquina com processador de velocidade de 1.7 GHz e 1 GB de memória RAM. Na máquina cliente para instalação do Oracle Discoverer, para a consulta e criação de relatórios, o hardware ideal sugerido é um processador de velocidade 1 GHz, com 1 GB de memória RAM. O hardware mínimo sugerido para a máquina cliente, para execução das consultas aos relatórios é um desktop com um processador de velocidade 700 MHz, com 512 MB de memória RAM. 11 Em relação aos recursos humanos, serão necessários 2 analistas de sistemas, 1 DBA (Database Administrator), 2 consultores ETL, 2 consultores OLAP para este desenvolvimento. Abaixo segue a descrição detalhada de recursos a ser utilizada. 3.4.1 Descrição de Recursos de Hardware Ideal Servidor Computador IBM PC ou Compatível; Processador 2 GHz; 2 GB de Memória RAM; HD de 160 GB; Teclado; Mouse; e Placa Ethernet 10/100. Máquina Cliente Computador IBM PC ou Compatível; Processador 1 GHz; 1 GB de Memória RAM; HD de 80 GB; Teclado; Mouse; e Placa Ethernet 10/100. 3.4.2 Descrição de Recursos de Hardware Mínimo Servidor Computador IBM PC ou Compatível; Processador 1.7 GHz; 1 GB de Memória RAM; HD de 100 GB; 12 Teclado; Mouse; e Placa Ethernet 10/100. Máquina Cliente Computador IBM PC ou Compatível; Processador 700 MHz; HD de 40 GB; 512 MB de Memória RAM; Teclado expandido; Mouse; e Placa Ethernet 10/100. 3.4.3 Descrição de Recursos de Software Servidor Sistema Operacional – Windows XP Professional; Banco de Dados – Oracle Database Server 9i (versão 9.2.0.1); Software de ETL – Oracle Warehouse Builder (versão 10.1.0.4); Software Front-End – Oracle Discoverer Administrator (versão 10.1.2.1); e Cliente Sistema Operacional - Windows XP Professional ou Home Edition; e Software Front-End – Oracle Discoverer Desktop. Desenvolvimento Ferramenta Case - Enterprise Architect 7.1. 3.4.4 Descrição de Recursos Humanos 2 analistas de sistemas; 1 DBA (Database Administrator); 2 consultores ETL; e 13 3.5 2 consultores OLAP. Relação Custo x Benefício A implementação de um Data Warehouse é um investimento de longo prazo, entretanto existe a possibilidade de durante o desenvolvimento deste, já obter alguns resultados por meio da construção de Data Marts departamentais separados que podem ser integrados ao fim do projeto. Desta forma, é possível que os gerentes tomem conhecimento de informações precisas que afetam diretamente na tomada de decisões estratégicas da evolução da escola. Com o armazenamento dos dados históricos possibilita a análise sobre as mensalidades pagas pelos alunos, o qual possibilita a criação de políticas para manter os alunos já matriculados ou convidar novos alunos a serem matriculados na instituição. 3.6 Áreas afetadas pela pesquisa Com a implementação do Data Warehouse, toda a escola será afetada a longo prazo, incluindo: Marketing; Diretoria; e Recursos Humanos. Porém para o desenvolvimento do protótipo será considerada a análise somente da área fim da escola, que abrange o assunto de ocorrências e notas dos alunos. 4. Metodologia da pesquisa A metodologia adotada para esta pesquisa é a pesquisa classificada como bibliográfica, pois se destina a investigar possibilidades do emprego dos melhores métodos e práticas a serem recomendadas a fim de aplicação prática de um estudo de Data Warehouse em uma instituição de ensino. Foram realizadas pesquisas bibliográficas com a finalidade de apoiar as idéias propostas, por meio de um estudo desenvolvido com base em materiais 14 originados de livros, materiais eletrônicos, com o objetivo de se levantar uma base para o embasamento teórico. 5. Detalhamento da pesquisa – Estudo Teórico Nesta seção serão apresentadas as principais características de um Data Warehouse. Embasado em trabalhos realizados e publicados por diversos autores renomados da área, o objetivo desta pesquisa é elucidar os principais aspectos relacionados à tecnologia citada. A princípio serão apresentados aspectos macros relativos ao assunto, tais como principais conceitos, objetivos, histórico, entre outras questões. Feito isso, outros aspectos mais profundos tais como modelagem, arquitetura, processos ETL (Extração, Transformação e Carga), criação de consultas e ciclo de desenvolvimento serão apresentados. 5.1. Introdução A importância de definir uma estratégia para conquistar clientes e conseqüentemente, aumentar o lucro e o capital das companhias faz com que o uso de tecnologia da informação voltada para a tomada de decisão seja cada vez mais utilizado dentro das companhias de forma a auxiliar no alcance dos objetivos contemplados por sua estratégia. Essas tecnologias são vitais porque a partir da visão dos dados contidos nos repositórios transacionais, será possível a extração de informações importantes e históricas para análise estratégica do negócio em um ambiente analítico próprio. Segundo Oliveira (2002) o Data Warehouse surgiu principalmente devido às dificuldades emergentes que as organizações começaram a enfrentar no momento de reunir os dados para uma análise mais eficiente. A solução para este problema foi armazenar os dados utilizando uma arquitetura própria e criada exclusivamente para suportar o armazenamento destes dados em um ambiente de análise de informações. Com isso, é possível identificar vários assuntos sobre os quais se deseja tomar uma decisão, a partir dos questionamentos gerenciais dos usuários interessados na implementação deste sistema. 15 Atualmente esta tecnologia é aplicada amplamente em empresas de grande porte no Brasil e no mundo, provendo ao alto escalão empresarial uma tecnologia robusta e completa que consegue atingir seus objetivos quando aplicada de forma correta. Trazendo este cenário para o mundo acadêmico, percebe-se a necessidade de uma análise estratégica dentro do ambiente escolar para o alcance de objetivos de igual importância quando comparados ao ramo da Indústria, Telecomunicações, Logística, entre outras. Com base nesta necessidade, esta pesquisa, tem como intuito de elucidar os principais conceitos relacionados à tecnologia DW e ao final responder a questões estratégicas referentes a um ambiente escolar específico por meio de um protótipo. 5.1.1. Conceito Um Data Warehouse oferece os fundamentos e os recursos necessários para um Sistema de Apoio a Decisão (SAD) eficiente, fornecendo dados integrados e históricos que servem desde a alta direção, que necessita de informações mais resumidas, até as gerencias de baixo nível, onde os dados detalhados ajudam a observar aspectos mais táticos da empresa. [Oliveira, 2002] Ralph Kimball e William Inmon estão entre os autores mais respeitados no universo Data Warehouse. Eles foram os pioneiros na tecnologia, e conceituam-na de formas um pouco diferente, entretanto complementares. Segundo Inmon (1997), um Data Warehouse é caracterizado como “uma coleção de dados orientada por assuntos, integrada, variante no tempo, e não volátil, que tem por objetivo dar suporte aos processos de tomada de decisão”. Já na opinião de Ralph Kimball (1998), um Data Warehouse é “uma cópia dos dados de transações, estruturadas especificamente para consultas e análises”. Sumarizando a essência dos conceitos, um Data Warehouse é um sistema que é utilizado pela alta cúpula empresarial com o intuito de auxiliar nas decisões estratégicas de uma corporação, de forma que utiliza os dados dos sistemas transacionais (OLTP) e os armazena em um ambiente de 16 arquitetura própria para análise, e que é orientado por assunto, integrado, variante no tempo e não volátil. A própria tradução do termo Data Warehouse diz bastante sobre o seu conceito. Um Armazém de Dados – tradução do termo DW - é um repositório de dados onde se podem guardar os dados históricos de uma organização. A alta gerência usuária do DW acessa o sistema usando ferramentas SAD para consulta instantânea de relatórios na tela com montagem de gráficos, textos, tabulação de números, entre outros recursos, acessando diretamente a base de dados corporativa da empresa. É importante salientar que estes artefatos são os resultados das necessidades que foram levantadas em algum momento pelos analistas de sistema DW juntamente com estes usuários. No entanto há situações onde os usuários podem criar suas próprias consultas a partir de uma estrutura já montada do Data Warehouse. Estas consultas são chamadas de ad hoc, ou simplesmente consultas aleatórias, que são criadas a partir de usuários com mais experiência e que conheçam a estrutura DW que lhe foi montada. 5.1.2. Objetivo O Data Warehouse tem o objetivo de integrar e mostrar informações gerenciais das organizações, para que estas sejam utilizadas como base pela alta cúpula da companhia durante a tomada de decisões. Essa ferramenta ajuda os gestores a terem uma visão abrangente dos seus processos de negócio por meio da seleção dos assuntos mais relevantes que cercam a corporação. A seleção destes assuntos por vezes envolve várias áreas de uma empresa. Um exemplo é quando um gestor deseja cruzar dados da área de Contabilidade e de Recursos Humanos e saber o valor do orçamento despendido com um determinado departamento por cargo. Estes assuntos, bem como seus relacionamentos, são definidos conforme as necessidades do gestor no início de um projeto DW e repassada à parte desenvolvedora para que esta possa avaliar a viabilidade de entrega deste assunto dentro do DW. Neste contexto o DW tem o objetivo de fornecer informações consistentes a seus usuários. O gestor no caso do exemplo acima deve ter certeza de que aqueles dados foram cruzados de forma correta e que aquela 17 informação pode ser tomada como base para a formação do conhecimento do gestor. Outro objetivo do DW é tornar as informações corporativas acessíveis para visualização. Isso significa que, uma vez fechado o escopo do projeto, os dados são carregados de forma que fiquem à disposição para seus usuários. Esta utilização geralmente é feita por meio de ferramentas de consultas OLAP, que oferecem visões por meio de relatórios, planilhas, entre outros. O termo acessível também quer significa que os o DW deve entregar suas informações de forma ágil. Outro objetivo também importante exercido pelo DW é a comparação das operações de forma histórica. Isso é possível devido a este tipo de sistema ter a capacidade de armazenar informações ao longo de vários anos. Ao armazenar os dados de forma histórica é possível verificar tendências relativas às operações de uma empresa, de modo que um processo possa ser remodelado por meio de um processo de reengenharia. O último objetivo é aumentar o lucro da empresa quando a alta gerência opta por implementar um Data Warehouse na empresa. Isso porque os usuários destes sistemas têm condições de conhecer exatamente os números de sua corporação. Por meio disso, estes usuários adquirem a capacidade de saber pontualmente que foco deve ser dado ao seu negócio de forma que o lucro desta corporação seja expandido. 5.1.3. Evolução dos Sistemas de Suporte à Decisão Segundo Inmon (2005), a figura abaixo mostra a evolução processamento de informação no começo dos anos sessenta com o início da criação de aplicativos individuais que funcionavam usando master files (arquivos-mestre). Os aplicativos com características de relatórios e programas normalmente eram escritos em Fortran ou Cobol, perfurando cartões ou fitas de papéis. Os master files eram hospedados em fitas magnéticas, que eram ótimas para armazenamento de grande volume dados barato, mas o inconveniente era o acesso seqüencial dos dados. Era possível o acesso aos 100% dos dados, porém normalmente 5% ou menos dos dados registrados eram realmente necessários. Além do acesso à fita inteira levava em torno de vinte a trinta minutos, dependendo de onde o dado se encontrava. 18 De acordo com Inmon (2005), por volta do meio da década de sessenta, o crescimento de master files e fitas magnéticas explodiram. Vindo também o crescimento da enorme quantidade de dados redundantes. A proliferação dos master files e dados redundantes apresentou um problema muito insidioso: A necessidade de sincronização sobre a atualização dos dados; A complexidade de manutenção dos programas; A complexidade da criação dos novos programas; e A necessidade de ampla quantia de hardware para suporte de todos os master files. Por volta dos anos setenta, deu-se início a uma nova tecnologia de armazenamento com o DASD (Direct Access Storage Device), dispositivo de armazenamento de acesso direto, que era diferente das fitas magnéticas, onde os dados poderiam ser acessados diretamente via DASD, não sendo mais necessário passar pelos dados 1, 2, 3, ...,,n até chegar ao dado gravado na posição n+1, pois o endereço do dado é conhecido, simplificando o acesso a este, além de que o tempo requerido para ir ao dado gravado na posição n+1 era um tempo significantemente menor que o tempo requerido para o acesso a este mesmo dado em uma fita magnética, agora sendo mensurado em milisegundos. Com o DASD, veio um novo tipo de sistema de software conhecido como Sistema Gerenciador de Banco de Dados (SGBD ou DBMS – Database Management System) com o propósito de facilitar o armazenamento e acesso de informações pelos programadores ao DASD. O DBMS tomava cuidado com alguns serviços de armazenamento de dados no DASD, como indexar a informação. Estas novas tecnologias vieram solucionar o problema dos master files e com o DBMS teve uma noção do que é um banco de dados. Em meados dos anos 1975, foi criado um meio de acesso rápido aos dados chamado OLTP, abrindo toda uma nova perspectiva para processamento e negócio, possibilitando o uso do computador em novas tarefas antes impossíveis, como sistema de controle de manufaturas, sistemas de reservas, entre outros. Em meados de 1980 vieram novas tecnologias, como os PCs (Personal Computers) e 4GL (Fourth-generation Languages), possibilitando o usuário 19 final controlar diretamente os dados e os sistemas. Com estas duas tecnologias teve-se a noção da simplicidade das transações Online. O MIS (Management Information System), eram processamentos usados para operar decisões de gerenciamento. Figura 2 – Evolução dos Sistemas de Apoio à Decisão [INMON, 2005] 20 5.1.4. Público Alvo A solução de Data Warehouse está voltada para o nível estratégico e gerencial de uma companhia de forma a suportar a tomada de decisões. Dentre os principais usuários deste tipo de sistema, pode-se citar os Sócios, Diretores, Analistas de Suporte a Decisão, Presidentes, Gerentes e Usuários Chave. Estes são profissionais de alto nível que devem estar informados a respeito da sua corporação de forma que possam contribuir com seu crescimento. Além de serem os usuários finais de uma solução de DW, estas são as pessoas que visualizam as necessidades que deverão ser supridas pelo sistema. Estes usuários geralmente são envolvidos diretamente no processo de levantamento dos assuntos que serão tratados por um DW. 5.1.5. Características Um DW proporciona uma sólida e concisa integração dos dados da empresa e análises gerenciais sólidas dos dados estratégicos de seus principais processos de negócio, preocupando-se em integrar as informações de fontes internas e externas, sumarizando, filtrando e limpando os dados. Entre as principais características de um Data Warehouse segundo Machado (2006) podem ser citadas as seguintes: Extração de dados de fontes heterogêneas internas e/ou externas – O DW possui um conjunto de processos responsáveis por carregar os dados a partir dos sistemas transacionais (OLTP). Este conjunto é denominado processos de extração, transformação e carga (ETL- Extraction, Transform and Load). Esta característica inicial se refere ao primeiro passo de coleta dos dados a partir dos sistemas OLTP para o DW. É basicamente uma cópia dos dados de um lado para o outro. Esta extração é realizada segundo normas de mapeamento de dados. Estas normas definem a localização bem como a origem e o destino dos dados que deverão ser carregados; Transformação e integração dos dados – Após os processos de extração dos sistemas OLTP para o DW são aplicadas algumas 21 regras de negócio aos dados. Esta transformação é realizada para que as necessidades dos usuários sejam refletidas nos dados e para transformá-los em informações úteis. Esta transformação então se refere à aplicação de filtros, conversão de dados, manipulação de dados de diferentes fontes. Um exemplo básico, o DW pode ser responsável por unificar as informações de Sexo (Masculino ou Feminino) que estão representadas em seus diversos sistemas ora como “M” para masculino e “F” para feminino, ora como “1” para homens e “2” para mulheres; Requer máquina e suporte próprios – Salvo casos especiais de implementação de Data Marts (assunto abordado mais a frente) departamentais ou demonstrações, um projeto de Data Warehouse comprometido com a empresa deve possuir recursos e máquinas próprios para que seja possível seu desenvolvimento; A visualização de dados pode ser feita em diferentes níveis – As informações podem ou não serem extraídas para um nível mais específico, como os Data Marts e deste para um BD individual; Uso de ferramentas para acesso ao DW com níveis diferentes de apresentação – Uma ferramenta de Data Warehouse deve ser capaz de mostrar várias perspectivas de visão da mesma informação. Isso significa que estas ferramentas devem oferecer a seus usuários, a capacidade de, a partir de uma determinada visão das informações, se aprofundar mais nos detalhes daquela visão (também chamado de Drill Down). Isso possibilita ao analista daquela informação ter um conhecimento maior sobre o assunto pesquisado; Os dados não são atualizados, são somente inseridos – Para se manter o histórico de mudanças dentro do sistema, geralmente os dados não sofrem processos de atualização (update). Por exemplo, se a descrição do peso de um produto de uma companhia for alterado, o DW por praxe, insere uma nova linha idêntica a anterior salvo pelo atributo peso. Para evitar duplicações geralmente é aplicado um atributo no registro dizendo se ele é ou não atual e qual foi a data de alteração do mesmo. Com isso, o analista das 22 informações tem a capacidade de acompanhar mudanças neste determinado produto; Orientação por assunto – Dentro de um Data Warehouse são comumente encontradas informações sobre diversos assuntos de uma empresa, e estes assuntos estão relacionados às suas áreas. Um exemplo é que dentro do universo DW de uma empresa, está inserido uma consulta retratando a quantidade de funcionários de uma empresa que estão lotados em determinadas diretorias e que participam de diversos centros de custo. Este exemplo mostra como três assuntos diferentes podem estar relacionados entre si, “funcionário” representando o assunto Recursos Humanos, “diretorias” representando Estrutura Organizacional e “centro de custo” representando o assunto Financeiro; Variação no tempo – Ao contrário dos sistemas OLTP, o DW precisa manter informações históricas relacionadas aos seus diversos assuntos. Ele faz isso armazenando seus dados por vários anos em algumas ocasiões. Estas informações servem de fundamento para análise histórica de alguma questão relacionada à corporação. Esta variação muitas vezes é importante para análise das tendências relacionadas a determinados assuntos. Não volátil – Em um sistema OLTP tradicional geralmente existem várias operações ocorrendo ao mesmo tempo, tais como operações de leitura, escrita, atualização e inserção. No DW estas operações basicamente se resumem a carga inicial dos dados (primeira inserção dos dados), carga incremental e a consultas destes dados. Como já visto, o DW mantém um histórico das suas informações o que significa que operações de “deleção” das informações são muito raras, tornando-o não volátil; e Integrado – Esta característica diz respeito a unicidade das informações, ou seja, mesmo que mesmas informações venham com formatos diferentes de lugares diferentes, estas informações devem ser unificadas para que seja apresentado apenas um valor dentro do Data Warehouse. 23 5.1.6. Papéis Por sua abrangência, o DW envolve vários profissionais, dentre eles analistas de processamento de dados até analistas de negócio, ou clientes deste ambiente. No ambiente de DW inclui os administradores do projeto, os projetistas do banco, os administradores de bancos de dados (Database Administrators) dos sistemas operacionais, os administradores de dados, programadores e analistas de sistemas, analistas de aplicativos e usuários finais, onde estes são agrupados por papéis como descrito a seguir: Analistas responsáveis pela carga dos dados composto por programadores que precisam conhecer o mapeamento entre o DW e os sistemas operacionais além dos requisitos para filtragem e integração dos dados; Usuários finais que são os especialistas, gerentes executivos e analistas de negocio que utilizam as informações para apoio à tomada de decisão, os quais estão sempre em busca de solução de um problema ou em busca de novas oportunidades de negócio. São divididos em dois grupos, os usuários diretos que acessam livremente o DW enquanto os usuários indiretos buscam os dados nos Data Marts (DMs) especializados; Analistas de desenvolvimento e manutenção do DW e DMs que abrangem os analistas de banco de dados e administradores de dados dos sistemas gerenciadores de banco de dados, sendo responsáveis pelos metadados, arquitetura de armazenamento e estrutura de dados afim de melhorar o desempenho das consultas; e Administradores de Dados que desempenham papel fundamental por ser um integrador dos ambientes transacional e dimensional, para garantia da qualidade e existência da integridade do DW, via acompanhamento e administração dos metadados entre os sistemas transacionais e seu processo de manutenção de extração, transformação e carga do DW. 24 5.2. PLANEJAMENTO DO PROJETO O plano de projeto proposto pode ser visualizado em quatro grandes partes, a saber: Ferramentas; Hardware; Recursos humanos; e Desenvolvimento da aplicação. Essa segmentação das atividades tem o objetivo de: Mitigar os riscos envolvidos com ciclo de desenvolvimento e implantação; Formalizar, por meio de uma boa documentação - ponto fundamental em EDW (Enterprise Data Warehouse), o elo entre design e construção; e Garantir a estabilidade da infra-estrutura. 5.2.1. Planejamento Na primeira etapa do projeto de Data Warehouse, é definido o escopo do projeto com ênfase no negócio. A definição da abordagem corporativa vai desde a escolha de um DW monolítico, grande, fortemente integrado em nível de projeto, do qual sairão os Data Marts posteriormente (abordagem top-down), até uma alternativa gradativa, onde os Data Marts evolutivos integrarão o DW na medida de suas implementações (abordagem bottom-up). Após a definição das áreas/assuntos do primeiro projeto, é feito o planejamento para a integração dos DM de forma gradativa, identificando os elos que possibilitarão as conexões futuras e integrações: 25 5.2.2. Plano do Processo de Desenvolvimento As atividades para o desenvolvimento de aplicações (cada produto a ser entregue) cobrem todas as tarefas - desde os levantamentos até o aceite final do produto pelo usuário-final, que, resumidamente, são as seguintes: Identificação da área de negócio; Estudo da cadeia de valores para identificação dos medidores/critérios de desempenho e a definição do escopo do produto; Modelagem dimensional preliminar do Data Mart (DM); Mapeamento de origem e destino dos dados; Definição dos processos de ETL; Construção dos processos de ETL; Construção das aplicações; Carga dos dados; e Teste, homologação e termo de aceite do produto. 5.2.3. Ciclo de vida do projeto O ciclo de vida para o projeto será dividido em seis fases na metodologia em espiral a saber: Levantamento – Fase em que são levantados os requisitos para o novo sistema ou para o sistema já existente. Neste ponto as necessidades são colhidas junto ao cliente; Design e Modelagem – Levantamento, documentação e Modelagem do DW a ser aprimorado a cada iteração; Codificação – Geração dos scripts ou dos programas de acordo com a evolução do projeto de DW; Testes e homologação – Testes unitários e homologação pelo cliente, feitos desde a documentação até o produto final; e Implantação – Implantação em ambiente produtivo para uso efetivo do DW. 26 5.2.4. Métodos de Desenvolvimento e ferramentas CASE O método para o levantamento de dados será baseado em pesquisa científica e método de desenvolvimento será o desenvolvimento em espiral, visto que as iterações da metodologia é atualmente muito utilizada como uma metodologia de desenvolvimento e que não contém somente informações sobre como construir Data Warehouse, mas também descreve como se usa um Data Warehouse. A metodologia de desenvolvimento em espiral descreve dinamicamente as atividades específicas, entregáveis das atividades e a ordem das atividades. O dinamismo da criação iterativa de um Data Warehouse, não são descritas, porém, é descrito um plano em três dimensões das migrações fragmentadas, enquanto que a metodologia de desenvolvimento espiral descreve os detalhes do plano em uma dimensão. Juntos, eles formam uma imagem completa do que é necessário para a construção do Data Warehouse. A ferramenta utilizada no desenvolvimento do projeto será o Enterprise Architec. 5.2.5. Ambiente de hardware para o desenvolvimento Para o desenvolvimento do Data Warehouse será necessário os seguintes hardwares: Servidor de banco de dados Oracle com alguma massa de dados considerável descaracterizado para geração dos cubos OLAP e fase de ETL; 2 Computadores IBM/PC ou compatível com 1 GB de RAM, velocidade de 1 Ghz e HD de 80 GB. 5.3. Placa Ethernet 10/100 Plano de Organização O plano de organização proposto para o desenvolvimento do Data Warehouse será dividida em duas equipes: Uma equipe de gerência do projeto e a equipe de Desenvolvimento do projeto, as quais são detalhadas a seguir. 5.3.1. Equipe de Gerência Será composto por um gerente de desenvolvimento de Data Warehouse, responsável por: 27 Coordenar os trabalhos; Auxiliar no desenvolvimento do plano; e Revisão final do plano. 5.3.2. Equipe de Desenvolvimento A equipe de desenvolvimento será composta por vários profissionais descritos abaixo Analistas responsáveis pela carga dos dados composto por programadores que precisam conhecer o mapeamento entre o DW e os sistemas operacionais além dos requisitos para filtragem e integração dos dados; Analistas de desenvolvimento e manutenção do DW e DMs que abrangem os analistas de banco de dados e administradores de dados dos sistemas gerenciadores de banco de dados, sendo responsáveis pelos metadados, arquitetura de armazenamento e estrutura de dados afim de melhorar o desempenho das consultas; e Administradores de Dados que desempenham papel fundamental por ser um integrador dos ambientes transacional e dimensional, para garantia da qualidade e existência da integridade do DW, via acompanhamento e administração dos metadados entre os sistemas transacionais e seu processo de manutenção de extração, transformação e carga do DW. 5.4. Três analistas de Banco de dados; Um administrador de dados; Plano de Acompanhamento Será descrito a seguir um plano de acompanhamento do desenvolvimento do Data Warehouse. 5.4.1. Marcos e Pontos de Controle Para a execução do projeto, serão pré-estabelecidos pontos de controles semanais para acompanhamento a fim de identificar falhas, cumprimento do cronograma de acordo com o estabelecido. 28 Cronograma Geral Fev Mar Abr Mai Jun Planejamento Levantamento das necessidades Modelagem dimensional Projeto físico dos banco de dados Projeto de ETL Desenvolvimento de aplicações Validação e Teste Treinamento Implantação. Tabela 1 – Cronograma geral do projeto 5.4.2. Métodos de acompanhamento e controle Por ser adotado o modelo de desenvolvimento em espiral, cada circuito completo da espiral resultará no desenvolvimento da especificação do produto até a conclusão do projeto. Em cada passagem pela região de planejamento resultará em ajustes do plano do projeto, onde o custo e o cronograma são ajustados com base no feedback derivado do cliente após a comunicação do andamento do projeto, o qual o gerente do projeto poderá ajustar o número planejado de iterações necessárias para completar o software. 29 5.4.3. Análise e Gerência de Riscos A seguir serão abordados os riscos identificados para o processo de desenvolvimento do Data Warehouse dos quais alguns problemas podem ocorrer durante o desenvolvimento do sistema DW. Carga de dados desnecessários dentro do DW; Confundir o projeto do banco de dados DW com o projeto de um sistema transacional 5.5. Plano de Documentação 5.5.1. Documentos do projeto Abaixo são descritos alguns documentos para para implementação de um DW. Tabela 2 – Documentos do projeto Nome Proposta de Descrição Especificação e Documento que descreve de forma Desenvolvimento do DW (plano de detalhada o escopo do projeto e o plano de projeto) trabalho do projeto de DW. Descrição da Modelagem do DW Documento que descreve, de forma detalhada, a modelagem do DW. Scripts do DW Documento que contém os scripts utilizados na geração do DW. Manual do Usuário do DW Documento que serve de referência para uso do software pelo cliente. 5.6. Plano de Recursos e Produtos A seguir serão descritos os planejamentos de recursos humanos, hardware e software necessários para o desenvolvimento do DW. 5.6.1. Recursos Humanos Tabela 3 – Quadro de funcionários necessários para desenvolvimento de um DW. Função Nome Formação Experiência 30 Formação superior em Analista de Sistemas Sistemas de Informação; André L. P Gonçalves Mestrado na área de analise de sistemas de Mínimo de 5 anos em Analise de Sistemas. informação. Formação superior em Administrador de Dados Sistemas de Informação. Sylvia S Shibata Modelagem de Mestrado ou especialização dados; banco de na área de gerencia de dados projeto. Superior completo na área Analista de Testes Sylvia S Shibata de tecnologia da informação. 5 anos em desenvolvmento e certificações na área de qualidade. Superior completo na área Analista de dados André L. P Gonçalves de tecnologia da Banco de dados informação. Analista de banco de dadosDBA Superior completo na área Sylvia S Shibata de tecnologia da Banco de dados informação. 31 5.6.2. Recursos de Hardware Os recursos de hardware necessários para o desenvolvimento do DW serão descritos a seguir: Recursos de Hardware Discriminação Unidade Quantidade de Medida Valor Índice de Valor Total Unitário Aplicação (R$) (%) (R$) Microcomputadores un. 04 1.800,00 100 7.200,00 Servidor un. 01 1.200,00 100 1.200,00 SUBTOTAL 8.400,00 5.6.3. Recursos de Software Os recursos de software necessários para o desenvolvimento do projeto são: Sistema Operacional – Windows XP Professional; Banco de Dados – Oracle Database Server 9i (versão 9.2.0.1); Software de ETL – Oracle Warehouse Builder (versão 10.1.0.4); Software Front-End – Oracle Discoverer Administrator (versão 10.1.2.1); e Sistema Operacional - Windows XP Professional ou Home Edition; e Software Front-End – Oracle Discoverer Desktop. Ferramenta Case - Enterprise Architect 7.1. 32 5.6.4. Recursos Financeiros Tabela 4 - Recursos Financeiros Recursos Financeiros Recursos Atividades Analista de Sistemas Gerente de Projeto Administrador de dados Administrador de dados DBA Analista de Testes Pessoal Total Serviços de Limpeza Terceiros Total Gastos não esperados Outros Total Total Fev mar Ano 2008 abr mai jun Total R$ 7.000 R$ 7.000 R$ 7.000 R$ 21.000 R$ 10.850 R$ 10.850 R$ 10.850 R$ 10.850 R$ 7.500 R$ 7.500 R$ 7.500 R$ 7.500 R$ 30.000 R$ 7.500 R$ 7.500 R$ 7.808 R$ 7.500 R$ 7.808 R$ 7.500 R$ 7.808 R$ 30.000 R$ 31.232 R$ 3.799 R$ 7.598 R$ 22.457 R$ 174.080 R$ 420 R$ 2.100 R$ 420 R$ 2.100 R$ 1.000 R$ 5.000 R$ 1.050 R$ 5.250 R$ 47.804 R$ 362.610 R$ 32.850 R$ 420 R$ 420 R$ 40.658 R$ 420 R$ 420 R$ 40.658 R$ 420 R$ 420 R$ 3.799 R$ 37.457 R$ 420 R$ 420 R$ 1.000 R$ 1.050 R$ 68.590 R$ 1.000 R$ 1.050 R$ 84.206 R$ 1.000 R$ 1.050 R$ 84.206 R$ 1.000 R$ 1.050 R$ 77.804 R$ 10.850 R$ 7.808 R$ 54.250 33 5.7. Cronograma A seguir será apresentado um cronograma resumido do projeto de Data Warehouse elaborado no MS Project. Figura 3 – Cronograma no MS Project. 5.8. Modelagem de Dados Segundo o Dicionário Aurélio, modelo significa Molde; Aquilo que serve como exemplo ou norma. Neste sentido, modelo de dados representa a essência de algo que deve ser criado. O modelo de dados utilizado em sistemas de Data Warehouse é essencialmente diferente da modelagem utilizada nos sistemas OLTP. Grande parte dos bancos de dados de sistemas transacionais das empresas atuais utiliza o Modelo Relacional. Data Warehouse utiliza o Modelo Multidimensional para organizar as informações. O porquê da utilização de dois modelos para estes dois ambientes está ligado intimamente à natureza de cada um dos mundos. Mundo Transacional versus Analítico. O ambiente OLTP está basicamente centrado em operações do dia-a-dia da empresa, tais como a inserção de um novo produto, a atualização do salário de um funcionário, a remoção de uma conta contábil, e outras manipulações no banco de dados. As operações de banco de dados para sistemas transacionais são 34 essencialmente select, insert, update, delete. Estas operações são bem pontuais e geralmente requerem pouca quantidade de processamento. Já no universo da análise o tipo de manipulação exercida sobre os dados é diferente. Quando um usuário DW deseja saber alguma informação, ele abre sua ferramenta preferida de análise e executa uma nova consulta. Esta pergunta na maioria das vezes requer a recuperação de milhares ou por vezes milhões de registros em um banco de dados. Neste caso a quantidade de processamento exigido é bem maior do que nos sistemas transacionais. As operações mais comuns em ambiente de análise são select e insert. Comumente um DW recebe uma carga inicial de dados e após esta etapa são feitas apenas cargas incrementais. A partir desta massa de dados seus usuários então podem realizar consultas (selects). A normalização é um processo que tem como objetivo a remoção da redundância de informações em bancos de dados além de garantir que a informação se relacione de forma precisa dentro deste ambiente. A normalização oferece um conjunto de normas (formas normais) que aconselham como o projetista deve montar a estrutura do banco. As formas normais servem como instrumento para que os mesmos dados não se repitam ao longo das tabelas do banco, causando a duplicação de dados de forma desnecessária e consequentemente afetando o desempenho do Sistema Gerenciador de Banco de Dados (SGBD). Neste contexto os sistemas OLTP por padrão apresentam estrutura bem mais normalizada quando comparados com os sistemas DW. Segundo Machado (2006) “a maioria das técnicas de modelagem concorda que a aplicação completa da teoria relacional não é apropriada para Data Warehouse.” e esta afirmação leva em consideração aspectos distintos dos dois ambientes tais como alto volume de dados dos sistemas DW. Apesar do DW utilizar técnicas de normalização em casos muito específicos, esta técnica é mais recomendada para sistemas OLTP. Técnicas de normalização aplicadas aos sistemas DW como um todo, apresentam um alto grau de ineficácia. Conclusivamente segundo Machado(2006) “Se mover o modelo de dados transacional para um banco de dados separado e inserir os dados históricos, chamando-o de Data Warehouse, não será possível trabalhar com estes dados, pois os usuários não conseguirão realizar consultas ad hoc por possuir uma complexidade muito alta e pelo fato do modelo transacional respeitar a terceira 35 forma normal, não respondendo com rapidez a questões de apoio à decisão por requererem de cinco a mais joins de tabelas.” Figura 4 – Exemplo de Modelo Relacional [DSPACE,2008] Figura 5 – Exemplo de Esquema de Modelo Multidimensional [DEVMEDIA, 2008] 36 Figura 6 – Exemplo de Modelo Multidimensional.[MICROSOFT, 2008] 5.8.1. Modelagem Multidimensional “A modelagem multidimensional é 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 em visões que suportem a análise dos valores desses dados.” [Machado,2006] Devido ao grande volume de dados e a complexidade envolvida nas consultas de Data Warehouse, o modelo multidimensional busca organizar as informações de forma a facilitar o entendimento do usuário final e de forma a agilizar o retorno das consultas. Entre os elementos básicos da modelagem multidimensional os Fatos, Dimensões e as Medidas são de suma importância par ao entendimento do modelo. 37 Conceitualmente os fatos, dimensões e medidas são determinados segundo Machado(2005) como: Fatos – são “elementos que representam um item, uma transação ou um evento de negócio e é utilizado para analisar o processo de negócio de uma empresa” e acrescenta que “a característica básica de um fato é que ele é representado por valores numéricos...”; Dimensões – são denominadas como “elementos que participam de um fato e são as possíveis formas de visualizar os dados, ou seja, são os ‘por’ dos dados: ‘por mês’, ‘por país’, ‘por produto’, ‘por região’, entre outros.”; e Medidas – “são os atributos numéricos que representa um fato, a performance de um indicador de negócios relativo às dimensões que participam deste fato”. Com isso pode-se dizer que a relação essencial entre Fatos, Medidas e Dimensões é bem simples: Os Fatos são os elementos quantificadores (valores) enquanto as Dimensões são os elementos qualificadores (descrições) enquanto as medidas são atributos numéricos que representam um fato. Fisicamente, dentro do modelo multidimensional os fatos ficam armazenados em tabelas chamadas “Tabelas de Fato” e as dimensões do negócio são armazenadas respectivamente nas “Tabelas de Dimensão”. Os fatos estão diretamente relacionados às dimensões, pois necessitam destas “descrições” para que se tenha uma análise com sentido completo. Outra característica física relacionada a estrutura de tabelas, é que as tabelas de fato carregam os identificadores das dimensões (chaves estrangeiras) como forma de interligar estas duas entidades. Abaixo um exemplo típico do modelo multidimensional. 38 Figura 7 – Exemplo de Estrutura Multidimensional [DEVMEDIA, 2008] Observa-se que para a tabela de fatos acima existe um conjunto de dimensões ligadas a ela. Isso justamente porque os fatos necessitam ser descritos de forma que se empregue semântica nas análises. Inseridas no fato existem medidas que são determinadas pela combinação das dimensões que participam de um fato e estão localizadas como atributos de um fato. As dimensões vão qualificar ou descrever os fatos. Um exemplo de uma das análises que pode ser feita a partir da estrutura multidimensional mostrada na figura é quando um gestor gostaria de obter a seguinte informação ilustrativa: Visualizar o valor em dólares (medida) das vendas (fato vendas) realizadas no mês de Dezembro de 2006/2007 e 2008 (dimensão tempo) dos aparelhos de telefone celular (dimensão produto) que foram vendidas em lojas de São Paulo, Brasília e Rio de Janeiro (dimensão loja). Este exemplo ilustra a forma como estes vários elementos podem se relacionar dentro da estrutura. O valor em dólares representa a medida, que é um atributo da tabela de fatos. Este atributo como o próprio conceito cita, armazena o valor numérico em questão. Já as dimensões representam as perspectivas sob qual aquela informação pode ser vista, e que no caso da figura acima são as dimensões de tempo, produto e loja. Em outras palavras, a mesma medida pode ser analisada somente sob o ponto de vista (Somente Por mês, ou Somente Por Loja, ou Somente Por Produto) ou pode ser combinada com várias outras perspectivas dimensionais. Na modelagem multidimensional, os usuários conseguem entender melhor o modelo de dados, pois muitas vezes estes navegam com facilidade pela estrutura de 39 dados resultante apesar de exigir um nível de abstração maior, comumente utilizado em modelo de dados transacionais. Ao invés de uma estrutura altamente complexa derivada da modelagem Entidade Relacionamento, a multidimensional mostra-se muito mais acessível em termos de visualização e praticidade, além de ser altamente adequada a ambientes de análise. O exemplo acima poderia muito bem representar um modelo lógico de alto nível em alguma situação prática de implementação. Durante a criação e visualização do modelo físico (ou de implementação), os relacionamentos deste modelo são bem mais intuitivos que os do modelo E/R. Neste contexto, existem várias formas de modelagem multidimensional. Conforme Thomas H. Harrison[HAR98] existem cinco opções de modelos multidimensionais. Cada opção tem um conjunto de vantagens e considerações: Estrela (Star Schema); Snowflake (Flocos de neve); Estrela Parcial; Tabela Fato Particionada; e Tabela dimensional. Apesar das várias opções o intuito desta pesquisa é mostrar as características dos dois principais modelos: Modelo Estrela e do Snowflake. Estes dois são os modelos mais comumente utilizados em implementações práticas. 5.8.2. Modelo Star Schema (Modelo Estrela) É o modelo mais utilizado dentro do universo multidimensional e ao contrário do modelo relacional este possui sua estrutura desnormalizada. “Sua composição típica possuiu uma grande entidade central denominado fato (fact table) e um conjunto de entidades menores denominadas dimensões (dimension table), arranjadas ao redor dessa entidade central, formando uma estrela.” [Machado, 2006] Entre as principais características do modelo a mais marcante e a que dá o nome ao modelo é a questão da existência de uma única tabela fato histórica simples ligada às dimensões por meio de chaves estrangeiras. Com uma única 40 tabela de fatos cercada de um conjunto de dimensões, este modelo lembra fisicamente o formato de uma estrela. Este histórico do fato é guardado devido as cargas incrementais realizadas nestas tabelas. Aliando conceito e prática, o DW tem o objetivo de apresentar dados históricos para análise e esta característica de cargas incrementais é a que representa claramente esta marca. As tabelas de dimensão também podem guardar histórico e para isso devem atualizar o registro antigo e fazer utilização de flags (bandeiras) que indicam que o registro antigo consta na tabela somente para fins históricos. Nos sistemas de Data Warehouse as tabelas de fatos são em geral bem maiores que as tabelas de dimensão. Ainda que possam existir tabelas de dimensão realmente grandes as tabelas de fato com freqüência atingem uma quantidade de registros muito grande, chegando a casa dos milhões. Para o caso de tabelas DW muito grandes existem soluções que podem ser empregadas para melhorar o desempenho de consultas de usuários finais. Entre essas técnicas estão inclusos o particionamento de tabelas e a sumarização de dados. O particionamento consiste em dividir logicamente as tabelas em porções menores de modo que as consultas sejam direcionadas diretamente àquela porção em que está contido o dado desejado. É como se uma grande tabela se tornasse várias outras pequenas. Já a sumarização ou agregação, consiste em agrupar registros de forma que o resultado final reflita um sumário contendo um número menor de linhas, mas que reflita a mesma realidade. A parte das soluções, este tipo de modelo é o mais apropriado para a construção de um Data Warehouse, pois melhora bastante a performance, diminuindo o número de ligações entre as tabelas. Além disso, o uso de uma tabela única por dimensão e de uma tabela fato simples por categoria assegura que definições dos metadados podem ser usadas novamente, independentemente do nível de sumário ou fatos. A performance também é aumentada usando uma única declaração SQL (Structured Query Language) para cada consulta – independente do conteúdo do relatório. A desvantagem consiste na grande replicação de dados nas dimensões desnormalizadas. Dependendo do banco de dados utilizado e do espaço reservado 41 para o armazenamento será necessário fazer uma análise do volume estimado para a criação do DW. 5.8.3. Modelo Snowflake (Floco de Neve) Os modelos Snowflake empregam uma combinação da normalização da base de dados para manter a integridade e reduzir os dados redundantes e a desnormalização para obter maior desempenho. O modelo é mais fácil de ser compreendido pelo usuário final, por esse motivo é muito utilizado como modelo lógico, sendo utilizados outros modelos como modelo físico. As dimensões são quebradas conforme os níveis de hierarquia apresentados fazendo ligações entre si. Por exemplo, uma dimensão tempo contendo ano, mês e dia será composta por três tabelas normalizadas, uma para cada atributo, passando a chave estrangeira da tabela ano para mês e da tabela mês para dia. Neste tipo de modelo, tem-se como principal vantagem, a integridade dos dados. Também diminui a replicação dos dados, ocupando menos espaço em disco. Contudo, como em um Data Warehouse o objetivo é agilizar as consultas, é importante considerar a baixa performance apresentada por este tipo de modelo. 5.9. Arquitetura Segundo o SEI (Software Engineering Institute), "A arquitetura de software de um programa ou de um sistema computacional é a estrutura ou estruturas do sistema, que abrangem elementos de software, as propriedades visíveis destes elementos, e as relações entre eles". Sintetizando a idéia, o termo arquitetura se refere a um conjunto de estruturas conhecidas (como programas ou módulos isolados) que, estruturadas de forma lógica e consistente, podem prover serviços ou funcionalidades umas para as outras de modo a atingir o objetivo de resolver um problema que o sistema como um todo se propõe a solucionar. O projeto da arquitetura de um sistema é de vital importância e muitas vezes está diretamente relacionado com o sucesso de um produto de software. É na arquitetura que se define a organização do sistema e como as estruturas trocarão mensagens ou proverão serviços a outros elementos. Com base nisto, Filho (2004) comenta que este provimento de serviços é desenhado diretamente no projeto arquitetural, que se for mal definido, pode afetar diretamente os atributos de 42 qualidade ou os requisitos não funcionais de um sistema tais como desempenho, portabilidade, confiabilidade, disponibilidade, entre outros. A partir deste cenário, entende-se que a escolha e a definição da arquitetura para um sistema de Data Warehouse é fundamental para que se consiga responder às perguntas que este sistema de apoio a decisão se propõe a esclarecer. Além disso, por ser um sistema que apoio gerencial, os fatores de qualidade citados podem ser cruciais para o sucesso neste tipo de sistema. Segundo Machado (2006), a escolha da arquitetura do projeto de DW, está baseado em fatores relacionados à infra-estrutura, ambiente do negócio, escopo, tempo que se tem para se realizar o projeto e a capacitação dos recursos humanos disponibilizados e projetados para investimento. Neste sentido, é necessário que a gerência do projeto tenha em mãos estas informações ao planejar a arquitetura destes sistemas. 5.9.1. Conceito Para que um Data Warehouse seja útil, ele deve ser capaz de responder a consultas avançadas de maneira rápida, sem deixar de mostrar detalhes relevantes às respostas. O estudo de uma arquitetura permite compreender como o DW faz para armazenar, integrar, comunicar, processar e apresentar os dados que os usuários utilizarão em suas decisões. Em [Oliveira,2002], o termo arquitetura Data Warehouse é definido como um conjunto de estruturas que servem de base para o desenvolvimento do projeto de um sistema ou produto. Uma arquitetura de dados tem como função primordial a identificação e o entendimento de como os dados se movimentam e são organizados dentro de um sistema e de como ele será empregado para o fim a que se destina. Neste tipo de sistema há vários aspectos que devem ser considerados durante o projeto de arquitetura. Alguns exemplos que podem ser citados é a maneira como a empresa enxerga o Data Warehouse, a forma como os dados são armazenados fisicamente no banco de dados, o volume de informação que este sistema deverá tratar. O último aspecto, por exemplo, é de suma importância para a previsão de recursos que serão necessários no projeto. Neste sentido, os aspectos 43 citados devem ser conhecidos amplamente antes da iniciação de um projeto de arquitetura. Estas decisões devem ser tomadas com base nos recursos globais que o projeto disporá, tais como recursos de infra-estrutura, humanos, orçamentários, tempo, entre outros. Além destes recursos, há uma série de variáveis que devem ser levadas em consideração e que são importantes para escolha da melhor arquitetura para o projeto mencionado. Para entender melhor as principais arquiteturas relacionadas à tecnologia DW, serão apresentadas a seguir, três abordagens consideradas as mais comumente utilizadas sobre o tema segundo Machado (2006). Entretanto, apesar de existirem outras arquiteturas disponíveis para a implementação destes sistemas, serão objetos de estudo deste trabalho, a Arquitetura Global, Arquitetura de Data Mart Independente e a Arquitetura de Data Mart Integrado. 5.9.2. Arquitetura Global A arquitetura global tem um foco corporativo. Segundo Machado (2006), esta arquitetura é aquela onde o Data Warehouse suporta as necessidades da empresa como um todo ou da maior parte destas necessidades. Isso significa que vários representantes dos sistemas transacionais daquela corporação terão seus dados transformados e repassados ao DW por meio de processos especiais. Como exemplo de representantes de sistemas transacionais, pode-se ilustrar o seguinte cenário em que uma empresa possui seis departamentos dentre os quais estão o Departamento de Recursos Humanos, Financeiro, Operacional, Jurídico, Comercial e de Tecnologia. Para o caso exposto, é dito que esta empresa possui um DW implementado de forma global, quando grande parte dos departamentos disponibiliza informações de seus sistemas no DW. Neste sentido o DW é implantado em toda empresa e não somente em um único departamento. O fato de grande parte de departamentos estarem contemplados no DW, significa uma maior abrangência de informações sobre questões operacionais da empresa. A vantagem deste tipo de arquitetura é a possibilidade de cruzamento de dados de vários departamentos de forma integrada, ou seja, quando se deseja obter informações sobre diferentes departamentos, não existe a necessidade de “garimpar” estas informações em diferentes fontes. A partir de uma arquitetura global 44 é possível coletar respostas em um repositório global, em um único momento. Basta que para isso estas perguntas sejam montadas antecipadamente no ambiente de consultas DW. Esta integração, em outras palavras significa maior visão da corporação. Em Inmon (1997) esta integração dados fontes diversas é comentada por ele como “Em todo ambiente, informações operacionais não integrados são complexos e difíceis” e para isso, os sistemas de DW têm suas próprias técnicas para lidarem com isso. Quando bem projetado, um sistema de DW consegue resolver a questão de integração de informações utilizando este tipo de arquitetura. Por contemplar maior parte da companhia, esta arquitetura possui obviamente um custo de implementação mais elevado. A quantidade de recursos necessários nas fases de implementação será maior simplesmente pelo fato desta arquitetura cobrir um escopo mais abrangente da empresa. Para este tipo de implementação geralmente existe um departamento de tecnologia que é responsável pela manutenção deste Data Warehouse. Este é um fato relevante, pois a manutenção destes sistemas será centralizada, evitando problemas de inconsistências ou de múltiplas interpretações. Entretanto este conceito não diz respeito a distribuição física do DW, ou seja, não existe relação do conceito elucidado acima com o fato do sistema ser fisicamente centralizado ou distribuído em locais diferentes. Por fim é importante observar que este tipo de arquitetura possui uma complexidade alta. 5.9.3. Arquitetura Data Mart Independente Arquitetura de Data Mart independente é voltada para grupos ou departamentos específicos, que desejam obter informações sobre suas próprias necessidades de forma isolada. Este tipo de arquitetura é totalmente distinto da arquitetura global e seu escopo são as próprias necessidades do departamento. As informações contidas neste DW independente não se integrarão com as outras áreas da empresa. Devido ao escopo mais limitado e são mais identificados com grupos de necessidades dos usuários, os Data Marts são construídos em esforço/time concentrado. O principal objetivo de implantação deste tipo de arquitetura surge da necessidade de responder a perguntas específicas de um determinado grupo de 45 usuários. Em alguns casos, ela é utilizada para fins demonstrativos por fornecedores de software como prova de conceito ou para apresentar as principais características do Data Warehouse. Neste caso, os dados são extraídos dos sistemas operacionais internos do departamento, com o auxílio da área de tecnologia da informação e carregados em um repositório de dados. Em muitos casos não existe uma manutenção do departamento de tecnologia para estes Data Marts, ficando esta completamente por sua área responsável. O custo de implementação de um Data Mart isolado é mais baixo do que a implementação de uma arquitetura global ou de um Data Mart integrado pelo fato de possuir um escopo menor que o escopo dos outros dois. Geralmente é reunido um pequeno conjunto de profissionais que serão responsáveis pela implantação daquele escopo com base nas necessidades do departamento. 5.9.4. Arquitetura Data Mart Integrado Esta arquitetura é caracterizada pela implementação separada por departamento do seu próprio Data Mart e posterior interconexão provendo uma visão corporativa maior das informações. Os Data Marts integrados mesclam características da arquitetura Global, pelo fato de sua alta integração de informações, e também semelhanças da arquitetura Data Mart Independente onde cada departamento implementa seu DM separadamente. A vantagem de utilização desta arquitetura é a maior distribuição do trabalho e de recursos entre departamentos para a consecução do desenvolvimento. Neste sentido, o custo de administração este tipo de ambiente é mais elevado. Eventualmente alguns departamentos podem compartilhar das mesmas informações e esta arquitetura provê suporte a este tipo de compartilhamento. O lado positivo dessa opção é que se aumenta a capacidade e qualidade de visão corporativa de informações. A responsabilidade pela manutenção deste ambiente é delegada ao departamento de Tecnologia, e a atuação deste nos processos de controle é essencial para integrar o controle e a administração dos Data Marts. 46 5.10. Abordagem de Implementação Em projetos de Data Warehouse podem ser utilizados vários tipos de abordagem de implementação. Entretanto existem dois tipos que são considerados segundo Machado (2006), substancialmente importantes: Implementação Top-Down e Botton-Up. Esta definição está diretamente relacionada a como sistema será desenvolvido. Se o desenvolvimento for gradativo, situação na qual os Data Marts evolutivos integrarão o DW na medida em que forem implementados, tem-se uma abordagem Botton-Up. Quando se opta por uma implementação que engloba o desenvolvimento do sistema todo e de uma só vez para posterior formação de Data Marts, ou implementação monolítica tem-se uma implementação Top-Down. 5.10.1. Top-Down Esta abordagem é muito utilizada como padrão inicial do conceito de DW. Esta abordagem requer um planejamento e definições conceituais de tecnologia completos antes de se iniciar o projeto. Isto se dá porque o sistema será construído de forma monolítica, ou seja, o DW será um construído de forma contínua em um só bloco, e depois disso servirá de base para a carga de Data Marts. Elucidando o conceito acima, nessa arquitetura 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 uma área de armazenagem intermediária ou até diretamente das fontes operacionais. A seguir, os dados são transferidos para o DW. Figura 8 – Abordagem de implementação Top-Down [MACHADO, 2007] 47 A escolha da abordagem deve levar em consideração as vantagens e desvantagens como se observa a seguir: Vantagens Herança de arquitetura - Os Data Marts utilizarão a arquitetura e dados do DW monolítico; Visão de empreendimento - Proporciona uma concentração de todos os negócios da empresa; Repositório de metadados centralizado e simples - Permite manutenções mais simples do que aquelas realizadas em múltiplos repositórios; e Controle e centralização das regras - Garante a existência de um único conjunto de aplicações para extração, limpeza e integração dos dados, além de processos centralizados de manutenção e monitoração. Desvantagens Implementação é muito longa - Nessa abordagem e o desenvolvimento é feito por áreas de assuntos tais como vendas, finanças, recursos humanos, entre outros. Neste sentido, são necessários em média quinze ou mais meses para que a primeira área de assunto esteja em produção; Alta taxa de risco - Não existem garantias para o investimento neste tipo de ambiente; Heranças de cruzamentos funcionais – Se trata de um fator negativo, pois é necessária uma equipe de desenvolvedores e usuários finais altamente capacitados, para avaliar as informações e consultas que garantam a empresa habilidade para sobreviver e prosperar; e Expectativas relacionadas ao ambiente – Esta questão pode gerar insatisfação justamente pelo fator demora de implementação, pois isso pode induzir expectativas nos usuários. 5.10.2. Botton-Up O fato da implementação Top-Down ser politicamente difícil, ser definida como cara e demorada, e com ROI (Return of Investment) demorado pode levar a 48 utilização da abordagem de implementação Botton-Up e é bem aceita pelos executivos pelo fato de possuir um ROI rápido. Para isso há de se fazer uma análise detalhada das vantagens e desvantagens de cada implementação para que seja possível calcular qual será a mais aplicável e vantajosa em um determinado cenário. Neste caso a implementação permite que o planejamento e o desenho dos Data Marts possam ser realizados sem esperar que seja definida uma infra-estrutura corporativa para o DW. A infra-estrutura existirá e será implementada conforme as Datas Marts forem sendo desenvolvidos. Elucidando o conceito da abordagem Botton-Up e o seu fluxo, o processo se inicia com a extração, a transformação e a integração das informações dos sistemas operativos e dados externos diretamente para um DM específico e lá ficam armazenados. No contexto empresarial pode existir diversos Data Marts relacionados com os assuntos da empresa (tais como RH, Financeiro, Operacional). Após a construção destes DMs eles serão integrados para a composição do Data Warehouse de forma única. Figura 9 – Abordagem de implementação Botton-Up [MACHADO, 2007] Vantagens Implementação rápida - Esta é altamente direcionada, permitindo um desenvolvimento rápido; 49 Retorno rápido - Permite que o produto mostre rapidamente seu valor e servindo como base para investimento adicional com nível mais elevado de confiança; Manutenção do enfoque da equipe - Em equipes fixas e subdivididas por assuntos é mais fácil de manter um foco definido do que quando se tem uma implementação; e Herança Incremental - Na medida em que obriga a entrega de recursos de informação passo a passo. Isso permite à equipe crescer e aprender, reduzindo os riscos. Desvantagens Desafio de possuir a visão de empreendimento - De modo a manter um rígido controle do negócio como um todo pois requer maior trabalho ao extrair e combinar as fontes individuais do que utilizar um DW; e Administrar e coordenar múltiplas equipes e iniciativas - Normalmente este tipo de arquitetura emprega o desenvolvimento de DM em paralelo. Isso pode conduzir a uma rígida administração, tentando coordenar os esforços e recursos das múltiplas equipes, especialmente nas áreas de regras e semântica empresariais. 5.11. Extração, Transformação e Carga Segundo Oliveira (2002) a fase de ETL (Extração, Transformação e Carga) é composta por um conjunto de processos que têm como objetivo coletar as informações que serão utilizadas no sistema Data Warehouse a partir do ambiente tradicional (OLTP). De maneira geral, seleciona-se as informações essenciais do sistema OLTP, realiza transformações e limpeza nos mesmos e logo após as carrega no ambiente DW. Conforme o autor citado, esta fase é considerada uma das etapas mais críticas da construção de um DW. Ela envolve a fase de extração dos dados dos sistemas transacionais ou de outras fontes tais como flat files (arquivos texto), planilhas; a fase de filtragem que consiste em garantir a integridade dos dados e a fase de carga dos dados no DW. 50 Esta fase constitui-se essencialmente em observar os requisitos dos usuários finais e reproduzir esta especificação na forma de mapeamentos. Este mapeamento deve dizer onde as informações solicitadas estarão presentes dentro dos sistemas fonte, quais são as regras de negócio que deverão ser aplicadas e qual deve ser o destino destes dados no DW. Durante a movimentação dos dados entre os sistemas transacionais e o DW tem-se a impressão que nada além de simples extrações de dados de um local para outro está ocorrendo. Em função disto, muitas vezes as empresas acabam perdendo tempo e dinheiro por ter de refazer toda a parte de extração. O desafio por trás disso não é técnico e sim gerencial, pois não é fácil automatizar estas tarefas. Especialistas afirmam que identificar fontes, definir regras de transformação e detectar e resolver questões de qualidade e integração consomem cerca de 80% do tempo de projeto. Além disso, existem outros fatores influentes na estimativa de tempo para estas tarefas, tais como o grande número de fontes e a qualidade dos metadados mantidos sobre estas fontes. 5.11.1. Melhores Práticas Segundo Kimball (1998) são necessários onze etapas para extração dos dados de produção para o DW que são consideradas melhores práticas no desenvolvimento deste tipo de sistema. As etapas são as seguintes: 1. Extração primária (Ler o formato legado); 2. Identificação dos registros modificados; 3. Generalização de chaves para dimensões e modificação; 4. Transformação em imagens de registro de carga; 5. Migração do sistema legado para o sistema de Data Warehouse; 6. Classificação e construção de agregados; 7. Generalização de chaves para agregados; 8. Carregamento; 9. Processamento de exceções; 51 10. Garantia de qualidade; e 11. Publicação. O processo de carga dos dados passa por algumas etapas: extração (envolve os passos 1, 2 e 3), transformação (passos 4, 5, 6 e 7), carga (passos 8 e 9) propriamente dita e homologação (passos 10 e 11). 5.11.2. Extração O processo de Extração de Dados de um ambiente de produção transacional para o Data Warehouse muitas vezes requer adaptação às tecnologias já existentes nestes sistemas transacionais. O fato é que os sistemas transacionais podem apresentar-se implementados utilizando diversas tecnologias de gerenciamento de banco de dados. Um exemplo desta heterogeneidade é o fato que muitas vezes, os dados são transferidos de um banco de dados hierárquico, como o Adabas, para uma nova tecnologia de SGBD para Data Warehouse, tal como o Oracle. Não menos comum é a utilização de arquivos texto (flat files) que utilizam algum símbolo textual específico como delimitador de colunas e que são utilizados como fonte para o DW. Estes flat files comumente são gerados a partir dos dados de um repositório especifico e disponibilizados para que sejam usados como fonte para os processos de Extração DW. Segundo Inmon (1997) algumas funcionalidades são necessárias durante a fase de extração dos dados: A seleção de dados do ambiente operacional pode ser muito complexa, pois muitas vezes é necessário selecionar vários campos de um sistema operacional para compor um único campo no Data Warehouse; Os dados são re-formatados. Por exemplo: um campo data do sistema operacional do tipo DD/MM/AAAA pode ser passado para o outro sistema do tipo ano e mês como AAAAMM; Podem existir várias fontes de dados diferentes para compor uma informação. Ela pode ser oriunda de uma planilha Excel enquanto uma outra que serviria para compor um mesmo fato viria de um arquivo texto; 52 Quando há vários arquivos de entrada, a escolha das chaves devem ser feitas antes que os arquivos sejam intercalados. Isso significa que se diferentes estruturas de chaves são usadas nos diferentes arquivos de entrada, então se deve optar por apenas uma dessas estruturas; Os arquivos devem ser gerados obedecendo a mesma ordem das colunas estipuladas no ambiente de Data Warehouse; Pode haver vários resultados. Dados podem ser produzidos em diferentes níveis de resumo pelo mesmo programa de criação do Data Warehouse; Valores padrões devem ser fornecidos. Às vezes pode existir um campo no Data Warehouse que não possui fonte de dados, então a solução é definir um valor padrão para estes campos; Data Warehouse espelha as informações históricas necessárias, enquanto o ambiente operacional focaliza as informações correntes; e Volumes massivos de entrada devem ser levados em consideração. Quando há somente uma pequena quantidade de dados de entrada, diversas opções de projetos podem ser conciliadas. Mas quando há muitos registros de entrada, opções especiais de projeto (como cargas em paralelo ou leituras em paralelo) talvez tenham que ser empregadas. 5.11.3. Transformação Seguindo o fluxo ETL existem os processos de transformação. Após a etapa de Extração dos dados é necessária uma definição de qual deverá ser o formato de armazenamento dos dados no Data Warehouse. Existe a necessidade de filtrar os dados para colocá-los no padrão definido. Esta etapa tem como um dos objetivos padronizar a informação vinda de diversas fontes de dados de forma a apresentar os dados de maneira homogênea. O objetivo disso é evitar várias interpretações que podem ser causadas pela existência da mesma informação com um formato diferente. Este passo garante que informações cruzadas de vários sistemas tenham um sentido único. Um exemplo simplório desta padronização se dá quando se considera um sistema operacional onde existe o campo de sexo sendo preenchido como “F” ou “M” e em outro sistema tem-se este mesmo dado está sendo preenchido como “0” 53 ou “1”. É, justamente, nesta hora que entra a parte de transformação, que remodela todos estes dados para o padrão definido. Outro objetivo da etapa é o de fazer com que as regras de negócio sejam carregadas no DW. O objetivo disso é fazer com o que o DW possa refletir com fidelidade a realidade dos processos da empresa. Exemplo deste cenário é quando em um sistema transacional se tem uma informação para um cálculo contábil de desconto de determinado imposto sobre o salário de um empregado. Para o caso desta regra de negócio específica, é necessário fazer uma transformação matemática envolvendo cinco campos do banco de dados, utilizando somas, percentuais, divisões. Para que esta informação seja reproduzida de maneira correta dentro do DW é preciso que esta regra de negócio seja implementada corretamente durante o processo de transformação de dados. Por fim o processo de transformação de dados é responsável por implementar rotinas que tornem os dados homogêneos à medida que estes dados são filtrados e limpos e também é responsável pela implementação da lógica do negócio para que os processos dos sistemas transacionais sejam refletidos dentro do Data Warehouse. 5.11.4. Carga Esta se trata da ultima etapa do processo, onde os registros são efetivamente gravados no banco de dados DW. Há algumas maneiras em que a informação pode ser inserida no DW, por meio de um registro por vez, por meio de uma interface de linguagem, ou em massa com a ajuda de um utilitário. Em geral, a carga de dados por meio de um utilitário é mais rápida. Em alguns casos, convém declarar a parte de índices após toda a carga inicial do Data Warehouse. A carga também pode ser incremental ou total. A carga incremental normalmente é feita para tabelas fatos e a carga por cima dos dados é feita em tabelas dimensões onde o analista terá que apagar os dados existentes e incluí-los novamente. Este processo de carga incremental para as dimensões normalmente acontece devido os usuários já estarem com o arquivo pronto, que foi gerado a partir 54 da extração dos operacionais. No entanto, se a modificação for apenas de inclusão de um registro, deve ser feito diretamente no Data Warehouse. Caso a carga não seja possível, por problemas de obtenção dos dados necessários, o Data Warehouse se tornará inutilizável. 5.11.5. Ferramentas Segundo Oliveira (2002), existem algumas categorias de ferramentas ETL conforme descrito na figura a seguir: 55 Figura 10 – Tabela de ferramentas segundo [OLIVEIRA, 2002] 5.12. OLAP Online Analiytical Processing (OLAP) é um conjunto de ferramentas que possibilitam a análise e exploração das informações contidas em um Data 56 Warehouse de maneira multidimensional ao invés de tabelas representando um conjunto de tecnologias projetadas para suportar análise e consultas ad hoc que segundo Inmon (1994) “são consultas com acesso casual único e tratamento dos dados segundo parâmetros nunca antes utilizados, geralmente executado de forma iterativa e heurística”. Segundo Machado (2006) este tipo de ferramenta permite ao usuário analisar o porquê dos resultados obtidos. Atualmente existe disponível no mercado uma variedade dessas ferramentas com diferentes abordagens. Estas ferramentas basicamente têm o papel de fazer interface entre o usuário e o sistema gerenciador de banco de dados. Entende-se por usuário tanto o desenvolvedor que é o profissional responsável pela criação das consultas, quanto os usuários finais os quais a solução é direcionada. Elas têm a habilidade de simplificar o processo de desenvolvimento, o gerenciamento de metadados, o processo de consulta dos usuários, entre outros. 5.12.1. Características das ferramentas OLAP Por meio do modelo multidimensional é possível fazer uma grande diversidade de combinações que possibilitam a extração das informações conforme necessidade. Estas informações ajudam analistas e executivos a sintetizarem informações sobre a empresa, utilizando comparações, visões personalizadas, análise histórica e projeção de dados em vários cenários de "e se..." entre outras funções estatísticas e financeiras por ser mais natural, fácil e intuitiva, permitindo a visão em diferentes perspectivas dos negócios da empresa, fazendo com que o analista seja um explorador da informação. Sistemas OLAP são implementados para ambientes multi usuário, arquitetura cliente-servidor oferecendo respostas rápidas e consistentes às consultas iterativas executadas pelos analistas, independente do tamanho e complexidade do banco de dados. Segundo Machado (2007) a arquitetura OLAP possui três componentes principais: Um modelo de negócios para análises interativas, implementado numa linguagem gráfica que permite diversas visões e níveis de detalhes dos dados; 57 Um motor OLAP para processar consultas multidimensionais contra o dado-alvo; e Um mecanismo para armazenar os dados a serem analisados. A base de dados usada define se o pacote é um ROLAP, que interfaceia(?) com um banco de dados relacional de mercado, ou um MOLAP, que se liga a um servidor OLAP, usando um banco de dados multidimensional e dedicado. Machado (2006) diferencia as variações de ferramentas OLAP como segue observado a seguir: ROLAP (Relational OLAP) – é um produto relacional OLAP que possibilita a análise multidimensional de dados, agrega e armazena dados em um SGBDR – Sistema Gerenciador de Banco de Dados Relacional. O processamento multidimensional pode ser feito dentro do SGBDR, ou na camada de servidor ou no cliente; MOLAP (Multidimensional OLAP) – é um banco de dados multidimensional. Um produto que pode armazenar e processar dados multidimensionais; HOLAP (Hibrid OLAP) – é um produto de OLAP híbrido que pode prover análise multidimensional e simultaneamente de dados armazenados em um banco de dados multidimensional e em um banco de dados relacional; e DOLAP (Desktop OLAP) – ferramentas OLAP voltadas para computadores pessoais. Este tipo de ferramenta vem sendo mais empregado nos bancos de dados individuais para análises mais específicas do que as realizadas no DM. Os dados, normalmente, são carregados a partir de DM. 5.12.2. Operações Básicas OLAP As operações OLAP são executadas basicamente por aplicativos para usuários finais que possuem acesso de leitura das bases de dados a fim de extraírem e manipularem o layout das informações para seus relatórios de forma que estes respondam às suas questões gerenciais. 58 Essas ferramentas surgiram juntamente com os sistemas de apoio à decisão (DSS – Decision Suport System) para fazerem consulta e análise dos Data Warehouses e Data Marts, apoiando o usuário final nas suas atividades, tais como slice and dice e drill, onde as operações drill utilizam a navegação nos dados, modificando o nível da granularidade da consulta e para navegar nas dimensões são utilizados as operações de slice and dice. Segundo Machado(2007) as principais operações OLAP são: Drill Down e Roll Up - método de exploração de dados detalhados que foram usados na criação de um nível sumarizado de dados ao longo dos níveis hierárquicos de uma dimensão. O Drill Down ocorre quando o usuário aumenta o nível de detalhe da informação, diminuindo o nível de granularidade; e Drill Up ou Roll Up – é o inverso, ocorrendo quando o usuário aumenta o nível de granularidade, diminuindo o nível de detalhamento da informação. Com a capacidade do drill o usuário pode navegar do mais alto nível até o nível mais detalhado. Já com a capacidade de roll up o usuário pode navegar no nível de detalhe até o mais alto nível de sumarização dos dados. Os quais os níveis de aprofundamento dependem da granularidade dos dados existentes no Data Warehouse; Drill Across - ocorre quando o usuário pula de um nível intermediário dentro de uma mesma dimensão, desde que ambos tenham algumas dimensões em conformidade, ou seja, as mesmas dimensões estão compartilhadas; Drill Through - está relacionado com o fato de se desejar uma informação num nível de detalhe menor do que aquele colocado na tabela fato e permitido pela sua granularidade. Em um Data Mart onde trabalha com informações sumarizadas no nível de Linha de Produtos e deseja baixar o nível, onde este nível menor é encontrado no Data Warehouse (havendo compatibilidade entre os dois ambientes). Neste caso, a ferramenta OLAP irá efetuar um Drill Through e buscar esta informação no ambiente de DW; e 59 Slice And Dice - é uma das principais características de uma ferramenta OLAP. Como a ferramenta OLAP recupera o micro cubo, surgiu a necessidade de criar um módulo que se convencionou de Slice and Dice para ficar responsável por trabalhar esta informação, servindo para modificar a posição de uma informação, alterar linhas por colunas de maneira a facilitar a compreensão dos usuários e girar o cubo sempre que tiver necessidade. Com o Slice and Dice é possível analisar as informações de diferentes prismas limitados somente pela imaginação e agindo como um filtro. Utilizando esta tecnologia é possível visualizar a informação sobre ângulos que anteriormente inexistiam sem a confecção de um Data Warehouse e a utilização de uma ferramenta OLAP. De maneira simplista, significa a redução de escopo das informações em análise, mudando a ordem das dimensões e a orientação de acordo com a maneira que os dados são visualizados. 5.13. Metadados Uma parte importante do Data Warehouse são os Metadados, também chamados de dados sobre os dados e índice do conteúdo de um DW. Possui um mapeamento de que modo os dados foram extraídos das fontes operacionais e como estão sendo inseridos no DW. Os metadados definem os tipos de dados e descrevem os dados de negócio, não apenas o conteúdo do DW, mas também informações úteis para o julgamento da qualidade do conteúdo. Em um projeto de Data Warehouse, o processo de metadados deve gerar e gerenciar uma documentação sobre o levantamento de dados, do banco de dados, a origem dos dados que alimentam o DW, processos de extração , tratamento e rotinas de cargas dos dados, as regras de negócios da empresa e todas as suas mudanças. Os metadados podem surgir de vários locais no decorrer do projeto e permitem ao usuário transformar os dados crus em informações que gerem conhecimento e tragam vantagem competitiva. O coração da arquitetura do ambiente de BI (Business Intelligence) é o Data Warehouse, e no seu centro nervoso estão os metadados, sendo considerado o 60 DNA do DW. Sem Metadados, o Data Warehouse e seus componentes nesta arquitetura, são meramente componentes deslocados, trabalhando independentemente e com metas diferentes. Para alcançar harmonia e unidade entre os diferentes componentes no ambiente de Data Warehouse, é necessário ter uma bem definida e disciplinada integração com metadados. Segundo Machado (2007), os metadados são classificados conforme descrito a seguir: Metadados Técnicos – Os metadados técnicos fornecem aos desenvolvedores e aos usuários técnicos de sistemas de suporte à decisão a confiança de que os dados estão corretos. Eles são críticos para a manutenção e o crescimento contínuo do DW; e Metadados de Negócio – Estes metadados são o elo de ligação entre os usuários de negócios (executivos e analistas de negócios) e o DW. Os metadados de negócios mostram que relatórios, consultas e dados estão no DW, a localização dos dados, confiabilidade dos dados, contexto dos dados, regras de transformação que foram aplicadas e as origens desses dados. 5.13.1. O Data Warehouse e o modelo de dados No ambiente do Data Warehouse, Inmon (1997) destaca três modelos de dados: corporativo (genérico), operacional (aplicações operacionais) e analítico (Data Warehouse). O modelo corporativo de dados contém primitivas básicas sobre o tipo de dados necessários para a corporação. Os outros dois modelos (operacional e analítico), são derivações do modelo corporativo. 5.13.2. Padrões para Metadados Atualmente existem vários padrões para descrever metadados, como The Text Encoding Initiative (TEI), Metadata Encoding and Transmission Standard (METS), Metadata Object Description Schema (MODS), The Encoded Archival Description (EAD) e MPEG-7. Entretanto o padrão de metadados Dublic Core é o principal dentre eles. Essas duas instituições (OCSC e NCSA) realizaram um 61 workshop em Dublin, Ohio no ano de 1995. Os trabalhos continuaram a serem desenvolvidos e gerenciados pelo DCMI. Ele tem como objetivo definir um grupo de elementos que possam ser usados por autores para descrever seus próprios recursos na Web. Isso ocorreu devido a grande incapacidade das bibliotecas eletrônicas de catalogar todos esses recursos, que atualmente são muitos na Web. O objetivo era definir poucos elementos e algumas regras para serem usadas nos recursos não catalogados. O DCMI tem uma definição própria que diz: “Dedicado a promover a adoção difundida de padrões interoperacionais de metadados e a desenvolver vocabulários especializados de metadados para sistemas de busca”. 5.13.3. Dublin Core Inicialmente, o padrão Dublin Core possuía treze elementos, agora são quinze: Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, Rights. Entretanto o Dublin Core passa por um problema: o de qualificar ao máximo suas descrições ou continuar simples e conciso. Se tornar qualificado pode trazer várias vantagens para esse padrão. Um bom exemplo disso é o elemento data, ele pode com outro significado, como identificar as data de alteração de um documento seguindo um padrão ISO (o qual definiu representação para data e hora). Todos os elementos do Dublin Core são opcionais e todos são repetíveis. Os elementos podem ser apresentados em toda a ordem. Os valores dos elementos não possuem um padrão. Entretanto, Dublin Core recomenda que use alguns valores controlados para campos apropriados, como Subject. O Dublin Core apenas recomenda isso, não é obrigatório. Por esse motivo alguns grupos vêm trabalhando para definir algum padrão para definir os campos (resource Type). Embora tão padrão tenha sido criado para descrever documentos Web, passou a ser usada em aplicações mais complexas, devido a sua eficiência e simplicidade. Pesquisadores, museus e músicas utilizam o padrão Dublin Core. 62 5.13.4. TEI O TEI, que significa iniciativa de codificação de textos, é um projeto internacional que busca desenvolver padrões para caracterizar textos eletrônicos como peças, poesias, novelas, entre outros. Primeiramente tem como finalidade possibilitar a pesquisa para a população, pretendendo chegar a estabelecer um padrão para a codificação de textos, o padrão do TEI também especifica um cabeçalho, que traz metadados sobre o próprio texto. 5.13.5. METS Foi desenvolvido com o intuito de suprir a necessidade de padrões para estruturação de dados em objetos complexos de bibliotecas digitais. O METS é um XML Schema para criação de documentos XML que expressam a estrutura de objetos de bibliotecas digitais, a descrição associada e metadados administrativos, além do nome e da localização do objeto digital. 5.13.6. EAD Foi criada para servir como uma forma de caracterizar estruturas de arquivos, para que estes arquivos pudessem ser procurados e mostrados na internet. Assim como o TEI a EAD trás um cabeçalho que descreve a estrutura de arquivo, e segue descrevendo a coleção, podendo trazer apontadores para objetos digitais. A EAD e bastante popular em bibliotecas acadêmicas, sociedades de história, e museus com grandes coleções. A EAD acaba tornando possível a disposição de peças únicas na internet. 5.13.7. RDF O padrão RDF foi desenvolvido pela W3C. É um modelo de dados para descrição de recursos na Web. Serve como um mecanismo para integração de múltiplos esquemas de metadados. Possui um namespace o qual é definido por uma url, apontando para a descrição do esquema de metadados usado. Pode haver vários namespaces apontando para vários esquemas usados ao mesmo tempo, geralmente expressos em XML. 63 5.14. Ciclo de Vida de Desenvolvimento Segundo Inmon (2005), é preciso ver como o dado operacional é usualmente orientado a aplicação e as suas conseqüências, como a falta de integridade, enquanto dados de Data Warehouse são integrados. Outra diferença existente entre o nível operacional de dado e processamento e o nível de DW de dado e processamento. O ciclo de vida de desenvolvimento subjacente destes sistemas pode causar profunda preocupação. Figura 11 – O Ciclo de Vida do desenvolvimento de sistemas [INMON, 2005] A figura 10 mostra que o Ciclo de vida de desenvolvimento de sistemas clássico (quadro à esquerda) é praticamente o oposto do ciclo de vida de desenvolvimento de DW (quadro à direita) 64 5.14.1. Fases para um projeto Data Warehouse Com o intuito de oferecer software de qualidade aos compradores, muitas vezes é preciso estabelecer quais serão as fases para a construção de um determinado produto. O planejamento destas fases é de vital importância, pois a partir dele é possível determinar uma série lógica de atividades que deverão ser executadas para a construção deste software. As atividades deverão ser totalmente claras e compreensíveis para toda equipe de projeto com o objetivo de construir o produto certo e da maneira certa. Neste sentido Barbiere (2001) sugere um conjunto de fases para o desenvolvimento de sistemas Data Warehouse e Data Mart. Estas fases são mostradas de forma macro a seguir e explicadas ao longo deste tópico da pesquisa. Estas fases ajudam a equipe de desenvolvimento na medida em que a norteiam em relação às principais atividades a serem executadas durante a construção do DW/DM. As fases por Barbiere (2001) são: Planejamento; Levantamento das necessidades; Modelagem dimensional; Projeto físico dos banco de dados; Projeto de ETL; Desenvolvimento de aplicações; Validação e Teste; Treinamento; e Implantação. A seguir estas fases são explicadas detalhadamente. 5.14.1.1. Levantamento das Necessidades Nesta etapa deverão ser identificados dois modelos. O primeiro modelo é o modelo Dimensional, ou aquele que representa os blocos conceituais de dados necessários ao alcance dos objetivos do sistema de suporte a decisão. O outro modelo é relacionado com as fontes das informações. É o modelo Fonte dos Dados. 65 Nele deverão ser registrados os blocos conceituais de dados existentes, com suas respectivas descrições e formas atuais de armazenamento e de uso nos sistemas. 5.14.1.2. Modelagem A modelagem de dados é seguramente um dos fatores críticos de sucesso em um projeto de DW e pode representar a fronteira entre o seu sucesso e o seu fracasso. Os volumes brutos dos dados deverão ser cuidadosamente considerados no projeto, visando ao processamento para obtenção das informações sumarizadas e consolidadas. 5.14.1.3. Projeto Físico Nessa etapa serão desenhadas as estruturas lógicas do modelo dimensional, com as definições das tabelas fatos e dimensões, relacionamentos, indexação, atributos de tabelas e implantação de regras. 5.14.1.4. Projeto ETL Nessa etapa deverão ser definidos os processos requeridos de transformação do modelo fonte para o modelo dimensional. Segundo Barbiere (2001), os conceitos de extração dos dados e de seu tratamento podem ser divididos em: Filtro de Dados – Relaciona os procedimentos e condições para se eliminar os elementos de dados indesejáveis no modelo dimensional; Integração dos Dados – Define a forma de se correlacionar informações existentes de formas distintas e que deverão ser integradas no sistema gerencial; Condensação dos Dados – Define forma de se reduzir volumes de dados visando a obter informações resumidas e sumarizadas; Conversão de Dados – Define os procedimentos para se transformar dados em unidades, formatos e dimensões diferentes; e Derivação de Dados – Define os meios e fórmulas para se produzir dados virtuais, a partir de dados existentes. 66 5.14.1.5. Desenvolvimento das Aplicações Nessa etapa será projetado o sistema aplicativo, objeto do trabalho. As ferramentas devem ser de fácil utilização e devem priorizar a interface Web, facilitando o acesso aos dados via browser. 5.14.1.6. Validação e Teste Fase em que o sistema é testado e validado, considerando-se o máximo possível, as simulações de volume e de processamentos. 5.14.1.7. Treinamento O grupo objeto do treinamento deverá ser formado prioritariamente de usuários voltados para atividades de negócios, além de gerentes das áreas envolvidas. 5.14.1.8. Implantação A implantação deverá ser seguida de um rigoroso acompanhamento de uso das aplicações disponibilizadas. Os usuários devem ser estimulados a apresentar criticas e sugestões de melhorias para as próximas versões do sistema. Em paralelo com as etapas descritas anteriormente, acontecerá a construção do diretório de metadados do projeto. 5.14.2. Problemas Comuns de Desenvolvimento Alguns problemas podem ocorrer durante o desenvolvimento de um sistema DW. Para ajudar o gerente do DW a detectá-los, Barquini (1996) antecipa os problemas mais comumente encontrados: Iniciação do projeto sem o comprometimento da diretoria da companhia – Para que o projeto de DW tenha sucesso e continuidade é necessário que a alta diretoria esteja comprometida com o projeto, garantindo as verbas necessárias e ajudando a direcionar o foco do DW para o negócio da organização; Levantar expectativas prometendo o que não é possível de ser cumprido – Frases do tipo "O DW guiará os gerentes para as melhores decisões" podem causar tanto desconfiança no projeto quanto desprezo. O DW não mostrará as melhores decisões, mas sim respostas às 67 consultas efetuadas. Cabe aos usuários elaborar consultas inteligentes e analisar as respostas obtidas; Carga de dados desnecessários dentro do DW – Nem todos os dados disponíveis nos sistemas transacionais da organização são necessariamente úteis para o DW. O arquiteto dos dados deve analisar, junto aos usuários, quais os dados que realmente contêm informações necessárias e desprezar aqueles que não fazem parte dos objetivos do DW; Confundir o projeto do banco de dados DW com o projeto de um sistema transacional – Em um processo transacional, o projeto deve fornecer velocidade de acesso e facilidades na atualização de registros. O DW é fundamentalmente diferente. A meta no DW são acessos agregados, ou seja, somas, médias, tendências, entre outros. Outra diferença entre os dois tipos de sistemas é o tipo de usuário. Nos sistemas transacionais um programador desenvolve uma consulta que poderá ser utilizada milhares de vezes. No DW o usuário final desenvolve suas consultas que podem ser utilizadas somente uma vez; Optar por gerente técnico de Data Warehouse – Escolher um gerente para o DW com orientação técnica: O DW é essencialmente uma prestação de serviços e não um serviço de armazenamento de dados, por isso é fundamental que o gerente do DW seja uma pessoa voltada aos interesses dos usuários e, principalmente, que fale a mesma “língua” deles; Grande foco em dados do tipo registros – Muitas vezes os projetos de DW partem do princípio de que as informações necessárias ao bom desempenho do DW estão somente em forma de registros nos arquivos dos sistemas transacionais da organização. Isto pode ser um equívoco, já que muitas informações podem estar armazenadas fora dos sistemas transacionais, em forma de textos, imagens, sons e vídeos; Crer nas promessas de performance, capacidade e escalabilidade dos fornecedores – A informática cresce de uma maneira muito rápida, isto também acontece com o tamanho do DW, portanto é interessante 68 fazer um estudo de crescimento do DW antes de definir a configuração que deve atender, com folga, o banco de dados do DW, pelo menos até a conclusão do projeto inicial. É interessante que o servidor do banco de dados do DW seja fornecido por uma organização idônea e que garanta futuras expansões; e Crer que ao término do projeto e a subida para a produção resolverá todos os problemas – Assim que o DW começar a rodar, os usuários começarão a criar mais consultas e estas consultas necessitarão de novos dados que resultarão em novas consultas. Assim, o projeto do DW precisa ser atualizado continuamente, não só com novos dados, mas também com novas tecnologias. 5.14.3. Recursos Humanos Segundo Inmon (1999) para criar e manter um Data Warehouse é necessário desenvolver uma série de funções. Dependendo do tamanho do projeto e do tipo de tecnologia utilizada podem ser necessárias várias pessoas para realizar as diferentes funções previstas e, ao mesmo tempo, deve-se manter a equipe de Data Warehouse relativamente pequena, para que possa responder de maneira rápida às necessidades de informação em constante mudança em toda organização. A maneira mais eficaz de arquitetar um DW que transforme dados em informação é ter, na equipe, funcionários que já fazem parte da organização, com habilidades de negócios necessárias para executar certas funções. Estas funções podem variar conforme o estágio em que se encontra o DW, bem como podem ser agrupadas para que uma só pessoa realize várias delas ao mesmo tempo. Inmon (1999) sugere o quadro a seguir para o desenvolvimento inicial de um Data Warehouse: Tabela 5 – Quadro de funcionários sugeridos para desenvolvimento inicial de um DW [INMON, 1999] Ftes1 Função Descrição Mínimos Iniciais 1 Full Time Equivalents – Funcionários equivalentes em tempo integral. 69 Administrador de Data Warehouse Gerencia o projeto total, desde incursão na implementação inicial ate 1 manutenção e iterações adicionais. Gerencia as expectativas e Gerente de Mudança percepções da organização quanto ao Organizacional de Data DW Warehouse, suas capacidades, Menos de 1 limitações e o impacto em todos os aspectos da organização Administrador de Banco de Dados Cria e gerencia o(s) banco(s) de dados físicos que compõe(m) todos os 1 níveis e aspectos do Data Warehouse Gerencia metadados de negócios e Gerente de técnicos, Metadados atuais, assegurando precisos e que estejam adequadamente Menos de 1 integrados Analista de necessidades de negócios Identifica e analisa as necessidades de informação de negócios da organização e auxilia no projeto do DW 2 para satisfazer essas necessidades Cria e mantém os modelos de Arquiteto de Data Warehouse dados para todos os níveis do DW. Analisa sistemas de origem para 1 determinar sistema(s) de registro. Projeta aquisição de dados e ambiente técnico Cria Desenvolvedor e mantém programas e de processos que executam a extração, Aquisição de Dados transformação e carga de dados das 1a3 origens até os alvos 70 Cria Desenvolvedor e mantém programas e de processos e “caminhos” predefinidos que Acesso a Dados 1a3 permitem que usuários finais acessem dados do DW Cria Desenvolvedores de Manutenção de DW e mantém programas e processos e procedimentos para executar tarefas de manutenção como 1 arquivamento, recuperação, segurança, monitoração, entre outros. Responsável executivo de Sistema de Informação Analista de Qualidade de Dados Responsável pelo suporte ao 1 (Não é projeto de DW em termos de fornecimento uma tarefa de fundos, recursos e de representação de tempo frente aos seus colegas de alto escalão. integral) Monitora e assegura qualidade de dados no DW que satisfaça as Mais do que 1 necessidades da organização Tabela 6 – Quadro de Funcionários de SI sugerido para Gerenciamento Contínuo de DW[INMON 1999] Função FTEs Adicionais por Iteração Lideres Administrador de Data Warehouse de equipe podem ser requeridos se a funcionalidade do DW crescer a um tamanho que os torne necessários. Gerente de Mudança Organizacional de Possivelmente DW Administrador de Banco de Dados 1 após diversas iterações. Até 1 para cada 2 ou 3 iterações adicionais. 71 Gerente de Metadados Mínimo de 1 após a primeira interação e as seguintes. 2 adicionais após a implementação Analista de necessidades de negócios inicial; até 1 para cada duas ou três iterações seguintes. Arquiteto de Data Warehouse Mínimo de 1 após a primeira iteração e as seguintes. Até 1 para cada uma ou duas novas Desenvolvedor de Aquisição de Dados iterações e para a sua manutenção, dependendo do crescimento da demanda de usuários. Até 1 para cada uma ou duas novas Desenvolvedor de Acesso a Dados iterações e para a sua manutenção, dependendo do crescimento da demanda de usuários. Desenvolvedores de Manutenção de DW 0 a 1 após dependendo da diversas iterações, complexidade das funções de manutenção. Responsável executivo de Sistema de 0 Informação (nenhum recurso adicional necessário) Possivelmente 1 ou mais após a iteração Analista de Qualidade de Dados qualidade inicial, de dependendo dados dos da novos sistemas de registro e da qualidade apresentada por sistemas de registro existentes. A equipe de projeto do Data Warehouse será tipicamente composta de doze a quinze pessoas que serão responsáveis por criar um Data Warehouse na organização. Inmon (1999) sugere que a equipe ideal deve ser composta de 72 projetistas de banco de dados, de pessoas que conheçam bem os sistemas legados por dentro e por fora para a extração dos dados necessários para o Data Warehouse (arqueologistas de dados), programadores de sistemas para assegurar que os dados dos sistemas legados movam-se de forma limpa e repetitiva pelo Data Warehouse, usuários, instrutores e administradores de Data Warehouse, que em geral, são responsáveis pela coordenação de todos os aspectos do projeto de DW e por equilibrar as necessidades e objetivos de todos os interessados. 6. Protótipo – Validação da Pesquisa Baseado na pesquisa realizada foi elaborado um protótipo para aplicação dos conceitos aqui apresentados em uma necessidade real. Este protótipo tem o objetivo de solucionar o problema da falta de um sistema gerencial para análise das informações obtidos a partir da base de dados transacional da Escola Tangran. O desenvolvimento de um Data Mart supre a necessidade da alta gerência da Escola em responder questões gerenciais relacionadas ao desempenho de alunos, professores e da Escola em si, de acordo com os dados obtidos nos sistemas transacionais. A metodologia utilizada para o desenvolvimento deste protótipo segue as fases sugeridas por Barbiere (2001) que foi apresentado anteriormente. Segue adiante o desenvolvimento do protótipo conforme as fases definidas para o projeto de um DW/DM. 6.1. Planejamento O escopo do projeto limita-se análise de questões de ocorrências de professores e alunos, desempenho e como a freqüência dos responsáveis tem influenciado no desempenho destes alunos. Estas questões são detalhadas no tópico seguinte. O Data Mart será desenvolvido utilizando a abordagem evolutiva ou Bottomup e poderá ser integrado, futuramente, a outros Data Marts a fim de formar um Data Warehouse. 73 Os recurso utilizados para a criação deste protótipo foi descrito no item 3.4 do presente trabalho, mas em geral vai contar com: O Sistema Gerenciador de Banco de Dados adotado será o Oracle Database Server 9i, e a ferramenta de ETL será o Oracle Warehouse Builder, montado em uma máquina HP DV4000 com 1 processador Centrino 2 GHz, 1GB de memória RAM, 80 GB de espaço interno; e A ferramenta que será utilizada para apresentação do Front End será o Oracle Discoverer, montada em um segundo equipamento HP DV1000 com 1 processador de 2 GHz, 1GB de memória RAM, 120 GB de espaço em disco. 6.2. Levantamento de Necessidades Existe a necessidade de informações gerenciais automatizadas e mais precisas para fornecimento de um subsidio confiável à tomada de decisão. Foi adotada uma granularidade de dados bimestral devido ao fato de que avaliações marco, tanto sobre a escola quanto sobre alunos, são feitas obedecendo a períodos de dois meses. Nesta etapa serão identificados dois modelos: O modelo dimensional e o modelo fonte dos dados. Durante a fase inicial, foram identificadas algumas necessidades junto a alta diretoria da escola sobre questões que deveriam ser respondidas por meio da implementação do sistema Data Warehouse, listadas a seguir: Nível de ocorrências por professor – No sistema OLTP existem ocorrências sobre diversos fatos relacionados aos alunos. Estas ocorrências são registradas por professores e armazenadas nos sistemas de banco de dados; Desempenho escolar por ano (notas por ano) – As notas a respeito das diversas disciplinas lecionadas na escola são armazenadas nos sistemas transacionais. Deseja-se acompanhar o desempenho da escola em geral por meio das notas dos alunos nestas diversas disciplinas; e Desempenho do aluno na disciplina por professor – As notas a respeito das diversas disciplinas lecionadas na escola são armazenadas 74 nos sistemas transacionais. Deseja-se acompanhar o desempenho dos alunos na disciplina de determinado professor. Com base nestes requisitos e com o que há disponível no sistema transacional e que foi levantado juntamente com os analistas de sistemas OLTP, foi apresentado um modelo dimensional de alto nível, ou seja, com a definição macro geral que o Data Mart Escolar deverá ter. Com base no exposto, o modelo dimensional que atenda os requisitos levantados acima deverá seguir, de forma geral o formato apresentado na figura 12: Figura 12– Modelo mostrando o modelo dimensional macro baseado em informações coletadas. 6.3. Modelagem Dimensional A partir da definição dos requisitos, tem-se base para o começo da construção do modelo dimensional. Esse modelo utiliza duas tabelas de fatos e sete tabelas dimensionais, devido a três necessidades distintas detalhadas a seguir: Registrar a quantidade de ocorrências por professor, o qual este cálculo armazenará a quantidade de ocorrências em determinada disciplina de um 75 determinado aluno por professor. O objetivo deste cálculo é atender o primeiro requisito solicitado ao sistema; Armazenar a média de notas dos alunos para a análise do desempenho por professor e o desempenho da escola em geral. Com base neste cálculo será possível responder questões de desempenho; e Analisar se o comparecimento de pais ou responsáveis influencia no desempenho geral dos alunos. Figura 13 – Modelo de dados dimensional utilizado para no Data Mart Escolar. 6.4. Projeto físico do banco de dados Foi criado um repositório chamado DM_ESCOLAR para armazenar as tabelas dimensionais e fato relacionadas a solução. Abaixo segue descrição física das tabelas dimensionais com a indicação da função de cada campo dentro da solução: TB_DIM_FUNCIONARIO ID_FUNCIONARIO Armazena o ID DW para a dimensão funcionário; 76 MATRICULA_FUNCIONARIO Armazena a matrícula do funcionário; NOME_FUNCIONARIO Armazena o nome do funcionário; DTH_NASCIMENTO Armazena a data de nascimento do funcionário; CARG_FUNCIONARIO Armazena o cargo do funcionário; DTH_ADMISSAO Armazena a data de admissão do funcionário; ESTADO_CIVIL Armazena o estado civil do funcionário; SEXO_FUNCIONARIO Armazena o sexo do funcionário; DTH_INICIO Data de entrada da dimensão no DW; DTH_FIM Data de mudança da dimensão no DW; e FL_CORRENTE Flag que indica se a dimensão é atual. TB_DIM_ALUNO ID_ALUNO Armazena o ID DW para a dimensão aluno; MATR_ALUNO Armazena a matrícula do aluno; NOME_ALUNO Armazena o nome do aluno; DTH_NASCIMENTO Armazena a data de nascimento do aluno; SEXO_ALUNO Armazena o sexo do aluno; DTH_INICIO Data de entrada da dimensão no DW; DTH_FIM Data de mudança da dimensão no DW; e FL_CORRENTE Flag que indica se a dimensão é atual. TB_DIM_OCORRENCIA 77 ID_OCORRENCIA Armazena o ID DW para a dimensão ocorrência; COD_CATEGORIA Armazena o código de categoria de ocorrência; DTH_INICIO Data de entrada da dimensão no DW; DTH_FIM Data de mudança da dimensão no DW; e FL_CORRENTE Flag que indica se a dimensão é atual. TB_DIM_DISCIPLINA ID_DISCIPLINA Armazena o ID DW para a dimensão disciplina; COD_ID_DISCIPLINA Armazena o ID OLTP para disciplina; COD_DISCIPLINA Armazena o código da disciplina; NOME_DISCIPLINA Armazena o nome da disciplina; DTH_INICIO Data de entrada da dimensão no DW; DTH_FIM Data de mudança da dimensão no DW; e FL_CORRENTE Flag que indica se a dimensão é atual. TB_DIM_TEMPO ID_TEMPO Armazena o ID DW para a dimensão tempo; ANO_REF Armazena o ano referente; SEMESTRE Armazena o semestre referente; BIMESTRE Armazena o bimestre referente; MES_REF Armazena o mês referente; MES_NOME Armazena o nome do mês referente; 78 DIA_ANO Armazena o dia do ano; DIA_MES Armazena o dia do mês; DIA_SEMANA Armazena o dia da semana; e DTH_REF Armazena a data. TB_FATO_ESCOLAR ID_FUNCIONARIO Armazena o ID DW do funcionário; ID_ALUNO Armazena o ID DW do aluno; ID_OCORRENCIA Armazena o ID DW de ocorrência; ID_DISCIPLINA Armazena o ID DW da disciplina; ID_TEMPO Armazena o ID DW do tempo; QTD_OCORRENCIA Armazena a quantidade das ocorrências; MDA_NOTA Armazena a média da nota do aluno; e QTD_FALTAS Armazena a quantidade de faltas do aluno. 6.5. Projeto de extração, transformação e carga De acordo com o modelo dimensional, pode-se fazer um projeto dos planos de carga para que os dados dos sistemas transacionais se adéqüem perfeitamente na estrutura do modelo dimensional. Na figura seguinte são mostradas as principais tabelas do sistema OLTP que serão utilizadas como fonte para o sistema DW. 79 Figura 14 – Modelo Físico do Sistema OLTP com as principais tabelas a serem utilizadas no DW.. A princípio não houve grande esforço para a carga das dimensões, pois elas já estavam bem encaixadas nas tabelas do modelo relacional. O plano de carga para as dimensões foi feito da seguinte forma: TB_DIM_FUNCIONARIO ID_FUNCIONARIO Chave primária gerado pelo script PL/SQL; MATRICULA_FUNCIONARIO Retirado do campo co_funcionario da tabela S_FUNCIONARIO. Este campo será utilizado como chave para avaliação de novos registros nesta dimensão; NOME_FUNCIONARIO Retirado do campo ds_funcionario da tabela S_FUNCIONARIO; DTH_NASCIMENTO Retirado do campo dt_nascimento da tabela S_FUNCIONARIO; ESTADO_CIVIL Retirado do campo tp_estado_civil da tabela S_FUNCIONARIO; SEXO_FUNCIONARIO Retirado do campo 80 tp_sexo da tabela S_FUNCIONARIO; DATA_INICIO Campo calculado gerado por PL/SQL indicando a data de entrada do registro de dimensão; DATA_FIM Campo calculado gerado por PL/SQL indicando a data de fim de vigência do registro de dimensão; e FL_CORRENTE Campo calculado gerado por PL/SQL indicando se o registro de dimensão é atual ou não. TB_DIM_ALUNO ID_ALUNO Chave primária gerada pelo script PL/SQL; MATRICULA_ALUNO Retirado do campo co_aluno da tabela S_ALUNO. Este campo será utilizado como chave para avaliação de novos registros nesta dimensão; NOME_ALUNO Retirado do campo ds_aluno da tabela S_ALUNO; DTH_NASCIMENTO Retirado do campo dt_nascimento da tabela S_ALUNO; SEXO_ALUNO Retirado do campo tp_sexo da tabela S_ALUNO; DATA_INICIO Campo calculado gerado por PL/SQL indicando a data de entrada do registro de dimensão; DATA_FIM Campo calculado gerado por PL/SQL indicando a data de fim de vigência do registro de dimensão; e 81 FL_CORRENTE Campo calculado gerado por PL/SQL indicando se o registro de dimensão é atual ou não. TB_DIM_OCORRENCIA ID_OCORRENCIA Chave primária gerado pelo script PL/SQL; CODIGO_OCORRENCIA Retirado do campo id_categoria da tabela S_CATEGORIA. Este campo será utilizado como chave para avaliação de novos registros nesta dimensão; DESCRICAO_OCORRENCIA Retirado do nome_categoria da tabela S_CATEGORIA; DATA_INICIO Campo calculado gerado por PL/SQL indicando a data de entrada do registro de dimensão; DATA_FIM Campo calculado gerado por PL/SQL indicando a data de fim de vigência do registro de dimensão; FL_CORRENTE Campo calculado gerado por PL/SQL indicando se o registro de dimensão é atual ou não. TB_DIM_DISCIPLINA ID_DISCIPLINA Chave primária gerado pelo script PL/SQL; CODIGO_DISCIPLINA Retirado do campo co_disciplina da tabela S_DISCIPLINA. Este campo será utilizado como chave para avaliação de novos registros nesta dimensão; NOME_DISCIPLINA Retirado do campo 82 ds_disciplina da tabela S_DISCIPLINA; DATA_INICIO Campo calculado gerado por PL/SQL indicando a data de entrada do registro de dimensão; DATA_FIM Campo calculado gerado por PL/SQL indicando a data de fim de vigência do registro de dimensão; e FL_CORRENTE Campo calculado gerado por PL/SQL indicando se o registro de dimensão é atual ou não. TB_DIM_TEMPO ID_TEMPO Chave primária gerado pelo script PL/SQL; ANO Campo gerado por script PL/SQL; SEMESTRE Campo gerado por script PL/SQL; BIMESTRE Campo gerado por script PL/SQL; MES Campo gerado por script PL/SQL; MES_NOME Campo gerado por script PL/SQL; DIA_ANO Campo gerado por script PL/SQL; DIA_MES Campo gerado por script PL/SQL; DIA_SEMANA Campo gerado por script PL/SQL; e DATA Campo gerado por script PL/SQL. TB_FATO_ESCOLAR ID_FUNCIONARIO Chave estrangeira que 83 referencia a tabela TB_DIM_FUNCIONARIO; ID_ALUNO Chave estrangeira que referencia a tabela TB_DIM_ALUNO; ID_OCORRENCIA Chave estrangeira que referencia a tabela TB_DIM_OCORRENCIA; ID_DISCIPLINA Chave estrangeira que referencia a tabela TB_DIM_DISCIPLINA; ID_TEMPO Chave estrangeira que referencia a tabela TB_DIM_TEMPO; QTD_OCORRENCIA Campo calculado com base na quantidade de ocorrências cometidas por alunos em determinada disciplina. Campo da tabela S_OCORRENCIA; e MDA_NOTA Retirado do campo nota da tabela NOTA. Para tupla da tabela, deve existir o campo nota com a média do aluno naquela disciplina. Campo da tabela S_ALUNO_DISCIPLINA. 6.6. Desenvolvimento de aplicações Uma vez realizada a carga do Data Mart, será utilizada a ferramenta Oracle Discoverer como ferramenta Front-End para consulta de dados que podem ser acessados via intranet, por meio de um browser Com base nas necessidades levantadas anteriormente pode efetuar várias pesquisas tais como: Nível de ocorrências por professor; Desempenho escolar por ano (notas por ano); Desempenho do aluno na disciplina por professor; e Desempenho escolar do aluno x Assiduidade dos Responsáveis. 84 7. Conclusão Um Data Warehouse é um grande centro de informações, que são constantemente incluídas, mantendo um histórico sobre todas as movimentações consideradas importantes para as companhias que constroem um Data Warehouse. É um processo demorado e de alto custo em alguns casos, desta forma, os objetivos da construção e uso de um Data Warehouse deverão ser muito bem fundamentadas, pois exigem também requisição de vários recursos de hardware, software e pessoal qualificado. No entanto é uma ferramenta cara e de difícil implantação, devido a isso, deve-se analisar bem antes da implantação. Os benefícios da construção de um Data Warehouse variam desde a campanhas para manter o estado atual dos negócios quanto para previsão de possíveis oportunidades para crescimento no mercado. Para se atingir os resultados por ele almejados é preciso saber utilizá-lo e também saber se é realmente necessário. Muitas vezes estas questões básicas são esquecidas e os pensamentos são enfocados apenas no que esta ferramenta pode nos oferecer, esquecendo muitas vezes a nossa própria realidade. Desta forma, deve-se dar a máxima importância para a etapa de coleta de requisitos em um projeto de DW, realizando todas as etapas do ciclo de desenvolvimento definido no projeto a fim de minimizar os erros de especificação e desta maneira, evitar-se o gasto desnecessário com novos levantamentos e atualização de documentação 85 Referência Bibliográfica [BAR01] BARBIERI, Carlos. BI – Business Inteligence – Modelagem & Tecnologia, Rio de Janeiro, Axcel Books, 2001. [DWBRASIL, 2003] DWBrasil – Disponível em <http://www.dwbrasil.com.br> Acessado em 13 de fevereiro de 2008 20h47. [CONGRESSO, 2008], MUSSI, Camilo. DataWarehouse – Da modelagem à implantação, – 2006 Disponível em <http://www.congreso- info.cu/UserFiles/File/Info/Intempres2006/Intempres2004/Sitio/Ponencias/8.pdf> Acesso em 05 de maio de 2008. [BIBLIOTECADIGITAL, 2008] Biblioteca – Digital Disponível em <www.sbc.org.br/bibliotecadigital/download.php?paper=262> Acesso em 05 de maio de 2008. [DATAMINIG, 2008] DataMining – EIS Disponível em <http://www.fieo.br/v2/central_aluno/revista/rev1999/DataMining_EIS.htm#Quem> Acesso em 06 de maio de 2008. [DATABASES, 2008] Databases – Disponível em <http://databases.about.com/od/specificproducts/a/normalization.htm> Acesso em 06 de maio de 2008. [DEVMEDIA, 2008] DevMedia group – asp.net, java, Delphi, SQL e Webdesign. Disponível em <http://www.devmedia.com.br/Imagens/gold/SQL/39/artigo1/image2.jpg> Acesso em 10 de maio de 08. 20h00. [DSPACE,2008] Instituto Superior Técnico – Universidade Técnica de Lisboa. Disponível <https://dspace.ist.utl.pt/bitstream/2295/54644/1/bdSchema.20060321.jpg> em: Acesso em 11 de maio de 2008. [GRA00] GRAEML, Alexandre R.. Sistemas de Informação: o alinhamento da estratégia de TI com a estratégia corporativa. São Paulo, Editora Atlas S.A., 2000. [GRA98] GRAY, Paul & Watson, Hugh J. Decision Support in the Data Warehouse. New Jersey, Prentice Hall PTR, 1998. 86 [INM99] INMON, W.H. – Gerenciando Data Warehouse. Rio de Janeiro, Makron Books, 1999. [INM05] INMON, William H. Building the Data Warehouse. Indianapolis, Indiana, Wiley Publishing, Inc., 2005. [KIM98a] KIMBALL, Ralph, ROSS, Margy. The Data Warehouse Toolkit 2th edition. Indianapolis, Indiana, Wiley Publishing, Inc. 1998. [KIM98b] KIMBALL, Ralph – The Data Warehouse Toolkit. São Paulo: Makron Books, 1998. 388p. [MAC07] MACHADO, Felipe N R. Tecnologia e Projeto de Data Warehouse: uma visão multidimensional. São Paulo, Érica, 2007. [MICROSOFT, 2008] Microsoft – Modelo multidimensional. Disponível em http://www.microsoft.com/brasil/msdn/images/tecnologias/arquitetura/Dados_Multidi mensionais/4_Whitepaper%20%20Modelagem%20de%20Bancos%20de%20Dados%20Multidimensionais_19.jpg> Acesso em 11 de maio de 2008 as 20h15 [OLI02] OLIVEIRA, José W. Data Warehouse. Visual Books, 2002. [ORACLE, 2008]ORACLE – ETL. Disponível em < - http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/ettover.htm> Acesso em 08 de maio de 2008 as 19h30. [SIL99] SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistemas de Bancos de Dados. 3. ed. Makron Books, 1999. [SPR91] SPRAGUE, H. e WATSON, J. – Sistema de apoio a decisão: colocando a teoria em prática. Ed. Campus, Rio de Janeiro, 1991. 87 Apêndice A Glossário Ad-Hoc Query ( consulta eventual ) Qualquer consulta que não possa ser determinada antes do momento da consulta ser emitida. Uma consulta que consiste em SQL construído dinamicamente, em geral por ferramentas de consulta residentes na estação de trabalho do usuário final. Agregados Resumos pré - calculados ou pré - armazenados que são mantidos no Data Warehouse para melhorar o desempenho de consulta. Atributo Um campo em uma tabela dimensional. Banco de dados Relacional Um sistema de banco de dados que suporta todos os comandos SQL padrão. Chave estrangeira (Foreign Key) Um campo de um banco de dados relacional cujos valores são obtidos de uma chave primária em outra tabela. Em um esquema star join, os componentes da chave composta de uma tabela de fatos são chaves estrangeiras respectivas a cada uma das tabelas de dimensão. Chave primária (Primary key) Um campo em um banco de dados exclusivos a cada registro da tabela. Cliente/Servidor Abordagem de tecnologia distribuída na qual o processamento é dividido por função. O componente servidor realiza funções compartilhadas - gestão de comunicações, fornecimento de serviços de base de dados etc. O componente cliente realiza funções individuais de usuário – disponibilização de interfaces adaptadas, navegação entre telas, funções de auxilio etc. 88 Consulta (Query) Uma instrução SQL SELECT passada de um aplicativo de front-end (que reside normalmente no cliente do usuário) para DBMS relacional. Data Mining Técnica que utiliza ferramentas de software geralmente orientadas para o usuário que não sabe exatamente o que está pesquisando, mas procura identificar determinados padrões ou tendências. O termo Data Mining (garimpo de Dados) identificação processo de separar grandes quantidades de dados de forma a identificar relacionamentos entre eles. Data Warehouse Uma cópia dos dados de transações, estruturada especificamente para consultas e análises. Drill Modo de exploração de dados detalhados que foram usados na criação de um nível sumarizado de dados. Os níveis de aprofundamento dependem de granularidade dos dados existentes no Data Warehouse. DSS (Decision Support System ou Sistema de Apoio a Decisão) Software que fornece ao usuário informações para a tomada de decisões. Executive Information System - (EIS) Sistema de Informações Executivas Ferramentas programadas para disponibilizar relatórios previamente preparados ou resumos impressos para executivos de alto nível. Elas oferecem poderosas capacidades de construção de relatórios e de detalhamento de informações. Atualmente estas ferramentas possibilitam a submissão de consultas especificas a base de dados multi-dimensionais e a maioria delas oferece aplicações analíticas especificas, como analise de vendas ou financeira. Ferramentas de front-end 89 É uma ferramenta-cliente que recupera ou manipula dados armazenados em um banco de dados relacional. Filtros Conjunto de critérios previamente escolhidos que especificam um subconjunto de informações em um Data Warehouse. Grão Significa um único registro em uma tabela de fatos. A definição da granularidade em uma tabela de fatos é a Segunda das quatro etapas principais envolvidas no projeto de um esquema star join. Metadados Qualquer dado mantido para suportar as operações ou uso de um Data Warehouse. Praticamente todas as ferramentas de Front-End exigem algum metadado próprio na forma de especificações ou status. O metadado é freqüentemente externo ao banco de dados relacional. Não existem padrões coerentes para o metadado. Modelo Dimensional Metodologia de projeto que lista dimensões e fatos relevantes a cada processo de negócio. Modelo Entidade/Relacionamento Modelo para os dados de uma organização que tem como objetivo remover todos os valores repetidos por meio de criação de tabelas adicionais. Normalizar Processo usado para eliminar a redundância de dados separando-os em várias tabelas. OLAP Processamento analítico On-Line. Um termo que contrasta com OLTP. Um conjunto de princípios com definição imprecisa que fornece uma estrutura para suporte a decisão. O termo OLAP também é utilizado para referir-se ao grupo de fornecedores 90 que oferecem produtos proprietários, não relacionais, destinados ao suporte à decisão. OLTP Processamento de transações On-Line. A descrição original de todas as atividades e sistemas associados à inserção de dados de forma confiável em um banco de dados. Embora utilizado freqüentemente com referência a banco de dados, OLTP pode ser usado genericamente para descrever um ambiente de processamento de transações. Repositório Banco de dados de um Data Warehouse. Slice and Dice (Fatiar) A descrição padrão da habilidade de acessar um Data Warehouse por meio de qualquer de suas dimensões de forma igual. Suporte à Decisão Utilização de dados na tomada de decisão em uma organização. Tabela de dimensão Uma tabela em um esquema star join com uma única chave primária. Tabela de Fatos A tabela central de um esquema star join, caracterizada por uma chave composta, em que cada elemento é uma chave externa de uma tabela de dimensão. Transação Um unidade indivisível de trabalho. Um sistema de processamento de transações pode executar somente a transação completa, e não apenas parte dela. 91 Apêndice B SCRIPT DE GERAÇÃO DO BANCO DE DADOS CREATE TABLE tb_dim_aluno (id_aluno NUMBER(8,0) NOT NULL, matricula_aluno VARCHAR2(10), nome_aluno VARCHAR2(200), data_nascimento_aluno DATE, sexo_aluno CHAR(1), data_inicio DATE, data_fim DATE, fl_corrente CHAR(1)) PARALLEL (DEGREE DEFAULT) / GRANT SELECT ON tb_dim_aluno To eul_escolar / GRANT REFERENCES ON tb_dim_aluno To eul_escolar / GRANT SELECT ON tb_dim_aluno TO eul_escolar / GRANT REFERENCES ON tb_dim_aluno TO eul_escolar / ALTER TABLE tb_dim_aluno ADD CONSTRAINT pk_dim_aluno PRIMARY KEY (id_aluno) USING INDEX / CREATE TABLE tb_dim_disciplina (id_disciplina NUMBER(8,0) NOT NULL, codigo_disciplina VARCHAR2(10), nome_disciplina VARCHAR2(50), data_inicio DATE, data_fim DATE, fl_corrente CHAR(1)) PARALLEL (DEGREE DEFAULT) / GRANT SELECT ON tb_dim_disciplina To eul_escolar / GRANT REFERENCES ON tb_dim_disciplina To eul_escolar / GRANT SELECT ON tb_dim_disciplina TO eul_escolar / GRANT REFERENCES ON tb_dim_disciplina TO eul_escolar / ALTER TABLE tb_dim_disciplina ADD CONSTRAINT pk_dim_disciplina PRIMARY KEY (id_disciplina) 92 USING INDEX / CREATE TABLE tb_dim_funcionario (id_funcionario NUMBER(8,0) NOT NULL, matricula_funcionario NUMBER(10,0), nome_funcionario VARCHAR2(200), dth_nascimento DATE, cargo_funcionario VARCHAR2(50), dth_admissao_funcionario DATE, estado_civil_funcionario VARCHAR2(15), sexo_funcionario CHAR(1), data_inicio DATE, data_fim DATE, fl_corrente CHAR(1)) PARALLEL (DEGREE DEFAULT) / GRANT SELECT ON tb_dim_funcionario To eul_escolar / GRANT REFERENCES ON tb_dim_funcionario To eul_escolar / GRANT SELECT ON tb_dim_funcionario TO eul_escolar / GRANT REFERENCES ON tb_dim_funcionario TO eul_escolar / ALTER TABLE tb_dim_funcionario ADD CONSTRAINT pk_dim_funcionario PRIMARY KEY (id_funcionario) USING INDEX / CREATE TABLE tb_dim_ocorrencia (id_ocorrencia NUMBER(8,0) NOT NULL, codigo_ocorrencia NUMBER(4,0), descricao_ocorrencia VARCHAR2(20), data_inicio DATE, data_fim DATE, fl_corrente CHAR(1)) PARALLEL (DEGREE DEFAULT) / ALTER TABLE tb_dim_ocorrencia ADD CONSTRAINT pk_dim_ocorrencia PRIMARY KEY (id_ocorrencia) USING INDEX / CREATE TABLE tb_dim_tempo (data DATE NOT NULL, data_chave DATE, mes VARCHAR2(15), ano NUMBER(4,0), 93 trimestre VARCHAR2(25), semestre VARCHAR2(25), diasemana VARCHAR2(15), semanadomes VARCHAR2(10), atual CHAR(1), mes_chave NUMBER(2,0), diasemana_chave NUMBER(2,0), descricao_mes VARCHAR2(15), bimestre VARCHAR2(25)) PARALLEL (DEGREE DEFAULT) / GRANT SELECT ON tb_dim_tempo To eul_escolar / GRANT REFERENCES ON tb_dim_tempo To eul_escolar / GRANT SELECT ON tb_dim_tempo TO eul_escolar / GRANT REFERENCES ON tb_dim_tempo TO eul_escolar / ALTER TABLE tb_dim_tempo ADD CONSTRAINT pk_tempovenda PRIMARY KEY (data) USING INDEX / CREATE TABLE tb_fato_aluno (id_aluno NUMBER(8,0), id_funcionario NUMBER(8,0), id_disciplina NUMBER(8,0), id_ocorrencia NUMBER(8,0), id_tempo DATE, nota NUMBER(4,2), falta NUMBER(3,0) qtd_ocorrencia NUMBER(3,0)) PARALLEL (DEGREE DEFAULT) / GRANT SELECT ON tb_fato_aluno To eul_escolar / GRANT REFERENCES ON tb_fato_aluno To eul_escolar / GRANT SELECT ON tb_fato_aluno TO eul_escolar / GRANT REFERENCES ON tb_fato_aluno TO eul_escolar / ALTER TABLE tb_fato_aluno ADD CONSTRAINT fk_dim_aluno FOREIGN KEY (id_aluno) REFERENCES tb_dim_aluno (id_aluno) ON DELETE CASCADE / ALTER TABLE tb_fato_aluno ADD CONSTRAINT fk_dim_disciplina FOREIGN KEY (id_disciplina) REFERENCES tb_dim_disciplina (id_disciplina) ON DELETE CASCADE 94 / ALTER TABLE tb_fato_aluno ADD CONSTRAINT fk_dim_funcionario FOREIGN KEY (id_funcionario) REFERENCES tb_dim_funcionario (id_funcionario) ON DELETE CASCADE / ALTER TABLE tb_fato_aluno ADD CONSTRAINT fk_dim_ocorrencia FOREIGN KEY (id_ocorrencia) REFERENCES tb_dim_ocorrencia (id_ocorrencia) ON DELETE CASCADE / ALTER TABLE tb_fato_aluno ADD CONSTRAINT fk_dim_tempo FOREIGN KEY (id_tempo) REFERENCES tb_dim_tempo (data) ON DELETE CASCADE / 95 Apêndice C TELAS DO PROTÓTIPO Figura 15 – Tela do aplicativo SQLPLUS mostrando todas as tabelas DW do esquema “dw_escolar”. Tabelas com prefixo diferente de “TB_” pertencem aos aplicativos core do Oracle Warehouse Builder. 96 Figura 16 – Tela da ferramenta de ETL Oracle Warehouse Builder, mostrando a perspectiva DW e a perspectiva OLTP. Figura 17 – Tela da ferramenta de ETL Oracle Warehouse Builder, mostrando os processos de ETL com prefixo “MAP_”. 97 Figura 18 – Tela da ferramenta de front-end Oracle Discoverer Administrator, mostrando a Business Area Criada para o projeto escolar. Figura 19 – Business Area para a Escola. Tela do Discoverer Administrator mostrando as tabelas do DW. 98 Figura 20 – Business Area para a Escola. Tela do Discoverer Administrator mostrando o detalhamento das tabelas. Perspectiva pronta para a criação de consultas ad hoc. 99
