X-META UMA METODOLOGIA DE DESENVOLVIMENTO DE DATA WAREHOUSE COM GERENCIAMENTO DE METADADOS. Liane Carneiro Barbosa Lima

Transcrição

1 X-META UMA METODOLOGIA DE DESENVOLVIMENTO DE DATA WAREHOUSE COM GERENCIAMENTO DE METADADOS Liane Carneiro Barbosa Lima Dissertação submetida ao corpo docente do Curso de Mestrado em Informática Aplicada da Universidade de Fortaleza como parte dos requisitos necessários para a obtenção do título de mestre em Ciência da Computação. Orientador: Prof. Dr.-Ing.Ângelo Roncalli Alencar Brayner Aprovada por: Prof. Ângelo Roncalli Alencar Brayner, Dr.-Ing. (Presidente da Banca) Prof a. Vânia Maria Ponte Vidal, D. Sc. Prof. Nabor das Chagas Mendonça, Ph. D. Maio de 2002

2 LIMA, LIANE CARNEIRO BARBOSA X-Meta: Uma Metodologia de Desenvolvimento de Data Warehouse com Gerenciamento de Metadados [Fortaleza] 2002 xi, 168 p., 29,7 cm (MIA/UNIFOR, M. Sc., Ciência da Computação, 2002) Tese Universidade de Fortaleza, MIA 1. Data Warehouse 2. Metodologia de Desenvolvimento 3. Metadados I. MIA/UNIFOR II. TÍTULO (série) ii

3 Para Thais e Raquel A Deus, que me deu o privilégio sagrado da vida... iii

4 AGRADECIMENTOS Ao Fernando, simplesmente por existir em minha vida e fazê-la tão completa, com seu amor, companheirismo, carinho e, principalmente, pelos estímulos constantes desde o início deste trabalho. Às minhas filhas Thaís e Raquel, por compreenderem os constantes momentos de ausência que as fiz passar. À minha mãe, pelo exemplo de vida. Ao Prof. Ângelo Brayner, meu orientador e amigo, que teve paciência e capacidade de me conduzir neste processo de investigação científica. Sua dedicação e apoio foram decisivos. À Prof a. Vânia Vidal e ao Prof. Nabor Mendonça pela participação em minha Banca Examinadora. Aos colegas da SEFIN, em especial à Equipe de Tributos do DCPD, que souberam, com humildade, colaborar para a conclusão deste trabalho. A todas as minhas amigas e amigos, pela amizade demonstrada, mesmo com o meu total abandono. À Leninha, pelo seu apoio e dedicação nas tarefas caseiras. À FUNCAP por haver me concedido uma bolsa neste segundo ano de mestrado. A todos aqueles que contribuíram de alguma forma para que este momento se concretizasse. iv

5 Resumo da Tese apresentada ao MIA/UNIFOR como parte dos requisitos necessários para a obtenção do título de mestre em Ciência da Computação (M.Sc.) X-META UMA METODOLOGIA DE DESENVOLVIMENTO DE DATA WAREHOUSE COM GERENCIAMENTO DE METADADOS Liane Carneiro Barbosa Lima Maio / 2002 Orientador: Dr.-Ing. Ângelo Roncalli Alencar Brayner Programa: Ciência da Computação Data Warehousing é um recurso poderoso utilizado pelas organizações para suporte ao processo de tomada de decisão. Esta tecnologia incorpora um repositório de dados analítico - Data Warehouse (DW) e tecnologias modernas, que processam e transformam dados em informações confiáveis e facilmente acessíveis. No entanto, desenvolver um DW é um processo complexo e uma atividade cara em desenvolvimento e gerenciamento de sistemas de informações, que requer estratégias adaptadas às características e necessidades da organização onde será implantado. Este trabalho apresenta uma metodologia de desenvolvimento de DW X-Meta. Esta metodologia é direcionada a organizações sem tradição no uso de sistemas automatizados de apoio à decisão e pode ser utilizada pelo pessoal interno da organização, inexperiente na tecnologia de DW, mas capacitado tecnicamente em desenvolvimento de sistemas convencionais e tecnologia de banco de dados. Além disso, uma estratégia para criação e gerenciamento de metadados integrado ao processo de desenvolvimento é proposta, para capturar o conhecimento organizacional e minimizar os problemas causados pela rotatividade dos funcionários, dentro e entre organizações. O presente trabalho também apresenta a aplicação da metodologia X-Meta em um caso real. v

6 Abstract of Thesis presented to MIA/UNIFOR as a partial fulfillment of the requirements for the degree of Master of Science (M.Sc.) X-META A METHODOLOGY FOR DATA WAREHOUSE DESIGN WITH METADATA MANAGEMENT Liane Carneiro Barbosa Lima Maio / 2002 Advisor: Dr.-Ing. Ângelo Roncalli Alencar Brayner Department: Computing Science Date Warehousing is a powerful resource for supporting decision-making processes in organizations. It incorporates a Data Warehouse (DW) and modern technologies that process and transform data in accurate and easily accessible information. However, developing DW is a complex process and a costly activity in information system development and management. It requires strategies, which should be specific to the characteristics and needs of the organization where it will be introduced. This dissertation presents a DW development methodology X-Meta. It is addressed to organizations with no tradition in the use of automated decision support systems and can be implanted by the internal employees, without expertise in DW technology but qualified in development of conventional systems and database technology. Moreover, a strategy for creating and managing metadata in an integrated way to the DW development process is proposed. The goal is to capture the organizational knowledge and minimize the problems caused by the mobility of employees within and among organizations. Furthermore, this work describes the application of the X-Meta methodology in a real case study. vi

7 SUMÁRIO 1 INTRODUÇÃO MOTIVAÇÃO E OBJETIVOS O PROBLEMA ORGANIZAÇÃO DA DISSERTAÇÃO DW: CONCEITOS, ARQUITETURAS E METADADOS INTRODUÇÃO SISTEMAS DE APOIO À DECISÃO DATA WAREHOUSE DATA MART TOPOLOGIAS DE DW MODELAGEM DIMENSIONAL APLICAÇÕES OLAP ARQUITETURAS DE DW Arquitetura Genérica Arquitetura de Dados Arquitetura de Acesso aos Dados Arquitetura Funcional METADADOS Conceituação O Papel dos Metadados no Ambiente de DW Repositório e Ferramentas REVISÃO BIBLIOGRÁFICA INTRODUÇÃO METODOLOGIAS DE DESENVOLVIMENTO A Proposta de GARDNER [GAR98] A Proposta de POE et al. [POE98] A Proposta de KIMBALL et al. [KIM98a] A Proposta de PEREIRA [PER00] Análise Comparativa das Metodologias Pesquisadas...66 vii

8 3.3 GERENCIAMENTO DE METADADOS A Abordagem de GARDNER [GAR98] A Abordagem de POE et al. [POE98] A Abordagem de KIMBALL et al. [KIM98a] Abordagem de INMON et al. [INM97, INM98, INM99] Considerações sobre Gerenciamento de Metadados CONCLUSÃO X-META: UMA METODOLOGIA DE DESENVOLVIMENTO DE DW INTRODUÇÃO A METODOLOGIA X-META FASE INTRODUÇÃO Subfase Planejamento inicial Subfase Desenvolvimento 1 0 protótipo Módulo Modelagem dimensional Módulo Projeto BD Módulo Extração e transformação Módulo População Módulo Disponibilização Subfase Decisão FASE DESENVOLVIMENTO Subfase Planejamento Subfase Identificação de requisitos e informações Subfase Ciclo de construção de DM/DW Módulo Arquitetura de dados Módulo Arquitetura funcional Módulo Infra-estrutura Módulo Teste de produtos Módulo Modelagem de metadados Módulo Infra-estrutura de metadados Módulo Modelagem dimensional Módulo Projeto BD Módulo Extração e transformação Módulo População Módulo Especificação de aplicações usuário final Módulo Desenvolvimento de aplicações usuário final Módulo Disponibilização viii

9 4.5 FASE PRODUÇÃO Subfase Suporte Subfase Crescimento FASE GERENCIAMENTO DE METADADOS FASE GERENCIAMENTO DO PROJETO ESTUDO DE CASO INTRODUÇÃO DESCRIÇÃO DO AMBIENTE PROJETO: INTRODUÇÃO DA TECNOLOGIA DW NA SEFIN Planejamento Inicial Desenvolvimento 1 0 Protótipo Decisão ANÁLISE DA METODOLOGIA X-META CONCLUSÃO CONSIDERAÇÕES FINAIS E CONTRIBUIÇÕES TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS ANEXO A ANEXO B ANEXO C ANEXO D ix

10 LISTA DE FIGURAS Figura 1 Arquitetura resumida de um ambiente Data Warehouse...11 Figura 2 Topologias de DW...14 Figura 3 Cubo de dados...15 Figura 4 Estrutura relacional versus estrutura dimensional...16 Figura 5 Esquema estrela...17 Figura 6 Esquema floco de neve...18 Figura 7 Formas de armazenamento de dados em DM/DW...19 Figura 8 Arquitetura genérica proposta por [SIN01]...23 Figura 9 Arquiteturas de dados propostas por [GRA98]...25 Figura 10 Arquiteturas de acesso aos dados propostas por [KIM98a]...26 Figura 11 Arquitetura funcional proposta por [CHA97]...28 Figura 12 Metodologia de [GAR98]...41 Figura 13 Metodologia de [POE98]...44 Figura 14 Metodologia de [KIM98a]...52 Figura 15 Metodologia de [PER00]...60 Figura 16 Fase protótipo da metodologia de [PER00]...62 Figura 17 Ciclo de teste e experimentação [PER00]...66 Figura 18 Fluxo de metadados [KIM98a]...85 Figura 19 Ambiente projetado [INM99]...87 Figura 20 Metodologia X-Meta...95 Figura 22 Sistemática de desenvolvimento do 1 0 protótipo de DW Figura 23 Subfase Ciclo de construção de DM/DW Figura 24 Casos de uso da área tributária Figura 25 Modelo de dados da rotina IP RINAE Figura 26 Estrutura operacional da arrecadação do IPTU Figura 27 Modelo conceitual do metamodelo Figura 28 Modelagem dimensional do protótipo Figura 29 Metadados técnicos do protótipo Figura 30 Arquitetura funcional do protótipo x

11 LISTA DE TABELAS Tabela 1 Resumo das principais características de um DW...10 Tabela 2 Resumo das diferenças entre OLTP e OLAP...21 Tabela 3 Comparativo entre configurações de arquitetura de dados...25 Tabela 4 Ferramentas para metadados...39 Tabela 5 Comparativo das metodologias de desenvolvimento de DM/DW investigadas 71 Tabela 6 Tipos de usuários e necessidades de metadados [POE98]...81 Tabela 7 Descrição do fluxo de metadados [KIM98a]...86 Tabela 8 Comparativo das abordagens sobre gerenciamento de metadados...91 Tabela 9 Metadados de negócio do protótipo Tabela 10 Comparativo das metodologias investigadas e proposta xi

12 1 INTRODUÇÃO 1.1 Motivação e Objetivos Historicamente, as organizações modernas vêm armazenando dados em algum tipo de sistema computacional. Esses dados são capturados nas transações diárias do negócio e garantem o funcionamento operacional da empresa. Todas as organizações precisam de dados, principalmente porque eles são a matéria-prima essencial para a criação da informação [DAV98]. No entanto, a habilidade de resumir e analisar tais dados, com o objetivo de extrair informação, ainda é um desafio. Para atender essa necessidade, os Sistemas de Apoio a Decisão (SAD) vêm se destacando, por permitir em organizações uma forma de integrar e consolidar seus dados, provendo informações que permitam analisar situações e tomar decisões rápidas, oportunas e com maior qualidade. Atualmente, Data Warehousing, tecnologia que incorpora um repositório de dados analítico - Data Warehouse (DW) usado como base para os SAD, além de dar agilidade e qualificar os processos decisórios de empresas e corporações, tanto do setor público como privado, amplia o conteúdo informacional das organizações, de modo a permitir detectar tendências, prever mudanças e analisar desempenho. Neste início do século XXI, já chamado de Era do conhecimento, o conhecimento dos sistemas, negócios, competidores, clientes e mercado determinará o sucesso ou fracasso do negócio [MAR00]. Para tomar decisões, além das informações armazenadas no DW, a maioria dos usuários precisará do conhecimento que, nas organizações, costuma estar embutido não só em documentos e repositórios, mas também em rotinas, processos, práticas e normas organizacionais [DAV98]. 1

13 Algumas organizações, principalmente empresas públicas, enquadram-se no seguinte cenário: (1) não existe tradição no uso de sistemas informatizados de apoio à decisão, mas os decisores já sentem necessidade desta tecnologia; (2) há infra-estrutura computacional mínima necessária para a construção de um DW, mas não dispõem de recursos humanos experientes no processo de desenvolvimento de DW; e (3) os decisores normalmente possuem pouca experiência no negócio, em razão de constante rotatividade nos cargos de nível gerencial e estratégico. Além dessas particularidades, observou-se que o processo de construção de um DW é altamente complexo, pois envolve enorme variedade de tecnologias, tanto de software quanto de hardware, tornando-se uma atividade cara em desenvolvimento e gerenciamento de sistema de informação. Outro fator relevante observado é que não existe uma metodologia de desenvolvimento de DW que possa ser aplicada indiscriminadamente a qualquer organização. Cada ambiente corporativo, mesmo aqueles do mesmo nicho de negócio, possuem particularidades e características específicas [SEN98] [GAR98]. Com base neste contexto, o objetivo principal desta dissertação é definir uma metodologia de desenvolvimento de DW, que permita introduzir Data Warehousing em organizações sem tradição no uso de sistemas de apoio à decisão, utilizando a infraestrutura técnica e os recursos humanos internos da organização, qualificados tecnicamente em desenvolvimento de sistemas em geral e tecnologia de banco de dados. Adicionalmente, a criação e o gerenciamento dos metadados serão questões centrais da metodologia proposta, para capturar o conhecimento utilizado nos processos organizacionais; dessa forma, minimizar os problemas que o afastamento de um especialista pode causar em uma organização. Outro objetivo importante é a aplicação da metodologia proposta na construção do primeiro DW da Prefeitura Municipal de Fortaleza (PMF), no âmbito da Secretaria de Finanças (SEFIN). Mais especificamente, destaca-se a área de Tributos, destinada a gerir o lançamento, arrecadação e cobrança dos tributos municipais da PMF. Na área pública, embora não se apliquem os critérios de competitividade, observa-se a necessidade de utilizar sistemas de informações que auxiliem na formulação de políticas públicas eficientes e na avaliação sistemática dos resultados. 2

14 Ao lado das vantagens advindas da possibilidade de tomada de decisões no momento apropriado, espera-se que o processo de desenvolvimento de DW, apoiado por um efetivo gerenciamento de metadados, possa ser usado para direcionar a formação do capital intelectual das instituições. 1.2 O Problema Tradicionalmente, investimentos têm sido feitos nas organizações, tanto no plano corporativo quanto de desktop, para gerar informações gerenciais para o auxílio na tomada de decisões. São as chamadas soluções tradicionais de SAD, utilizadas, principalmente, para administrar o imenso volume de dados produzidos pelos sistemas legados de muitas organizações. A maioria das organizações ainda utiliza programas de extração, que varrem um arquivo ou banco de dados, usam alguns critérios de seleção e, ao encontrar dados que atendam aos critérios, transportam esses dados para outro arquivo ou banco de dados e os disponibilizam através de consultas ou relatórios. Essa solução foi constatada como inadequada, em virtude da falta de integração e de dados históricos, e por depender da execução de rotinas de programação específicas sempre que uma consulta ou análise nova se faz necessária [INM97]. Além destas, outras deficiências em soluções tradicionais de SAD podem ser observadas: os dados não são entendidos pelos usuários, estes discordam das definições dos dados, os dados são sujos, os relatórios são inconsistentes, existe pouca produtividade, entre outras. A disseminação dos computadores e da informática em geral, que permitiu aos usuários ficarem tecnologicamente instruídos, não foram suficientes para assentir que os usuários decisores pudessem penetrar no labirinto de dados existentes nas organizações, quanto mais extrair informações consistentes deles. Principalmente no nível gerencial e estratégico, acumular dados não representa necessariamente possuir informações. Até mesmo possuir informação, muitas vezes, não é suficiente para atender às necessidades dos usuários decisores. O contexto da informação é tão importante quanto o conteúdo, para ser possível compreender e interpretar a informação. Além disso, existe a necessidade de que as informações possam ser buscadas, da maneira mais lógica e intuitiva, com qualidade e precisão. 3

15 Tais motivos, nos últimos anos, respondem pelo grande destaque que vem ganhando Data Warehousing, por oferecer às organizações uma maneira flexível e eficiente de obter informações, necessárias aos processos decisórios. A opção por essa tecnologia, entretanto, é um desafio, pois construir um DW é um processo complexo que envolve enorme variedade de tecnologias, tanto de software quanto de hardware. Muitos autores, baseados na complexidade desta tecnologia, defendem a idéia de que a construção de um DW seja realizada por equipe de profissionais experientes no assunto. Em conseqüência, há poucas metodologias de desenvolvimento de DW voltadas especificamente para equipes de desenvolvimento inexperientes em DW. Além disso, principalmente nas entidades públicas, existe a dificuldade na contratação de equipes externas (consultoria, firmas de desenvolvimento especializadas), em razão de fatores como legislação, recursos financeiros, sigilo das informações, prazos, etc. Um exemplo do cenário discutido no parágrafo anterior é a Secretaria de Finanças, órgão da administração direta da Prefeitura Municipal de Fortaleza. A SEFIN possui profissionais altamente qualificados e detentores de conhecimentos teóricos e práticos sobre desenvolvimento de sistemas e tecnologia de banco de dados. Alguns desses profissionais têm, inclusive, conhecimentos teóricos sobre DW, não havendo, contudo, experiência prática para a sua construção. Outra maneira utilizada para tomar decisões, habitual em muitas organizações, é fazer uso da intuição e da experiência dos dirigentes, acumuladas por vários anos de trabalho na empresa. No entanto, utilizar essa opção tem sido cada vez mais difícil, principalmente em organizações públicas, como é o caso da SEFIN, em virtude das constantes mudanças nas chefias, no mínimo a cada quatro anos, e na escolha política dos dirigentes, o que ocorre na maioria das vezes. Alguns administradores normalmente não têm o mínimo conhecimento sobre o negócio. A intuição e a experiência, nesses casos, nem conseguem ser utilizadas para tomar uma decisão. Principalmente em decorrência da necessidade de reduzir o impacto da rotatividade dos funcionários nas organizações, como também para aumentar a segurança dos usuários nos dados armazenados no DW, os metadados têm despontado como essenciais para o ambiente de apoio à decisão [MAR00] [KIM98a] [POE98]. No ambiente de DW, os dados armazenados são resultados de transformações, integrações e outras manipulações das informações existentes nos sistemas legados e/ou fontes externas aos sistemas. Para tomar decisões, os usuários necessitam conhecer informações sobre quando o dado foi carregado 4

16 pela última vez, de que fontes provêm e como foi combinado ou manipulado. Sem essas informações, os usuários terão dificuldades de usar o DW e gastarão muito tempo desenvolvendo e testando consultas ou perguntando a alguém mais hábil sobre como fazer suas consultas. Embora autores como [GAR98] [POE98] [KIM98a] [INM99], dentre vários outros, defendam a idéia de que os metadados são imprescindíveis para o sucesso de projetos DW, não existe uma metodologia de desenvolvimento de DW que considere a criação e o gerenciamento de metadados como parte integrante de todo o processo de desenvolvimento e produção do DW. 1.3 Organização da Dissertação Este trabalho, além desta introdução, está organizado em mais cinco capítulos, descritos, resumidamente, a seguir. CAPÍTULO 2 - DW: CONCEITOS, ARQUITETURAS E METADADOS Discorre-se sobre os principais conceitos que norteiam Data Warehousing, buscando-se fornecer algumas noções para a construção de um DW. Além disso, descreve-se sobre metadados, tendo-se a preocupação de mostrar o porquê da sua importância no ambiente de DW. CAPÍTULO 3 - REVISÃO BIBLIOGRÁFICA São apresentadas algumas metodologias de desenvolvimento de DW pesquisadas e trabalhos sobre gerenciamento de metadados, com o objetivo de selecionar as tecnologias mais adequadas a serem utilizadas como referencial para o capítulo seguinte. CAPÍTULO 4 - X-META: UMA METODOLOGIA DE DESENVOLVIMENTO DE DW Apresenta-se e detalha-se uma metodologia de desenvolvimento de DW, para atender às organizações com o perfil caracterizado no capítulo 1. CAPÍTULO 5 - ESTUDO DE CASO Descreve-se o ambiente organizacional da SEFIN e detalha-se a aplicação da metodologia X-Meta, como estudo de caso. 5

17 CAPÍTULO 6 - CONCLUSÃO Conclui-se o trabalho, evidenciando-se suas contribuições e futuras atividades de pesquisa que poderão ser desenvolvidas. 6

18 2 DW: CONCEITOS, ARQUITETURAS E METADADOS 2.1 Introdução Este capítulo provê uma visão geral sobre Data Warehousing, para atender ao contexto deste trabalho. Da próxima seção até a seção 2.4, são descritos termos básicos como Sistemas de Apoio à Decisão (SAD), Data Warehouse (DW) e Data Mart (DM). A seção 2.5 apresenta as principais topologias de DW encontradas na literatura. Na seção 2.6 detalha-se sobre modelagem dimensional e na seção 2.7 sobre aplicações OLAP. A seção 2.8 está destinada às principais arquiteturas que podem ser utilizadas para a construção de um DW. Ao final do capítulo, na seção 2.9, discorre-se sobre metadados, focando principalmente a sua importância e aplicação no ambiente de DW. 2.2 Sistemas de Apoio à Decisão As aplicações típicas de uma organização moderna podem ser classificadas da seguinte forma: aplicações do negócio: esta classe consiste de aplicações que dão suporte ao dia-a-dia do negócio e garantem o funcionamento operacional da empresa. Esta classe também pode ser denominada de sistemas de produção, sistemas 7

19 operacionais transacionais, ou ainda OLTP (On-Line Transaction Processing processamento de transações on-line); aplicações sobre o negócio: nesta classe encontram-se as aplicações que analisam o negócio, ajudando a interpretar o que ocorreu e a tomar decisões futuras para a empresa. Estão inseridos nesta classe os Sistemas de Apoio à Decisão (SAD) ou Sistemas de Suporte à Decisão (DSS-Decision Support System). Os Sistemas de Apoio à Decisão configuram sistemas que realizam tipicamente o processamento analítico de informações, muitas vezes referenciado também como processamento informacional. Os SADs são utilizados em empresas para prover as informações necessárias para suporte às decisões estratégicas ou táticas. Segundo [POE98], a tomada de decisão estratégica é realizada através da análise de padrões, comportamentos e tendências, levando a tomadas de decisões que afetam os rumos e as diretrizes de um empreendimento como um todo. O desenvolvimento de novos produtos e serviços é um exemplo desse tipo de decisão, que normalmente ocorre através da análise de grande quantidade de dados armazenados por vários anos. Já as decisões táticas, bem mais freqüentes, usualmente analisam uma quantidade menor de dados e têm como finalidade responder imediatamente a situações específicas do negócio, como, por exemplo, revisão e modificação das atividades de um setor. Os SADs vêm de uma longa e complexa evolução, existindo tanto no ambiente de desenvolvimento espontâneo quanto no ambiente de desenvolvimento projetado. Para se entender a diferença entre esses dois ambientes, deve-se perceber a distinção entre dois tipos de dados dados primitivos e dados derivados. No ambiente espontâneo, onde se encontra atualmente a maioria das organizações, está o processamento operacional, também referenciado como processamento de aplicações de missão crítica. Esse ambiente utiliza-se dos dados primitivos na execução das operações cotidianas da empresa. Por outro lado, o ambiente projetado utiliza-se de dados derivados, resumidos ou calculados a partir dos dados primitivos, de forma a atender às necessidades da gerência da empresa. No contexto do ambiente projetado, está o processamento analítico, também chamado de informacional ou processamento de suporte à decisão. Este tipo de processamento permite ao usuário analisar grande quantidade de dados, normalmente 8

20 históricos, de modo a verificar problemas e situações, facilitando e qualificando a tomada de decisão. O Data Warehouse encontra-se nesse ambiente. 2.3 Data Warehouse Não existe um consenso quanto à definição de um DW. Dessa forma, serão apresentadas definições de diversos autores: INMON [INM97]: consiste de uma coleção de dados orientada por assuntos, integrada, não volátil e variável em relação ao tempo, que tem por objetivo dar suporte ao processo gerencial de tomada de decisão; KIMBALL [KIM98b]: um DW não consiste apenas em dados, mas também em um conjunto de ferramentas para consultar, analisar e apresentar informações; GARDNER [GAR98]: define Data Warehousing como um processo, não um produto, para a montagem e administração de dados provenientes de várias fontes, com o propósito de obter uma simples e detalhada visão de parte de todo o negócio; POE et al. [POE98]: representa um banco de dados analítico, usado como base para os SADs. É desenvolvido para colecionar, integrar e armazenar um grande volume de dados. Para enriquecer e aumentar o valor dos dados, ações são executadas sobre esses dados, para transformá-los em informações e para prover acesso intuitivo a estas informações, que serão usadas na tomada de decisões; GRAY et al. [GRA98]: compreende tipicamente um sistema de banco de dados dedicado que é separado dos sistemas OLTP da organização; SEN et al. [SEN98]: são construídos no interesse de suporte à decisão de negócios e contêm dados históricos sumarizados e consolidados provenientes de registros individuais de banco de dados operacionais; SINGH [SIN01]: consiste na separação física dos sistemas de dados operacionais de uma organização dos seus sistemas de suporte à decisão. Ele inclui um repositório de informações, construído com dados em nível de detalhe, departamentalizados, compondo o amplo sistema de informações da empresa, de forma que esses dados possam ser modelados e analisados pelos administradores do negócio. 9

21 Como se pode observar, existem diferentes visões para um Data Warehouse: uma arquitetura, um conjunto de dados consistentes, um conjunto de ferramentas, ou ainda um processo. No contexto desta dissertação, a sigla DW será utilizada para designar Data Warehouse como um sistema de banco de dados analítico, mantenedor de dados integrados e históricos que servem, desde a alta direção, necessitada de informações mais resumidas, até às gerências de baixo nível, onde os dados detalhados ajudam a observar aspectos mais táticos. As principais características de um DW, como também uma breve descrição dessas características, são apresentadas na tabela 1. Já uma discussão mais detalhada pode ser obtida em [INM97] [GRA98] [CAM98] [PER99]. Tabela 1 Resumo das principais características de um DW Características Orientado por assunto/tema Integrado Não volátil Variável em relação ao tempo Grandes volumes Não normalizado Agregação Entrada Descrição resumida Os dados são organizados da forma como os usuários a eles se referem As inconsistências são removidas em nomenclatura e conflito de informação, isto é, os dados são limpos Os dados são somente de leitura, não podendo ser atualizados pelos usuários Dados armazenados são históricos, significando que estão associados a um ponto no tempo Manter dados históricos implica em uma maior quantidade de detalhes e necessidade de espaço de armazenamento Dados podem ser redundantes Dados são sumarizados, quando necessário, para aumentar o desempenho das consultas As fontes dos dados são os sistemas legados e fontes externas Data Warehousing refere-se a toda a tecnologia do ambiente onde o DW está inserido, inclusive o seu processo de desenvolvimento, sendo considerado um novo paradigma dentro da tecnologia da informação (TI). Engloba algoritmos e ferramentas que possibilitam que dados selecionados de diferentes provedores de informação sejam armazenados em único repositório de dados. Tais algoritmos e ferramentas garantem ainda o acesso aos dados desse repositório, em atendimento às consultas e análises realizadas por usuários finais. A maioria dos autores, como em [BON98] [GAR98] [GRA98] [INM97] [KIM98a] [POE98], concorda com o argumento de que Data Warehousing envolve três grandes componentes, os quais estão ilustrados na figura 1. O primeiro corresponde ao software de obtenção de dados ou back end e é responsável pela extração dos dados de sistemas OLTP 10

22 e fontes externas, pela transformação e integração (limpeza, combinação, validação, consolidação, agregação e sumarização) desses dados e por sua carga no DW. Alguns autores denominam estas atividades de processo ETL - Extração, Transformação e Carga (Load). O DW, ou simplesmente repositório de dados, corresponde ao segundo componente. Trata-se de um banco de dados analítico, onde os dados estão organizados para permitir alto desempenho na recuperação de informações. Finalmente, o terceiro componente é formado por ferramentas front end, onde os usuários acessam o repositório, executando suas consultas e relatórios, de modo a obterem informações que permitam a tomada de decisões. Software de obtenção dos dados BACK END: extração de dados de sistemas legados e fontes externas consolidação e sumarização de dados carga dentro do repositório de dados Data Warehouse Software cliente FRONT END: usuários acessam o repositório de dados usuários efetuam análise dos dados Figura 1 Arquitetura resumida de um ambiente Data Warehouse O escopo de um DW pode ser tão amplo quanto aquele que inclui todo o conjunto de informações de uma empresa ou tão restrito quanto um DW pessoal de um gerente. Pode-se constatar, no entanto, que, quanto maior o escopo, mais valor o DW agrega para a empresa. Porém, nesse caso, mais cara e trabalhosa é a criação e manutenção do DW. Por isso, muitas empresas tendem a começar com um DW restrito a um ambiente departamental e, só após obter um retorno das expectativas de seus usuários, expandir seu escopo. 2.4 Data Mart Data Marts (DM) são DW projetados para representar uma área de negócio específica ou setor da empresa (marketing, finanças, vendas etc.). Um DM pode ser entendido como um subconjunto lógico de um DW completo. Portanto, um DM representa um DW de pequena capacidade, usado para atender especificamente a uma unidade estratégica de negócio ou a um departamento da corporação [KIM98a] [POE98] [GRA98]. 11

23 Dessa forma, os três grandes componentes (back end, banco de dados analítico e front end) existentes em um ambiente de DW, já descritos na seção 2.3, também existem em um DM. Além disso, como no DW, Data Mart pode conter dados armazenados em vários níveis de detalhe, dependendo das exigências do negócio e das aplicações do usuário final. Algumas organizações optam por iniciar o projeto de desenvolvimento de um ambiente de DW a partir de DM. As vantagens dessa estratégia são: rapidez na implementação; baixo custo; necessidade de conhecimento tecnológico mais restrito; controle local, em vez de centralizado; e redução do tempo de resposta a consultas, tornando o binômio custo-benefício muito favorável. Essas características contrastam com o esforço prolongado de modelagem, tempo de desenvolvimento e recursos financeiros exigidos pelo DW. Na verdade, as organizações que decidem iniciar o ambiente de suporte à decisão através dessa abordagem, constroem um DM e, simultaneamente, seu primeiro DW. Ao se adotar esta estratégia, a integração dos diversos DMs, constituintes de um ambiente DW, deve ser uma das principais questões a definir logo no início do projeto, para evitar a proliferação desordenada e sem planejamento desses mesmos DMs. 2.5 Topologias de DW Denomina-se topologia de um DW a estrutura do ambiente computacional na qual o DW estará inserido. O desenvolvimento de um projeto DW, para atender a toda a organização, deve iniciar com a definição de como o ambiente DW será estruturado. As principais topologias encontradas na literatura, ilustradas na figura 2, estão apresentadas a seguir: Data Warehouse Centralizado: consiste de um DW único que suporta todas as necessidades de informações da organização, atendendo a toda a comunidade de usuários e as mais diversas aplicações (figura 2(a)). Esta topologia é escolhida para 12

24 grandes DWs, quando se procura por vantagens de economia e um sistema de gerenciamento centralizado. Data Mart Dependente: constitui-se de vários DMs ligados a um DW centralizado, em uma configuração de três camadas (figura 2(b)). Os usuários são conectados a específicos DMs, que extraem os dados do DW. Também é possível ao usuário acessar diretamente o DW para obter informações de outras áreas de negócios. Esta topologia facilita a entrega de dados limpos e integrados do DW para os DMs dependentes, apresentando alto desempenho na recuperação e apresentação de resultados de consultas. Data Mart Independente: como na topologia anterior, os usuários são conectados a específicos DMs, não existindo, no entanto, um DW centralizado (figura 2(c)). Dessa forma, os sistemas operacionais transacionais são a fonte dos dados para os DMs independentes. Esta topologia caracteriza-se pela rapidez no desenvolvimento, controle local e baixo custo. Apresenta ainda vantagens no acesso às informações de forma otimizada, e alto desempenho na recuperação e apresentação de resultados de consultas. O principal problema é que, sem um planejamento global, o desenvolvimento em paralelo de vários DMs pode acarretar falta de integração e compartilhamento de dados. Data Warehouse Distribuído: consiste de vários DW interligados através de rede, com forte suporte a processamento distribuído (figura 2(d)). Isto permite que qualquer usuário, em qualquer lugar, se conecte a qualquer DW e trabalhe como se estivesse ligado a um simples e centralizado DW, embora esteja fisicamente distribuído ao longo de múltiplos DW. Esta topologia exige alta capacidade no gerenciamento de banco de dados distribuídos, além de poder apresentar sérios problemas e até mesmo inviabilizar a sua utilização, caso as aplicações exijam freqüentes operações de junção entre tabelas distribuídas, comprometendo significativamente o desempenho e o tempo de apresentação das informações solicitadas. Data Warehouse Híbrido: consiste no desenvolvimento inicial de um ou mais DMs com escopo básico, ao mesmo tempo em que se prevê o crescimento incremental desses DMs na fase de planejamento (figura 2(e)). Dessa forma, combina-se a disponibilização bottom-up desses DMs com o desenvolvimento top- 13

25 down do modelo de dados de alto nível. Esse desenvolvimento híbrido (bottom-up e top-down) de DM, de forma planejada, possibilita a criação de sistemas que sejam flexíveis e escaláveis, na medida do crescimento do DW. Dados operacionais DW DW DM DM Data Warehouse Centralizado (a) DM Data Mart Independente (c) Data Mart Dependente (b) Dados operacionais MODELAGEM TOP-DOWN DE ALTO NÍVEL Dados operacionais DW DW PROCESSAMENTO DISTRIBUÍDO DM DM Data Warehouse Híbrido (e) Data Warehouse Distribuído (d) Figura 2 Topologias de DW 2.6 Modelagem Dimensional A modelagem dimensional é um nome novo para uma técnica antiga usada para criar bancos de dados simples e compreensíveis. É uma alternativa para a modelagem de dados através do Modelo Entidade Relacionamento (MER) e contém as mesmas informações, como, por exemplo, entidades, relacionamentos e atributos [KIM98a]. As características do modelo relacional já são amplamente conhecidas. O seu principal objetivo é eliminar, ao máximo, a redundância de dados, de tal forma que uma transação que promova mudanças no banco de dados atue o mais pontualmente possível. Com isso, os dados são fragmentados por diversas tabelas, o que traz considerável 14

26 complexidade à formulação de consultas por um usuário final, porque muitas vezes é necessário especificar diversas operações de junção para reunir esses dados. Como as consultas típicas de SAD requerem acessos interativos aos bancos de dados, o tempo de resposta se mostra ruim e frustra os usuários. Portanto, esta abordagem não parece ser a mais adequada para projeto de DW, para o qual estruturas mais simples e com menor grau de normalização devem ser buscadas. A modelagem dimensional busca apresentar os dados em uma estrutura padronizada, que é intuitiva e permite alto desempenho de acesso, adequada para suportar processamento analítico. Neste tipo de modelagem, os dados são visualizados através de uma estrutura simples de cubo de dados, no qual os lados representam os eixos das dimensões dos dados e permitem consultas sob múltiplas perspectivas. Qualquer ponto no interior do cubo está na interseção das coordenadas definidas pelas arestas do cubo e representam as medições do negócio. Esta estrutura simples de cubo de dados pode ser facilmente entendida e navegada, tanto pelo usuário final quanto pelo software, tornando a interface do usuário simples e o desempenho das consultas aceitáveis. Deve-se ressaltar que os cubos de dados podem apresentar de duas até n dimensões. Na figura 3, apresenta-se um exemplo de modelagem dimensional. Neste exemplo, a arrecadação da PMF pode ser examinada sob as perspectivas: período (anual, semestral), tipo de tributo (IPTU, ISS, ITBI) e órgão expedidor (SEFIN, Regional I, Regional II). Os pontos dentro do cubo permitem analisar o volume da arrecadação, utilizando mais de uma dessas perspectivas (volume de arrecadação por órgão/tipo do tributo, volume de arrecadação por semestre/órgão etc.). Volume de Arrecadação Volume de Arrecadação IPTU Tipo do Tributo ISS Taxas SEFIN Regional I Regional II Regional Semestre Órgão Figura 3 Cubo de dados 15

27 Para compreender como os dados multidimensionais estarão armazenados, a figura 4 mostra um exemplo de uma estrutura relacional comparada a uma estrutura dimensional, com duas dimensões. Pode-se observar que cada eixo no espaço dimensional corresponde a um atributo (coluna) da tabela relacional e cada ponto a um valor correspondente à interseção das colunas. Para se implementar dados representados através da modelagem dimensional, em um banco de dados relacional, precisam-se de dois tipos de tabelas: fato e dimensão (figura 5 e 6). A tabela fato é central e possui uma chave primária composta pelas chaves primárias das tabelas dimensão. Usualmente, as tabelas fato armazenam grande quantidade de dados (de gigabytes a terabytes) e contêm as medições numéricas do negócio. As tabelas dimensão possuem chave simples, são pequenas e armazenam dados descritivos do negócio. A chave primária simples da tabela dimensão corresponde exatamente à chave estrangeira da tabela fato, permitindo, assim, a ligação entre as tabelas. Dessa maneira, estruturas relacionais podem ser usadas para a representação e o armazenamento de dados multidimensionais. Há dois tipos principais de estruturas ou esquemas habitualmente utilizados para manipular dimensões: esquema estrela (star schema) e esquema floco de neve (snowflake schema). A figura 5 mostra um exemplo de um esquema estrela e a figura 6 uma representação de um esquema floco de neve. BD RELACIONAL Tributo Órgão Arrecadação Órgão MATRIZ DIMENSIONAL SEFIN Regional I Regional II Tributo IPTU SEFIN 6 IPTU Taxa 1 SEFIN 5 Taxa Taxa 2 SEFIN 4 Taxa Taxa 3 SEFIN 3 Taxa Taxa 1 Regional I 5 Taxa 2 Regional I 5 Taxa 3 Regional I 4 Taxa 1 Regional II 3 Taxa 2 Regional II 2 Figura 4 Estrutura relacional versus estrutura dimensional No esquema estrela, existe uma tabela fato (dominante) no centro do esquema e as tabelas dimensão nas extremidades. A tabela fato é ligada às demais tabelas por múltiplas junções, enquanto as tabelas dimensão se ligam apenas à tabela central por uma junção. Apesar das vantagens desse esquema tradicional maior compreensão do negócio pelo 16

28 usuário final, bem como um melhor desempenho em consultas e grande flexibilidade na modificação do modelo, quando uma tabela dimensão possui uma quantidade muito grande de registros e atributos, podem ser utilizadas soluções alternativas ou variações do esquema estrela. Em [POE98] estão as seguintes variações do esquema estrela: Esquema estrela com múltiplas tabelas fatos: é utilizado quando existem fatos que, apesar de se ligarem às mesmas dimensões, não estão relacionados, ou ainda por causa da diferente periodicidade de tempo de carga. Esquema estrela com tabelas associativas: utilizado para definir relacionamentos muitos-para-muitos entre certas dimensões e negócios. Esquema estrela com tabelas externas: neste esquema, uma ou mais tabelas dimensão podem conter uma chave estrangeira que referencia a chave primária de outra dimensão. É possível representar uma hierarquia de tabelas externas. Esquema multi-estrela: é utilizado quando a chave primária composta da tabela fato identifica mais de um registro nesta tabela. Quando isto ocorre, há necessidade de acrescentar um ou mais campos-chave, de modo que a chave composta da tabela fato identifique única tupla nesta tabela. Dimensão Tempo Chave_tempo Dia_do_mês Mês Ano Flag_feriado Fato arrecadação Chave_tempo Chave_tributo Chave_órgão Reais arrecadados Qtd. pagantes Figura 5 Esquema estrela Dimensão Tributo Chave_tributo Descrição Tipo_arrecadação Categoria Dimensão Órgão Chave_órgão Nome_órgão Endereço Responsável O esquema floco de neve é uma variação do esquema estrela, onde cada uma das pontas da estrela passa a ser o centro de outras estrelas. Assemelha-se muito ao esquema estrela com tabelas externas, sendo que são normalizadas todas as tabelas dimensão. Além de continuarem ligadas à tabela fato, passam a se ligar a outra tabela dimensão. Os motivos para a escolha desse esquema são: economia de espaço de armazenamento; redução do tamanho das tabelas dimensão; setores de informática de algumas organizações sentem-se mais à vontade pela adoção de um esquema mais próximo da modelagem relacional; dentre 17

29 outros. Como desvantagens pode-se citar: redução na eficiência da recuperação dos dados; aumento da complexidade da arquitetura em razão do aumento do número de tabelas, comprometendo a compreensão do usuário; a economia de espaço de armazenamento é questionável (segundo [KIM98a] não chega a 0,1%); dentre outras. Em estudos de vários autores [KIM98a] [POE98] [GRA98], pode-se encontrar mais detalhes das vantagens e desvantagens na adoção dos diversos esquemas. O importante é que, independentemente do tipo de esquema dimensional a ser adotado, deve-se garantir que um projeto de banco de dados analítico seja conduzido no sentido de obter o máximo de vantagens do ambiente de processamento analítico, como, por exemplo, a padronização e a qualidade dos dados, a usabilidade, o desempenho, dentre outras. Dimensão Tempo Dimensão Tributo Dimensão Tipo arrecadação Chave_tempo Dia_do_mês Mês Ano Flag_feriado Fato arrecadação Chave_tempo Chave_tributo Chave_órgão Reais arrecadados Qtd. pagantes Chave_tributo Tributo_descr Chave_tipo_arrec Dimensão Órgão Chave_órgão Nome_órgão Endereço Responsável Chave_tipo_arrec Tipo_arrec_descr Categoria Figura 6 Esquema floco de neve 2.7 Aplicações OLAP O termo OLAP (On-line Analytical Processing) refere-se ao tipo de processamento e ferramentas voltados para análise de dados típica de sistemas de suporte à decisão. Os dados são apresentados através de uma visão dimensional, que é independente de como os dados estão armazenados. Este termo foi introduzido em 1993 por E. F. Codd. O problema surgiu quando bancos de dados relacionais eram submetidos a consultas SQL, relativamente simples, sobre grandes massas de dados. Codd advogou o uso de bancos de dados multidimensionais, cuja idéia básica é a capacidade que o usuário poderia ter de manipular um banco de dados através de suas dimensões, utilizando processamento e ferramentas voltadas para a análise típica de suporte à decisão. Codd publicou doze regras 18

30 para OLAP, as quais podem ser obtidas, em sua íntegra, em [GRA98]. Os dados armazenados em um DW são otimizados para recuperação através de processamento analítico (OLAP), que se constitui em todas as atividades gerais de consulta e apresentação de dados numéricos e textos, provenientes do DW, assim como as formas específicas de consulta e apresentação, exemplificadas por grande quantidade de ferramentas OLAP [KIM98a]. Existem algumas considerações sobre a forma de armazenamento desses dados no DW (veja figura 7). Granularidade é o nível de detalhe ou sumarização dos dados em um DW. O nível de granularidade é uma das principais questões a serem levadas em consideração em um projeto de DW. Um esquema de DW pode ter um nível mais alto ou mais baixo de granularidade, dependendo da decisão tomada pela equipe que o está projetando. Em níveis mais baixos de granularidade, temos dados mais sumarizados ou mais agregados. Já em níveis de granularidade mais altos, temos dados numa forma mais atômica, mais detalhados. O nível de granularidade tem efeito direto no tamanho do banco de dados e no tipo de análise que o banco de dados pode suportar. Dados altamente resumidos Dados levemente resumidos Dados detalhados atuais Dados detalhados antigos Figura 7 Formas de armazenamento de dados em DM/DW Segundo [INM97], 95% ou mais do processamento em SADs são feitos sobre o nível de dados levemente resumidos e altamente resumidos, que são mais compactos, de fácil acesso e de menor tempo de resposta a consultas. Apenas cinco por cento ou menos 19

31 das consultas normalmente são feitas sobre o nível de dados detalhados atuais e detalhados antigos, nos quais o acesso é mais complexo, caro e de elevado tempo de apresentação dos dados consultados. Para fornecer recursos OLAP, existem três grandes correntes de tecnologia de ferramentas na área de banco de dados: MOLAP, ROLAP e ROLAP. MOLAP (Multidimensional OLAP) é uma tecnologia proprietária, constituída de um conjunto de interfaces de usuário e aplicações com características eminentemente dimensionais. O banco de dados é multidimensional, armazena seus dados em um cubo de n dimensões e adiciona o tempo às dimensões. Uma grande vantagem desses bancos proprietários é que eles são otimizados para apresentar alta velocidade e facilidade de resposta às consultas. ROLAP (Relational OLAP) constitui-se de um conjunto de interfaces de usuário e aplicações que dá, ao banco de dados relacional, características dimensionais. HOLAP (Hybrid OLAP) constitui-se em uma nova tecnologia que procura combinar as melhores características de MOLAP e ROLAP. Esta tecnologia já está presente em alguns produtos no mercado (ex. MS SQL 7.0). Mais detalhes e uma comparação entre essas tecnologias podem ser encontrados em [GRA98] [PER99], pois a escolha entre ROLAP, MOLAP e HOLAP depende de quais características do problema e dados devem ser prioritários. A exploração dos dados em DW é feita pelos usuários através de operações, ferramentas e aplicações projetadas para esse fim. As principais operações de navegação em um sistema OLAP são: Roll-up Permitir agregação dos dados em uma ou mais dimensões; Slice-dice Consiste em mudar a ordem das dimensões, mudando assim a orientação segundo a qual os dados são visualizados; Drill-down Consiste em permitir ao usuário descer pelas hierarquias das dimensões. É a forma de pedir mais detalhes (diminuir o nível de agregação). Drill-up Operação contrária ao drill-down (aumentar o nível de agregação); Drill-across Operação que permite ao usuário mover-se lateralmente de um conjunto de dados para outro no mesmo nível; 20

32 Drill-within Detalhamento através dos atributos de uma dimensão; Pivoting Inversão/rotação de eixos. Para efetuar essas operações, facilitando aos usuários a realização de análises multidimensionais (habilidade de manipular dados que tenham sido agregados em várias categorias ou dimensões ), existem as ferramentas OLAP, utilizadas para acessar os dados de forma rápida, consistente e interativa e podem ser encontradas no mercado, apresentando funcionalidades diversas. Uma classificação dessas ferramentas pode ser encontrada em [BER97] e [CAM00]. Um resumo comparativo entre sistemas OLAP e sistemas OLTP é apresentado na tabela 2. Tabela 2 Resumo das diferenças entre OLTP e OLAP OLTP Baseado em aplicações Atende à comunidade funcional Contínua atualização (dados voláteis) Acessa um registro por vez Voltado para transações Não contempla a redundância Pequena quantidade de dados utilizado em um processamento Atende às necessidades cotidianas Normalmente relacional Dados presentes Orientado ao processo Metadados são opcionais OLAP Baseado em assuntos ou negócios Atende à comunidade gerencial Dados não são atualizados (dados não voláteis) Acessa um conjunto por vez Voltado para análise Permite a redundância Grande quantidade de dados utilizado em um processamento Atende às necessidades gerenciais Normalmente multidimensional Dados históricos Orientado ao negócio Metadados são obrigatórios 2.8 Arquiteturas de DW Uma arquitetura é um conjunto de regras ou procedimentos de construção de uma estrutura para projetar, como um todo, um sistema ou um produto. O estudo de uma arquitetura para o ambiente de DW permitirá compreender melhor a estrutura geral de armazenamento, integração, comunicação, processamento e apresentação dos dados que os usuários utilizarão em suas decisões. As diversas abordagens para uma arquitetura de DW serão apresentadas a seguir Arquitetura Genérica Nesta arquitetura são descritos os papéis dos componentes de um ambiente de DW 21

33 e de como estes componentes estão relacionados. Na figura 8 está ilustrada a arquitetura genérica proposta em [SIN01]. Para o autor, apenas as organizações mais sofisticadas serão capazes de reunir, logo de início, uma arquitetura como esta. Os elementos que compõem o ambiente de DW, nesta arquitetura (figura 8), são agrupados nas seguintes camadas: camada de bancos de dados operacionais/dados externos: composta pelos dados dos sistemas operacionais transacionais das empresas e informações provenientes de fontes externas que serão integradas para compor o DW; camada de acesso à informação: envolve o hardware e o software utilizados para obtenção de relatórios, planilhas, gráficos e consultas. É nesta camada que os usuários finais interagem com o DW, utilizando ferramentas de manipulação, análise e apresentação dos dados, incluindo as ferramentas de data mining; camada de acesso aos dados: é responsável pela ligação entre as ferramentas de acesso à informação e os bancos de dados dos sistemas operacionais transacionais, abrangendo diferentes sistemas de bancos de dados, sistemas de arquivos e fontes, sob diferentes protocolos de comunicação e fabricantes. Sendo assim, fornece aos usuários acesso universal aos dados, o que significa, ao menos teoricamente, que os usuários, independentemente de sua localização ou da ferramenta utilizada, sejam capazes de acessar quaisquer ou todos os dados de que necessitam; camada de metadados: fornece acesso a dados universais e é absolutamente necessário manter alguma forma de diretório ou de repositório de informação de metadados; camada de gerenciamento de processos: responsável pelo gerenciamento dos processos que contribuem para manter o DW atualizado e consistente. Está envolvida com o controle das várias tarefas que devem ser realizadas para se construir e manter as informações do dicionário de dados e do DW; camada de mensagem da aplicação: gerencia o transporte de informações pelo ambiente de rede. Inclui a coleta de mensagens e transações e se encarrega de entregá-las em local e tempo determinados. Também conhecida como middleware, é usada para isolar aplicações, operacionais ou informacionais, do formato real dos dados nas duas pontas; camada Data Warehouse: é o DW propriamente dito, e corresponde aos dados utilizados para obter informações. Algumas vezes o DW pode ser simplesmente 22

34 uma visão lógica ou virtual dos dados, não envolvendo o armazenamento de dados. Um DW físico pode armazenar muitas cópias de dados operacionais e externos em um formato fácil de acessar e altamente flexível; camada Data Staging: também chamada de gerenciamento de cópia ou gerenciamento de replicação, inclui todos os processos necessários para selecionar, editar, sumarizar, combinar e carregar dados de banco de dados operacionais e/ou externos no DW. Geralmente envolve programação complexa, incluindo programas de qualidade e filtros que identificam padrões e estruturas de dados, nos dados operacionais. Figura 8 Arquitetura genérica proposta por [SIN01] Arquitetura de Dados Diferente da arquitetura genérica, que procura sistematizar papéis no ambiente DW, a arquitetura de dados objetiva identificar e entender como os dados são transferidos entre os diversos sistemas da empresa (OLTP, SADs) e como são utilizados. Os dados, para atender aos requisitos de implementação de um DW, podem ser categorizados da seguinte forma: dados de tempo real: algumas vezes chamados de dados operacionais porque são usados por sistemas OLTP. Contêm todos os registros de dados individuais detalhados e cada atualização substitui a entrada anterior (o histórico das alterações não é preservado). Normalmente são armazenados em um ambiente heterogêneo, 23

35 composto por vários tipos de banco de dados e de tecnologias de banco de dados de fornecedores diferentes; dados reconciliados: contêm registros detalhados do nível de tempo real em que foram limpos, ajustados ou otimizados para que possam ser usados por sistemas de informação. Em um ambiente heterogêneo, é aconselhável realizar a extração e transformação de dados para transferir e combinar os dados discrepantes em única tecnologia de banco de dados que atenda aos requisitos de sistemas de informação; dados derivados: são sumarizados, calculados ou agregados a partir de múltiplas fontes de dados em tempo real ou reconciliados, para melhorar a capacidade de processamento; dados modificados: pertencem a arquivos de dados que contêm todas as alterações (adições, exclusões, atualizações) feitas em dados de tempo real. Os dados são mantidos como uma seqüência e refletem o histórico das alterações. É possível obter qualquer nível de análise ao longo do tempo. Manter o histórico dos dados modificados resultará em questões adicionais para o gerenciamento de dados; metadados: são dados que representam tanto informações do sistema como informações do usuário. O arquivo de metadados é construído e mantido pelo administrador do DW. Existem algumas configurações usadas para entender o ambiente físico de dados, cada qual com características diferentes e utilizadas de acordo com a necessidade do ambiente. Na abordagem adotada por [GRA98], ilustrada na figura 9, pode-se identificar o tipo de configuração da arquitetura, determinando-se o número de camadas onde os dados são organizados e também de acordo com a ligação entre os dados analíticos e operacionais: uma camada: existe apenas um lugar para armazenar os dados, fazendo com que os sistemas OLTP e analíticos atuem sobre o mesmo conjunto de dados. Os dados, portanto, são referenciados como dados de tempo real (figura 9(a)); duas camadas: os dados dos sistemas OLTP e analíticos são separados em camadas distintas. Sobre os dados de tempo real atuam os sistemas operacionais transacionais, no modo de leitura e escrita. Os sistemas analíticos agem sobre os dados derivados, que provêm da camada de dados de tempo real, através de uma 24

36 simples cópia de dados ou em conseqüência de processos de derivação (figura 9(b)); três camadas: pressupõe que são necessários dois passos para a transformação dos dados dos sistemas OLTP para os sistemas analíticos. O primeiro é a reconciliação de dados originários da camada de dados do tempo real; o outro é a derivação de dados a partir da camada de dados reconciliados (figura 9(c)). Aplicação OLTP Aplicação SAD Aplicação OLTP Aplicação SAD Aplicação OLTP Aplicação SAD Dados de TempoReal Dados Derivados Dados Derivados Dados de Tempo Real Dados de TempoReal Dados Reconciliados Arquitetura de uma camada (a) Figura 9 Arquiteturas de dados propostas por [GRA98] Um resumo sobre a aplicabilidade de cada arquitetura, suas vantagens e desvantagens, é mostrado na tabela 3. Tabela 3 Comparativo entre configurações de arquitetura de dados Uma camada Duas camadas Três camadas Em ambiente computacional homogêneo e limitado com pouco número de plataformas de hardware e software e onde se requer Aplicabilidade Pequenos DMs com poucos usuários e um conjunto limitado de dados; em sistemas com grande quantidade de dados e limitada atividade de análise normalmente realizada no nível de agregados Vantagens Simples, havendo poucos problemas e exigências de armazenamento e gerenciamento de dados Desvantagens Concorrência entre os sistemas OLTP e analíticos, podendo deixar indisponíveis os dados para aplicações analíticas ou degradar o tempo de resposta para aplicações operacionais Arquitetura de duas camadas (b) principalmente dados sumarizados, derivados de simples fontes de dados Não há concorrência entre os sistemas OLTP e analíticos e pode-se ter níveis de derivação detalhado ou sumarizado Alto nível de duplicação de dados, originando problemas de espaço de armazenamento e gerenciamento de dados; limitada escalabilidade para migração para outros sistemas de maior porte Arquitetura de três camadas (c) Ideal para construção de DW com DM independentes Separação de funções do ambiente DW; o espaço de armazenamento é realizado de forma controlada e compreensível Pode aumentar a complexidade para os usuários, dificultando o formato e localização de seus dados 25

37 [SIN01] define quatro configurações de arquitetura de dados bastante semelhantes às de [GRA98]. O diferencial, comparando com [GRA98], está na inclusão dos dados modificados e dos metadados em todas as configurações, e na denominação das arquiteturas (cópia única, dados reconciliados, dados derivados e dados híbridos). A configuração de dados reconciliados não é apresentada por [GRA98] Arquitetura de Acesso aos Dados Uma abordagem de arquitetura um pouco diferente da proposta de [GRA98] foi definida por [KIM98a] e está ilustrada na figura 10. Metadados Usuários do Negócio DW Arquitetura de duas camadas (a) Metadados Servidor de Aplicações Servidor de Relatórios Front End Usuários do Negócio DW Arquitetura de três camadas (ROLAP) (b) Front End Usuários do Negócio Metadados Servidor OLAP DW Arquitetura de três camadas + (MOLAP) (c) Cubo OLAP Figura 10 Arquiteturas de acesso aos dados propostas por [KIM98a] 26

38 Nesta abordagem de acesso aos dados, as camadas são nomeadas de acordo com as funcionalidades providas pelas ferramentas de acesso aos dados, disponibilizadas para os usuários finais. Observa-se que neste tipo de arquitetura não são consideradas as ligações dos dados analíticos com os dados operacionais. As propostas de [KIM98a] (figura10) estão descritas a seguir: duas camadas: os dados são acessados através de ferramentas projetadas para se conectarem diretamente ao repositório de dados (figura 10(a)); três camadas (ROLAP): separa a maioria das funções de gerenciamento de consultas das ferramentas de front end e as centraliza em um servidor de aplicações, o qual representa, para o cliente, o banco de dados analítico como um ambiente multidimensional. Os metadados, que residem em tabelas relacionais e descrevem fatos, dimensões, medidas do negócio, hierarquias, perfis de usuários, etc., são usados intensivamente pelas ferramentas ROLAP (figura 10(b)); três camadas + (MOLAP): neste caso, a camada intermediária (servidor OLAP) inclui sua estrutura de banco de dados, denominada de banco de dados de cubo dimensional. As consultas dos usuários finais são gerenciadas pelo servidor OLAP, que as envia inicialmente ao cubo OLAP e, caso esse não possa atendê-las, tais consultas são destinadas ao DW (figura 10(c)) Arquitetura Funcional A arquitetura funcional representa um plano geral do fluxo de controle e de dados de um DW, quando este estiver completamente construído. Trata-se de um tipo de arquitetura que descreve o fluxo de dados dos sistemas-fonte até os usuários finais e inclui recursos de gerenciamento e implementação. A arquitetura funcional e a infra-estrutura técnica estão estreitamente relacionadas [POE98]. A infra-estrutura técnica corresponde às tecnologias, plataformas, banco de dados, gateways (envolve conexões entre diferentes redes, diferentes protocolos de comunicação e diferentes representações de dados), treinamento e outros componentes necessários para a implementação de uma arquitetura de DW. Entretanto, uma mesma arquitetura pode requerer diferentes infra-estruturas, dependendo do ambiente corporativo, das necessidades de suporte à decisão e da arquitetura do sistema. 27

39 Várias propostas de arquiteturas funcionais detalham o ambiente de DW [INM97] [POE98] [GRA98] [KIM98a]. A arquitetura de [CHA97], ilustrada na figura 11, embora mais simples, permite compreender os componentes envolvidos na construção do DW e os fluxos dos dados que ocorrem no sistema. A arquitetura de [KIM98a], também com as mesmas características, é bastante completa e detalhada. Os dois círculos da figura 11 representam as duas partes principais da arquitetura proposta em [KIM98a] (área interna e área externa). Área Externa [KIM98a] Área Interna [KIM98a] Figura 11 Arquitetura funcional proposta por [CHA97] A arquitetura de [CHA97] está dividida em: fontes de dados de onde o DW irá retirar seus dados de origem; conjunto de estruturas de dados analíticos armazenados: o DW do sistema; Sistema Gerenciador de Banco de Dados (SGBD) otimizado para atender aos requisitos analíticos dos sistemas de DW; componente back end: conjunto de aplicações responsáveis por extrair, filtrar, transformar, integrar e carregar os dados de diferentes origens no DW; 28

40 componente front end: conjunto de aplicações responsáveis por disponibilizar aos usuários finais acesso ao DW; e repositório para armazenar e gerenciar os metadados do sistema. Cinco principais fluxos fazem parte do sistema: fluxo de entrada (inflow), fluxo de saída (outflow), fluxo de subida (upflow), fluxo de descida (downflow) e fluxo de metadados (metaflow) (figura11). O primeiro fluxo é o de entrada dos dados no sistema (inflow), que envolve extrair, filtrar, transformar, integrar e carregar os dados de várias fontes no DW. Deve-se considerar as fontes de dados que pertencem à empresa e as fontes externas. O fluxo de entrada é geralmente implementado com a ajuda de ferramentas especialmente desenvolvidas para esse fim. O segundo fluxo é o de descida dos dados (downflow), ou seja, em tempo predeterminado, de dois a cinco anos, dependendo da empresa, os dados armazenados no DW passam para o estado de dados antigos. Este é o fluxo que remove do DW aqueles dados considerados velhos, que já não são mais utilizados com freqüência. O terceiro fluxo é o de subida dos dados (upflow), em que é enfocada a necessidade de colocar os dados em formatos mais acessíveis aos usuários finais. Este processo sumariza e agrupa os dados dentro de "visões" mais adequadas aos usuários finais e as aplicações front end que eles utilizam, tais como tabelas sumarizadas, planilhas, gráficos, páginas no formato Hyper Text Markup Language (HTML), banco de dados pessoais, entre outros formatos. Também é função do fluxo de subida a distribuição dos dados para os diferentes níveis do sistema como, por exemplo, DM e bancos de dados pessoais localizados nas estações de trabalho dos usuários finais. O quarto fluxo é o de saída dos dados (outflow), cuja função é a de disponibilizar acesso aos usuários finais do sistema. Este processo é implementado através de uma variedade de ferramentas front end, tais como geradores de consulta e relatório, ferramentas com características On-line Analytical Processing (OLAP), pacotes estatísticos, ferramentas de Data Mining, ferramentas de visualização, Executive Information System (EIS), Sistemas de Suporte à Decisão, entre outras. As ferramentas front end podem acessar, tanto dados previamente preparados pelo fluxo de subida, quanto dados "brutos" e detalhados, armazenados no DW. 29

41 O quinto e último fluxo pode ser chamado de fluxo de metadados (metaflow). Ao contrário dos quatro fluxos de dados citados há pouco, que descrevem como os dados se movem no DW, o metaflow move metadados, ou seja, dados sobre os outros fluxos. O repositório de metadados é responsável pela gerência do sistema como um todo, indicando de onde vêm os dados, como são transformados, quando são atualizados, o que significam, como são acessados e quem os vê. 2.9 Metadados Metadados e repositório de metadados não são conceitos novos. Eles datam do início dos anos 1970, quando surgiram os dicionários de dados com o propósito de auxiliar os administradores de banco de dados (DBAs) no planejamento, controle do armazenamento e uso dos dados. As informações armazenadas diziam respeito às definições, relacionamentos, origem, domínio, formato e uso dos dados. Ainda nesta época, foram introduzidas as primeiras ferramentas CASE (Computer Aided Software Engineering), que apoiavam os processos de projeto de banco de dados e softwares aplicativos. Adicionalmente, também armazenavam dados sobre os dados que elas controlavam. As ferramentas CASE foram as primeiras ferramentas comerciais a oferecer serviços de metadados [MAR00]. Apesar da evolução destas ferramentas durante os anos 1980, não houve acordo para integração entre os metadados das diversas ferramentas, pois não existia interesse, por parte de quem os desenvolvia, que enxergavam nessa integração uma facilidade para migração de sua ferramenta para a de competidores, além de acharem que suas ferramentas podiam prover todas as funcionalidades necessárias. No final dos anos 1980, muitas companhias, incluindo a IBM, disponibilizaram ferramentas de repositório de metadados para mainframe. No entanto, o escopo era restrito à descrição dos dados, não passando de meros dicionários de dados sofisticados, atendendo basicamente aos administradores de banco de dados e administradores de dados Além disso, segundo [INM98], havia outros problemas que provocaram o legendário fracasso desses repositórios nesta época: criar e atualizar os dicionários e repositórios era difícil porque as pessoas que conheciam os antigos sistemas, muitas vezes, já estavam afastadas da empresa. Alguns códigos fonte nem existiam mais; 30

42 ainda que pudessem ser criados, mantê-los atualizado era impossível, pois os programadores não faziam documentação e certamente também não estavam inclinados a fazer metadados; ninguém queria gastar dinheiro com sistemas que já estavam envelhecendo; e os benefícios de um repositório para o negócio eram difíceis de demonstrar. No início dos anos 1990, surgiu então o reconhecimento do valor dos metadados, além da sua utilização técnica. Os metadados do negócio, que dão suporte aos usuários finais, despontaram com a introdução das ferramentas para suporte à decisão. Com o passar dos anos, os usuários dessas ferramentas, cada vez mais exigentes e informados sobre Tecnologia da Informação (TI), passaram a procurar por informações confiáveis, no menor tempo e com o mínimo de pesquisa possível. O cenário de metadados, ampliado pelas informações da área do negócio, assumiu então um papel da maior importância e tornou-se essencial para o ambiente de apoio à decisão [MAR00] [KIM98a] [POE98]. Outros fatores que têm despertado a necessidade de metadados nos negócios hoje são: os sistemas atuais são inflexíveis e não integrados; as necessidades dos usuários de negócio não estão sendo atendidas; as companhias precisam reduzir o impacto da rotatividade dos funcionários; e necessidade de aumentar a segurança dos usuários nos dados. Atualmente, vários trabalhos descrevendo a necessidade de se gerenciar metadados podem ser encontrados na literatura. Esta preocupação tem sido gerada principalmente pelo crescimento de Data Warehousing. A maioria dos autores pesquisados, como em [KIM98a] [POE98] [INM99] [MAR00], concorda que a utilização de metadados, para descrever todo o contexto e informações dos dados armazenados no ambiente DW, bem como o conhecimento dos processos de negócio, facilita o uso e a manutenção do DW e garantem o sucesso dos projetos Conceituação Além da definição padrão e popular dados sobre dados os metadados também podem ser definidos como uma abstração dos dados ou dados de mais alto nível que descrevem dados de um nível inferior. Pode-se citar como exemplos de metadados as 31

43 descrições de registros em um programa de aplicação, esquema de banco de dados ou, ainda, as informações armazenadas em um dicionário de dados. Não há consenso sobre uma conceituação precisa de metadados no contexto de Data Warehousing. Por este motivo, são apresentadas algumas definições de metadados, a seguir: GRAY et al. [GRA98]: metadados representam informações mantidas acerca do DW em lugar de informação provida pelo DW, sendo essenciais tanto para o grupo de trabalho quanto aos usuários do DW. Cada um desses grupos requer diferentes informações. Para a equipe de desenvolvimento, os metadados incluem: um diretório dos tipos de dados e de sua localização no DW; um guia que mapeia a forma como os dados provenientes das fontes de dados são carregados no DW; regras usadas para sumarização. Por sua vez, os metadados incluem, para os usuários, os termos do negócio que podem ser usados para acessar os dados; as fontes de dados, as regras usadas para derivá-las e onde foram criadas. POE et al. [POE98]: metadados provêem informações sobre a estrutura de dados e as relações entre estas, dentro ou entre bancos de dados. Dois tipos de metadados são identificados. O primeiro é o de integração de dados, que associa os dados dos sistemas fonte aos dados do DW. O segundo é o de transformação, também chamado de metadados SAD, cuja finalidade é a de mapear os dados do DW para o usuário final, através de ferramentas front end. SEN et al. [SEN98]: metadados são abstrações de dados, que são instrumentos na definição de dados brutos. Três tipos de metadados são identificados: nível operacional define a estrutura de dados nos bancos de dados operacionais; nível depósito de dados define a forma como os dados transformados são interpretados; nível de negócio onde os metadados do DW são mapeados para os conceitos do negócio. GARDNER [GAR98]: para o autor, em banco de dados relacionais metadados são a representação de objetos definidos no banco de dados, especificamente as definições de tabelas, colunas, visões e qualquer outro objeto. Em DW, metadados referem-se a qualquer coisa que defina objetos DW, tal como tabelas, colunas, consultas, relatórios, regras de negócio ou um algoritmo de transformação. 32

44 KIMBALL et al. [KIM98a]: metadados são todas as informações do ambiente de DW que não dizem respeito a seus próprios dados. HARRRISON [HAR98]: metadados devem funcionar como um componente de arquitetura que reduz o tempo de desenvolvimento e as necessidades de apoio ao usuário, proporcionando uma camada dinâmica entre o DW e a lógica do aplicativo. SINGH [SIN01]: metadados são informações necessárias para tornar úteis dados científicos. Em um sentido geral, são usados para definir um contexto. O termo é usado para descrever a definição dos dados armazenados no DW, permitindo o uso mais eficiente da análise dos dados do DW. MARCO [MAR00]: metadado é todo dado físico (contido em software e outros meios) e conhecimento (contido nos trabalhadores e outros meios) interno e externo à organização, incluindo informações sobre dados físicos, processos técnicos e de negócio, regras e restrições de dados, e estruturas de dados usados por uma corporação. No contexto da presente dissertação será adotada a definição de [MAR00] como referencial conceitual para metadados O Papel dos Metadados no Ambiente de DW Os metadados têm uma importância fundamental no ambiente analítico, diferentemente do seu papel no ambiente operacional [KIM98a] [INM98] [POE98] [SIN01]. Neste ambiente, os metadados são relegados ao mesmo nível de importância da documentação, sendo, muitos deles, opcionais. Isso acontece porque, no ambiente operacional, os usuários finais interagem com as informações através de formulários, telas e relatórios de aplicações, desconhecendo como as informações estão armazenadas nos bancos de dados. Dessa maneira, os metadados no ambiente operacional são especialmente valiosos para os desenvolvedores de aplicações e administradores de banco de dados. Ao contrário, nos ambientes de suporte à decisão os usuários são analistas de dados e executivos que buscam informações relacionadas ao negócio para apoio à decisão. Esses usuários do DW precisam obter todas as informações possíveis sobre o tratamento conferido aos dados, pois normalmente os fatos que eles procuram não são usuais. Os metadados podem prover significativo valor e acesso fácil às informações do ambiente 33

45 DSS para os usuários do negócio. Gerentes de TI e usuários finais já percebem que DW somente é útil com a qualidade, precisão e facilidade de uso dos seus dados. Entender a importância de metadados é fácil. A dificuldade é saber avaliar quais requisitos os metadados devem procurar enfocar, bem como quais informações devem ser armazenadas, para garantir o mapeamento de metadados dos sistemas legados para o DW e o acesso dessas informações pelo usuário final. Além disso, como os dados no DW são armazenados ao longo do tempo, não é suficiente apenas armazenar o conteúdo da informação, mas também o seu contexto, para ser possível compreender e interpretar a informação. Por exemplo, para se efetuar uma análise adequada sobre a evolução da arrecadação dos tributos na SEFIN não basta apenas conhecer quais foram os resultados obtidos, mas também conhecer as circunstâncias (índice de inflação, aumento no número de imóveis, alteração na legislação etc.), para entender por que existem diferenças nos valores obtidos. O contexto da informação, tão importante quanto o conteúdo, também deve ser armazenado e gerenciado, com o passar do tempo, em forma de metadados. A existência de metadados é visível desde o inicio do projeto de desenvolvimento de um DW e perdura por toda a sua vida útil. Desta forma, a coleção de metadados em um projeto DW assume uma forma incremental e, como conseqüência, o volume de metadados é imenso. Além disso, há diferentes tipos, fontes e usuários de metadados no ambiente DW. A necessidade de gerenciar metadados despontou com o crescimento de Data Warehousing. Este gerenciamento envolve as atividades de criação e manutenção dos metadados, além de dar cobertura à infra-estrutura técnica do DW para os desenvolvedores e usuários, enquanto mantém o modo de ser dos dados perfeitamente claros. Para tomar decisões, os usuários necessitam conhecer informações, tais como quando o dado foi carregado pela última vez, de que fontes provêem e como o dado foi combinado ou manipulado. Sem essas informações, os usuários vêem-se privados de usar o DW, ou acabam gastando muito tempo desenvolvendo e testando consultas, ou perguntando a alguém mais hábil para escrevê-las. Portanto, o verdadeiro valor do DW reside na habilidade do usuário em saber aproveitar os dados, as informações e o conhecimento do negócio de forma útil. Gerenciamento de metadados em DW será abordado com detalhes na seção

46 2.9.3 Repositório e Ferramentas Os metadados são colecionados e armazenados fisicamente em um repositório, para que se tornem persistentes. Neste trabalho, repositório de metadados é tratado como o conjunto de tabelas do banco de dados onde os metadados estão armazenados e funciona como uma plataforma de integração de metadados. O repositório de metadados é o componente do ambiente DW que dá suporte ao gerenciamento dos metadados. Entre outras coisas, um repositório de metadados bem-construído deve dar suporte a todas as fases do ciclo de vida de um DW e contribuir para integrar o ambiente analítico com o ambiente operacional. Tal propriedade facilita a manutenção do ambiente DW e garante a sua consistência. Segundo [MAR00], a construção de um repositório de metadados envolve grande conhecimento e investimento, assim como uma abordagem sistemática de desenvolvimento. Além disso, é necessária uma mudança cultural dentro da organização, com participação ativa dos usuários. Se os usuários não se envolverem ativamente no processo de captura e manutenção dos metadados, a qualidade provavelmente será pobre e o repositório de metadados não será capaz de fornecer o valor que os usuários do negócio e de TI exigem. Para ele, o maior erro, na maioria das organizações que pretendem iniciar projetos de repositório de metadados, é acreditar que basta adquirir uma ferramenta que as funcionalidades de metadados magicamente aparecerão. Em [MAR00] pode-se encontrar um guia completo para construção e gerenciamento de repositório de metadados. Muitas ferramentas de um ambiente DW, como ferramentas de ETL (extração, transformação e carga), SGBDs, ferramentas OLAP e outras, já incluem facilidades próprias para controle de metadados. No entanto, o que se exige hoje são produtos com foco em gerência de metadados. Ferramentas para gerência de metadados devem prover armazenamento, gerência e acesso a metadados. Para um ambiente de DW, há diversas ferramentas disponíveis no mercado para gerenciamento de metadados. Estas ferramentas manipulam metadados em geral, não específicos de qualquer ferramenta, e algumas conseguem ler o repositório de outras ferramentas, para povoar seu próprio repositório. No entanto, segundo [BAR97a], não há nenhum conjunto de ferramentas integradas que permita unificar os processos de projeto, recuperação de dados e transformação, e o relacionamento entre sistemas origens e finais, e muito menos a habilidade de lidar com diferentes versões. A dificuldade do mercado em 35

47 disponibilizar uma ferramenta com estas características é a falta de um padrão para representar metadados. Conseqüentemente não existe também um padrão para modelo de metadados (metamodelo-meta model). Segundo [MAR00], um metamodelo é um modelo físico de dados do repositório de metadados, que contém, inclusive, a modelagem das funções e regras do negócio que influenciam os dados dos sistemas de informação. Em [MAR00] podem ser encontradas especificações sobre a criação de um metamodelo, bem como um guia para decidir qual o tipo de modelo (relacional ou objeto) é mais apropriado, dependendo dos objetivos relacionados a metadados na organização. Um metamodelo padrão tem dois importantes objetivos: permitir o compartilhamento de metadados entre ferramentas e a interoperabilidade entre ferramentas e repositórios. Atualmente, existem dois grupos conduzidos por desenvolvedores de ferramentas, que tentam estabelecer um metamodelo padrão para representação e troca de metadados: Metadata Coalition (MDC) o padrão OIM (Open Information Model) foi adotado por este grupo em julho de 1999, com a finalidade de definir e implementar um formato-padrão de intercâmbio de metadados, bem como os mecanismos de suporte necessários nos contextos de análise e projeto de sistemas de informação e de ambientes DW. Permite o acompanhamento de todas as fases de desenvolvimento de um sistema de informação, desde a fase de análise até a de implantação. O padrão OIM é baseado nos padrões da indústria UML (Unified Modeling Language), XML (extensible Markup Language), e SQL (Structure Query Language), e busca prover o suporte a tecnologias de computação diversas como CASE, componentes, intranet, banco de dados e Data Warehousing, através de sub-modelos que descrevem metadados de domínios específicos: Modelo de Análise e Projeto cobre o domínio da modelagem orientada a objeto e projeto de sistemas de software; Modelo de Objetos e Componentes cobre os diferentes aspectos envolvidos no ciclo de vida de desenvolvimento de componentes; Modelo de Engenharia de Negócios provê os tipos de metadados necessários à captura dos objetivos e da infra-estrutura organizacional de um negócio, bem como dos processos e regras que governam o negócio; Modelo de Gerenciamento do Conhecimento busca prover os mecanismos necessários para captura, organização e uso dos recursos de informação de uma empresa, de forma a adicionar valor ao negócio; Modelo de Bancos de Dados e Data Warehousing provê tipos de 36

48 metadados para o gerenciamento de esquemas no contexto de projeto de banco de dados, reuso e esquemas e DW. Object Management Group (OMG) o padrão CWM (Common Warehousing Metadata) foi adotado por este grupo em junho de 2000, com o objetivo de permitir a integração de sistemas de DW, e-business e sistemas de negócios inteligentes em ambientes heterogêneos e distribuídos, através de uma representação e de um formato de troca de metadados. Este padrão está baseado nas especificações UML, MOF (Meta Object Facility), uma metalinguagem e um padrão de repositório de metadados, e XMI (XML Meta Data Interchange), um padrão baseado em XML para troca de metadados entre ferramentas e repositórios orientados a objetos. Assim como o padrão OIM, o padrão CWM é definido em UML 1.3 e organiza os tipos de metadados por assunto: CWM Foundation provê os tipos de metadados para representação de conceitos e estruturas compartilhados por outros pacotes CWM; Warehouse Deployment provê os tipos de metadados para registrar como hardware e software são utilizados no DW; Relational provê os tipos de metadados para descrever dados acessíveis através de uma interface relacional; e segue o padrão SQL; Record-Oriented provê os tipos de metadados para descrição dos conceitos básicos de um registro e suas estruturas; Multidimensional Database (MDDB) corresponde a uma representação genérica de um banco de dados multidimensional (MOLAP); XML provê os tipos de metadados para descrever fontes de dados em XML; Transformation provê os tipos de metadados para descrever transformações entre diferentes tipos de fontes de dados; OLAP define um metamodelo dos construtores OLAP essenciais presentes nas aplicações e ferramentas OLAP; Warehouse Process provê os tipos de metadados para documentar o fluxo de processos utilizados para executar as transformações; Warehouse Operation contém classes para o registro das operações diárias de um DW. Os padrões OIM e CWM atuam no nível conceitual, especificando metamodelos que podem ser vistos como os esquemas conceituais para os metadados, incorporando aspectos de aplicações específicas. Abordam, portanto, aspectos de semântica. O outro padrão adotado pelo grupo OMG, XML Metadata Interchange (XMI), atua no nível físico, preocupando-se em estabelecer um conjunto de regras capaz de gerar documentos XML e, portanto, abordando aspectos de sintaxe. Pretende-se utilizar o padrão XMI como uma 37

49 ponte universal entre as ferramentas de desenvolvimento orientadas a objeto, evitando desta forma a criação de uma variedade de formatos proprietários, cada um específico de cada fornecedor, à medida que cada ferramenta passe a importar e exportar metadados no formato XMI. Apesar das discussões sobre padrões de metadados entre comitês e órgãos internacionais no sentido de garantir interoperabilidade de ferramentas e repositórios, a troca de metadados entre ferramentas ainda é uma tarefa crítica, visto que as ferramentas codificam e armazenam seus metadados de forma proprietária, segundo esquemas conceituais também proprietários. Dois tipos diferentes de ferramentas para metadados podem ser encontrados atualmente no mercado, segundo [MAR00]: ferramenta de integração: é especializada em integrar várias fontes de metadados em um repositório central. Uma ferramenta de integração deve possuir um modelo de metadados que atenda tanto ao lado técnico como ao de negócio, e permita o acesso a qualquer fonte de dados, com pouca ou nenhuma alteração no modelo; e ferramenta de acesso: permite executar funções de acesso ao repositório. Utilizar a mesma ferramenta que os usuários do negócio utilizam para acessar o DW elimina a necessidade dos usuários aprenderem outra ferramenta e assegura que eles usarão o repositório de metadados. Ainda em [MAR00] pode-se encontrar um checklist que serve como um guia, para ajudar a avaliar e definir a ferramenta necessária para uma organização. Através desse checklist, pode-se determinar qual produto avaliado é mais adequado às prioridades e características de cada organização. Além disso, apresenta algumas ferramentas para metadados disponíveis no mercado, como pode ser visto na tabela 4. Observa-se que, mesmo sem o suporte de uma ferramenta, é fundamental a captura e documentação dos metadados em um ambiente DW. Aliás, o primeiro passo para selecionar uma ferramenta para repositório de metadados é exatamente determinar que metadados existem dentro da organização, os tipos de metadados que se necessita capturar e quais as fontes desses metadados. Somente após essas tarefas, pode-se determinar como o repositório será acessado e consultado, e como serão providas a segurança e a manutenção dele. 38

50 Tabela 4 Ferramentas para metadados Ferramenta de integração Ardent MetaStage (Informix) IBM Information Catalog Informatica MX2 Platinum repository (Computer Associates) Unisys Universal Repository Viasoft Rochade Ferramenta de acesso Brio Enterprise Business objects Cognos Impromptu and Powerplay Information Advantage Business Intelligence Microsoft OLAP Services ( Plato ) Microstrategy DSS Web and Server 39

51 3 REVISÃO BIBLIOGRÁFICA 3.1 INTRODUÇÃO Este capítulo apresenta e analisa alguns trabalhos relacionados ao processo de desenvolvimento de Data Warehouse, com o objetivo de guiar a definição de uma metodologia de desenvolvimento de DW que atenda às necessidades de corporações com o perfil já caracterizado no capítulo 1. Na seção 3.2 estão detalhadas algumas das principais metodologias de desenvolvimento para o ambiente DW encontradas na literatura. Ao final desta seção, será apresentada uma análise comparativa das metodologias identificadas, baseada nos critérios definidos na seção A seção 3.3 destina-se especificamente para a apresentação das abordagens relacionadas a gerenciamento de metadados no ambiente DW encontradas na literatura. Ao final desta seção, são trazidas as considerações sobre gerenciamento de metadados, de modo a selecionar as características mais adequadas a serem utilizadas como referencial no restante desta dissertação. Concluindo o capítulo, a seção 3.4 apresenta as conclusões sobre os trabalhos pesquisados. 3.2 METODOLOGIAS DE DESENVOLVIMENTO Todo projeto de desenvolvimento de sistemas possui um conjunto de tarefas e passos que são realizados desde o início do processo até a implementação das completas funcionalidades do sistema produzido. Um projeto de DW não é diferente de uma análise de sistema e planejamento de projeto. Portanto, na construção de um DW, é prudente 40

52 enfatizar o processo de desenvolvimento de DW. No entanto, em razão das diferenças entre os ambientes operacional e analítico, a metodologia para desenvolver sistemas OLTP não pode ser empregada diretamente no desenvolvimento de DW. Utilizar uma metodologia consistente, eficiente e comprovadamente testada é um dos principais fatores de sucesso de projetos de DW [GAR98] [KIM98a]. O desejo de atender a esta exigência levou vários estudiosos a definir metodologias de desenvolvimento de DW ou ciclo de vida de suporte à decisão, como alguns autores preferem chamar. Porém, a maioria das organizações necessita de uma metodologia adaptada às suas características e expectativas. A seguir, estão detalhadas as metodologias investigadas em [GAR98], [POE98], [KIM98a] e [PER00] A Proposta de GARDNER [GAR98] GARDNER [GAR98] propõe a utilização do modelo apresentado na figura 12, o qual, segundo ele, já foi devidamente testado e empregado com sucesso em várias oportunidades. Esta é a principal ênfase de [GAR98] para sua metodologia, pois ele defende a implementação com sucesso de um DW através de arquitetura e projeto comprovados. Acrescenta ainda que a construção de DW deve ser realizada por pessoal experiente no assunto, apontando que o fator inexperiência é uma das principais causas de falha em projetos de DW. Descoberta de requisitos do negócio Consultoria Desenvolvimento de modelos de descoberta de conhecimento Data mining e aplicações analíticas Revisão lógica da base de Descoberta de Informações Modelagem lógica de dd Projeto da arquitetura Solution Readiness Desenvolvimento de aplicações cliente/servidor Projeto físico da base de dados Transformação de dados Integrador de soluções Sistema de suporte ao empreendimento Revisão física da base de Ajuste/ Sintonia Capacidade de planejamento Gerenciamento (processos e operações) Auditoria Planejamento Projeto e implementação Uso, Suporte e Extensão Figura 12 Metodologia de [GAR98] 41

53 Em relação à arquitetura de dados de DW, limita-se a citar três tipos: centralizada, DM dependente e DM independente, não tecendo considerações sobre como decidir para a adoção de um ou outro tipo, apesar de destacar a importância da correta escolha da arquitetura de dados. Quanto à adoção de uma metodologia de desenvolvimento, [GAR98] descreve seu modelo, de forma resumida, em três fases genéricas, denominadas planejamento, projeto e implementação e uso, suporte e extensão. No entanto, pode-se observar várias etapas (modelagem lógica de dados, projeto da arquitetura, projeto físico da base de dados etc.), ilustradas na figura 12, que não estão detalhadas em seu trabalho. Na fase planejamento, os serviços de descoberta de informações provêem processos estruturados que identificam os problemas do negócio a serem resolvidos. Esses serviços podem ser independentes e realizados de forma concorrente. Cada área de planejamento representa um ponto de entrada na metodologia. A segunda fase, projeto e implementação, provê a análise do ambiente corrente da organização e tem a intenção de protegê-la da tentativa de implementar uma solução para a qual ela não esteja preparada ou que possa influenciar outras áreas funcionais dentro da organização que não foram incluídas no planejamento. O processo Solution Readiness, primeira etapa dessa fase, é um outro ponto de entrada e se inicia quando os desenvolvedores estão prontos para começar o primeiro projeto de construção do DW e a cada projeto adicional, à medida que o repositório cresce. Este processo investiga todos os elementos necessários para suportar a implementação, incluindo dados, tecnologia, funcionalidades, suporte e infra-estrutura. O plano de projeto de implementação deve ser ajustado, se necessário, com base nos resultados das avaliações. A última fase, uso, suporte e extensão, compreende um conjunto de atividades e processos que suportam a operação e a manutenção do DW. Esses processos têm os seguintes propósitos: suportar as atividades diárias de uso do DW, assegurando sua disponibilidade e contínuo desempenho; assistir e auxiliar a expansão do uso do DW e, portanto, do benefício da solução; expandir o sistema, possibilitando a inclusão de novas aplicações, usuários e dados, como também expandir o uso da solução através da educação dos usuários finais; e 42

54 ajudar a manter o sistema continuamente atualizado e em crescimento, de modo a melhorar o suporte à tomada de decisão. Sendo assim, permitir que as decisões sejam tomadas de uma maneira planejada e controlada, para dar valor à organização. Na conclusão da sua metodologia, [GAR98] acrescenta que a construção de um DW é um processo interativo, sendo importante a existência de vários pontos de entrada na metodologia. Esse autor enfatiza, como condição para aumentar as chances de sucesso do sistema, o fato de que a equipe deve trabalhar em colaboração com o departamento de Tecnologia da Informação (TI) e com os usuários do negócio, além de usar uma metodologia comprovadamente testada A Proposta de POE et al. [POE98] Em seu trabalho, POE et al. [POE98] utilizam a expressão ciclo de vida de suporte à decisão em vez de metodologia de desenvolvimento, deixando bem clara a importância de se estabelecer, antes da construção do DW, uma arquitetura de dados que realmente atenda às necessidades da corporação. Nesta abordagem, a infra-estrutura técnica necessária para atender ao DW (hardware, software, bancos de dados, ferramentas de conversão de dados, rede local, ferramentas de acesso aos dados etc.) depende da arquitetura de dados escolhida. Isto ressalta a relação íntima da arquitetura de dados com a infra-estrutura, bastante destacada em seu trabalho. [POE98] recomenda, chegando a citar como obrigatório, que a arquitetura de dados e a infra-estrutura técnica do DW tenham sido bem pensadas, talvez até definidas, antes de iniciar o desenvolvimento do projeto. As fases que compõem a metodologia de desenvolvimento, que [POE98] aborda de forma completa e bastante detalhada, estão apresentadas na figura 13 e detalhadas em Um projeto piloto, antes da criação de um completo DW, é recomendado em [POE98]. Segundo os autores, as vantagens advindas de um projeto piloto bem-sucedido são: manter os pés no chão ; ganhar experiência; evitar um possível insucesso no futuro; mostrar o valor de informações para suporte à decisão aos usuários; e provar a idéia aos dirigentes. Os detalhes sobre desenvolvimento de projeto piloto estão descritos em [POE98] recomenda que a equipe de desenvolvimento possua pelo menos um integrante, de preferência o gerente do projeto, com especialidade em desenvolvimento e 43

55 processamento de suporte à decisão. Um consultor especializado pode ser contratado para guiar e orientar o gerente do projeto. Planejamento Levantamento de requisitos e modelagem Projeto físico da base de dados e desenvolvimento Determinação e mapeamento das fontes de dados População do DW Automação dos processos de carga de dados Criação de conjunto inicial de relatórios Validação e teste de dados Treinamento Produção Figura 13 Metodologia de [POE98] Fases da Metodologia de [POE98] Planejamento Esta fase preocupa-se com: definição e/ou clarificação do escopo do projeto; criação de um plano de projeto; definição dos recursos técnicos necessários (internos e externos); definição dos participantes e responsabilidades; definição de tarefas e prazos de conclusão; definição de cronograma, incluindo o prazo final de entrega do projeto; e definição das responsabilidades finais do projeto. Outras considerações técnicas necessárias, as quais deverão fazer parte do plano de projeto, mas definidas nas fases posteriores, são: 44

56 estratégias de integração, arquivamento, reconsulta e atualização de dados; operação e agendamento de trabalhos; estratégia para gerenciamento de metadados; e procedimentos para o usuário final acessar os dados. Caso a infra-estrutura não esteja pronta, os seguintes itens deverão também fazer parte do planejamento: tecnologia LAN/WAN, plataforma selecionada, conectividade com a base de dados, base de dados e seus utilitários, estações de trabalho devidamente configuradas e ferramentas de acesso aos dados. Levantamento de requisitos e modelagem Esta fase preocupa-se com o entendimento das necessidades do negócio e dos requisitos de dados dos usuários do sistema, inclusive com a modelagem destes requisitos. [POE98] aconselha que se deve despender no máximo de quatro a seis semanas com esta fase. Caso não seja possível, deve-se revisar o projeto, ou dividi-lo em múltiplos projetos. A fase de levantamento de requisitos e modelagem será abordada a seguir em duas etapas distintas: Levantamento de requisitos Preocupa-se com o entendimento do negócio, exigências e necessidades dos usuários. São realizadas várias atividades (entrevistas, seções de facilitação, estudo de documentos e relatórios etc.), de maneira a identificar os seguintes pontos: entendimento de como o usuário realiza as atividades do negócio, quais os fatores que dirigem o negócio, de quais atributos o usuário necessita, quais os requeridos e quais os desejados; quais as hierarquias; quais dados os usuários utilizam e quais deveriam utilizar; qual o nível de detalhes que o usuário necessita; qual tipo de ferramenta de acesso aos dados o usuário utilizará; e como o usuário espera ver o resultado de suas consultas. [POE98] classifica os usuários que interagem com o DW em 5 níveis: usuário casual; novato; poderoso; analista de negócios; e desenvolvedor de aplicações. Enfatiza que cada um desses níveis de usuários pode ter diferentes requisitos de dados e geralmente 45

57 requerem diferentes métodos de acesso aos dados. Com isso, o uso e a necessidade de metadados diferem substancialmente para cada um desses níveis de usuários. Adicionalmente, detalha como proceder para realizar entrevistas com sucesso, apresentando um guia completo sobre quem entrevistar, o que perguntar aos usuários finais e executivos, documentar as entrevistas e considerar utilizar um facilitador, que é especialmente treinado para manter o grupo em alinhamento. Modelagem de dados Responsável por traduzir os conceitos do negócio em um modelo diagramático, para o escopo do projeto de desenvolvimento. Este modelo pode ser um modelo lógico de dados, que inclua relacionamentos, cardinalidade, atributos, definições e chaves candidatas. Pode ainda ser um modelo de negócio dimensional, que inclua fatos, dimensões, hierarquias, relacionamentos e chaves candidatas. [POE98] defende a idéia de que há necessidade de adequar a modelagem às condições locais da organização e seus negócios, de modo a se obter melhores resultados. Sendo assim, propõe a adoção de modelos e técnicas híbridas, além dos tradicionais esquemas estrela e floco de neve. Também, até a conclusão desta fase, a infra-estrutura técnica deve estar resolvida, pois pode interferir no tempo de desenvolvimento do DW. Projeto físico da base de dados Nesta fase são realizadas as seguintes tarefas: projeto da base de dados, incluindo tabelas fato, tabelas dimensão, relacionamento entre tabelas; desnormalização dos dados; identificação de chaves; criação de objetos apropriados na base de dados; e estratégias de criação de índices, agregação e particionamento. Para esta fase é imperativo que a equipe de desenvolvimento tenha treinamento e entenda de: conceitos de suporte à decisão; conceitos de hierarquia, dimensão, e fatos; conceitos de esquema estrela para projeto de banco de dados. Portanto, aconselha que se tenha um especialista em administração de banco de dados. 46

58 Determinação, integração e mapeamento das fontes de dados Esta é a fase que consome mais tempo de desenvolvimento, em virtude da necessidade de interação com os sistemas OLTP. Durante esta fase deve-se: identificar as possíveis fontes de dados e suas respectivas estruturas; executar a análise de dados para determinar as melhores fontes de dados e processos de integração necessários; desenvolver programas que permitam realizar as conversões de dados para cada campo e refinar a estratégia de integração; e mapear as fontes de dados para os objetos da base analítica. População do DW Nesta fase deve-se ter um cuidado especial no tratamento dos dados, localizando e tratando adequadamente os elementos de dados dos arquivos fontes, que muitas vezes contêm dados: sinônimos são elementos de dados que têm diferentes nomes, no entanto, têm o mesmo significado ou representam o mesmo fato do negócio; homônimos são elementos de dados que têm o mesmo nome, embora representem diferentes fatos do negócio; e análogos são elementos de dados que têm equivalentes significados e apresentam reais desafios na identificação. Normalmente aparecem como sinônimos, mas podem ter uma sombra de diferença no sentido. Essa diferença pode ser significativa para o entendimento do negócio sobre o dado. O tratamento indevido desses dados poderá produzir falta de credibilidade dos dados e, por conseguinte, um provável insucesso do projeto. As atividades desta fase são: desenvolvimento de programas ou utilização de ferramentas para extrair e mover os dados; desenvolvimento de estratégias e procedimentos de carga de dados dentro do DW; desenvolvimento de programas ou utilização de ferramentas de conversão de dados para integração dos dados; desenvolvimento de estratégias de re-consulta e atualização de dados; 47

59 execução de programas e procedimentos de extração, transformação e carga de dados; desenvolvimento e realização de processos de validação e teste dos dados extraídos, transformados e carregados no DW; e desenvolvimento de procedimentos que permitam o tratamento de exceções, geração de estatísticas e garantia da qualidade dos dados. Automação dos processos de carga de dados Automação e agendamento dos processos de extração, conversão e carga de dados; criação de procedimentos de backup e recovery; e realização de teste completo de todos os procedimentos automatizados. Criação do conjunto inicial de relatórios Criação de relatórios predefinidos; teste dos relatórios; documentação das aplicações; e desenvolvimento de estruturas de navegação dos relatórios. Validação e teste de dados Validação de dados, utilizando o conjunto inicial de relatórios; validação de dados, utilizando processos padronizados; e modificações iterativas dos dados. Treinamento Compreende as atividades de treinamento para atender especificamente aos usuários: treinamento sobre o escopo do DW; treinamento nas ferramentas de acesso aos dados e de como acessar e navegar através dos metadados, para conseguir as informações desejadas; treinamento em aplicações de suporte à decisão ou no conjunto de relatórios disponibilizados aos usuários finais; e contínuo treinamento e assistência aos usuários. 48

60 Produção Preocupa-se com as tarefas necessárias à disponibilização do DW e o correspondente suporte necessário aos usuários finais. Inclui: instalação de infra-estrutura física a todos os usuários; disponibilização de aplicações; criação de procedimentos para adicionar novos relatórios e expandir as aplicações; desenvolvimento de procedimentos de backup para as aplicações; e criação de procedimentos para investigar e resolver assuntos relacionados com a integridade de dados Projeto piloto [POE98] deixa claro que o projeto piloto de DW deve ser tratado como um projeto de desenvolvimento (alocação de recursos apropriados e de um gerente de projeto) e que os propósitos e objetivos devem estar bem-definidos. Portanto, embora não tenha especificado uma metodologia de desenvolvimento específica para o projeto piloto, supõe-se que devem ser utilizadas as mesmas atividades descritas nas fases de sua metodologia principal. Apresenta dois tipos distintos de construção de projeto piloto. Projeto piloto prova de concepção Destina-se a possibilitar aos administradores e decisores de mais alto nível uma visão de como o DW pode ser viável e valioso para a corporação. Neste tipo de projeto piloto, os usuários podem interagir com o sistema, obtendo algumas informações úteis para suporte à decisão, possibilitando entender como essas informações poderão ajudá-los. Não existe a necessidade de que todos os componentes técnicos e de infra-estrutura estejam disponíveis, podendo-se utilizar tecnologias com as quais os desenvolvedores, programadores e DBAs já estejam familiarizados. Dessa maneira, o projeto pode ser desenvolvido rapidamente, normalmente em poucas semanas, apoiando-se em um pequeno conjunto de dados. Os focos do projeto piloto prova de concepção devem ser os dados e a interação do usuário com as informações de suporte à decisão. Deve-se desenvolver um projeto de banco de dados simples e acessível, e despender tempo e atenção para ensinar os usuários 49

61 na navegação e capacidades dos dados de suporte à decisão; principalmente, deve-se prover pequeno treinamento no ambiente de suporte à decisão, trabalhar na construção de consultas predefinidas e encontrar ferramentas front end, com as quais eles estejam familiarizados. Projeto piloto arquitetura e infra-estrutura Também é utilizado um conjunto restrito de dados, como no projeto piloto prova de concepção, embora com dados mais abrangentes. No entanto, são executadas todas as fases da metodologia, permitindo entendê-las e ganhar experiência. Desta forma, pode-se verificar como todos os componentes do DW trabalham juntos. As diversas arquiteturas devem ser utilizadas e testadas, como também os componentes da infra-estrutura (comunicações, ferramentas de extração, transformação e carga de dados, estratégias de atualização de dados, software de consulta de dados etc.). Os principais objetivos deste tipo de projeto piloto são: entendimento da complexidade envolvida no desenvolvimento de DW; aquisição de experiência com novas ferramentas e tecnologias; aprendizagem sobre as diversas tarefas que compõem cada fase do desenvolvimento do DW; e aprendizagem sobre como atribuir tempos e prazos na execução das diversas tarefas. Em seu trabalho, [POE98] enumera um conjunto de atividades básicas que devem ser realizadas para a construção desse tipo de projeto piloto: escolha de uma área significativa dentro da corporação e definição do escopo adequado do protótipo; definição clara do objetivo do projeto piloto; definição de uma arquitetura de dados apropriada, que servirá como um mapa de alto nível a ser utilizado durante todo o desenvolvimento do projeto piloto; garantia de disponibilização da infra-estrutura necessária; definição clara da equipe de projeto, atribuindo a seus integrantes, responsabilidades e prazos para a realização das diversas tarefas (reunião de requisitos junto ao usuário final; projeto conceitual, lógico e físico; levantamento, 50

62 estudo e definição das fontes de dados a serem utilizadas no protótipo; realização de testes com os meios da infra-estrutura disponível; se for o caso, a definição de equipamentos a serem adquiridos; realização das atividades de mapeamento, extração, transformação e carga de dados; criação do conjunto inicial de relatórios etc.); disponibilizar treinamento para garantir que os membros da equipe de desenvolvimento do projeto e usuários entendam as diferenças entre as tecnologias que cercam os sistemas operacionais transacionais e os sistemas de suporte à decisão. Inclui prática com ferramentas de extração, transformação e carga de dados, teste de aplicativos, dentre outras; reunir recursos adequados como: contratar assessores, consultores, especialista em sistemas de apoio à decisão etc., quando não se tem este profissional na corporação. Segundo [POE98], no desenvolvimento do protótipo, não se deve prescindir de pessoas com experiência na construção de DW; e escolha das ferramentas de acesso aos dados, baseada nas necessidades e habilidades dos usuários finais. Deve-se ter a noção de que um projeto piloto normalmente é a base para o desenvolvimento de projetos futuros. Dessa forma, é conveniente que se construa uma base de dados, de modo que possa vir a ser utilizada como ponto de partida a um futuro desenvolvimento de DW, evitando o retrabalho. Os benefícios que um projeto piloto poderá trazer, segundo [POE98], independente de qual seja o tipo, são: um primeiro contato com o modelo dimensional de negócios; idéias de como projetar a base de dados analítica; entendimento de como mapear, extrair, transformar e carregar os dados; utilizar o projeto piloto como um protótipo de DW; os exemplos concretos de processamento analítico poderão servir como um meio inicial de reflexão para os usuários finais; e entendimento de como as ferramentas de acesso aos dados trabalham. 51

63 3.2.3 A Proposta de KIMBALL et al. [KIM98a] KIMBALL et al. [KIM98a], assim como em [POE98], também utiliza em seu trabalho a expressão ciclo de vida para DW no lugar de metodologia de desenvolvimento, abordando de forma completa e bastante detalhada todas as fases da metodologia (figura 14), descritas a seguir. Planejamento Definição de requisitos do negócio Projeto da arquitetura técnica Modelagem dimensional Seleção e instalação de produtos Projeto físico Projeto e desenvolvimento do Data Staging Disponibilização do DW Manutenção e crescimento Especificação de aplicações de usuário final Desenvolvimento de aplicações de usuário final Gerenciamento do projeto Figura 14 Metodologia de [KIM98a] Podem ser observadas duas considerações importantes: a existência temporal entre as fases apresentadas, ou seja, a fase de planejamento deve ser executada antes da fase definição de requisitos do negócio, e assim por diante; e a existência de fases que podem ser executadas de forma concorrente, como é o caso das fases projeto da arquitetura técnica e modelagem dimensional, assim como seleção e instalação de produtos e projeto físico Fases da Metodologia de [KIM98A] Planejamento O planejamento do DW é a primeira atividade crítica do DW e uma das mais importantes, pois [KIM98a] considera que a qualidade dos levantamentos e definições afetará o projeto como um todo. Por esse motivo, deve-se ser o mais criterioso possível nos diversos levantamentos, analisando e transformando as definições em um documento denominado plano de projeto, ou similar, que servirá como um mapa durante a execução do projeto. Não há uma receita de bolo ou linearidade para esta fase, uma vez que as 52

64 atividades de planejamento variam de uma corporação para outra. Resumidamente, as principais atividades que envolvem esta fase do projeto e seu gerenciamento são as seguintes: definição do projeto, através da verificação da real demanda por informações gerenciais e de onde ela está (chefias e lideranças influentes na organização desejosos pela implementação do DW, motivação para o projeto de DW, cultura organizacional, viabilidade técnica, parcerias entre usuários e o departamento de TI na organização etc.); definição do escopo inicial do projeto, baseado nos requisitos do negócio, o que é feito através de entrevistas com os usuários; levantamento dos fatores que permitem mensurar o sucesso, assim como dos riscos do projeto do DW; elaboração de justificativas para o projeto, devendo-se abordar o investimento financeiro e seus custos (hardware, software, manutenção etc.); e elaboração de um plano de projeto, a partir dos dados iniciais levantados. Este documento, além de registrar os dados já descritos nesta seção, deve conter, dentre outras informações, a identidade do projeto, a identificação da equipe (patrocinadores, gerente de projeto, analista de negócios, DBA, desenvolvedores de aplicações, arquiteto de dados etc.), assim como as respectivas tarefas, atribuições e prazos a serem cumpridos, estabelecimento de data de início do desenvolvimento do projeto, especificação do cronograma das diversas fases e atividades do DW. Definição de requisitos do negócio É abordada a importância de se entender com clareza o negócio do usuário final, suas particularidades, requisitos e exigências, cujos dados podem ser levantados através de entrevistas, seções de facilitação, análise de documentos e relatórios, auditoria nos dados internos e externos da corporação, ou ainda através de outros métodos quaisquer a serem conduzidos pela equipe de projeto. Nessa fase são realizadas as seguintes atividades: identificação e preparação da equipe de entrevistadores; preparação dos entrevistados (realização de encontro para o pontapé inicial); agendamento e realização das diversas entrevistas; 53

65 análise dos resultados de cada entrevista. É importante identificar, ao final das entrevistas, os possíveis fatores que permitem mensurar o sucesso do DM, em reunião realizada com a presença de todos os entrevistadores; revisão do escopo do projeto e priorização; e revisão do plano de projeto. Projeto da arquitetura técnica Nesta fase são realizadas duas atividades fundamentais: uma é o estabelecimento de uma estrutura arquitetural de alto nível, também referenciada como arquitetura funcional, onde são abordados os elementos fundamentais em um DW, tais como a área interna, área externa e seus serviços correspondentes (figura 11); e a outra consiste na especificação da infra-estrutura técnica e os respectivos componentes necessários para permitir a criação do DW. Ressalta, como [POE98] também ressalta, que os componentes e tecnologias da infraestrutura dependerão diretamente do projeto de arquitetura técnica adotado. As atividades que compreendem esta fase são as seguintes: especificação de um grupo responsável pela criação da arquitetura do DW; reunião e documentação dos requisitos técnicos, revisão do ambiente técnico corrente, criação de uma arquitetura técnica e determinação das etapas a serem cumpridas; criação de um plano de infra-estrutura, definindo hardware, software, servidores, rede de comunicações, estações de trabalho, dentre outras; aceitação do projeto pelo usuário final; e revisão do projeto. Seleção e instalação de produtos As atividades desta fase, que somente será executada após a criação do projeto de arquitetura técnica, são as seguintes: pesquisa de produtos candidatos; avaliação das funcionalidades dos produtos sob diversos pontos de vista, como, por exemplo: funcionalidades básicas (possibilita extração de dados de múltiplas plataformas e fontes de dados, provê compressão e descompressão de dados, suporta funções de transformação etc.); controle de trabalho (suporta agendamento 54

66 baseado em tempo e/ou evento, realiza monitoramento, suporta arquivamento e restauração de dados etc.); metadados e padrões (disponibiliza repositório aberto, suporta o emprego de metadados com produtos de terceiros etc.); itens específicos do vendedor (custo, suporte técnico, documentação, treinamento, consultoria etc.); desenvolvimento de protótipos pelos vendedores, em um ambiente devidamente controlado e parametrizado, de modo a permitir melhor avaliação das funcionalidades dos softwares pré-selecionados para aquisição; seleção das ferramentas e produtos mais adequados estabelecimento de contrato com vendedores; aceitação do projeto pelo usuário final; e revisão do projeto. Modelagem dimensional O objetivo desta fase é desenvolver um modelo dimensional adequado, baseado nos requisitos do negócio levantados na fase definição de requisitos do negócio. São realizadas as seguintes atividades: construção de uma matriz onde um dos lados representa todos os DMs possíveis de desenvolvimento e o outro lado todas as possíveis dimensões. A interseção dos dois lados possibilita a visualização das dimensões de determinada área de negócio (DM). Um dos objetivos dessa matriz é assegurar que o DW seja utilizável e extensível a todas as áreas da organização; definição do DM a ser desenvolvido e as correspondentes granularidades de dados, tabelas dimensão e seus atributos, tabelas fato e seus fatos, agregados etc.; revisão da modelagem dimensional com usuário final e aceitação do modelo de dados; revisão do projeto e recomendações quanto às ferramentas de usuário final à base de dados analítica; atualização do projeto lógico da base de dados analítica; revisão lógica do projeto da base de dados analítica; aceitação do projeto pelo usuário final; e revisão do projeto. 55

67 Durante esta fase, também é realizada a análise das diversas fontes de dados, de modo a identificar aquelas que possuem os dados necessários para atender ao modelo de dados, assim como procurar especificar, dentre estas, as melhores fontes de dados. Projeto físico definição de nomes padronizados para os objetos da base de dados; execução do projeto físico, criando os objetos da base de dados analítica; estimativa do tamanho da base de dados analítica; desenvolvimento de um plano inicial de indexação, agregação e particionamento; aceitação do projeto pelo usuário final; e revisão do projeto. Projeto e desenvolvimento do Data Staging Para [KIM98a], Data Staging é um processo maior que inclui, entre outros, ou seguintes subprocessos: extração, transformação, carga e indexação. A área Data Staging armazena os dados-fontes que foram limpos, transformados, combinados etc., para uso no DW. As atividades fundamentais desta fase são: criação de uma arquitetura de alto nível que represente o fluxo de dados dos sistemas-fonte para a base de dados analítica de destino; teste e escolha de ferramentas de terceiros ou desenvolvimento de programas específicos para a realização das atividades de organização de dados; detalhamento da arquitetura de alto nível, determinando, por exemplo, quais tabelas e em que ordens serão realizadas as atividades de extração, transformação e carga; quais as atividades de transformação que serão realizadas nas diversas tabelas etc.; realização do processo de organização de dados com uma dimensão e avaliação do resultado; definição e realização de modificações lógicas e atualização dos registros das dimensões, quando necessário. [KIM98a] propõe três técnicas básicas quando um registro da dimensão é atualizado: substituição pelo registro mais recente, criação de registro na dimensão ou, por último, criação de um campo na dimensão que 56

68 armazene somente o campo alterado, de forma que sejam armazenados os campos novos e antigos; realização do processo de organização de dados com as demais dimensões; realização do processo de organização de dados com a tabela fato; desenvolvimento de procedimentos que permitam a carga incremental de tabelas fato que sejam muito grandes, utilizando os recursos baseados em novas transações, logs de bancos de dados, replicação, realização de múltiplos passos de carga e execução paralela; carga de tabelas de agregados; operação e automação do processo de carga, podendo incluir atividades, tais como agendamento de trabalhos, monitoramento, geração de logs, manipulação de exceções e erros, notificação etc.; desenvolvimento e aplicação de procedimentos para assegurar a qualidade dos dados; desenvolvimento e realização de atividades de arquivamento, backup e recuperação de dados; aceitação do projeto pelo usuário final; e revisão do projeto. Especificações de aplicações de usuário final Nesta fase deve-se procurar identificar as áreas prioritárias e, a partir destas, definir um conjunto padronizado de aplicações destinadas aos usuários finais. As atividades desta fase são as seguintes: priorização e identificação dos relatórios candidatos, desenvolvimento de uma estrutura geral de acesso aos diversos relatórios de forma estruturada (menu de relatórios) e determinação de estruturas padronizadas de relatórios; revisão das estruturas padronizadas e documentação; aceitação do projeto pelo usuário final; revisão do projeto. 57

69 Desenvolvimento de aplicações de usuário final De acordo com os levantamentos realizados na fase anterior, são desenvolvidas as aplicações necessárias. As atividades que compreendem esta fase são: seleção do ambiente de desenvolvimento dos relatórios (baseado na WEB, na utilização direta de ferramentas, na utilização de interface desenvolvida pela equipe de DW etc.); revisão e desenvolvimento de aplicações padronizadas, verificação da precisão dos dados, desenvolvimento de estruturas de navegação e documentação das aplicações de usuário final; desenvolvimento de procedimentos de manutenção e atualização das aplicações de usuário final; aceitação do projeto pelo usuário final; revisão do projeto. Disponibilização do DW Esta fase é composta basicamente pelas seguintes atividades: pano de disponibilização do DW (plano de verificação da infra-estrutura, estratégia de treinamento dos usuários finais, estratégia de suporte ao usuário final, plano de atualização de versão do DW etc.); teste completo do sistema (executar um teste completo, executar aplicações de usuários finais, rever todos os processos, etc.); disponibilização do DW propriamente dito (disponibilizar o DW aos usuários finais, configurar e testar a infra-estrutura, configurar privilégios de segurança etc.); aceitação do projeto pelo usuário final; revisão do projeto. Manutenção e crescimento do DW Esta fase é composta basicamente pelas seguintes atividades: contínuo suporte e treinamento dos usuários e manutenção da infra-estrutura técnica; 58

70 monitoramento de consultas realizadas pelos usuários finais, do desempenho da organização de dados e do contínuo sucesso do DW; comunicação e publicidade dos sucessos obtidos em razão do uso do DW; aceitação do projeto pelo usuário final; e revisão do projeto A Proposta de PEREIRA [PER00] Dois problemas relevantes foram detectados por PEREIRA [PER00] em várias organizações: necessidade imediata da inserção da tecnologia de DM/DW para ajudar aos administradores em suas tomadas de decisão; e necessidade dos projetos de DM/DW serem conduzidos e executados por equipe integrante destas corporações, devidamente capacitada tecnicamente, mas inexperiente na construção de DM/DW. Para resolver esses problemas, [PER00] desenvolveu uma metodologia de desenvolvimento de um projeto piloto de DM/DW, adaptada dos trabalhos de [POE98] e [KIM98a], principalmente utilizando a idéia de [POE98] para a construção de um projeto piloto de arquitetura e infra-estrutura, visando principalmente ao ganho de experiência na tecnologia de DM/DW, para evitar um possível insucesso. [PER00] definiu sua metodologia considerando quatro requisitos mínimos que uma metodologia de desenvolvimento de DM/DW deve satisfazer: completude deve ser completa, cobrindo o projeto desde a fase inicial até a sua conclusão; detalhamento todas as fases devem ser bem detalhadas, fazendo que todas as atividades requeridas sejam realizadas com facilidade; inexperiência possuir características especiais que permitam que o desenvolvimento possa ser conduzido por pessoal que não tem experiência prática em desenvolvimento de DW; 59

71 experimentação e teste de tecnologias possuir uma fase especial que possibilite a experimentação e teste de tecnologias, metodologias, arquiteturas, infra-estrutura etc. O ciclo de vida da metodologia de [PER00] é dividido em três partes principais, conforme ilustradas na figura 15 e detalhadas a seguir. Experimentação Definição Execução Levantamento Preliminar Planejamento Preliminar Levantamento Detalhado Protótipo Definições do Projeto e atualização do planejamento do projeto piloto Projeto piloto de DM/DW propriamente dito Gerenciamento do projeto piloto DM/DW Figura 15 Metodologia de [PER00] Etapas da Metodologia de [PER00] Experimentação Esta etapa é o ponto central e mais importante da metodologia, destacando-se principalmente a fase protótipo. O grande objetivo desta etapa é permitir que, ao seu final, a equipe de desenvolvimento tenha adquirido bastante conhecimento e habilidades técnicas que seja possível concluir sobre o conjunto de tecnologias que apresentam o melhor custo/benefício para a corporação e que efetivamente será utilizado na construção do projeto piloto, baseado na experiência adquirida. Serão detalhadas a seguir as quatro fases que compõem esta etapa. Levantamento preliminar Destina-se a coletar o máximo de dados possíveis do ambiente de desenvolvimento, de forma que os resultados obtidos sirvam como entrada para a próxima fase e também para outras fases. Esta é subdividida em seis módulos independentes e os dados podem ser coletados de forma concorrente: ambiente e influência organizacional: reunir os fatores humanos relacionados com o ambiente organizacional, tais como o interesse e expectativas de gerentes e 60

72 administradores com o projeto, a influência organizacional do patrocinador do projeto, capacidade e disposição de investimento etc.; reunião de requisitos: compreender e coletar os requisitos do negócio (estimativa de custos, serviços, hardware, software, ferramentas, corpo de funcionários, área de negócio e escopo do DM); projeto da base de dados: definir o que e quais os requisitos do negócio serão traduzidos em objetos físicos do banco de dados (tabelas fato e dimensão, granularidade, agregações, etc.) e quem irá executar tais atividades; fontes de dados: determinar as possíveis fontes de dados, a sua localização (interna, externa), as plataformas em que se situam e a estrutura dos arquivos, de modo que seja possível realizar as atividades de extração, transformação e carga de dados no DM; apresentação de dados: levantar os detalhes referentes à apresentação dos dados aos usuários decisores, assim como as ferramentas e/ou programas necessários (relatórios pré-formatados e ad hoc, interfaces etc.); e administração e suporte: levantar as atividades de administração e suporte ao projeto, antes, durante, e após o seu desenvolvimento. Planejamento preliminar Nesta fase, os dados e informações obtidos na fase anterior são consolidados em um documento chamado Plano de Projeto, o qual guiará o projeto piloto como um todo. O Plano de Projeto é estruturado de acordo com os tópicos da fase levantamento preliminar, contendo ainda outros itens importantes, tais como: nome do projeto e seus possíveis escopos, análise de viabilidade do projeto, critério de sucesso, estudo dos riscos, cronograma etc. O Plano de projeto deve ser submetido ao patrocinador do projeto, à direção e aos usuários, para uma análise minuciosa de todos os tópicos, particularidades e atividades. Ao fim desta análise, o Plano de Projeto pode ser aprovado, receber adaptações e ajustes, ou até mesmo ser recusado, encerrando o seu desenvolvimento. Levantamento detalhado As atividades realizadas na fase de levantamento preliminar são aprofundadas e é também o momento para atualizar o Plano de Projeto em questões como: constituição da equipe de desenvolvimento, revisão e atualização de cronogramas, arquiteturas de dados, 61

73 arquiteturas funcionais e estratégia de aplicações de suas atividades e processos, possíveis infra-estrutura e técnicas de modelagem dimensional que poderão ser adotadas, revisão e definição de detalhes sobre o projeto de banco de dados etc. O resultado desta fase estabelece as bases para todas as demais no projeto. Conseqüentemente, a qualidade do sistema depende fortemente de todos estes detalhes e da precisão dos levantamentos realizados nesta fase. Protótipo Esta é a principal fase da etapa experimentação, ilustrada na figura 16, e a que permite o desenvolvimento de um DM/DW por profissionais inexperientes nesta área, proporcionando a realização de variados testes e experimentações em tecnologias, arquiteturas, produtos etc., até se chegar ao conjunto de tecnologias que melhor atenderá ao projeto piloto. Fase Levantamento detalhado P l a n e j a m e n t o Arquitetura de dados Arquitetura funcional Infra-estrutura Modelagem dimensional Teste de produtos Projeto BD Execução arquitetura funcional Aplicações de usuário final Auditoria nos dados Uso, suporte e extensão Ajuste BD Revisão lógica BD Revisão física BD Suporte Uso Extensão Etapa Definições Gerenciamento do protótipo Figura 16 Fase protótipo da metodologia de [PER00] O objetivo desta fase é o mesmo do projeto piloto do tipo arquitetura e infraestrutura [POE98], que é estabelecer corretamente a arquitetura e infra-estrutura, convenientes à construção do DW, para evitar insucesso no seu desenvolvimento e uso. [PER00] acrescentou à metodologia de [POE98] a discriminação de um ciclo de vida completo e detalhado, provendo guias precisos para os testes. Sendo assim, esta fase recebe os dados e definições, provenientes da fase levantamento detalhado, testa as diversas possibilidades tecnológicas e entrega os resultados à etapa seguinte. Os módulos desta fase (figura 16) podem ser executados tantas vezes quantas forem necessárias, dentro das disponibilidades de tempo, pessoal, prazos, ferramentas etc. Isto 62

74 permite várias experimentações e testes de tecnologias, arquiteturas, ferramentas etc., possibilitando o ganho de experiência e a eliminação das incertezas. A seguir descreve-se sucintamente cada módulos desta fase. Planejamento: neste módulo é realizado o planejamento sumário das diversas atividades a serem realizadas para cada protótipo, devendo conter a definição clara do objetivo, a equipe e suas tarefas correspondentes, responsabilidades e prazos, definição da área de negócio e definição dos relatórios prioritários e candidatos, inclusive sua estrutura e apresentação. Arquitetura de dados: destina-se basicamente à escolha da arquitetura que servirá como um mapa, através do qual é possível entender como os dados se organizam no protótipo ( centralizada, DM dependentes, DM independentes ). Arquitetura funcional: consiste na definição do plano geral do que se deseja do DW quando ele estiver completamente concluído. Esse plano descreve o fluxo de dados dos sistemas-fonte até os usuários, representando os principais elementos do DW (sistemas-fonte, área de organização de dados, servidor de organização, usuários etc.), o fluxo de dados e os serviços correspondentes (extração, transformação, carga de dados etc.). Infra-estrutura: destina-se à especificação dos recursos tecnológicos necessários para atender à arquitetura funcional escolhida (hardware, software, rede de comunicações, assessoria, treinamento etc.). Cabe notar que a definição da arquitetura funcional tem forte influência na escolha dos recursos técnicos e viceversa. Teste de produtos: envolve os testes de aplicativos e ferramentas que serão utilizados no protótipo, de modo a aprender detalhes quanto ao uso, identificar funcionalidades e verificar desempenho (tempo de recuperação de informações, de extração de dados, de transformação etc.). Observa-se, pela figura 16, que existe uma seta permitindo que o módulo possa ser executado várias vezes, mostrando que é possível testar diversas ferramentas sob as mesmas condições de ambiente (mesma arquitetura de dados, infra-estrutura etc.) ou trocar os ambientes para testar o desempenho de um mesmo produto sob diferentes situações. No final deste módulo, pode-se concluir se os produtos disponíveis e testados serão suficientes para atender às diversas atividades de desenvolvimento, tais como mapeamento, 63

75 extração, transformação, carga etc. Em caso negativo, deve-se especificar quais programas deverão ser implementados e os detalhes correspondentes (linguagem de programação, equipe de desenvolvimento, prazos etc.). Modelagem dimensional: neste módulo a equipe de projeto deverá escolher uma estrutura multidimensional ( estrela, floco de neve, ou uma de suas variações) e implementá-la, considerando os requisitos da área de negócio selecionada. Projeto da base de dados: cerca todas as atividades requeridas para preparar a base de dados analítica para receber os dados do protótipo, tais como a estimativa do tamanho da BD, criação de arquivos e estruturas físicas de acordo com o banco de dados adotado, particionamento físico do BD, proteção dos dados (backup e recovery), segurança dos dados, criação de índices, dentre outras. Execução da arquitetura funcional: tem por finalidade realizar atividades para atender às especificações resultantes do módulo arquitetura funcional. Neste módulo, os dados são mapeados das fontes de dados, extraídos, transformados e carregados na base de dados analítica do protótipo. Utilizam-se as ferramentas de terceiros, testadas e aprovadas no módulo teste de produtos, ou os programas desenvolvidos a partir de especificações levantadas, também no módulo teste de produtos. Aplicações de usuários finais: destina-se à construção do conjunto inicial de relatórios necessários para atender aos usuários em suas atividades de tomada de decisão, a partir de especificações originárias do módulo planejamento do protótipo. Auditoria nos dados: a finalidade deste módulo é verificar e garantir a qualidade dos dados armazenados na base de dados analítica, através de atividades como: validação de dados, utilizando-se o conjunto inicial de relatórios; desenvolvimento de procedimentos para verificar a correção dos processos de extração, transformação e carga dos dados; análise dos arquivos de log; dentre outras. Uso, suporte e extensão: tem a finalidade de suportar as atividades diárias de uso do protótipo, assegurando a sua disponibilidade e contínuo desempenho; assistir e auxiliar na expansão do seu uso, podendo incluir novas aplicações, usuários e dados; e ajudar a manter o sistema continuamente atualizado e em crescimento, de modo a permitir melhor suporte na tomada de decisões. 64

76 Gerenciamento do protótipo: consiste no acompanhamento rigoroso das atividades previstas no planejamento do protótipo de modo a assegurar o seu cumprimento integral, evitando a perda de rumo na execução do projeto Definições Esta etapa é composta por uma simples fase denominada Definições do projeto e atualização do planejamento do projeto piloto e destina-se a transformar os resultados e os aprendizados obtidos nas etapas anteriores em mais definições precisas para guiar a construção do projeto piloto até a sua conclusão. As definições adotadas nesta etapa atualizam o documento plano de projeto e envolvem várias atividades de revisão, tais como: confirmação da equipe de desenvolvimento e as correspondentes tarefas, responsabilidades e prazos; cronograma; investimento financeiro; dentre outras. Ao final desta etapa, todas as definições necessárias à construção do DM/DW deverão estar concluídas (arquitetura de dados e funcional, infra-estrutura, as tabelas de fato e dimensões, granularidade dos dados, uso de agregado, detalhes do banco de dados, aplicações dos usuários, estrutura de navegação etc.) Execução Esta etapa é dedicada ao efetivo desenvolvimento do projeto piloto de DM/DW, a partir dos resultados obtidos nas etapas anteriores. Sua única fase denomina-se Projeto piloto de DM/DW propriamente dito. Os módulos desta fase são similares aos da fase protótipo, sendo que alguns módulos (arquitetura funcional e teste de produtos), decididos na etapa definições foram eliminados. Novas questões podem ser consideradas, principalmente o grande volume de dados e o aumento na complexidade dos processos da aplicação. No entanto, a maioria das dificuldades e incertezas já foi eliminada através do desenvolvimento repetitivo do protótipo e na revisão do planejamento Ciclo de desenvolvimento Para atender aos requisitos inexperiência e experimentação, [PER00] baseou sua metodologia no paradigma do modelo espiral da engenharia de software [PRE97]. Nesta metodologia, existem quatro ciclos lógicos de teste e experimentações, como ilustrado na figura 17: 65

77 Projeto piloto: o projeto piloto como um todo (figura 15) pode se desenvolver como um completo DM/DW. Ao seu final, poderá receber ajustes, ser executado outras vezes, ou ser abortado, no caso da corporação considerar que a conclusão do projeto não é viável. Etapa experimentação : a cada desenvolvimento de um projeto piloto, poderá ser executada uma ou mais etapas experimentação (figura 15 e figura 16), de acordo com a disponibilidade de pessoal, tempo e outros recursos. Fase protótipo : esta fase (figura 15 e figura 16) permite que a cada execução de um projeto piloto, durante a etapa experimentação, a equipe de desenvolvimento teste as diversas possibilidades tecnológicas, verificando as mais adequadas à corporação. Módulo teste de produtos : cada execução da fase protótipo pode disparar a execução do módulo teste de produtos (figura 16), uma ou mais vezes. Vale ressaltar que, para cada execução deste módulo, podem ser testados vários aplicativos e ferramentas, de modo a identificar as suas funcionalidades, aprender detalhes quanto ao uso e verificar desempenho. Projeto piloto Etapa experimentação Fase protótipo Módulo teste de produtos Figura 17 Ciclo de teste e experimentação [PER00] Análise Comparativa das Metodologias Pesquisadas Percebe-se que muito trabalho já foi feito relativamente a definição de metodologias de desenvolvimento de DW. Porém, as metodologias são normalmente dirigidas para ambientes genéricos, não atendendo, desta forma, às organizações que necessitam de uma metodologia adaptada às suas características e expectativas. Nesta seção, será feita uma análise comparativa entre as quatro metodologias de desenvolvimento de DW investigadas neste trabalho. Esta análise está baseada em seis 66

78 critérios distintos, identificados como fundamentais e que devem estar presentes em uma metodologia, direcionada ao ambiente organizacional com o perfil já caracterizado neste trabalho, como é o caso da SEFIN Critérios identificados Abordagem Evolucionária e Incremental Um processo de desenvolvimento interativo e incremental permite que o projeto seja desenvolvido e implementado em partes [FOW00]. Utilizar essa abordagem evolucionaria permitirá que o DW seja projetado e carregado passo a passo. Existem algumas opções: (1) iniciar o processo a partir de uma área específica da empresa, normalmente uma área carente e cujo trabalho seja relevante para os negócios da empresa; (2) selecionar um grupo de usuários e construir um pequeno protótipo do DW, deixando que os usuários experimentem com pequenas amostras de dados; (3) utilizar as opções (1) e (2). A utilização dessas opções permitirá que a solução de DW seja flexível e que ajustes possam ser feitos desde o início do processo. Isto é necessário porque com DW é sempre preciso pensar à frente, adaptando-se às mudanças naturais que ocorrem no ambiente; mudanças de que os usuários precisam, mudanças nas condições do negócio, mudanças naturais dos dados, e ainda do ambiente técnico, que está em constante evolução. Portanto, utilizando-se esta abordagem, o DW estará sempre pronto para aumentar sua capacidade, seja pela necessidade dos usuários, crescimento dos dados armazenados, ou quando forem incrementados novos usuários ou aplicações. Em resumo, o ambiente DW terá flexibilidade para adaptar-se às mudanças, que, sabemos, sempre estarão acontecendo, embora não saibamos que mudanças serão Formação da Equipe de Desenvolvimento A atividade de desenvolver software depende de pessoas, que têm funções e características diversas. Normalmente, a equipe de desenvolvimento é formada pelo time de projeto e o time de usuários. Uma equipe de desenvolvimento, para qualquer projeto de software, segundo [PRE97], deve ser formada por bons profissionais. Vários autores [DYC98], [GAR98], 67

79 [KIM98] e [POE98] defendem a idéia de que a construção de DW seja realizada por equipe de projeto constituído por profissionais experientes no assunto. No entanto, algumas organizações dispõem, internamente, apenas de bons profissionais, qualificados tecnicamente em desenvolvimento de sistemas em geral e tecnologia de banco de dados, dentre outras, contudo sem possuir a correspondente experiência no desenvolvimento de DW. Também, principalmente em organizações públicas, existe dificuldade para contratação de equipes externas especializadas, em virtude de fatores como legislação, recursos financeiros, sigilo dos dados, prazos, dentre outros. É importante que uma metodologia de desenvolvimento de DW possa atenuar esses problemas, permitindo que a construção de DW possa ser desenvolvida por equipe interna da organização, sem dificuldades. Quanto ao time de usuários, observa-se cada vez mais a participação destes no processo de desenvolvimento de software. Este assunto, segundo publicação do IEEE Software, de janeiro de 2000, é uma das melhores influências em engenharia de software para os próximos 50 anos. Em todo o processo de desenvolvimento de software, o ponto inicial e o ponto final coincidem com os usuários. No início do desenvolvimento, identificam-se suas necessidades, constroem-se os produtos e os disponibiliza, com interfaces fáceis de usar. Em DW, além disto, até o modelo de dados construído (estrutura de cubo de dados ) é simples e pode facilmente ser entendido pelo usuário final. Portanto, é importante melhorar e estimular a sua participação e o seu envolvimento, em todo o processo. Usuários que nunca tiveram oportunidade de trabalhar com uma nova tecnologia não sabem exatamente o que perguntar ou questionar. Principalmente no ambiente DW, os usuários não saberão que pedidos poderão fazer ao sistema até que eles realmente trabalhem com o mesmo. Existem diversos tipos de usuários que irão interagir com o DW. Desenvolvedores de aplicações, executivos e analistas de negócio, são alguns exemplos. Cada um desses usuários pode ter diferentes necessidades e geralmente requerem diferentes métodos de acesso aos dados. Mesmo para um tipo específico de usuário, existem diferentes perfis. Para executivos, por exemplo, pode haver alguns experientes no uso de planilhas eletrônicas, outros com experiência limitada, e outros, ainda, nenhuma experiência. Portanto, o uso e a necessidade de metadados difere para cada um desses tipos de usuários e difere, também, quanto ao perfil de cada um. Considerar a participação de usuários, como membros do time de projeto, facilitará a criação de metadados de negócio e poderá ajudar a 68

80 superar a resistência política dentro da organização, juntamente com o patrocinador do projeto. Utilizar a estratégia de envolver o usuário em todo o processo de desenvolvimento permitirá que o DW seja realmente construído para resolver problemas específicos do negócio e não para exibir as maravilhas da tecnologia. Também, pode-se esperar que os usuários realmente utilizem o sistema, pois este é um dos principais fatores de sucesso de um projeto Definição dos Produtos Resultantes do Processo de Desenvolvimento O desenvolvimento de um projeto de DW envolve várias tecnologias, tanto de hardware como de software, como visto no capítulo 2. Antes de definir uma metodologia, adequada ao ambiente onde o projeto de DW será implementado, é necessário definir os produtos resultantes das fases da metodologia de desenvolvimento que será adotada e que serão partes integrantes do ambiente DW. Como exemplo desses produtos, é válido citar: arquitetura de dados, arquitetura funcional, infra-estrutura técnica, esquemas dimensionais, projeto da base de dados, metadados, aplicações de usuário final, aplicações para extração de dados, dentre outros. A identificação dos produtos necessários ao ambiente DW permite a definição de algumas tarefas e atividades, e ambos integram a estrutura da metodologia como um todo. Várias metodologias estudadas destacam fases exclusivas, especialmente definidas e muitas vezes com a mesma denominação, para determinados produtos. Constata-se, pois, uma estreita ligação entre a definição das fases da metodologia e os produtos integrantes do ambiente DW Detalhamento das Fases Além da definição de produtos do ambiente DW, é necessário que a metodologia seja bem detalhada, definindo todas as fases, componentes e atividades, que serão executadas desde o início do projeto até a sua conclusão. Neste momento, é oportuno lembrar um dos principais aspectos abordado como problema neste trabalho, que é falta de equipe experiente, no quadro da organização, para inserir a tecnologia de DW. Portanto, este critério mostra-se como um dos mais importantes a ser considerado, pois facilitará a execução das diversas fases e atividades da metodologia proposta, até a construção do 69

81 completo DW. Também é importante a definição de uma fase que possibilite a manutenção e o crescimento do DW. Um plano de projeto, outro componente importante no desenvolvimento de DW, citado por vários autores, orientará os desenvolvedores quanto às tarefas críticas que devem ser executadas e quando cada tarefa deve ser iniciada e completada. Identifica ainda quem deve executar cada tarefa e descreve o que será disponibilizado em cada atividade. Conforme escreveu-se, não existe uma metodologia formal que possa ser aplicada indiscriminadamente a qualquer organização. Mesmo em organizações do mesmo nicho de negócio existem particularidades e características específicas próprias. Portanto, é normal que adaptações sejam feitas, mesmo em metodologias já comprovadamente testadas Projeto piloto Em razão da complexidade da tecnologia de DW, como também pela utilização de qualquer nova tecnologia, a maioria dos autores indica a escolha de uma área específica mais apropriada para um piloto inicial. Um projeto piloto normalmente é a base para o desenvolvimento de projetos futuros, antes da criação de um completo DW. Dessa forma, é conveniente que se construa uma base de dados real, de modo que possa vir a ser utilizada como ponto de partida ao futuro desenvolvimento de DM e DW corporativo, evitando o re-trabalho. Este critério está sendo considerado, juntamente com o critério detalhamento das fases, como uma solução casada para o problema inexperiência. Podem ser feitos mais de um projeto piloto, com finalidades distintas, tais como verificar como todos os componentes do DM/DW trabalham juntos, ganhar experiência, avaliar a viabilidade e o provável custo/benefício, dentre outras Criação e Gerenciamento de Metadados Os metadados, elemento essencial do ambiente DW, são raramente determinados de uma só vez. A existência de metadados é percebida desde o inicio do projeto de desenvolvimento e perdura por toda a vida útil do DW. Desta forma, a coleção de metadados em um projeto DW assume uma forma incremental e, como conseqüência, o volume de metadados é imenso. Também existem diferentes tipos, fontes e usuários de metadados. Por essas razões, como também pelas mudanças introduzidas em virtude da utilização de uma metodologia iterativa e incremental, mudanças nos negócios da empresa, 70

82 evolução por motivo de utilização e ao mesmo por tempo erros, entre outras, uma estratégia para criação e gerenciamento de metadados deve ser considerada em projetos DW. Projetos de DW devem, portanto, adotar uma metodologia de desenvolvimento de DW que considere a criação e o gerenciamento de metadados como partes integrantes de todo o processo de desenvolvimento e produção do DW. Definição de tarefas, tempo e recursos técnicos devem ser especificamente definidos para atender a esta característica Análises das metodologias investigadas em face dos critérios identificados Tabela 5 Comparativo das metodologias de desenvolvimento de DM/DW investigadas Critérios [GAR98] [POE98] [KIM98a] [PER00] Abordagem evolucionária e incremental Formação da equipe de desenvolvimento Produtos resultantes do processo de desenvolvimento Sim Sim Não Sim Equipe experiente e usuários do negócio - Arquitetura de dados - Projeto da base de dados - Metadados Equipe experiente e usuário facilitador - Arquitetura de dados - Arquitetura funcional - Infra-estrutura técnica - Esquemas dimensionais - Projeto da base de dados - Aplicações de usuário final - Metadados Equipe experiente - Arquitetura de dados - Arquitetura funcional - Infra-estrutura técnica - Esquemas dimensionais - Projeto da base de dados - Aplicações de usuário final - Metadados Equipe inexperiente - Arquitetura de dados - Arquitetura funcional - Infra-estrutura técnica - Esquemas dimensionais - Projeto da base de dados - Aplicações de usuário final Detalhamento das fases Pouco detalhado Detalhado Bem detalhado Bem detalhado Projeto piloto Criação e gerenciamento de metadados Não Pouco detalhado "prova de concepção" e "arquitetura e infraestrutura", antes do desenvolvimento do DW Detalhado, mas não integra à metodologia "prova de concepção", na fase de "Seleção e instalação de produtos" Detalhado, mas não integra à metodologia "arquitetura e infraestrutura", na fase "experimentação" Não detalhado A tabela 5 apresenta, de forma resumida e comparativa, as metodologias estudadas e os critérios de análise considerados. Confirma-se que nenhuma metodologia estudada poderá ser adotada integralmente, considerando o contexto deste trabalho, principalmente em razão do critério criação e gerenciamento de metadados. Apresenta-se, a seguir, uma análise detalhada de cada trabalho pesquisado em face dos critérios destacados. A análise sobre criação e gerenciamento de metadados será mais bem detalhada na seção Abordagem Evolucionária e Incremental Quanto a esta característica, observou-se o seguinte: 71

83 [GAR98] permite vários pontos de entrada em sua metodologia, enfatizando a sua iteratividade. No entanto, conclui-se que estes pontos de entrada sejam utilizados para o crescimento normal do DW, principalmente em virtude do fato de que não recomenda o desenvolvimento por equipe inexperiente, chegando inclusive a argumentar ser esta uma das principais causas de falhas em projetos de DW; [KIM98a] não comenta em seu trabalho sobre começar pequeno. No entanto, define sua metodologia baseada em uma estrutura, que guia o projeto em fases separadas. Ao final de cada fase, recomenda uma atividade para revisão do projeto; [POE98] recomenda o desenvolvimento através de uma metodologia iterativa. As fases do ciclo de vida da metodologia seriam executadas, na sua totalidade, várias vezes. Cada novo projeto seria construído sobre seu predecessor, através de refinamentos sucessivos. A intenção é permitir que o usuário possa descobrir novos requisitos, usando o ambiente; [PER00] propõe uma metodologia completa para a construção de um projeto piloto de DM/DW, baseada no paradigma do modelo espiral da engenharia de software. O ciclo de testes e experimentações (figura 17) destina-se a ajudar no desenvolvimento de projetos por equipe inexperiente em DW Formação da Equipe de Desenvolvimento Somente em [PER00] encontra-se uma metodologia direcionada a equipes inexperientes no desenvolvimento de DM/DW. Os demais autores insistem em que a equipe seja formada por pessoal experiente. Quanto à participação dos usuários na equipe de desenvolvimento, observa-se o seguinte: [GAR98] cita que a falta de sociedade entre o departamento de TI e os usuários do negócio é uma das cinco principais razões de falhas em projeto de DW. No entanto, não tece comentários sobre como esta sociedade deveria se formar; [POE98] propõe a figura do facilitador, que é uma pessoa especificamente treinada para manter o grupo em alinhamento, recomendando utilizá-lo até a fase planejamento. Caracteriza de forma explícita o perfil dos usuários final e a estreita relação destes com o desenvolvimento de DW. No entanto, limita-se a envolver o usuário somente até o momento de entender sua necessidade; 72

84 [KIM98a], ao final de cada fase de sua metodologia, especifica uma atividade que ele nomeia de aceitação do projeto pelo usuário final. É de se supor que existam usuários integrados à equipe de desenvolvimento, no mínimo destacados temporariamente para essa atividade; [PER00] não se propõem envolver os usuários diretamente no desenvolvimento do projeto. Limita-se a submeter o plano de projeto para aprovação pelos usuários, antes de iniciar a fase protótipo Definição dos Produtos Resultantes do Processo de Desenvolvimento Comparando o trabalho de cada autor, observou-se que: [GAR98] possui o trabalho menos completo, apresentando apenas breve referência quanto a arquitetura de dados, projeto da base de dados e metadados; o trabalho de [POE98] e [KIM98a] são os mais completos. Detalham cada componente e integra-os coerentemente em suas metodologias. [POE98] apresenta algumas contribuições adicionais: estabelece e comprova a ligação íntima entre a arquitetura de dados e a infra-estrutura técnica; apresenta variações de modelos dimensionais, além dos tradicionais estrela e floco de neve ; categoriza os usuários que interagem com o DW (usuários casuais, novatos, poderosos etc.). Ambos abordam a importância dos metadados no processo de desenvolvimento; a metodologia de [PER00] utiliza os trabalhos de [POE98] e [KIM98a] como referência conceitual. Dessa forma, seu trabalho também é bastante completo quanto a este critério. No entanto, não faz referência aos metadados Detalhamento das Fases [GAR98] (figura 12) divide seu trabalho em três grandes fases ( planejamento, projeto e desenvolvimento e uso, suporte e extensão ), detalhando pouco os diversos módulos; o trabalho de [POE98] (figura 13) é bem detalhado quanto às diversas fases que compõem sua metodologia. No entanto, existe carência quanto ao detalhamento da composição de algumas fases, como por exemplo, a de Projeto físico da base de dados e desenvolvimento ; 73

85 no trabalho de [KIM98a] (figura 14), observa-se que as diversas fases estão bem detalhadas. Existe também coerência entre as atividades que devem ser desenvolvidas em cada fase e as funcionalidades dos componentes; [PER00], que desenvolveu seu trabalho (figura 15) baseado principalmente em [POE98] e [KIM98a], apresenta detalhes e coerência entre as fases e atividades que compõem sua metodologia. Especialmente a fase experimentação, que segundo ele constitui-se de um laboratório, apresenta uma sistemática completa para desenvolvimento de protótipo. Dessa maneira, reduz os riscos e incertezas envolvidas no desenvolvimento de projeto piloto Projeto piloto [GAR98] não aborda este critério; dentre os trabalhos pesquisados, [POE98] é a que apresenta esta característica com detalhes. Recomenda uma fase explícita antes do efetivo desenvolvimento do DM/DW, sugerindo dois tipos distintos: prova de concepção e arquitetura e infra-estrutura, ambos descritos na seção [KIM98a] aborda a utilização de projeto piloto prova de concepção para escolha de ferramentas, que é utilizado na fase seleção e instalação de produtos ; [PER00] sugere o tipo de projeto piloto arquitetura e infra-estrutura, baseado no de trabalho de [POE98]. A distinção entre os dois trabalhos está no fato de que [PER00] detalhou uma sistemática completa para o desenvolvimento do projeto piloto, o que não foi feito por [POE98] Criação e Gerenciamento de Metadados Todos os autores pesquisados concordam com a idéia de que metadados são imprescindíveis para o sucesso de projetos de DW. Alguns, inclusive, chegam a afirmar que não se pode discutir DW sem falar em metadados. No entanto, nenhum dos trabalhos analisados integra a criação e o gerenciamento de metadados à metodologia de desenvolvimento. Na seção 3.3 está detalhado cada trabalho pesquisado, exceto o trabalho de [PER00], em relação à criação e ao gerenciamento de metadados. 74

86 3.3 GERENCIAMENTO DE METADADOS Como destacado na seção 2.9, os metadados ajudam os desenvolvedores a construir e gerenciar o DW, e os usuários a acessar os dados armazenados. No entanto, somente quando o DW está em uso, é que a maioria das organizações se depara com a necessidade de metadados e constata a sua importância. Haverá dados de várias formas e tipos que se possa imaginar armazenados no DW. Estes dados precisam ser conhecidos e entendidos para gerar informação confiável e guiar para tomar decisões de qualidade. A seguir estão descritas as abordagens encontradas em GARDNER [GAR98], POE et al. [POE98], KIMBALL et al. [KIM98a] e INMON et al. [INM97] [INM98] [INM99] quanto ao tratamento dispensado aos metadados em seus trabalhos A Abordagem de GARDNER [GAR98] Para GARDNER [GAR98], o gerenciamento de metadados deve controlar tudo - desde o desenvolvimento de programas que extraem dados dos sistemas operacionais transacionais até a coleção de dados dentro do DW. Apesar dessa visão abrangente com relação ao gerenciamento de metadados, o autor limita-se a direcionar a criação de um catálogo de metadados. Este catálogo permite o controle da localização e significado dos vários objetos de informação dentro do DW e funciona como uma biblioteca, onde os usuários finais fazem requisições por informações, baseados em seleções feitas no catálogo. O catálogo deve estar organizado para atender aos seguintes requisitos: servir como um mapa para a localização das informações armazenadas no repositório; incluir dois tipos de componentes para cada item, a definição necessária para a tecnologia de banco de dados (nome da tabela e dono da tabela) e a definição necessária para o usuário do negócio; prover um plano para o caminho em que um tipo de informação é derivado de outro tipo de informação; prover um plano para extratores que capturam dados dos sistemas operacionais transacionais e os carregam para dentro do DW; 75

87 armazenar a construção de regras do negócio dentro do DW; armazenar controle de acesso e regras de segurança; possibilitar que metadados possam trilhar as trocas ocorrentes, no futuro; organizar metadados para se ter versões sobre o histórico das mudanças ocorridas; armazenar a estrutura e o conteúdo do DW; identificar clara e formalmente o sistema de arquivamento do DW; disponibilizar a lógica de integração e transformação como uma parte normal dos metadados do repositório; armazenar o histórico do refresh de dados (limpeza ou reorganização de dados antigos); e armazenar métricas para que os usuários finais possam determinar se uma requisição será grande ou pequena antes de submetê-la A Abordagem de POE et al. [POE98] Para POE et al. [POE98], metadados para um ambiente de DW representam informações geradas em cada ponto, durante o ciclo de vida do desenvolvimento do DW. Assinala que existe muita controvérsia em torno de metadados, gerada principalmente pelas muitas ferramentas e produtos associados com o ambiente DW. Para simplificar o entendimento, os autores classificam os metadados em dois tipos: metadados para integração de dados são produzidos em todos os pontos do processo no qual os dados são movidos dos sistemas operacionais transacionais para população no DW. Exemplos desse tipo de metadado são a documentação inicial que descreve os dados dos sistemas-origem, o processamento de regras de conversão dos dados-origem para dentro do DW, e a linguagem de definição de dados (DDL) usada para criar o banco de dados relacional. Essas informações permitem que o administrador ou gerente de mudanças execute as análises requeridas para estimar o impacto das mudanças solicitadas, frente ao atual DW a ser implementado; metadados para transformação de dados são produzidos em todos os pontos do processo no qual os dados são movidos do DW para chegar ao desktop do usuário final, como resultado de uma consulta. Esses metadados são usados durante o 76

88 processo no qual os usuários finais acessam dados do DW e os transforma em informação. Geralmente incluem regras de transformação para produzir e calcular dados (se não foi feito na carga do banco de dados), tabelas e atributos de definição do negócio, assim como valores default e associados com atributos individuais ou domínios. Também incluem as dimensões e as hierarquias de dimensões do DW que serão usadas com a ferramenta multidimensional de acesso aos dados. Os usuários finais consultam esses metadados para transformar os dados armazenados no DW em dados usáveis, em informações com valor adicionado pela formatação, sumarização, e na visão dos dados em estilos específicas. Gerenciar metadados configura um papel crítico para a implantação, com sucesso, de um DW. Também, para o sucesso do ambiente DW, uma documentação rigorosa (ou coleção automatizada) de metadados e a habilidade de armazenar, controlar, e acessar metadados fornecerão uma maneira de manter o controle de versões de objetos individuais e, adicionalmente, associar todos os objetos relacionados a uma release específica. A execução dessas duas tarefas, eficientemente, diminuirá o tempo de distribuição dos dados no ambiente DW. Em [POE98] é destacada a importância de se distinguir esses dois termos: versão quando um objeto (modelo de dados, código-fonte, banco de dados físico etc.) é modificado, o novo estado desse objeto, depois da aplicação da mudança, é a versão ; release refere-se a um grupo de objetos relacionados (banco de dados, scripts, definição da estrutura dos dados etc.) requeridos para executar uma aplicação. Em [POE98], é definida a função de um diretório de metadados no ambiente DW ( ) e a classificação dos usuários que interagem com o DW ( ). É feita uma avaliação realista de gerenciamento de metadados em corporações ( ) e proposta uma solução, denominada de solução de curto prazo, para projeto de metadados em DW ( ). Finalmente, destaca a importância do gerenciamento das mudanças ( ), afirmando ser a base para o sucesso de DW já em produção Diretório de Metadados Em [POE98], diretório de metadados é definido como um banco de dados que armazena todos os dados que descrevem o DW. Ele será usado pelos usuários do negócio, 77

89 que visualizarão os metadados para transformação de dados antes da consulta de dados no DW. Será povoado por metadados para integração de dados, pelos desenvolvedores responsáveis pela criação e gerenciamento do DW, e será mantido pelos administradores de dados, ou administrador de metadados, que são responsáveis por manter a exatidão e uso dos metadados. O conteúdo do diretório de metadados pode consistir de informações relacionadas ao negócio, tais como, aplicações origens, arquivos e nomes de campos, descrições de uso, proprietários dos dados, proprietários das aplicações e nomes dos usuários das aplicações. Os metadados mais comuns são tipos de dados, tamanho, valores válidos e índices, dentre outros, definidos no diagrama entidade relacionamento (DER) ou linguagem de definição de dados (DDL). As informações mais críticas, tais como regras de conversão, derivação e agregação, costumam ser mais difíceis de capturar. O principal obstáculo para se ter um diretório de metadados é que ainda não existe um processo-padrão que simplesmente reúna e integre os metadados, necessários para gerenciar o ciclo de vida do DW, e dar suporte às informações necessárias aos desenvolvedores e usuários do DW, em único local. A dificuldade de se definir esta padronização evidencia-se pelo fato de que os metadados são subprodutos de vários processos, geralmente executados com diferentes ferramentas, que possuem métodos proprietários para criar e armazenar metadados. Algumas soluções de companhias que reconhecem o problema e entendem o valor de reunir e gerenciar metadados são: publicar um conjunto de procedimentos, estabelecendo padrões de uso para cada uma das ferramentas do ambiente de desenvolvimento para promover consistência. Uma tabela de conteúdo ou índice é providenciada para que os usuários e desenvolvedores encontrem as informações de que eles precisam; e criar o próprio banco de dados para reunir os metadados e publicá-los na intranet da companhia, tornando-os disponíveis. Para [POE98], se houver a intenção de estabelecer as funções de administração de dados e implementar o diretório de metadados, isso deve ser reconhecido como tarefa significante e requer a participação dos membros-chave da equipe de desenvolvimento e do patrocinador do negócio. 78

90 Tipos de Usuários Existem muitos tipos diferentes de usuários que interagem com o DW. Cada um desses tipos de usuários pode ter diferentes necessidades de dados e geralmente requerem diferentes métodos de acesso aos dados. Em [POE98], os usuários que interagem com o DW são categorizados da seguinte forma: usuário executivo caracterizam-se por necessitar de acesso fácil. Precisam ainda de relatórios predefinidos que possam ser facilmente localizados em navegação por menus. Para esta classe de usuários, os resultados devem ser mostrados graficamente, com o suporte aos detalhes, se necessário. Análises adicionais podem ser desejadas, mas normalmente telefonam ou enviam para uma pessoa, ou departamento apropriado; usuário novato/casual alguém que necessita acesso a informações em determinadas ocasiões. Não acessam diariamente o DW, e em alguns casos nem semanalmente. Em virtude do longo tempo entre os acessos, a navegação de menus é requerida. Esperam encontrar análises predefinidas. Este tipo de usuário pode também estar interessado em usar parâmetros para executar qualquer relatório a qualquer momento; analista de negócio são os usuários finais, que usam informação diariamente, mas não têm (e não necessariamente querem ter) conhecimentos técnicos para construir relatórios completos do nada. Este usuário pode ser ajudado inicialmente para encontrar caminhos predefinidos de navegação e depois aprende a navegar diretamente ao relatório da sua escolha. Regularmente modificam parâmetros e visualizam os resultados de maneiras diferentes. Querem modificar relatórios existentes para customizá-los e encontrar necessidades específicas; usuário superior são profissionais do negócio que conhecem a tecnologia. Esses usuários querem modificar parâmetros e manipular resultados, e sentem-se confortáveis criando seus relatórios/análises. Querem ser hábeis para criar as próprias macros e armazenam os resultados em ferramentas de usuário final, tal como Excel, para facilitar a manipulação. Freqüentemente desenvolvem relatórios que podem ser compartilhados na organização; e desenvolvedor de aplicação as diferenças entre o usuário superior e o desenvolvedor são menores. Usualmente, as responsabilidades primárias do 79

91 desenvolvedor de aplicação existem para suportar o negócio, especialmente responsabilidades com o negócio atual. São treinados não somente para criar relatórios/análises para uso por outros, mas também forçar um ambiente-padrão, tal como quando e como relatórios serão nomeados e armazenados. Geralmente estão voltados para otimizar o desempenho dos relatórios Avaliação Realista de Gerenciamento de Metadados Para [POE98], cada vez mais se percebe a falta de políticas, procedimentos e estrutura organizacional para gerenciar metadados. Normalmente a implementação de metadados é abandonada no meio do ciclo de vida do desenvolvimento devido a ilusão, que cresce na cabeça das pessoas, de que é fácil desenvolver DW. O campo de metadados é crescente na arena de suporte à decisão. A ênfase no acesso aos dados pelos usuários finais está forçando as corporações a discutir questões de gerenciamento de recursos de informação. É quase comum a falta de infra-estrutura para gerenciamento de metadados dentro das organizações. Recomenda para as equipes de desenvolvimento, que estejam construindo o primeiro DW, pensar desde o início em criar a infra-estrutura para implementar metadados. Se necessário, deve orçar e requerer recursos adicionais para focar a análise e implementação de metadados em seus projetos. Como sugestão destaca: reconhecer e endereçar essas necessidades durante a fase planejamento do ciclo de vida do desenvolvimento; dedicar recursos para essa tarefa; montar uma solução de curto prazo, baseada nas necessidades dos usuários finais por metadados, que pode ser posteriormente expandida; e investir pesadamente em ter uma pessoa ou grupo, dentro da organização, com a responsabilidade pelo gerenciamento de metadados e também ter uma infraestrutura de desenvolvimento associada Solução de Curto Prazo para metadados Segundo [POE98], uma solução completa para gerenciamento de metadados, incluindo utilizar metadados para controlar as mudanças do ambiente de produção, é um investimento substancial de tempo e dinheiro. É necessário manter uma equipe trabalhando 80

92 com um especialista neste campo, para ajudar a montar a infra-estrutura, os processos, os métodos, a estrutura organizacional e o sistema para gerenciamento de metadados. No entanto, há soluções mais simples que podem ser aplicadas para projetos específicos de ambiente de suporte à decisão. Para [POE98], é mais difícil implementar metadados de integração de dados para o primeiro DW. Por outro lado, metadados de transformação de dados não são tão difíceis. A recomendação, para desenvolver uma solução de curto prazo, para atender as necessidades de metadados, é verificar quais metadados realmente são necessários. Como primeiro passo, recomenda-se desenvolver uma matriz dos metadados necessários para cada tipo de usuário, detalhados na seção , dentro da corporação (vide tabela 6). Pode-se observar, na tabela 6, uma grande quantidade de metadados de transformação. Além de serem mais fáceis de implementar, muitas ferramentas front-end de acesso aos dados, especialmente ferramentas multidimensionais, provêem uma visão desses metadados como parte de suas funcionalidades. Tabela 6 Tipos de usuários e necessidades de metadados [POE98] Tipo de Usuários Tipo de Metadados Executivo Casual Analista de negócio Usuário superior Desenvolvedor de aplicação Definições do negócio X X X X X Regras de conversão X Descrição de arquivos origem X DDL, tipos de dados, e defaults X X Regras de sumarização X X X Cálculos X X X Dimensões e hierarquias X X X X X Definições de consultas X X X Um método praticável, que [POE98] denomina de curto prazo, utilizado em algumas companhias: para usuários do tipo casual, analistas de negócio e executivos, é um simples programa de ajuda que permita aos usuários clicar em um campo específico e obter a definição para este campo. Podem ser inclusos nesta definição: cálculos com este campo em particular e qualquer outra informação que possa ajudar o usuário; e para usuários do tipo superior e desenvolvedores de aplicação, uma completa abrangência de metadados de integração de dados e de transformação de dados é necessária. Se não existe infra-estrutura para todos esses metadados em um sistema 81

93 de gerenciamento, pode-se prover metadados manuais ou uma simples base de dados de informação de metadados Gerenciamento das mudanças No ambiente de DW, a integração de dados é na realidade responsável pela transformação dos dados, que são apenas uma coleção de elementos discretos (arquivos, por exemplo), em informação. A informação surge da consolidação, agregação, derivação, classificação, estruturação e apresentação dos dados. No início, os metadados são usados na análise dos arquivos-fontes selecionados para povoar o DW e, ao longo deste processo, metadados são produzidos a todo momento. Portanto, quando o DW está em produção, o seu gerenciamento lida com grande volume de metadados armazenados. Estes metadados são usados para entender o conteúdo dos dados-fontes, todos os passos de conversão dos dados, e como os dados estão descritos no DW. Quando os usuários do negócio começam a utilizar o DW, ficam mais familiarizados com os tipos de questões a que eles têm vontade de responder. Isto faz crescer o número de requisições para adicionar e modificar dados no DW. Este aumento inevitável do volume de requisições, em razão do alto grau de envolvimento do usuário, deve ser suportado pelo gerenciamento de metadados e pelo processo de controle de mudanças. Além disso, a volatilidade do ambiente de produção do DW demanda um ciclo de desenvolvimento rápido, exigindo novas funções, métodos, tarefas e ferramentas para gerenciar metadados, além de múltiplos ambientes de teste. Gerenciamento das mudanças envolve a coordenação sobre o impacto das mudanças, alterações que se sobrepõem a outras, estimativas e programação das implementações, para o ambiente de produção do DW. Para uma efetiva administração das mudanças, é necessário seguir a pista de todos os componentes requeridos para suportar o crescimento progressivo do DW. Portanto, é extremamente importante ter sistemas que permitam controle de versão e gerenciamento de release. Daí a importância do gerenciamento das mudanças em um ambiente de suporte à decisão, já em produção. Para [POE98], o gerenciamento das mudanças é a base para o sucesso de DW em produção e os metadados são usados neste processo, como componente essencial. Embora essa visão do ambiente de produção somente se torne clara quando o DW estiver funcionando, é recomendada em [POE98] uma geração ativa de metadados, como também seu uso, através de todo o ciclo de desenvolvimento. Dessa maneira, pode-se 82

94 estabelecer os metadados necessários e viáveis que farão parte da arquitetura do DW e pode-se perceber cedo com o que se vai trabalhar. O processo de desenvolvimento deve ser ajustado para favorecer a entrega e manutenção de metadados junto com os dados. No entanto, isto é visto como uma redução na produtividade e pode haver resistência A Abordagem de KIMBALL et al. [KIM98a] KIMBALL et al. [KIM98a] classificam os metadados em duas diferentes classes, descritas a seguir: metadados back room os metadados pertencentes a esta classe estão relacionados a processos, pois orientam os processos de extração, limpeza e carga dos dados. Ajudam o DBA a mover os dados para o DW e são também importantes aos usuários de negócio, principalmente quando estes necessitam obter informações sobre as fontes de dados. Nesse tipo de metadados estão os metadados dos sistemas-fonte, metadados dos processos de ETL e os metadados do SGBD; metadados front room os metadados desta classe são mais descritivos do que os do tipo anterior. Têm a finalidade de auxiliar as ferramentas de consulta e programadores de relatórios a executarem suas tarefas mais facilmente. Na maioria das vezes beneficiam o usuário. Exemplos desse tipo de metadados são: nomes do negócio e descrição para colunas, tabelas e índices; consultas pré-formatadas e definições de relatórios, privilégios dos usuários, estatística do uso do sistema, mapas para acesso e uso das tabelas, visões e relatórios, dentre outros. Para gerenciar metadados, em [KIM98a] é proposto que as seguintes atividades devam ser executadas pelos administradores de DW: 1. fazer uma detalhada lista de todos os metadados; 2. decidir a importância de cada tipo de metadado; 3. assumir a responsabilidade ou designar a responsabilidade para alguém; 4. decidir o conjunto de tarefas consistentes para trabalhar com metadados; 5. decidir de fazer ou comprar uma ferramenta para gerenciar metadados; 6. armazenar os metadados em algum lugar para backup e recuperação; 7. tornar os metadados disponíveis para as pessoas que precisam deles; 83

95 8. assegurar a qualidade dos metadados e fazê-los completos e atualizáveis; 9. controlar os metadados de algum lugar; e 10. documentar bem todas estas responsabilidades para manter este trabalho longe das atividades do DW. [KIM98a] assegura que não é fácil saber o que é exatamente metadados, pois declara que metadados é tudo!. Para ajudar a entender metadados, apresenta uma lista detalhada dos tipos de metadados. Considera metadados como o DNA do ambiente DW, pois ele define o que todos os elementos são e como eles trabalham juntos. Recomenda criar e manter a lista de metadados, identificando para o que ele é usado e onde está armazenado. Em [KIM98a], é definida a função de um catálogo de metadados no ambiente DW ( ) e proposta uma solução denominada de Metadados ativos, para projeto de metadados em ambiente DW ( ) Catálogo de Metadados [KIM98a] usa a dicção catálogo de metadados como um descritor genérico para todo o conjunto de metadados usados em um ambiente DW. Como todas as etapas do DW devem usar metadados, o catálogo de metadados desempenha um papel crítico na infraestrutura deste ambiente, provendo parâmetros e informações para as aplicações executarem suas tarefas. Embora não exista uma ferramenta que possa ler e gravar todos os metadados diretamente, uma ferramenta para catalogação de todos os metadados é necessária, para ajudar a gerenciar os metadados armazenados em muitos locais diferentes. Além disso, recomenda que a equipe do DW providencie uma ferramenta para manutenção dos metadados não criados e gerenciados pelas ferramentas ou serviços do DW; como, por exemplo, comentários anotados pelo usuário, hierarquias para controle do uso do DW, dentre outros. A seguir, a lista de funções e serviços requeridos para manutenção do catálogo de metadados: catalogar as informações de integração (por exemplo, do modelo de dados para o banco de dados, para a ferramenta front-end); 84

96 gerenciamento dos metadados (por exemplo, remover antigos e não utilizados); exibir em modo gráfico e tabular o conteúdo do catálogo; manter perfil de usuários para aplicações e uso de segurança; suportar catálogo de metadados local ou centralizado. Infelizmente, segundo [KIM98a], não existe um tipo de sistema integrado que cerque todas as formas de metadados, como detalhado na seção Metadados Ativos Para [KIM98a], metadados é como documentação em sistemas tradicionais, em algum ponto os recursos necessários para criar e manter metadados serão desviados para algum projeto mais urgente. Para resolver este problema, define metadados ativos, como metadados que guiam o processo de documentação de metadados. A figura 18 ilustra um exemplo gráfico do fluxo de metadados proposto por [KIM98a]. Ferramenta modelagem (1) Modelo DW Catálogo de Metadados (2) Definições fontes Sistemasfontes Modelo físico Modelo lógico Defs. fontes Mapeamento das fontes p/ destino (3) Definições tabelas (4) Mapeamento da (5) Inf. mapeamento e fonte p/ destino transformação (8) Inf. da carga Ferramenta (6) Dados extraídos Data (7) Dados transformados staging (5a) Informações físicas Data Warehouse Inf. das consultas Grupos p/ área de negócios Inf. da carga (12) Informações das consultas (10) Requisições de consulta (9) Descrições de negócios (conteúdo e nomes das tabelas e colunas, valores exemplos etc. Ferramentas front-end (11) Dados Figura 18 Fluxo de metadados [KIM98a] 85

97 O fluxo da figura 18 nos permite que se entenda como a proposta Metadados ativos funciona e se visualize a perspectiva de metadados no ambiente DW. Na tabela 7, apresenta-se uma breve descrição de cada passo diagramado na figura 18. A partir dos passos descritos na tabela 7 e observando-se a figura 18, constata-se que o objetivo da proposta metadados ativos é manter a trilha de todos os metadados existentes no ambiente DW, capturando-os durante o processo de desenvolvimento do DW e armazenando estes metadados no catálogo. Cada passo, ou conjunto de passos, é executado em uma etapa específica do processo, da seguinte maneira: 1. o passo (1) é executado durante a definição dos modelos de dados do DW; 2. os passos (2) a (4) são executados durante o processo de definição das fontes de dados e mapeamento dos dados para o DW; 3. os passos (5) a (8) são executados durante os processos de extração, transformação e carga dos dados; e 4. Os passos (9) a (12) são executados durante os processos de especificação e definição das aplicações e acesso aos dados pelo usuário. Tabela 7 Descrição do fluxo de metadados [KIM98a] Passo Processo (1) Criar os modelos de dados lógico e físico do DW e armazená-los no catálogo, incluindo os termos do negócio, nomes das tabelas etc. (2) Capturar as definições dos sistemas-fonte e armazenar as definições das fontes de dados no catálogo (3) Capturar informações sobre transformações, definindo a relação entre os metadados já armazenados (modelo DW e fontes de dados), isto é a relação entre fonte e destino (4) Organizar e armazenar as informações sobre mapeamento das fontes de dados para o destino (5) Consulta os metadados armazenados para efetuar a carga dos dados. O passo (5a) pode ser utilizado (6) Realmente extrai os dados fontes (7) Carrega os dados transformados no DW (8) Capturar algumas estatísticas e informações de auditoria sobre a carga e armazenar estes metadados no catálogo (9) Disponibilizar consultas a metadados agrupados por área de negócio (10) Usuários formulam consultas, acessando os metadados (11) Os resultados são retornados aos usuários (12) Informações sobre o uso do DW são armazenadas no catálogo 86

98 3.3.4 Abordagem de INMON et al. [INM97, INM98, INM99] Um dos requisitos tecnológicos, relacionados por INMON et al. em [INM97], [INM98] e [INM99] para o ambiente DW é possuir um gerenciamento contínuo sobre os metadados. Para ele, os metadados representam o centro nervoso de uma arquitetura maior (a arquitetura do DW) e é através dos metadados que se alcança uniformidade e coesão entre os diferentes componentes do ambiente projetado, ilustrado na figura 19. transformação Data Mart / OLAP levemente sumarizado Data Warehouse dados correntes detalhados aplicativos operacionais ODS Figura 19 Ambiente projetado [INM99] O ambiente projetado (figura 19), descrito na seção 2.2 e detalhado em [INM99], possui 5 componentes. Cada componente serve a diferentes propósitos e possui os próprios metadados. Os componentes do ambiente projetado e os metadados de cada componente estão descritos a seguir: ambiente operacional layout de arquivos, especificações de índices, características físicas dos dados, especificações de blocos de controle, especificações de programação; camada de transformação especificações origem para destino, tópicos de conversão, especificações de agregações, reorganização de índices; operational data store (ODS) identificação origem para destino, freqüência de atualização, layouts de arquivos; dados correntes detalhados do DW layouts de arquivos, identificação origem para destino, informações de versão, métricas, programação de atualização, referência cruzada entre negócios e tecnologia, referência cruzada de alias; e 87

99 DM levemente sumarizado do DW identificação origem para destino, estrutura física, indexação, referência cruzada entre negócios e tecnologia. Além dos metadados residindo em cada componente, [INM98] identifica dois lados para metadados, descritos a seguir: metadados de negócio modelo de dados, sistema de identificação de registro, agrupamento de tabelas por área e assunto, referência cruzada entre planejamento estratégico e modelo de dados. Estes metadados são adequados ao dia-a-dia do negócio da corporação; e metadados técnicos layout da estrutura física, referência cruzada entre modelo de dados e projeto do banco de dados, especificação origem para destino. Estes metadados servem ao dia-a-dia tecnológico da corporação. Em resumo, os aspectos sobre os quais os metadados devem manter informações, segundo [INM97], são: a estrutura dos dados segundo a visão do programador; a estrutura dos dados segundo a visão dos analistas de SAD; a fonte de dados que alimenta o DW; a transformação pela qual os dados passam no momento de sua migração para o DW; o modelo de dados; o relacionamento entre o modelo de dados e o DW; e o histórico das extrações de dados. Ao longo das diferentes partes da arquitetura do ambiente projetado (figura 19), em [INM99] são identificados diferentes tipos de usuários: usuários do nível operacional funcionários que executam o processamento de transações rotineiras; usuário do ODS executivo corporativo que toma decisões táticas; usuário dos dados correntes detalhados analista SAD que explora padrões e tendências; e 88

100 usuários do nível DM/OLAP executivos e analistas SAD que tomam decisões ad hoc ou previsíveis A Infra-Estrutura para Metadados Segundo [INM99], para alcançar a harmonia e unidade dos diferentes componentes do ambiente projetado é preciso estabelecer uma infra-estrutura para metadados. Para administrar essa infra-estrutura, existe a figura do gerente de metadados, que deve participar na definição e no desenvolvimento da infra-estrutura de metadados. As atividades básicas do gerente de metadados são: obter metadados; colocar metadados em um estado de utilização; arquivar metadados; manter o histórico de metadados; coordenar o movimento de metadados; resolver discrepância de tecnologia quanto a metadados nos locais em que eles devem ser manipulados; definir a arquitetura de metadados; e manter os metadados atualizados. Segundo [INM98], a infra-estrutura de metadados deve atender aos seguintes objetivos: (1) reconhecer a necessidade de metadados comuns aos diferentes ambientes e permitir que metadados sejam compartilhados pelos diferentes componentes do ambiente; e (2) reconhecer a necessidade de autonomia local em cada ambiente, permitindo que os metadados sejam gerenciados localmente sem interferência ou considerações de outros usuários de fora do ambiente imediato. Além de satisfazer esses objetivos, a infra-estrutura de metadados deve: (1) poder distribuir objetos de metadados por toda a rede; (2) ser tecnologicamente compatível e disponível ao ambiente de metadados local. Segundo [INM98], um das razões pela qual os metadados aparecem como problema é a existência de duas forças contrárias que puxam os metadados atualmente: integração, uniformidade e consistência (1) e autonomia de processamento dos usuários finais (2). Em [INM99], são propostas três arquiteturas para a infra-estrutura de metadados. Estas arquiteturas estão descritas a seguir: centralizada: enfatiza a capacidade de compartilhamento dos metadados. Todos os metadados são armazenados em único local e são gerenciados de forma centralizada no repositório. Na opinião de [INM99], exercer um controle 89

101 centralizado de uma infra-estrutura ampla e complexa não funciona na prática e já foi provado ser impossível. O problema é que, nesta abordagem, há pouco ou nenhum espaço para a necessidade de controle local e autônomo dos dados; descentralizada: os metadados são criados e controlados através do ambiente arquitetado em diversos ambientes locais pequenos. Não há uniformidade de metadados, nem a possibilidade de compartilhamento ou de intercâmbio de metadados. Cada ambiente fica plenamente satisfeito quanto às suas necessidades e desejos imediatos. No entanto, existe uma imensa perda em economia de escala e não existe disciplina ou uniformidade de metadados ao longo do ambiente. Outra denominação para esta abordagem é todos-fazem-do-seu-próprio-jeito. distribuída: para [INM99], a abordagem distribuída de metadados é moderna e preenche igualmente todos os objetivos de metadados. A idéia é alcançar uma unificação dos metadados, através das plataformas de hardware e das tecnologias de software, que permita que os diferentes componentes do ambiente projetado se relacionem. O primeiro passo é distribuir os metadados ao longo do ambiente projetado, de modo que cada componente tenha seus metadados. No entanto, nenhum componente pode ficar isolado, sendo essencial a comunicação entre cada um dos componentes através da disponibilização e uso interativo de metadados. A abordagem da arquitetura de metadados distribuída, segundo [INM98], é a mais natural para ambiente heterogêneo e distribuído de suporte à decisão. Ao mesmo tempo, é possível: distribuição de componentes compartilháveis e distribuídos; e autonomia e controle de componentes locais não compartilháveis. Com a estrutura unificada desta arquitetura, encontram-se dois tipos de metadados: compartilhados e privados, também chamados de globais e locais. No nível do usuário final, os dois tipos estão presentes. No nível ODS, nível corrente de detalhe do DW e ambiente OLAP, os metadados são quase que exclusivamente compartilhados. O compartilhamento dos metadados, através da rede do DW corporativo, permite a uniformidade e consistência de metadados. A integridade é mantida através de um sistema de registros [INM98]. Com o sistema de registro, existe apenas um possuidor e gerenciador de um objeto. Cabe a este a responsabilidade de determinar onde os metadados podem ser compartilhados e onde não podem. Também, somente o possuidor pode efetuar mudanças no objeto. 90

102 3.3.5 Considerações sobre Gerenciamento de Metadados Como demonstrado neste capítulo, gerenciamento de metadados é um grande desafio para muitos projetos de DW. Isto porque não existe na indústria um padrão, de aceitação geral, para armazenamento e gerenciamento de metadados, como destacado na seção 2.9. Além disso, existe muita controvérsia sobre metadados entre as muitas ferramentas e produtos associados com o ambiente DW. Apesar desses obstáculos, em virtude da importância dos metadados em ambiente analítico, alguns trabalhos têm sido desenvolvidos para garantir o gerenciamento de metadados neste ambiente. Nas quatro seções anteriores deste capítulo, foram detalhadas abordagens sobre gerenciamento de metadados. As principais características utilizadas pelos autores foram identificadas. A tabela 8 apresenta, de forma resumida e comparativa, as estratégias de gerenciamento de metadados pesquisadas e as principais características consideradas. Tabela 8 Comparativo das abordagens sobre gerenciamento de metadados Características [GAR98] [POE98] [KIM98a] [INM97, INM98, INM99] Define e detalha tipos de metadados Sim Sim Sim Sim Classifica os metadados Não - Integração de dados; - Transformação de dados - Back room - Front room - Técnicos; - Negócios Define e detalha tipos de usuários Define um modelo de metadados Define infra-estrutura de metadados Define a forma de armazenar metadados Integra o gerenciamento de metadados à metodologia de desenvolvimento Não - Executivo; Novato; - Analista de negócio; - Usuário superior; - Desenvolvedor Não - Usuário operacional; - Usuário ODS; - Usuário dados correntes detalhados; - Usuário DM/OLAP Não Sim Não Sim Não Pouco detalhada Não Catálogo Diretório Catálogo - Centralizada; - Descentralizada; - Distribuída Repositório e Sistema de registro (abordagem distribuída) Não Não Não Não Dentre estas, observou-se que todos os trabalhos definem e detalham tipos de metadados, como também a forma de armazená-los. Somente em [GAR98] não existe uma classificação para metadados. Quanto aos critérios define e detalha tipos de usuários, define um modelo de metadados e define infra-estrutura de metadados, observa-se que somente [POE98] e [INM99] abordam estas características em seus trabalhos. 91

103 Neste momento é oportuno relembrar um dos principais aspectos do problema abordado no início deste trabalho, que é a necessidade de metadados no ambiente DW em razão do pouco conhecimento do negócio pelos usuários em algumas organizações, das quais a SEFIN constitui um caso típico. Dessa forma, o critério integra o gerenciamento de metadados à metodologia de desenvolvimento está sendo considerado, por permitir que o rumo dos metadados não se perca durante o desenvolvimento de DM/DW. Isto vai garantir que existam metadados, que estes sejam confiáveis, e que facilitem o acesso dos usuários ao DW. A partir desta colocação, no contexto deste ensaio, considera-se que uma metodologia de desenvolvimento de DM/DW deve acionar procedimentos especiais que permitam e facilitem o gerenciamento de metadados desde o início do projeto até a sua conclusão. 3.4 Conclusão Na seção 3.2 deste capítulo, foram realizadas análises sobre os trabalhos pesquisados, considerando o problema levantado na seção 1.2. Confirma-se que nenhuma das metodologias estudadas poderá ser adotada integralmente, considerando o contexto desta dissertação. Apesar disso, este estudo mostrou que é possível a adaptação das quatro metodologias em uma que permita inserir a tecnologia de DW em corporações sem tradição no uso de sistemas de apoio à decisão. Adicionalmente, a metodologia proposta deve ainda buscar a ampliação do conteúdo informacional das corporações, através do efetivo gerenciamento de metadados. Desta forma, o capítulo seguinte destina-se a apresentar e detalhar uma metodologia de desenvolvimento de DM/DW que atenda ao contexto deste trabalho. 92

104 4 X-META: UMA METODOLOGIA DE DESENVOLVIMENTO DE DW 4.1 Introdução Como mencionado, algumas organizações necessitam de sistemas automatizados para apoio à decisão. A eficiência desses sistemas depende da existência de um DM/DW. No entanto, para a construção do primeiro DM/DW, a maioria das organizações conta apenas com sua equipe de desenvolvimento interna, capacitada tecnicamente, contudo muitas vezes sem experiência prática para o desenvolvimento de DW. Essa dificuldade, principalmente em empresas públicas, decorre da dificuldade de contratação de firmas especializadas ou consultoria. Outras dificuldades envolvidas no desenvolvimento de DM/DW, já discutidas na seção 1.2, seriam o alto custo desses projetos, prazos e sigilo dos dados. Também já foi destacado em capítulos anteriores que, para se obter sucesso em projetos de construção de DW, não basta apenas construir o DM/DW, mas é fundamental usá-lo com eficácia, permitindo que seus usuários, através dos metadados, por exemplo, possam buscar e encontrar as informações da maneira mais lógica e intuitiva. Com o objetivo de solucionar os problemas supracitados, ao longo do capítulo 3 foram descritas e analisadas diversas metodologias de desenvolvimento de DM/DW propostas e estratégias para gerenciamento de metadados no ambiente DW. Entretanto, constatou-se que nenhuma metodologia investigada atendia completamente aos critérios estabelecidos como necessários, e que devem estar presentes em uma metodologia para atender particularmente ao cenário organizacional descrito neste trabalho. Com efeito, este 93

105 capítulo descreve a metodologia X-Meta, que possui os critérios necessários para o desenvolvimento eficiente de DW em organizações com o perfil descrito no capítulo 1. Este capítulo está estruturado da seguinte forma: na próxima seção, apresenta-se uma visão geral da metodologia proposta. Em seguida, da seção 4.3 até a seção 4.7, estão detalhadas todas as fases que compõem a metodologia X-Meta. 4.2 A Metodologia X-Meta A estratégia básica da metodologia proposta neste trabalho é iniciar o primeiro projeto de DM/DW de uma instituição com base nas especificações de [POE98] sobre projeto piloto do tipo prova de concepção. A idéia é o desenvolvimento de um primeiro protótipo para provar a viabilidade e o valor de DW para a corporação. Adicionalmente, através do primeiro projeto e de subseqüentes projetos piloto, esta estratégia pode permitir que a equipe de desenvolvedores possa adquirir conhecimento e experiência com novas ferramentas e tecnologias, através de múltiplas iterações na metodologia proposta. A metodologia de desenvolvimento de DW proposta - X-Meta, ilustrada na figura 20, se propõe a facilitar o processo de desenvolvimento do DW corporativo e torná-lo possível de ser executado por desenvolvedores inexperientes. A metodologia X-Meta [LIM02] [LIM01] está dividida em cinco fases principais: Introdução, Desenvolvimento, Produção, Gerenciamento de metadados e Gerenciamento do projeto. Através da visão macro apresentada na figura 20, observa-se que uma fase pode estar dividida em subfases. Uma subfase, como é o caso da subfase Desenvolvimento 1 0 protótipo, ilustrada na figura 22 (página 102), e Ciclo de construção de DM/DW, ilustrada na figura 23 (página 109), pode estar dividida em módulos. Na subfase Ciclo de construção de DM/DW (figura 23) seus módulos estão ainda organizados em grupos, que representam diferentes pontos de entrada para esta subfase. Para facilitar a compreensão da metodologia X-Meta, apresenta-se o padrão genérico para divisão das fases: Fase {Subfases {Grupos {Módulos {Atividades (0,n) (0,n) (1,n) (1,n) 94

106 G e r e n c i a m e n t o d e m e t a d a d o s Planejamento inicial Planejamento Suporte Introdução Desenvolvimento 1 0 protótipo Desenvolvimento Identificação de requisitos e informações Produção Crescimento Decisão Ciclo de construção de DM/DW G e r e n c i a m e n t o d o p r o j e t o Figura 20 Metodologia X-Meta O processo de desenvolvimento de DW proposto pela metodologia X-Meta está baseado no paradigma do modelo espiral [PRE97], o qual combina prototipações com elementos do ciclo de vida clássico. O objetivo de se utilizar o modelo espiral é que a cada nova iteração na espiral, ilustrada na figura 21, progressivamente têm-se versões mais completas do DW a ser construído. Dessa forma, habilita-se o usuário e a equipe de desenvolvimento a entenderem e reagirem a riscos em cada nível evolucionário. A metodologia X-Meta apresenta três tipos distintos de iteração, ou nível evolucionário, cada qual com uma finalidade específica: (1) primeiro protótipo tem a finalidade básica de permitir a inserção da tecnologia DW na organização. Esta iteração, que é executada única vez dentro do processo de desenvolvimento do DW, utiliza somente a fase Introdução para o desenvolvimento do primeiro projeto piloto da organização. Ao fim desta iteração, o projeto pode ser aprovado, receber adaptações e ajustes, ou até mesmo ser recusado, encerrando a idéia de construção do DW corporativo; (2) projeto piloto permite o desenvolvimento incremental e evolucionário de projetos piloto, cada um com uma finalidade específica, como, por exemplo: testar 95

107 produtos, ganhar experiência, desenvolver repositório de metadados, dentre outras. Cada projeto piloto indica uma iteração em X-Meta, que iniciará na subfase Planejamento e utilizará uma ou mais entradas da subfase Ciclo de construção de DM/DW, dependendo da finalidade do projeto. Cada iteração terminará na subfase Ciclo de construção de DM/DW ou na fase Produção. Isto dependerá do nível evolucionário e da finalidade do projeto. Por exemplo, um projeto denominado Testar aplicativos e ferramentas, onde o objetivo seria identificar funcionalidades e aprender detalhes quanto ao uso de aplicativos e ferramentas, terminará na subfase Ciclo de construção de DM/DW, não sendo necessário, portanto, utilizar a fase Produção. Ao fim de cada iteração, é efetuada análise das alternativas e identificação/resolução de riscos; (3) projeto DM/DW O processo de desenvolvimento nesta iteração em X-Meta, que corresponde a projetos DM/DW propriamente ditos, é a mesma utilizada em iterações do tipo projeto piloto, descrita há pouco. Neste nível, vários projetos piloto já podem ter sido desenvolvidos e muitas das incertezas e inexperiências já foram eliminadas. Dessa forma, alguns módulos da subfase Ciclo de construção de DM/DW podem precisar apenas de revisão, se, por exemplo, já foi decidida a arquitetura de dados, arquitetura funcional. No entanto, novas particularidades, tais como maior volume de dados e complexidade na execução de algumas atividades, vão exigir mais esforço da equipe. A fase Produção tem um papel fundamental neste nível, quando versões completas de DM/DW serão liberadas. A idéia é que o produto final na metodologia X-Meta Data Warehouse Corporativo da Organização seja o resultado da execução de várias iterações. A primeira iteração (primeiro protótipo) é executada única vez e os outros dois tipos (projeto piloto e projeto DM/DW) podem ser executados diversas vezes. Em cada iteração, realizam-se atividades, definidas nos módulos e subfases, requeridas e adaptadas às características do projeto a ser executado. Após a primeira iteração, que corresponde exatamente ao primeiro protótipo a ser disponibilizado, as demais iterações serão evoluções da iteração anterior, onde protótipos podem ser disponibilizados em cada nível. A figura 21 apresenta um exemplo de possíveis projetos a serem desenvolvidos em uma organização, utilizando-se a metodologia aqui proposta. Cada espiral representa um projeto e cada projeto utiliza um determinado tipo de iteração, como se observa na legenda da figura 21. A extensão de cada 96

108 projeto dependerá da finalidade do projeto, do nível de experiência adquirida pela equipe de DW, da disponibilidade de tempo e pessoal, dentre outros motivos. Como se pode observar, a metodologia X-Meta integra uma abordagem de desenvolvimento incremental e uma abordagem de desenvolvimento evolutiva. A abordagem de desenvolvimento incremental resolve o problema de usuários sem tradição no uso de sistemas automatizados de apoio à decisão, pois esta abordagem embute a idéia de que conhecemos a maioria dos requisitos do produto e, simplesmente, escolhemos prioridades de implementação, aumentando pouco a pouco sua capacidade. Por outro lado, a abordagem de desenvolvimento evolutiva é adequada ao problema de inexperiência da equipe de desenvolvimento em projetos DW, pois esta abordagem enfoca a idéia de que não conhecemos todos os requisitos e que temos a necessidade de experimentar o que conhecemos, de forma a aprender sobre os objetivos do produto. PRIMEIRO PROTÓTIPO PROJETO PILOTO PROJETO DM/DW Figura 21 Exemplo de iterações na metodologia X-Meta Nas seções seguintes estão detalhadas as fases, subfases e módulos que compõem a metodologia X-Meta. 4.3 Fase Introdução Esta fase constitui o primeiro diferencial da metodologia proposta, considerando que não existe uma fase similar no ciclo de vida de DM/DW, em nenhum dos trabalhos analisados e apresentados no capítulo 3. Em [POE98] é sugerida a construção de um projeto piloto Prova de Concepção, antes da construção do DW propriamente dito. No entanto, a autora não inclui este assunto em nenhuma das fases da sua metodologia, 97

109 limitando-se a discriminar uma série de atividades a serem observadas e executadas, apesar da importância destacada pela mesma ao assunto. Já em [PER00], encontra-se uma metodologia completamente direcionada para a construção de um projeto piloto. No entanto, verifica-se a existência de um grande projeto para testar as diversas tecnologias DW disponíveis, que em organizações sem conhecimento de DW pode ser um esforço muito grande logo de início. Portanto, uma sistemática completa para desenvolvimento de um primeiro projeto piloto foi definida para a metodologia X-Meta. Vale ressaltar que esta primeira fase foi criada objetivando atender ao problema destacado no início deste trabalho, que ocorre em muitas organizações: necessidade imediata de uso de sistemas automatizados de apoio à decisão para atender aos administradores, em empresas onde não existe conhecimento ou experiência sobre tais sistemas. Adicionalmente, esta primeira fase torna viável que o projeto seja conduzido por equipe integrante do quadro de TI da organização, capacitada tecnicamente e com conhecimento em Data Warehousing, e da sua importância, no entanto sem nunca ter desenvolvido um projeto DW. O principal objetivo da fase Introdução é auxiliar a equipe de desenvolvimento do DW, para que esta possa lidar, de forma sistemática e eficiente, com seu primeiro desafio introduzir a tecnologia DW na corporação através da construção de um protótipo. Para a disponibilização do primeiro protótipo, será necessária uma infra-estrutura mínima, devendo já estar disponível na corporação. Embora a construção do primeiro protótipo seja um esforço pequeno e de baixo custo para demonstrar o potencial impacto de DW para a comunidade de negócio da empresa, a dificuldade reside nas pessoas que, na maioria das organizações, com o perfil caracterizado neste trabalho, não entendem ou percebem do que eles precisam. Esta primeira fase de desenvolvimento foi definida e deve ser utilizada por equipe de desenvolvimento e usuários conhecedores do negócio. Os requisitos do negócio que serão descobertos e a facilidade de acesso às informações serão um caminho valioso para educar a organização e gerar entusiasmo em torno da tecnologia de DW. Ao final da fase Introdução pretende-se que: o time de desenvolvimento tenha adquirido bastante conhecimento e habilidades técnicas, que seja possível tomar decisões melhores e mais seguras nas várias questões que envolvem a construção de DM/DW; 98

110 os usuários tenham assimilado conhecimentos sobre Data Warehousing, suas possibilidades e o valor para a organização; e o projeto tenha conseguido patrocinador, que dará suporte durante todo o ciclo de desenvolvimento da metodologia proposta. É de crítica importância a sua escolha, devendo ser uma pessoa poderosa e líder de grande influência organizacional. Com a fase Introdução, os benefícios descritos a seguir devem ter sido alcançados pela equipe de desenvolvimento do DW: aprender e entender as diferentes tarefas que envolvem as fases de desenvolvimento de DM/DW; ter um primeiro contato com o modelo dimensional de dados; aprender e praticar o projeto de um banco de dados analítico; entender e realizar atividades tais como mapeamento, extração, transformação e carga de dados; entender como trabalham as ferramentas de acesso aos dados; entender e aprender a identificar e reunir metadados; e entender e praticar técnicas para reunir requisitos de decisão, interagindo com o usuário e provendo-o de informações úteis. Para se alcançar os objetivos e os benefícios esperados nesta fase, suas subfases Planejamento Inicial, Desenvolvimento 1 0 protótipo e Decisão são executadas única vez, quando do desenvolvimento do primeiro projeto de DW da corporação, para garantir que o usuário possa ter um contato inicial e perceber a utilidade dos dados de apoio a decisão, o mais rápido possível. Cabe ressaltar que cuidados devem ser tomados, principalmente quanto ao escopo e às expectativas dos usuários, evitando possíveis decepções. Sugere-se elaborar um documento com um estudo fundamentado sobre a viabilidade de realização do primeiro projeto de DW e justificativa do negócio, abordando seus custos e retornos. A aprovação desde documento dará início ao projeto. As subfases da fase Introdução serão detalhadas nas seções a seguir. 99

111 4.3.1 Subfase Planejamento inicial O principal objetivo desta subfase é garantir que, mesmo para um projeto com escopo reduzido e com o objetivo de ser rapidamente disponibilizado, as principais atividades de um projeto de desenvolvimento de sistemas sejam executadas de forma eficiente. Dessa maneira, a subfase Planejamento inicial engloba, de modo menos complexo, algumas atividades das subfases Planejamento e Identificação de requisitos e informações da fase Desenvolvimento (figura 20), como também algumas atividades do módulo Modelagem de metadados (figura 21). As informações coletadas e os resultados obtidos servirão como subsídio para a próxima subfase e também para planejamento de futuros projetos. Tendo como foco o desenvolvimento do primeiro protótipo, esta subfase apresenta as atividades delineadas na seqüência. 1. Definição do escopo do projeto Uma boa estratégia para a definição do escopo do projeto é priorizar uma área (setor, segmento do negócio) com alto grau de praticabilidade e potencial de impacto no negócio da organização, preferencialmente que possua dados bastante confiáveis e com pouca complexidade. Os desenvolvedores de sistemas, que conhecem os sistemas legados, já podem ter em mente uma área com essas características, além de identificar dados homogêneos e fáceis de localizar e extrair. Dessa maneira, a integração de dados será uma tarefa menos complexa, permitindo diminuir sobremaneira o tempo de disponibilização do protótipo. A escolha do escopo do projeto deve envolver os usuários, que a partir de então se integrarão à equipe do projeto. Estes usuários serão os representantes do negócio e responsáveis pelo esforço, junto com o pessoal de TI. Na verdade, os dois times, desenvolvedores e usuários, formarão uma sociedade que compartilhará responsabilidades e benefícios com a iniciativa do projeto. A criação de um documento que guiará o projeto piloto como um todo deve ser introduzido neste momento. Recomenda-se utilizar uma ferramenta de gerenciamento de projeto disponível na organização. Este documento, nomeado por vários autores como Plano de Projeto [KIM98a] [POE98], deve registrar todas as atividades e informações coletadas durante o ciclo de desenvolvimento do protótipo, e servirá como subsídio para novos projetos. 100

112 2. Definição da infra-estrutura técnica Especificar os recursos tecnológicos, como a plataforma de hardware, banco de dados e seus utilitários, e ferramentas de acesso aos dados, disponíveis ao desenvolvimento do primeiro protótipo. 3. Definição dos participantes, responsabilidades e prazos de conclusão Caso o documento inicial de aprovação não tenha especificado o tempo de duração do projeto, isto deve ser feito neste momento. Deve-se especificar a data de início do projeto e a estimativa de conclusão do protótipo. Com base nos recursos humanos disponibilizados para o projeto, e tempo de dedicação destes ao projeto, estabelecer o cronograma preliminar de cada atividade, o seu responsável e os correspondentes prazos. 4. Definição dos requisitos da área de negócio selecionada Através de entrevistas com os usuários, deve-se entender e coletar os requisitos da área de negócio selecionada, sensibilizando-os para a importância de sua participação no processo de desenvolvimento, para que possam dar informações que assegurem a utilidade do DW. Também deve ficar clara a importância de limitar o número de usuários que irão acessar inicialmente o DW, para evitar uma expectativa maior, para um projeto inicial. Desde o início desta atividade, o papel dos metadados no projeto deve ficar evidente, principalmente a importância de documentar os metadados. 5. Definição do que será disponibilizado aos usuários Através do levantamento dos tipos de relatórios que os usuários decisores utilizam, definir os relatórios e consultas prioritárias que serão disponibilizados. 6. Definição de uma solução de metadados para o protótipo A definição de uma solução inicial de metadados, nesta subfase, destina-se a possibilitar a documentação e uso de metadados que serão identificados durante todo o processo de desenvolvimento do protótipo, portanto, entender e aprender a identificar e reunir metadados. Os passos a serem executados nessa atividade foram adaptados do trabalho de [POE98] e [MAR00] e estão descritos a seguir: definir os objetivos da solução de metadados, que devem ser adequados aos objetivos do primeiro protótipo, mas com a visão de que esta solução também é um protótipo e será posteriormente expandida; 101

113 levantar os metadados mais comuns que serão reunidos, assim como já determinar uma classificação para eles; elaborar uma representação gráfica das regras do negócio, da área-alvo do protótipo, mostrando as hierarquias e relações nas operações do negócio. Isto facilitará a identificação dos diferentes metadados que cercam o ambiente organizacional, e que serão capturados; e criar um metamodelo. Embora a construção do repositório de metadados não seja uma atividade desta iteração, o modelo de dados do repositório facilitará a criação e uso dos metadados, e servirá como contribuição para o futuro projeto corporativo de metadados, quando se utilizará a segunda entrada do ciclo de construção de DM/DW (representada por ➋ na figura 23) para a construção do repositório de metadados Subfase Desenvolvimento 1 0 protótipo Esta é a subfase mais crítica da fase Introdução. É composta de cinco módulos que representam uma sistemática própria para a construção do primeiro protótipo de DW da organização, como ilustrado na figura 22. Tendo como entrada as especificações coletadas na subfase Planejamento inicial, esta subfase é responsável pelas atividades de construção e disponibilização do protótipo. Ao seu final, os resultados são entregues à subfase seguinte, denominada Decisão. A subfase Desenvolvimento 1 0 Protótipo está subdividida em cinco módulos independentes denominados Modelagem dimensional, Projeto BD, Extração e transformação, População e Disponibilização (figura 22). Vale destacar que estes módulos têm denominações e atividades semelhantes aos módulos que compõem o terceiro grupo de entrada da subfase Ciclo de construção de DM/DW (➌), pertencente à fase Desenvolvimento, ilustrada na figura 23. No entanto, as atividades a serem executadas por estes módulos, nesta subfase, foram simplificadas, para permitir rapidez na disponibilização do protótipo, sem, contudo, interferir na confiabilidade e qualidade do DW produzido. Os módulos integrantes desta subfase podem ser repetidos tantas vezes quantas necessárias, como pode ser observado na figura 22, dentro das disponibilidades de tempo e pessoal, possibilitando o ganho de experiência e a eliminação das incertezas. Ao final de 102

114 cada módulo, deve-se revisar as atividades executadas e o projeto como um todo, juntamente com o usuário final, atestando a sua aceitação. Vale destacar a atividade de reunir e documentar os metadados, que deve ser realizada em todos os módulos. Planejamento inicial ➌ Modelagem dimensional Projeto BD Extração e transformação População Disponibilização Decisão Figura 22 Sistemática de desenvolvimento do 1 0 protótipo de DW Os módulos que compõem a sistemática de desenvolvimento do primeiro protótipo estão descritos a seguir. Vale destacar que estes módulos apresentam os mesmos objetivos que os módulos demonstrados na seção Contudo, como mencionado há pouco, as atividades destes módulos na fase Introdução são simplificadas Módulo Modelagem dimensional A partir dos requisitos da área de negócio selecionada, a equipe do projeto deverá escolher um modelo de dados dimensional ( estrela ou flocos de neve ) adequado às condições do assunto de negócio escolhido na subfase Planejamento inicial, e implementá-lo. Deve-se identificar as fontes de dados que possuam os dados definidos no modelo dimensional, assim como procurar especificar, dentre estas, as melhores fontes de dados. Ao final, estarão definidos as tabelas dimensão e seus atributos, as tabelas fato e seus fatos. Para atender ao objetivo principal desta fase, introduzir a tecnologia DW na organização, recomenda-se armazenar dados sumarizados, evitando armazenar dados muito detalhados. Isto simplifica o modelo de dados, além de facilitar o acesso aos dados com menor tempo de resposta às consultas Módulo Projeto BD Este módulo é responsável pela definição do modelo de dados físico e pela criação do banco de dados, a partir do modelo de dados dimensional de negócios (modelo conceitual) especificado no módulo Modelagem dimensional. As atividades deste módulo, que são atividades comuns de projetos de banco de dados tradicionais, como também os detalhes do modelo e da implementação física dependem de fatores individuais do projeto, tais como: modelo conceitual, DBMS a ser 103

115 utilizado, volume de dados, ferramentas envolvidas, entre outros. Estas atividades já estão detalhadas na seção (módulo Projeto BD da subfase Ciclo de construção de DM/DW da fase Desenvolvimento ), e devem ser utilizadas aqui visando apenas a disponibilizar o banco dados para receber os dados do primeiro protótipo. Dessa maneira, as atividades que compõem esse módulo são: 1. projeto do modelo físico do BD a partir do modelo dimensional definido no módulo anterior; 2. definição dos scripts para criação das tabelas, iniciando desde cedo alguns padrões para o nome das tabelas e de seus atributos; 3. definição dos índices; e 4. criação do banco de dados a partir dos scripts produzidos Módulo Extração e transformação A finalidade deste módulo é localizar os dados identificados no módulo Modelagem dimensional e disponibilizá-los para o módulo seguinte, População, onde os dados serão finalmente armazenados no banco de dados e posteriormente utilizados pelos usuários decisores. As atividades básicas deste módulo são: 1. análise das informações requeridas para o DW e dos tipos de dados; 2. definição dos processos de transformação necessários; 3. definição de estratégias e procedimentos de carga de dados dentro do DW. Isto é, definir onde e como os dados extraídos serão armazenados, antes de serem carregados no banco de dados; 4. desenvolvimento de programas para extrair os dados e realizar as conversões dos mesmos, se for o caso; e 5. teste dos programas Módulo População Este módulo é responsável pelo armazenamento dos dados no banco de dados alvo. Ao seu final, o protótipo estará pronto para ser acessado. Neste módulo são executadas as seguintes atividades: 104

116 1. desenvolvimento dos procedimentos de carga dos dados; 2. execução dos programas e procedimentos de extração, transformação e carga dos dados; e 3. validação e teste dos dados extraídos, transformados e carregados Módulo Disponibilização A finalidade deste módulo é disponibilizar o protótipo aos usuários finais. A primeira atividade deste módulo é definir uma ferramenta para o usuário acessar os dados, de preferência uma com a qual eles já estejam familiarizados. Outras atividades deste módulo são: 1. desenvolver aplicações de consultas e relatórios; 2. teste completo do sistema; 3. checagem profunda da consistência dos dados; e 4. treinar os usuários Subfase Decisão Após a disponibilização do protótipo, encontra-se o momento de maior incerteza do projeto, em decorrência da expectativa da decisão - Investir em um DW corporativo ou encerrar a idéia, que deverá ser tomada pela alta direção da organização, ao final desta subfase. O foco desta subfase deve ser a interação do usuário com as informações de suporte à decisão. As principais atividades são: 1. contínuo suporte aos usuários na utilização do primeiro protótipo; 2. monitoramento das consultas realizadas pelos usuários finais; 3. comunicação e publicidade dos sucessos obtidos em razão do uso do DW; e 4. elaborar relatório final e/ou apresentação formal da conclusão do projeto. Com a aceitação definitiva do projeto, considera-se que a tecnologia DW foi introduzida com sucesso na organização e terá início um desafio ainda maior: desenvolver DM/DW mais complexos. 105

117 4.4 Fase Desenvolvimento A fase Introdução disponibilizou o primeiro protótipo de DW para os usuários. Eles irão interagir com o ambiente, criando consultas para responder as suas questões do negócio. O sucesso do primeiro protótipo sedimentará a sociedade formada entre as comunidades de negócios e de TI, um dos critérios que aumentam as chances de sucesso no desenvolvimento dos novos projetos. Com a utilização e familiarização dos usuários com DW, como também em razão de novos requisitos de negócio que surgirão com seu uso, as mudanças serão inevitáveis, o que exige rapidez no desenvolvimento de novas funções. A Fase Desenvolvimento está dividida em três subfases denominadas Planejamento, Identificação de requisitos e informações e Ciclo de construção de DM/ DW, como apresentado na figura 20. Estas subfases e seus módulos podem ser utilizados para a construção de projetos piloto ou projetos DM/DW propriamente ditos. Todas as subfases e módulos definidos para esta fase já devem ter sido utilizados na condução de projetos piloto, antes da construção de completos DM/DW, pois é necessário reduzir, tanto quanto possível, os riscos e incertezas, e também transformar as experiências obtidas em definições mais precisas. Como explicado na seção 4.2, algumas subfases ou módulos desta fase podem não ser utilizados no desenvolvimento de determinados projetos. Para permitir esta flexibilidade, a subfase Ciclo de construção de DM/DW (figura 23) possui quatro pontos de entrada distintos que podem ser executados de forma concorrente ou individualmente, dependendo do tipo de projeto. A existência de variados pontos de entrada na metodologia proposta favorece o desenvolvimento incremental de DM/DW. As subfases da fase Desenvolvimento serão detalhadas nas seções a seguir Subfase Planejamento O planejamento engloba muitas tarefas idênticas às utilizadas em outros tipos de projeto de desenvolvimento de sistemas. Algumas destas tarefas já foram, inclusive, utilizadas na subfase Planejamento inicial da fase Introdução (seção 4.3.1). No entanto, esta subfase destina-se a um planejamento mais abrangente e detalhado, e visa a atender a projetos de níveis evolucionários diversos. Dessa forma, a abrangência e a 106

118 complexidade do planejamento podem variar significativamente, até porque as atividades de planejamento também variam de uma organização para outra. O documento plano de projeto, como descrito na seção 4.3.1, é o suporte necessário para o gerenciamento do projeto e deve ser continuamente revisado e atualizado. As atividades desta subfase foram extraídas do trabalho de [KIM98a], as quais estão apresentadas a seguir: 1. definição do projeto e do seu escopo; 2. criação do plano de projeto, onde devem constar a identificação do projeto e o planejamento das atividades que serão realizadas até o final do projeto. As atividades estão descritas nos módulos que compõem a subfase Desenvolvimento, que serão selecionados com base no objetivo, tipo e nível do projeto que será desenvolvido; 3. estudo dos riscos do projeto; 4. estabelecimento preliminar dos participantes, suas responsabilidades e tarefas; 5. estabelecimento preliminar de cronogramas; 6. definição da estratégia para o levantamento de requisitos (reuniões, estimativas de tempo, prováveis participantes, registro das reuniões, plano de comunicação entre os participantes etc.); e 7. revisão geral do projeto Subfase Identificação de requisitos e informações Esta subfase pode influenciar e causar impacto em todas as demais fases e aspectos do DW, sendo, portanto, de fundamental importância. Os requisitos do negócio e a necessidade das informações determinam quais dados serão disponibilizados no DW, como serão organizados e sua freqüência de atualização. Até o projeto da arquitetura de dados do DW depende dos requisitos do negócio e das informações, como mostra a tabela 3. Dessa forma, embora aparentemente esta subfase seja vista como necessária apenas para projetos que tenham o objetivo de disponibilizar produto ao usuário final, ela também é necessária para outros tipos de projeto. Em virtude da sua importância, esta subfase deve ser cuidadosamente conduzida. Inicialmente deve-se entender com clareza o negócio do usuário final, suas 107

119 particularidades, requisitos e exigências. Os dados podem ser levantados através de entrevistas, seções de facilitação, análise de documentos e relatórios, auditoria nos dados internos e externos da corporação, ou ainda através de outros métodos quaisquer a serem conduzidos pela equipe de projeto. Nessa fase são realizadas as seguintes atividades: 1. identificação e preparação da equipe de entrevistadores (seleção de entrevistadores, determinando seus os papéis e responsabilidades); 2. identificação dos entrevistados da área de negócio (executivos, analistas, gerentes) e da área de TI (responsáveis pelos sistemas legados); 3. agendamento e realização das diversas entrevistas; 4. análise dos resultados de cada entrevista. É importante identificar, ao final das entrevistas, os possíveis fatores que permitam mensurar o sucesso do DW, em reunião realizada com a presença de todos os entrevistadores; 5. revisão do escopo do projeto; e 6. revisão geral do projeto. Ao final desta subfase deve-se ter clareza sobre o que os usuários querem e o que deve ser feito para fornecer o que eles querem. Por esse motivo, os seguintes pontos devem ser identificados: quais os dados disponíveis para suportar os requisitos dos usuários; qual o nível de detalhamento dos dados que o usuário necessita (granularidade); e como o usuário espera visualizar o resultado de suas consultas. Em virtude da natureza incremental do processo de construção do DW, sempre haverá mudanças e pedidos adicionais. Portanto, não se deve despender muito tempo tentando capturar tudo de uma vez para realizar os objetivos. As necessidades virão, inclusive mais claramente, com o uso do DW. Também, a sociedade iniciada na fase Introdução, entre os usuários do negócio e a equipe de desenvolvimento do DW, deve ser estreitada, garantindo a continuidade do envolvimento do usuário no processo. Este envolvimento permitirá que os usuários possam perceber, mais cedo, suas necessidade e possibilidades. 108

120 4.4.3 Subfase Ciclo de construção de DM/DW A subfase Ciclo de construção de DM/DW, ilustrada na figura 23, é composta por um conjunto de módulos ( Arquitetura de dados, Arquitetura funcional, Infraestrutura, Modelagem de metadados etc.). Cada módulo representa um conjunto de atividades, que serão realizadas quando um módulo é utilizado em um determinado projeto. Como pode ser observado na figura 23, há quatro pontos de entrada identificados como ➊, ➋, ➌ e ➍, para a subfase Ciclo de construção de DM/DW, que correspondem a grupos de módulos e representam objetivos específicos para projetos. Vale ressaltar que os grupos de módulos podem ser executados de forma concorrente ou individualmente, sendo que a finalização desta subfase, para cada iteração, ou projeto, é executada no módulo Disponibilização. A existência dos diferentes pontos de entrada, que permite esta execução concorrente das atividades, confere à metodologia sua natureza evolucionária. Por exemplo, dependendo da disponibilização de pessoal, do nível de conhecimento adquirido pela equipe, de recursos financeiros e do objetivo e abrangência de um projeto, pode-se utilizar as entradas ➊ e ➋, ou ➊, ➌ e ➍, ou até ➊, ➋, ➌ e ➍, simultaneamente. ➊ Arquitetura de dados Arquitetura funcional Infra-estrutura Teste de produtos ➋ Modelagem de metadados Infra-estrutura de metadados Disponibilização ➌ Modelagem dimensional Projeto BD Extração e transformação População ➍ Especificação de aplicações usuário final Desenvolvimento de aplicações usuário final Figura 23 Subfase Ciclo de construção de DM/DW O primeiro grupo ou primeira entrada do ciclo de construção de DM/DW (representada por ➊ na figura 23) engloba os módulos Arquitetura de dados, 109

121 Arquitetura funcional, Infra-estrutura e Teste de produtos, que correspondem às atividades que definem a arquitetura técnica do DW. Todos os resultados gerados por esses módulos (desenhos, modelos, mapas etc.) têm o valor de uma boa documentação e ajudam quando são necessárias mudanças ou novas implementações. É importante que a arquitetura de dados, arquitetura funcional e infra-estrutura, convenientes à construção do DW, sejam estabelecidas durante a construção do primeiro projeto piloto, ou até o próximo projeto de DM, se for o caso, para evitar o problema da integração de DM. O segundo grupo ou segunda entrada do ciclo de construção de DM/DW (representada por ➋ na figura 23) é mais um diferencial desta metodologia, pois não existe atividade similar em nenhum dos trabalhos analisados e apresentados no capítulo 3. Este grupo é formado pelos módulos Modelagem de metadados e Infra-estrutura de metadados, constituindo um grande passo rumo à solução do problema destacado na seção 1.2 (falta de conhecimento organizacional dos dirigentes em razão da pouca experiência no negócio). Embora muitas das atividades previstas nestes módulos existam em outros trabalhos [POE98] [KIM98a] [GAR98], estes não integram estas atividades em sua metodologia de desenvolvimento. As atividades e os resultados destes módulos são essenciais para a fase Gerenciamento de metadados, descrita na seção 4.6. O terceiro grupo ou terceira entrada do ciclo de construção (representada por ➌ na figura 23) é formado pelos módulos Modelagem dimensional, Projeto BD, Extração e transformação e População. As atividades realizadas nesta entrada relacionam-se aos dados que, identificados nas subfases anteriores, serão aqui modelados. Após isto, será projetado e criado um banco de dados para armazenar os dados multidimensionais, sendo então disponibilizados para uso. Os módulos Especificação de aplicações usuário final e Desenvolvimento de aplicações usuário final formam o quarto grupo ou quarta entrada do ciclo de construção de DM/DW (representada por ➍ na figura 23). A responsabilidade destes dois módulos é prover mecanismos para acesso aos dados a serem disponibilizados aos usuários decisores. Os requisitos e definições provenientes das subfases anteriores Planejamento e Identificação de requisitos e informações servem como entrada para esta subfase e podem ser utilizados por qualquer grupo de módulos. A entrega dos resultados para a fase Produção pode não ocorrer em determinados projetos piloto ou mesmo ter uma utilização mais restrita, como por exemplo, em um projeto piloto cujo objetivo seja testar e 110

122 selecionar ferramenta OLAP, o produto resultante deste projeto pode não ser diretamente disponibilizado para o usuário final, e sim incorporado ao projeto de definição da arquitetura técnica do ambiente de DW da organização. Não é necessária, portanto, a execução da fase produção neste caso. A seguir, uma descrição dos objetivos e atividades de cada módulo que compõe a subfase Ciclo de construção de DM/DW Módulo Arquitetura de dados Neste módulo é escolhida e definida uma arquitetura de dados que seja adequada ao ambiente organizacional e servirá como um mapa de alto nível, onde se poderá identificar e entender como os dados serão organizados ao longo dos sistemas e como serão utilizados no ambiente DW. Esta definição deve basear-se nos objetivos do negócio, obstáculos e prioridades da organização. Principalmente, deve ser adequada para suportar as mudanças que ocorrem no ambiente DW. Na seção 2.8.2, encontra-se uma descrição das arquiteturas de dados mais importantes ( uma camada, duas camadas, três camadas, entre outras). As definições resultantes deste módulo (granularidade, volume etc.) são importantes parâmetros para os dois módulos seguintes: Arquitetura funcional e Infra-estrutura Módulo Arquitetura funcional O objetivo deste módulo é definir o plano geral do fluxo dos dados que ocorrerá no ambiente DW (sistemas operacionais transacionais/dw, DW/usuários, metadados etc.) e o controle dos serviços correspondentes (extração, transformação, carga etc.); basicamente, definir o que se espera do DW quando ele estiver pronto. A proposta de arquitetura funcional de [CHA97], uma das mais simples encontradas na literatura, está detalhada na seção Outros tipos de arquitetura funcional podem ser encontrados em [POE98], [KIM98a] e [SIN01]. Cabe notar que a arquitetura funcional escolhida influenciará diretamente na determinação dos recursos tecnológicos necessários para atendê-la Módulo Infra-estrutura Neste módulo, são realizadas as especificações dos recursos tecnológicos necessários (hardware, software, rede de comunicação, treinamento, assessória etc.) para 111

123 atender à arquitetura de dados e arquitetura funcional escolhidas. Pode ocorrer que a infraestrutura técnica determine características e mudanças na arquitetura funcional. A seta dupla da figura 23 representa a influência mútua entre a arquitetura funcional e a infraestrutura técnica. Vale ressaltar que metadados, embora seja um dos componentes da infra-estrutura de DW, é tratado com detalhes na seção ( Modelagem de metadados ) e ( Infra-estrutura de metadados ) em virtude da sua importância no contexto desta metodologia Módulo Teste de produtos Este módulo é responsável por selecionar os produtos que irão suportar toda a arquitetura técnica definida para o DW (arquitetura de dados, arquitetura funcional, infraestrutura). Isto é, identificar vendedores e produtos para prover as necessidades de negócios identificadas e suas capacidades. As atividades básicas que devem ser realizados são: 1. testar aplicativos e ferramentas; 2. aprender detalhes quanto ao uso; 3. identificar funcionalidades; 4. verificar desempenho, atentando principalmente quanto ao elemento tempo (tempo de extração, tempo de carga, tempo de recuperação de informações etc.). Como se pode observar na figura 23, este módulo pode ser executado várias vezes, ou mesmo não ser necessário. O último caso ocorrerá quando houver a decisão final sobre os produtos disponíveis e devidamente testados. Pode ocorre que alguns produtos não sejam suficientes para atender totalmente às atividades, tais como mapeamento, extração, transformação e carga. Neste caso, deve-se especificar quais programas deverão ser implementados e seus detalhes (função, linguagem de programação, equipe de desenvolvimento, prazos etc.). Para evitar possíveis problemas, em relação à decisão sobre os produtos, é importante avaliá-los através de dois pontos-chave: requisitos do negócio e requisitos técnicos. Para isso, pode ser útil testar algumas ferramentas sob diferentes condições de ambiente (arquitetura de dados, funcional, infra-estrutura) [PER00]. 112

124 Módulo Modelagem de metadados Este módulo e o módulo seguinte ( Infra-estrutura de metadados ) formam a segunda entrada da subfase Ciclo de construção de DM/DM (representada por ➋ na figura 23), que tem o objetivo de definir e controlar as atividades relacionadas aos metadados, fornecendo diretrizes para sua criação, uso e manutenção. Através do repositório de metadados, os metadados estarão disponíveis não só para o ambiente DW como também para toda a organização. Segundo [MAR00], ao iniciar um projeto de metadados, as organizações devem executar as seguintes atividades: definir os objetivos técnicos e de negócio do repositório de metadados; definir os requisitos do projeto antes de avaliar ferramentas de metadados; efetuar avaliação criteriosa antes de selecionar uma ferramenta de metadados; criar uma equipe para o repositório de metadados e trabalhar junto da equipe do DW. Além disso, não deixar que o projeto seja gerenciado pelo vendedor da ferramenta; automatizar a maioria dos processos de integração de metadados; criar padrões de metadados que sejam simples de entender e seguir. Estes padrões devem ser criados logo que possível, para que sejam adotados em todos os projetos de TI da organização e utilizados pelos usuários do negócio e membros da equipe DW; e prover acesso livre aos metadados, tanto por usuários técnicos como de negócio, com pouco ou nenhum esforço. Dessa maneira, as atividades deste módulo têm inicio com a criação de um plano para metadados, incorporado ao plano de projeto. Uma solução completa para gerenciamento de metadados, incluindo metadados de desenvolvimento e metadados para controlar as mudanças do ambiente de produção, pode ser difícil logo de início e requer investimento de tempo e dinheiro. [POE98] recomenda começar com soluções simples e evoluir até soluções de metadados de integração de dados, mais difíceis de construir para os primeiros DM/DW. 113

125 Seguem as atividades realizadas neste módulo, que têm a finalidade de produzir um modelo de metadados, o qual será usado na construção do repositório de metadados e na fase gerenciamento de metadados. Vale lembrar que algumas destas atividades já foram iniciadas na solução de metadados do primeiro protótipo (subfase Planejamento inicial da fase Introdução). 1. definição e classificação dos tipos de metadados que serão armazenados; 2. definição dos tipos de usuários que irão interagir com o DW e o repositório de metadados. Os níveis e métodos de acesso ao repositório devem ser definidos; 3. determinação das fontes de metadados dentro da organização (ferramentas CASE, planilhas, documentos, leis, software etc.); 4. definição e construção do modelo de metadados (veja seções e 4.3.1); e 5. definição do fluxo de metadados (como os metadados se movem durante a construção do DW e a integração destes metadados com os metadados da fase Produção ). As diretrizes para a administração e o gerenciamento de metadados, durante o desenvolvimento dos projetos e quando o DW estiver em produção, devem também ser definidas Módulo Infra-estrutura de metadados Os metadados são vistos como um componente da infra-estrutura do ambiente DW, servindo a todos os outros componentes do ambiente e funcionando como integrador. Portanto, para se alcançar harmonia e unidade dos diferentes componentes do ambiente DW, é preciso estabelecer uma infra-estrutura de metadados. A finalidade deste módulo é definir a infra-estrutura de metadados geral da organização, a partir das definições do módulo anterior ( Modelagem de metadados ). Esta infra-estrutura terá como objetivos: compartilhar metadados pelos diferentes componentes do ambiente DW; permitir autonomia local dos metadados de cada ambiente de negócio, sem interferência de outros usuários de fora do ambiente; e distribuir e usar metadados ao longo de plataformas diferentes. As atividades deste módulo são: 114

126 1. construção de uma arquitetura para metadados (centralizada, descentralizada, distribuída); 2. definição da equipe de gerenciamento de metadados e suas responsabilidades; 3. avaliação de ferramentas de metadados; 4. seleção de uma ferramenta de metadados; 5. implementação física do repositório de metadados; e 6. definição de procedimentos de segurança. Além do desenvolvimento de um repositório de metadados, uma estratégia para coletar, manter e distribuir os metadados deve ser definida. Adicionalmente, é necessário assegurar um mecanismo que povoe e mantenha o repositório de metadados e que todo caminho de acesso ao DW tenha metadados como ponto de entrada. Em outras palavras, assegurar que qualquer dado a ser inserido no DW seja documentado no repositório de metadados e que qualquer ferramenta que vá utilizar os dados do DW necessariamente utilize o repositório. Dessa maneira, pode-se garantir a ausência de dados no DW que efetivamente não estejam bem documentados, registrados e claros no que diz respeito à sua utilização. Todas as pessoas que utilizarem o DW efetivamente estarão acessando os metadados e terão de forma clara, ampla e bem-definida, a origem daquele dado Módulo Modelagem dimensional O objetivo deste módulo é desenvolver um modelo dimensional (veja seção 2.6), baseado nos requisitos do negócio levantados na subfase Identificação de requisitos e informações. Isso equivale a dizer que será selecionada e implementada uma técnica de modelo lógico, entre as tradicionais ( estrela ou floco de neve ) ou suas variações ( estrela com múltiplas tabela fatos, estrela com tabelas associativas etc.), ou ainda adaptar uma modelagem, caso seja necessário, para refletir o modelo de negócio. Independentemente do modelo lógico adotado, deve-se iniciar as atividades deste módulo a partir dos DMs que comporão o DW, cujo objetivo é evitar a proliferação desordenada e sem planejamento desses DM. Entre as estratégias utilizadas para a consecução desse objetivo, pode-se destacar: criar um DW e usá-lo para povoar os DMs, aos quais permanecem conectados [GRA98]; 115

127 realizar inicialmente uma modelagem de dados top down global do empreendimento e posteriormente realizar o desenvolvimento de um ou mais DMs de acordo com o especificado na modelagem [BON98]; e através da implementação do conceito Data Warehouse Bus, proposto por [KIM98a]. A decisão deve basear-se no ambiente organizacional onde o DW será implantado. Com base nos problemas para os quais esta metodologia foi desenvolvida, recomenda-se a estratégia de [BON98] ou [KIM98a]. Outras atividades deste módulo são: análise inicial das diversas fontes de dados que possuem os dados necessários para atender ao modelo de dados definido; definição de quais agregados serão necessários; e o processo para criação e manutenção destes. Estas atividades, sendo iniciadas ainda neste módulo, facilitarão a execução dos módulos Projeto BD (seção ) e Extração e transformação (seção ) Módulo Projeto BD Neste módulo são executadas as atividades que transformam o modelo lógico, definido no módulo Modelagem dimensional, em um banco de dados físico. Estas atividades, como citado, dependem de fatores individuais do projeto, tais como: modelo lógico, DBMS, volume de dados, ferramentas envolvidas, entre outros. As atividades deste módulo estão descritas na seqüência. 1. desenvolvimento de um plano para implementação física, incorporado ao plano de projeto. Este plano deve ser iniciado desde o primeiro projeto piloto, e sua atualização contínua trará facilidades para novos projetos; 2. projeto do modelo físico a partir do modelo lógico; 3. definição dos scripts para criação das tabelas físicas e colunas no banco de dados adotado, utilizando os padrões definidos desde o primeiro protótipo; 4. estimativa do tamanho do banco de dados; 5. revisão do plano de agregação; 6. definição dos índices e estratégias de indexação; 7. definição dos procedimentos de segurança para acesso ao banco de dados; 8. definição dos procedimentos de geração do backup do banco de dados; 116

128 9. instalar o DBMS; 10. determinar os parâmetros fixos do DBMS; 11. construir a estrutura de armazenamento física; e 12. criar as tabelas e os índices, a partir dos scripts produzidos Módulo Extração e transformação Segundo [POE98] e [KIM98a], este é o módulo que consome mais tempo de desenvolvimento em razão da dependência aos dados dispersos nos sistemas OLTP. No entanto, a atividade de localizar, analisar e entender os tipos de dados dos sistemas OLTP, nesta metodologia, é iniciada no módulo Modelagem dimensional e apenas validada neste módulo. A finalidade deste módulo é preparar os dados identificados no módulo Modelagem dimensional e disponibilizá-los para a fase seguinte ( População ), onde os dados serão finalmente armazenados no banco de dados. Para a realização deste objetivo, as atividades básicas deste módulo são: 1. validação dos dados fontes identificados; 2. detalhamento, a partir da arquitetura funcional definida, do fluxo dos dados dos sistemas-fonte para o banco de dados; 3. definição das transformações que serão realizadas; 4. definição de estratégias e procedimentos de carga de dados dentro do DW. Isto é, definir onde e como os dados extraídos serão armazenados, antes de serem carregados no banco de dados; 5. definir como e em que ordem serão realizadas as atividades de extração, transformação e carga; e 6. desenvolvimento de programas para extrair os dados e realizar as conversões destes, quando for o caso Módulo População O objetivo deste módulo é executar os procedimentos necessários para que os dados extraídos e transformados dos sistemas-fonte sejam finalmente armazenados no banco de dados do ambiente DW. Neste módulo, são executadas as seguintes atividades: 1. desenvolvimento dos procedimentos de carga dos dados; 117

129 2. execução dos programas e procedimentos de extração, transformação e carga dos dados; 3. realização de teste completo de todos os procedimentos; 4. desenvolvimento e realização de arquivamento, backup e recuperação de dados; 5. validação e teste dos dados extraídos, transformados e carregados; e 6. desenvolvimento de procedimentos que permitam o tratamento de exceções e geração de estatísticas Módulo Especificação de aplicações usuário final Este módulo e o seguinte compõem a quarta entrada da subfase ciclo de construção de DM/DW e são responsáveis pela disponibilização do front end do DW, ou seja, pelas aplicações, através das quais os usuários acessarão os dados armazenados no DM/DW. As atividades deste módulo podem ser realizadas em dois momentos distintos para cada iteração executada nesta metodologia. O primeiro momento deve acontecer logo depois de terminada a subfase Identificação de requisitos e informações, para evitar uma possível perda de informações, em virtude do tempo despendido entre estes dois módulos. As atividades que devem ser realizadas são: 1. definição dos modelos iniciais de relatórios, baseada nas informações colhidas durante as entrevistas; e 2. identificação de relatórios candidatos. O segundo momento, que tem como ponto inicial os modelos e relatórios definidos nas atividades acima, possui as seguintes atividades: 3. desenvolvimento de uma estrutura geral que permita aos usuários acessar os diversos relatórios de forma padronizada (navegação de menus); e 4. determinação de estruturas padronizadas de relatórios, baseada no nível dos usuários. Como visualizado na figura 23, este módulo sempre antecede o módulo Desenvolvimento de aplicações usuário final para garantir que as especificações sejam revisadas sempre que novo desenvolvimento de aplicações seja necessário. Como algum tempo pode ter passado entre este módulo e o último desenvolvimento de aplicações, é 118

130 aconselhável atualizar os padrões de especificações para refletir as mudanças que normalmente ocorrem Módulo Desenvolvimento de aplicações usuário final As atividades requeridas para este módulo são altamente dependentes do ambiente organizacional onde o projeto DW está sendo desenvolvido e das ferramentas de acesso que serão usadas. Antes de iniciar as atividades deste módulo, propriamente ditas, deve-se determinar a abordagem para implementação dos modelos de relatórios, cujas principais opções disponíveis atualmente são: baseado na WEB, via intranet ou Internet; utilização direta de ferramentas de acesso a dados; e utilização de interface desenvolvida pela equipe de desenvolvimento do DW. Dentre as atividades realizadas neste módulo, pode-se citar: 1. desenvolvimento do conjunto de relatórios; 2. desenvolvimento das estruturas de navegação; 3. documentação das aplicações desenvolvidas; 4. teste das aplicações e verificação dos dados gerados; e 5. desenvolvimento de procedimentos de manutenção e atualização das aplicações desenvolvidas Módulo Disponibilização A finalidade deste módulo é disponibilizar os resultados obtidos em quaisquer das quatro entradas da subfase Ciclo de construção de DM/DW. Somente os resultados da primeira entrada, que se referem a questões mais técnicas do DW, não são disponibilizados de uma forma direta para os usuários finais. Neste caso, pode-se efetuar apenas uma breve explanação sobre os resultados obtidos, para os usuários envolvidos no projeto. Para a disponibilização dos demais resultados, as seguintes atividades devem ser realizadas: 1. teste completo do sistema; 2. checagem profunda da consistência dos dados; 3. treinamento dos usuários; e 4. verificação da infra-estrutura da mesa de trabalho dos usuários (configuração hardware, conexão BD etc.); 119

131 5. avaliação geral do projeto, baseado no estudo de riscos efetuado na subfase Planejamento ; e 6. revisão geral do projeto. 4.5 Fase Produção Os usuários estão acessando os resultados disponibilizados na fase anterior, e esta é a maior recompensa por todo o esforço despendido até aqui. Mas o trabalho de desenvolvimento não termina, porque é a partir do uso contínuo do sistema que os usuários tomarão melhores decisões e novas necessidades podem surgir. O principal objetivo desta fase é planejar os procedimentos que atenderão às novas demandas dos usuários e também do time de desenvolvimento, além de suportar a operação e manutenção do ambiente DW. Os resultados esperados desta fase são procedimentos que permitam ao DM/DW crescer e evoluir, da maneira mais simples possível, sem interferir na sua disponibilidade e desempenho. As funcionalidades de suporte e crescimento, apesar de normalmente ter um emprego mais restrito quando se trata de projeto piloto, acrescentam uma flexibilidade maior na sistemática de desenvolvimento, possibilitando a realização de vários testes. Por exemplo, a partir da disponibilização de um protótipo com tuplas, poder-se-ia identificar novas necessidades junto aos usuários decisores e construir um segundo protótipo com tuplas, utilizando o primeiro como base. A vantagem deste teste seria a verificação do comportamento das tecnologias envolvidas. Duas subfases, denominadas Suporte e Crescimento (figura 20), são responsáveis pelas atividades desenvolvidas para se garantir o contínuo sucesso dos projetos. Estas subfases estão descritas a seguir Subfase Suporte Esta subfase é composta das seguintes atividades: 1. apoiar as atividades diárias de uso do DM/DW; 2. preparar mecanismos e políticas de manutenção da infra-estrutura técnica; 3. definir estratégias para suporte aos usuários finais; 120

132 4. definir estratégias para atualização do DM/DW, assim como os procedimentos de atualização propriamente ditos; e 5. expandir o sistema, com a inclusão de novas aplicações, usuários ou dados, e com o aumento do uso da solução, através da educação dos usuários. O suporte aos usuários deve ir além do simples atendimento a problemas reportados. Não se deve esperar que o usuário relate suas dificuldades e sim continuar com a perfeita sociedade existente desde o início do projeto. Para isso, é importante que a comunicação e a educação dos usuários sejam atividades contínuas, garantindo o monitoramento do sucesso do uso do DW. Dessa forma, o Ambiente DW se mantém estável e a equipe pode cuidar das novas implementações Subfase Crescimento A interação contínua dos usuários com o DW, através de ferramentas e aplicações, faz surgir novas exigências. Conseqüentemente, pode ser necessário reiniciar o ciclo de desenvolvimento, para que as modificações sejam feitas. Além disso, com o sucesso do DW e a natureza evolutiva desta metodologia, os usuários surgirão com novos projetos. O rumo e as regras-bases para o crescimento do DW precisam ser planejados entre a comunidade de usuários e de TI. Portanto, o objetivo desta subfase é sistematizar algumas atividades para facilitar o planejamento e a decisão das oportunidades de evolução e crescimento do DW, tais como: 1. formação de um comitê para decidir as prioridades de iniciativas de crescimento do DW; 2. procedimentos para definição de níveis de crescimento. Os pedidos de mudanças podem variar desde a adição de uma tabela de agregação até a criação de um DM completo; e 3. definição dos processos de requisição das mudanças. Como ilustrado na figura 20, pode-se voltar ao início do ciclo de desenvolvimento. Isto pode ocorrer tanto para projetos piloto quanto para projetos de completos DM/DW, com a vantagem de que o conhecimento e a experiência adquiridos durante cada projeto são usados em projetos subseqüentes. 121

133 4.6 Fase Gerenciamento de metadados A fase Gerenciamento de metadados, ilustrada na figura 20, objetiva controlar e acompanhar as atividades relacionadas aos metadados, durante o ciclo de desenvolvimento e no ambiente de produção do DW. Dessa forma, as atividades desta fase então divididas em três categorias: projeto: as atividades desta categoria visam principalmente a gerenciar as atividades executadas nos módulos Modelagem de metadados e Infra-estrutura de metadados, que compõem a segunda entrada da subfase Ciclo de construção de DM/DM da fase Desenvolvimento. Como já descrito nas seções e , estes módulos são responsáveis pela definição, construção e disponibilização do repositório de metadados. Além de gerenciar as atividades destes módulos, durante todo o processo de desenvolvimento, iniciando ainda na subfase planejamento inicial da fase Introdução (onde é definida a solução de metadados para o primeiro protótipo), deve assegurar que os metadados gerados nas atividades realizadas sejam reunidos e armazenados; produção: nesta categoria estão as atividades para obtenção de metadados, armazenamento de metadados, dentre outras, com a finalidade de colocar os metadados em estado de utilização. Estas atividades são realizadas em todo o ciclo de desenvolvimento; e manutenção: tem o objetivo de controlar o uso, a segurança, a integridade e a qualidade do repositório de metadados, no ambiente de produção do DW. A principal atividade é manter os metadados atualizados. 4.7 Fase Gerenciamento do projeto Em virtude do desenvolvimento incremental e evolucionário da metodologia X-Meta, a fase Gerenciamento do projeto (figura 20) objetiva manter os produtos gerados pelas diversas iterações sob controle e em sincronia. Em linhas gerais, constitui-se do acompanhamento rigoroso das atividades previstas nas subfases e módulos, como também da seqüência de tarefas executadas em cada iteração na metodologia proposta, visando a assegurar o cumprimento integral dessas atividades. Para garantir este 122

134 acompanhamento, além das técnicas básicas de gerenciamento de projeto, é necessário focar a preservação do escopo de cada projeto, delimitando o inicio e o fim de cada um. O desenvolvimento do DW nunca termina. Portanto, a comunicação dentro da organização é essencial para manter a expectativa organizacional com o DW sob controle. Principalmente, não se há de esquecer de documentar tudo e manter um histórico da documentação acessível a todos os envolvidos. 123

135 5 ESTUDO DE CASO 5.1 Introdução O objetivo deste capítulo é apresentar o estudo de caso onde a metodologia de desenvolvimento de DW X-Meta, apresentada no capítulo 4, foi aplicada. Na próxima seção, estão descritos o ambiente organizacional e a área de negócio selecionada para este estudo de caso, destacando-se seus pontos críticos. Em seguida, na seção 5.3, estão detalhados o desenvolvimento do projeto e os resultados alcançados. Ao final do capítulo, será discutida e analisada a aplicação da metodologia X-Meta na SEFIN, destacando-se os benefícios decorrentes da introdução de sistemas automatizados de apoio à decisão. 5.2 Descrição do Ambiente A Secretaria de Finanças do Município - SEFIN, órgão da administração direta da Prefeitura Municipal de Fortaleza - PMF, tem por finalidade Desenvolver as políticas financeira, orçamentária, tributária e fiscal junto ao Poder Executivo Municipal [CON01]. A área tributaria foi escolhida para este estudo de caso, detalhado na seção 5.3, em virtude da sua importância junto ao Prefeito e aos Munícipes e, principalmente, pela disponibilização dos dados e de profissionais internos da organização. Este domínio é responsável pela entrada de recursos financeiros próprios nos cofres do Município, que são as receitas oriundas dos impostos: IPTU (Imposto Predial e Territorial Urbano), ISS (Imposto Sobre Serviços) e ITBI (Imposto Transmissão Bens Inter-vivos); e Taxas: TIS 124

136 (Taxa de Instalação e Registro Sanitário), TIP (Taxa de Iluminação Pública), dentre outras de competência do Município. Para entender os processos de negócio da área tributária, utilizou-se o diagrama de caso de uso da UML, ilustrado na figura 24, que fornece uma visão de alto nível das funcionalidades (elipses), mediante o recebimento de uma requisição (setas) de usuários (stick man). Paga imposto/taxa Dá entrada em Processo Contribuinte Calcula imposto/taxa Efetua cobrança Controla arrecadação Funcionário SEFIN Efetua fiscalização Figura 24 Casos de uso da área tributária O sistema de informação da SEFIN, responsável pelo controle do lançamento, cobrança, arrecadação e fiscalização de impostos e taxas da PMF, é denominado Sistema de Tributos. Este sistema é formado por um conjunto de sistemas OLTP, constituído por cerca de 235 tabelas e oitocentos programas desenvolvidos em DATAFLEX, que é uma ferramenta de desenvolvimento que engloba um SGBD relacional e um Sistema Gerador de Aplicações [BUR88]. Estes programas são executados em plataforma AIX. O sistema de tributos possibilita um restrito suporte à decisão através de relatórios pré-formatados. Normalmente, os relatórios de natureza gerencial são complexos, referemse apenas a um ano e não apresentam padrões e tendências. A grande maioria desses relatórios tem a mesma formatação há vários anos e eles são emitidos somente quando solicitados. Um novo relatório normalmente demora de quatro a dez dias para ser 125

137 confeccionado, não conseguindo atender às necessidades dos decisores no momento oportuno. Outro agravante no contexto do Sistema de Tributos é a falta de documentação dos processos e modelo de dados. O sistema foi desenvolvido há doze anos e pouca ou nenhuma atenção foi dada à documentação de novas rotinas ou alterações feitas ao longo desse tempo. Vale destacar que estas mudanças não podem ser perdidas por no mínimo 10 anos (tempo de decadência), pois é garantido a qualquer contribuinte questionar, por exemplo, um cálculo de tributo ou cobrança indevida. No entanto, as regras definidas nas leis, atos e instruções normativas estão armazenadas nos programas dos sistemas legados ou na cabeça dos funcionários. Como normalmente os diretores são trocados, em média, a cada quatro anos, na maioria das vezes esse conhecimento sai porta a fora. Por causa desta grande rotatividade, pelo menos uma parte do conhecimento poderia ser formalizada e os novos diretores não precisariam depender das pessoas, que raramente dão seu conhecimento, principalmente em instituições públicas. Relembrando o que foi abordado na seção 1.2, ressalta-se que a SEFIN possui recursos computacionais modernos, que podem ser utilizados no primeiro projeto DM/DW, assim como profissionais altamente capacitados em desenvolvimento de sistemas e BD, alguns inclusive com conhecimentos em SAD. Apesar disso, atualmente não existe nenhum sistema desse tipo em apoio ao sistema de tributos ou a outras áreas da SEFIN. Esse conjunto de fatores caracteriza a área tributária da SEFIN como um exemplo típico do contexto adotado neste trabalho. Dentro desta área, o domínio Arrecadação do IPTU foi escolhido para este estudo de caso, como será abordado na seção 5.3. Para compreender como os dados são utilizados no funcionamento do negócio, a figura 25 ilustra o modelo de dados da rotina que atualmente fornece o relatório Inadimplentes IPTU no Exercício (IP RINAE). Para se ter uma idéia da complexidade deste relatório, uma cópia dele pode ser encontrada no Anexo A. Este relatório é analisado pela assessoria técnica do Secretário de Finanças da PMF, juntamente com outros relatórios, para fornecer informações sobre o comportamento da arrecadação do IPTU ao Prefeito. A base de dados disponibilizada para esta rotina é composta por 8 tabelas principais (figura 25), além de outras tabelas auxiliares não diagramadas, como tabela de índices financeiros, tabela de situação, dentre outras. Das tabelas principais, 3 podem ser consideradas tabelas primárias: 126

138 IPTUIMOV.DAT: contém os dados sobre os imóveis do Município, possuindo atualmente mais de tuplas. Os dados armazenados identificam cada imóvel através de sua localização fiscal (região), localização administrativa (regional), tipo do imóvel (predial, territorial, favela), classificação arquitetônica (casa, apartamento, sala, loja, galpão etc.), proprietário, características do terreno, características da edificação, dentre outras. IPTUPAR.DAT: armazena o lançamento do IPTU do exercício corrente. Existe uma tupla para cada imóvel, a exceção de imóveis imunes e favelas. A cada novo exercício fiscal, os lançamentos do exercício anterior são expurgados desta tabela e gravados em outra, que armazena os lançamentos de exercícios anteriores. IPTUREC.DAT: contém as transações de pagamentos realizados para liquidar o débito do IPTU do exercício atual. 1 n n 1 n n n n n 1 1 n 1 Figura 25 Modelo de dados da rotina IP RINAE Para cada tupla da tabela IPTUPAR.DAT podem ocorrer até 12 tuplas na tabela IPTUREC.DAT. Caso uma tupla da tabela IPTUPAR.DAT não esteja associada a tuplas da tabela IPTUREC.DAT, então o imóvel é um total inadimplente. A opção de pagamento pode ser feita pelo contribuinte de três formas distintas: cota única (realizado através de um único pagamento, com desconto de 21%); desconto de 10% (quando realizado em até seis parcelas) e sem desconto (quando realizado em mais de seis parcelas). Vale ressaltar que estes critérios de recebimento, como também os de lançamentos do IPTU, têm sido normalmente modificados nos últimos anos. Isto mostra a necessidade de se manter 127

139 atualizada a documentação das rotinas, principalmente armazenar o histórico das mudanças. 5.3 Projeto: Introdução da Tecnologia DW na SEFIN O objetivo deste estudo de caso foi desenvolver o primeiro projeto piloto de DW da SEFIN, aplicando a fase Introdução, primeira fase da metodologia X-Meta, de forma a construir um protótipo que disponha de ferramentas de análise e acompanhamento, com enfoque na área de Arrecadação do IPTU. Apesar da natureza acadêmica deste projeto, ele foi apresentado para os diretores, assessores, e o próprio Secretário de Finanças, sendo incluído no Plano Gerencial 2001 da SEFIN. Isto ratificou o interesse e comprometimento de todos, principalmente do Departamento Central de Processamento de Dados (DCPD), de onde partiu a iniciativa do projeto. Após a aprovação do projeto, que inicialmente teve um prazo de três meses para conclusão, o DCPD disponibilizou um microcomputador para ser o servidor, e o SGBD Oracle, recursos que não tiveram nenhum investimento financeiro. A equipe de desenvolvimento empregada no projeto foi constituída por três pessoas, todas com aprofundados conhecimentos no desenvolvimento de sistemas OLTP. Essa equipe era composta por um coordenador/desenvolvedor e uma colaboradora, ambos com conhecimentos aprofundados em DW, entretanto sem experiência no desenvolvimento de projetos DW; e um DBA, este último sem conhecimentos consideráveis de DW. Além destas, integrou-se ao projeto a assessora técnica, que analisava os resultados da arrecadação do IPTU. A seguir, estão detalhadas as atividades realizadas para a consecução deste projeto Planejamento Inicial Nesta primeira etapa, que corresponde à primeira subfase da fase Introdução, da metodologia X-Meta (figura 20), foram realizadas as seguintes atividades: 128

140 1. Definição do escopo do projeto Como a equipe de desenvolvimento já tinha conhecimento sobre o negócio da organização, procurou-se identificar um nicho do negócio onde estava ocorrendo demanda por informações gerenciais. Dessa forma, verificou-se junto à assessoria técnica que o relatório IP RINAE, normalmente solicitado ao final de cada exercício, estava tendo intensas solicitações. Além disso, este relatório era manipulado pela assessora técnica, juntamente com outros, para fornecer informações sobre a previsão e o comportamento da arrecadação do IPTU. Portanto, este foi o foco escolhido para o primeiro projeto, por estar em destaque e ser uma área de interesse do Secretário e do Prefeito. Durante a definição do escopo do projeto, um estudo fundamentado sobre a viabilidade de realização do projeto e justificativa do negócio, abordando custos e retornos, foi apresentado ao Secretário de Finanças. Uma cópia deste documento encontra-se no anexo B. Após sua aprovação, a equipe deu início aos trabalhos, que começou com a apresentação de um mini-seminário para disseminar os conceitos Data Warehousing. Antes de dar continuidade às atividades, criou-se o documento Plano de Projeto, utilizando-se a ferramenta de gerenciamento de projeto MS-Project. Este documento, apresentado no anexo C, foi continuamente atualizado, até a conclusão do projeto. 2. Definição da infra-estrutura técnica Apesar da constatação de que não seria realizado nenhum investimento financeiro, a SEFIN dispunha de componentes que poderiam ser utilizados para compor a infraestrutura técnica do projeto, como já citado no documento do anexo B. Dessa forma, foram disponibilizados componentes da arquitetura AIX e NT, além de componentes do SGBD Oracle. Neste momento, foi elaborado o esboço inicial da arquitetura funcional, que foi completamente finalizada no módulo Projeto BD, na subfase seguinte. A definição final do funcionamento do ambiente está esquematizada na figura Definição dos participantes, responsabilidades e prazos de conclusão Foram definidas as responsabilidades pela execução das tarefas, tanto desta subfase como da subfase seguinte, assim como os prazos de conclusão. Inicialmente foi apresentado um cronograma, quando da elaboração do documento do projeto (anexo B). Posteriormente foi detalhado novo cronograma, na subfase Desenvolvimento 1 0 protótipo, e atualizado o Plano de Projeto (anexo C). Vale destacar que somente 20 horas 129

141 semanais de cada componente da equipe foram dedicadas ao projeto, inicialmente. Esta restrição, como também a não-existência de um local físico apropriado, refletiu mais tarde no cumprimento dos prazos. 4. Definição dos requisitos O levantamento das necessidades analíticas foi realizado através do estudo dos relatórios gerenciais produzidos pelos sistemas OLTP da SEFIN e entrevistas com usuários. Pode-se citar como exemplo de alguns relatórios gerenciais: Demonstrativo do parcelamento; Resumo Financeiro; Inadimplentes no exercício (anexo A); Previsão do cálculo; e Receitas mensais (emitido pelo sistema de contabilidade). Cabe ressaltar novamente que estes relatórios gerenciais referem-se somente a um ano, não sendo habitual a geração de relatórios que integrem vários anos, embora estas informações estejam armazenadas e disponíveis. As entrevistas com a assessora técnica, que fornece informações gerenciais ao Secretário, permitiram identificar, dentre outras coisas, que: as informações analíticas, atualmente disponibilizadas ao Secretário, são gráficos/relatórios Excel, ou ainda relatórios formatados no Word, gerados a partir de dados extraídos dos relatórios gerenciais emitidos pelo sistema de tributos; mesmo extraindo e manipulando os dados, para gerar relatórios mais resumidos e com as informações solicitadas, estes relatórios formatados para análise referem-se normalmente a único exercício; os gráficos ou relatórios gerados no Excel somente são criados quando solicitados pelo Secretário, geralmente para eventuais entrevistas com a imprensa, ou quando solicitado por outras instituições; além do tempo de geração dos relatórios gerenciais no sistema OLTP, ainda é gasto um tempo considerável para a formatação dos gráficos, o que muitas vezes não atende às solicitações no momento oportuno; e com todos estes problemas, existe ainda grande preocupação quanto a informações divergentes entre os diversos relatórios gerenciais do sistema de tributos, e ainda com possíveis erros que podem ser gerados ao se manipular informações de forma manual. 130

142 Após criteriosa análise das informações e minucioso estudo dos relatórios OLTP, inclusive do código DATAFLEX usado para gerá-los, pôde-se observar, na prática, como resultado dessa atividade, que: os atributos do negócio absolutamente requeridos para apresentação dos dados são regional, uso do imóvel, faixa de valor venal e opção de pagamento; e os atributos desejáveis são alíquota e situação do lançamento; o problema da divergência nos relatórios do sistema de tributos é a falta de documentação sobre a natureza, objetivo e atributos de cada relatório. Além disso, os mesmos não refletem as alterações que ocorrem nos dados dos imóveis e, conseqüentemente, na arrecadação; e o sucesso das entrevistas, conseguido principalmente em virtude do cuidado na preparação destas. Focamos pontos como: quem entrevistar, o que perguntar, controlamos o tempo da entrevista e, principalmente, documentamos os resultados. Os resultados, devidamente organizados, foram posteriormente apresentados aos entrevistados para aprovação. Em conseqüência, a assessora técnica passou a integrar a equipe do projeto. 5. Definição do que será disponibilizado aos usuários Durante a apresentação dos resultados alcançados com a definição dos requisitos, ficaram decididos os relatórios e consultas prioritárias a serem disponibilizados inicialmente pelo protótipo: 1. concentração dos imóveis lançados; 2. concentração dos pagamentos; 3. inadimplência; 4. previsão da arrecadação; e 5. comportamento da arrecadação. Além disso, todas as consultas e relatórios teriam os seguintes padrões: utilização dos atributos-chaves identificados: regional, uso do imóvel, faixa de valor venal, alíquotas, parcelamento do imposto, situação do lançamento e opções de pagamento; 131

143 armazenamento dos dados com a maior granularidade possível, pois os relatórios atualmente utilizados não se referem a dados individuais dos imóveis. Com isso, evita-se manipular dados muito detalhados, simplificando e tornando mais rápida a recuperação dos dados e informações; apresentação dos dados através de interface gráfica padrão Windows, com a qual os usuários já estão acostumados a trabalhar; e Acesso às consultas e relatórios através do MS-Excel e alguns previamente formatados. 6. Definição da solução de metadados do protótipo Inicialmente, decidiu-se que a solução de metadados do protótipo teria apenas a finalidade de reunir e disponibilizar os metadados aos usuários, de forma manual. Como o objetivo dessa atividade é entender e aprender a identificar e documentar metadados, tornase necessário apenas definir o modelo conceitual. Armazenar e consultar metadados, isto é, o modelo físico, está fora do escopo deste estudo de caso, em razão da sua complexidade. Após a definição sobre os objetivos da solução, foi designada à colaboradora do projeto a função de gerenciamento da solução de metadados, a qual deveria dedicar, de início, a metade do seu tempo a esta tarefa. A partir desta decisão, todas as atividades envolvendo metadados ficaram sob sua responsabilidade, e ela apresentava todas as decisões tomadas aos demais integrantes da equipe. Para a classificação dos tipos de metadados, optou-se pela definição de [INM98]: metadados negócio e metadados técnico. Como citado na seção 1.2, existe pouco conhecimento dos usuários no negócio, principalmente quando se trata de histórico. Portanto, foram destacados os metadados relacionados às regras e estrutura do negócio em uma classificação própria, metadados de negócio. Nesta classe também devem estar incluídos as regras de transformação, sumarização, e outros, que os usuários finais possam utilizar para agregar valor às informações. Na classe metadados técnicos, estarão os metadados dos processos ETL, a estrutura dos dados dos sistemas OLTP, a estrutura dos dados do DW, nomes e definições dos relatórios dos usuários, dentre outros, que basicamente servirão aos desenvolvedores. Para a identificação dos diferentes tipos de metadados da classe negócio e suas relações foi elaborada uma representação gráfica das regras do negócio, da área 132

144 estabelecida para o protótipo, e que teriam seus dados modelados para análises. O diagrama ilustrado na figura 26 mostra a estrutura operacional da Arrecadação do IPTU, construída, principalmente, através dos atributos-chaves para apresentação dos dados já identificados nas atividades anteriores. Um exemplo dos metadados de negócio identificados pode ser visto na tabela 9. Arrecadação IPTU Tem Lançamento Isenção Recebimento Por Tipo imóvel Por Por Faixa valor venal Automática Forma Solicitada Por Quantidade prestações Tem Tem Alíquotas Figura 26 Estrutura operacional da arrecadação do IPTU A partir dos metadados de negócio identificados e dos metadados técnicos definidos, foi criado o modelo conceitual do metamodelo para o prótotipo, como visto na figura 27. Este metamodelo, que também é um protótipo, será posteriormente concluído quando do projeto de construção do repositório de metadados corporativo, oportunidade em que se utilizará a segunda entrada do ciclo de construção de DM/DW (representada por ➋ na figura 23 e detalhada na seção 4.4.3). A opção pelo modelo relacional para a representação do metamodelo (figura 27) levou em consideração o fato de que o modelo relacional é mais fácil de desenvolver e entender do que o modelo orientado a objeto (OO) [MAR00]. Além disso, o metamodelo será posteriormente ampliado para uma solução mais completa e no plano corporativo, quando é recomendado utilizar o modelo UML, pois este permite maior manutenibilidade e facilidade de expansão. 133

145 1 1 n 1 n n Figura 27 Modelo conceitual do metamodelo Quanto a esta atividade, os seguintes detalhes foram observados: as informações coletadas nas entrevistas e relatórios gerenciais não foram suficientes para reunir os metadados de negócio, sendo necessário uma pesquisa em [CON01] e nos programas OLTP que efetuam o cálculo do IPTU e a atualização dos pagamentos (baixa). Através dessa pesquisa, recuperou-se o histórico das mudanças, como se pode observar nos exemplos de metadados da tabela 9; e os metadados técnicos foram identificados e documentados a medida das necessidades detectadas durante a subfase Desenvolvimento 1 0 protótipo. O objetivo da solução de metadados do protótipo foi posteriormente ampliado, para permitir acesso a metadados da classe negócio, através da ferramenta de apresentação dos dados. Foi criado uma tabela, para armazenar os metadados, no servidor NT, com a mesma estrutura apresentada na figura 26, para acesso via MS-Excel. Isto foi possível em virtude da simplicidade da estrutura operacional da arrecadação do IPTU. 134

146 Tabela 9 Metadados de negócio do protótipo Exercício Lançamento 1998 Alíquota 0,7% 1999 Alíquota 1% 2000 Alíquota 1% 2001 Residencial com vl. venal até R$ alíquota de 1% Residencial com vl. venal > R$ alíquota 1,5% Não residencial com vl. Venal até R$ alíquota 1% Não residencial com vl. Venal > R$ alíquota 2,0% Territorial não dotados de infra-estrutura urbana alíquota 1% Territorial dotados de infra-estrutura urbana alíquota 2% 2002 Residencial com vl. Venal até R$ alíquota 0,6% Residencial com vl. venal > R$ e <= R$ ,00- alíquota 0,8% Residencial com vl. venal > R$ alíquota 1,4% Não residencial com vl. venal até R$ ou sem infra-estrutura alíquota 1% Não residencial com vl. venal > R$ e dotados de infra-estrutura alíquota 2% Territorial não dotados de infra-estrutura alíquota 1% Territorial dotados de Infra-estrutura e com muro e calçada alíquota 1,6% Territorial dotados de infra-estrutura e sem muro ou sem calçada alíquota 2% Exercício 1998 Isenção total - vl. venal até 10000,00 UFIR 1999 Isenção total - vl. venal até 10000,00 UFIR 2000 Isenção total - vl. venal até 10000,00 UFIR 2001 Isenção total - vl. venal até 13302,00 Reais 2002 Isenção total - vl. venal até 16627,00 Reais Isenção Exercício Recebimento 1998 Pagamento total até 31/01/ % desconto 1999 Pagamento total até 31/01/ % desconto Pagamento em até 6 parcelas 10% desconto Pagamento de 7 até 12 parcelas sem desconto 2000 Residencial e não residencial Pagamento total até 31/01/ % desconto Pagamento em até 6 parcelas 10% desconto Pagamento de 7 até 12 parcelas sem desconto 2001 Pagamento total até 31/01/ % desconto Pagamento até 6 parcelas 10% desconto Pagamento de 7 até 12 parcelas sem desconto 2002 Pagamento total até 08/02/ % desconto Pagamento até 6 parcelas 10% desconto Pagamento de 7 até 12 parcelas sem desconto Terrenos Pagamento total até 31/03/ % desconto Pagamento em até 6 parcelas 10% desconto Pagamento de 7 até 10 parcelas sem desconto Resultados obtidos na subfase Planejamento inicial No final desta subfase, pode-se observar na prática os seguintes resultados: visão geral dos diversos aspectos de natureza operacional e gerencial que compõem a área de arrecadação do IPTU da SEFIN; a expectativa dos usuários em realizar o projeto de DW foi crescendo a cada atividade realizada e apresentada; a falta de cultura analítica foi reduzida através de seminários ministrados para os usuários e pessoal de TI; 135

147 a equipe de desenvolvimento ampliou seus conhecimentos em Data Warehousing e conseguiu diferenciar as tecnologias que cercam os sistemas operacionais transacionais e os sistemas de apoio à decisão; apesar da interrupção do projeto durante o final do exercício de 2001, como se pode observar no plano de projeto (anexo C), a retomada das atividades aconteceu de forma natural, inclusive com ritmo mais intenso. Este fato foi resultado do horário integral dedicado pelo coordenador do projeto, quando foi dada prioridade ao projeto; e O rigoroso acompanhamento do projeto evitou a perda de foco e manteve o escopo do projeto alinhado com seus objetivos Desenvolvimento 1 0 Protótipo Ao iniciar esta subfase, a principal preocupação foi tentar simplificar ao máximo o projeto, garantindo, no entanto, que todas as necessidades detectadas e acordadas durante o planejamento fossem atendidas. A construção do protótipo foi realizada através da sistemática de desenvolvimento apresentada na seção (figura 22), cujos módulos, à exceção do módulo Disponibilização, foram repetidos duas vezes. Ao longo da execução repetitiva da subfase Desenvolvimento do 1 o Protótipo foram sendo testados e consolidados os diversos componentes das arquiteturas AIX e NT, a modelagem dimensional e os objetos a serem criados na base de dados. Na primeira experiência, utilizou-se um conjunto bastante reduzido de dados (um exercício), que não foi disponibilizado aos usuários. Na segunda experiência, foram empregados três exercícios (2000, 2001 e 2002), totalizando em torno de tuplas. Neste momento, o projeto piloto foi nomeado de Sistema de Análise da Arrecadação do IPTU (SAAI). A seguir estão detalhadas todas as atividades realizadas em cada módulo executado, bem como as diversas particularidades e dificuldades encontradas Modelagem dimensional A análise criteriosa das tabelas descritas na seção 5.2, como também dos relatórios gerenciais, permitiu observar que os dados relativos à arrecadação do IPTU podem ser reunidos em 2 unidades de negócio denominadas lançamento e recebimento. Alguns atributos comuns entre estas unidades de negócios foram identificados: regional, uso do 136

148 imóvel, faixa de valor venal, alíquota e quantidade de parcelas. No entanto, a representação do negócio em única tabela fato tornou-se inviável, pois cada uma dessas unidades apresenta peculiaridades com relação a outros atributos, como pode ser observado a seguir. Lançamento Cada imóvel possui único valor lançado por ano, que representa o valor devido do imposto IPTU. O valor lançado é calculado no primeiro dia de cada exercício através da aplicação de uma alíquota sobre o valor venal do imóvel. O valor lançado de um imóvel é dividido de uma até doze parcelas, dependendo do valor mínimo estimado em lei. No entanto, podem ocorrer cálculos de novos imóveis no decorrer do exercício, ou um cálculo pode ser alterado, o que se denomina relançamento. Pode ocorrer ainda a exclusão do valor lançado, que pode acontecer por erro, cancelamento ou isenção. Observa-se aí o principal problema destacado pelos usuários, mudanças no lançamento que causam inconsistências durante as análises atualmente realizadas. Além disso, determinados imóveis podem iniciar o lançamento anual já em situação de isenção, situações também previstas em lei. Estas situações não são previstas no recebimento. Recebimento O valor pago pelo contribuinte para liquidar o débito de cada imóvel lançado pode ser realizado de forma parcelada, ou de uma única vez, o que se denomina cota única. A opção pelo pagamento feita pelo contribuinte, portanto, ocorre após o lançamento do IPTU. Atualmente, o pagamento em cota única recebe desconto superior ao desconto concedido para pagamento parcelado em até seis vezes, e acima de seis parcelas não existe desconto. Vale ressaltar que tanto as regras de lançamento como as de recebimento do débito, utilizadas em um exercício, têm sido normalmente modificadas para o exercício seguinte, como se pode constatar através dos metadados descritos na tabela 9. A partir destas considerações e dos atributos identificados durante a descoberta de requisitos do negócio, foi realizada a modelagem conceitual do protótipo, empregando-se o esquema estrela com múltiplas tabelas fato. A figura 28 mostra a visão conceitual da modelagem do protótipo. A decisão por este tipo de esquema decorreu da constatação de que as unidades de negócio identificadas possuem atributos dimensionais não comuns (tipo de isenção e opção de recebimento), representando situações distintas. Além disso, a periodicidade de carga dos dados da tabela fato lançamento é anual e a da tabela fato 137

149 recebimento é mensal. Dessa forma, cada unidade de negócio (lançamento e recebimento) ficou representada em tabelas fato distintas. 1 1 n n 1 n n n n 1 n 1 1 n n 1 n n 1 Figura 28 Modelagem dimensional do protótipo Neste módulo, detectou-se a necessidade de documentação dos metadados técnicos. Foi elaborada uma planilha, apresentada na figura 29, que mostra a origem dos atributos das tabelas do DW. Observa-se que alguns atributos são originados de transformações de mais de um atributo do sistema OLTP, como é o caso do atributo uso do imóvel. Estes metadados devem ser posteriormente incluídos no metamodelo da figura 27. Vale destacar que a planilha somente foi completamente finalizada no módulo Extração e transformação. Quanto a esta atividade, verificaram-se as seguintes detalhes: antes de se realizar a modelagem conceitual, foram efetivados vários estudos, de modo a identificar os componentes a serem utilizados (granularidade, esquemas multidimensionais etc.); 138

150 este foi o módulo que consumiu mais tempo, principalmente pela falta de experiência da equipe neste tipo de modelagem; a tendência em utilizar a maior granularidade possível, como destacado na seção , e decidida durante a subfase Planejamento inicial, dificultou a utilização do atributo faixa de valor venal, dada a grande especificidade de valores; e para resolver o problema das mudanças no lançamento, destacadas pelos usuários desde o início do projeto, que causam inconsistências durante as análises atualmente realizadas, a tabela lançamento deve ser expandida para ser carregada mensalmente com a situação dos lançamentos ao final de cada mês. Dimensão tempo Dimensão regional Dimensão alíquota Dimensão uso imóvel Origem Operação Destino - - nr_mes - - nr_ano - Auto-incremento id_tep - - ds_reg - Auto-incremento id-reg Iptupar.alíquota - vl_alq - Auto-incremento Id_alq Iptuimov.tipoimovel, ds_uso_imo Iptuimov.usoespecifico Se tipoimovel=predial Se usoespecifico=casa ou apto. residencial Senão não residencial Senão territorial - Auto-incremento id_uso_imo Situdiv.situacao - ds_ise Dimensão tipo isenção Iptupar.situacao - id_ise ds_rec Dimensão recebimento Dimensão parcela Fato lançamento anual - 1 cota única 2 até 6 parcelas 3 acima 6 parcelas - Auto-incremento id_rec Iptupar.qtdpar - id_qtd_par Iptupar.qtdpar - ds_par Iptupar.qtdpar Soma de ((Iptupar.qtdpar-1) * vl_lan iptupar.valdpar iptupar.valdpar+ iptupar.val1par iptupar.val1par) - - qt_lan Iptupar.qtdpar iptupar.valdpar iptupar.val1par Se não tem endereço correspondência vl_sem Soma de ((Iptupar.qtdpar-1) * iptupar.valdpar+ iptupar.val1par) - Contador da quantidade de imóveis qt_sen Iptupar.vlrvenal Soma dos valores venais vl_vve Ipturec.valpag Soma dos valores recebidos vl_rec qt_rec Fato recebimento - Contador da quantidade de recebimentos Figura 29 Metadados técnicos do protótipo 139

151 Projeto BD Neste módulo, foram realizadas diversas atividades, destacando-se as seguintes: definição de padrões para o nome das tabelas: TTT_NN1_NN2_..., onde TTT representa o tipo da tabela (TBF=Tabela fato, TBD=Tabela dimensão, TBI=Tabela temporária, TBE=tabela externa) e NN1,NN2,..., são nomes ou abreviaturas que irão formar o nome sugestivo para a tabela. Por exemplo, a tabela lançamento anual será definida no banco de dados como TBF_LAN_ANU. Todas as abreviaturas serão definidas e armazenadas no repositório de metadados para serem facilmente consultadas; definição de padrões para o nome dos atributos das tabelas: TT_NNN_NNN..., onde TT representa o tipo do atributo (VL=Valor, NM=Nome, CD=Código etc.) e NN1,NN2,.., são abreviaturas de nomes que irão formar o nome sugestivo para o atributo. Por exemplo, o atributo valor mínimo da Parcela seria definido em qualquer tabela do banco de dados como VL_MIN_PAR ; criação dos scripts para criação do BD; Criação dos scripts para criação das tabelas no DW, inclusive das tabelas temporárias dos processos de agregação; cálculo sumário do espaço de armazenamento necessário, em disco rígido, para acomodar a base de dados analítica, considerando todos os seus objetos, inclusive os decorrentes da área de organização de dados. Para o protótipo, foi alocado um espaço mínimo de 2,5 gigabytes; definição dos procedimentos de backup e recuperação dos dados, em caso de perda; e teste e execução dos scripts. No final deste módulo, foi finalizada a arquitetura funcional do protótipo, como mostrado na figura 30. Através desta arquitetura, foi possível representar os componentes e detalhar, no plano operacional, como e quando será realizada a maioria das atividades do sistema SAAI. 140

152 SISTEMAS FONTE Arquivos : Cadastros do IPTU Formato : DATAFLEX Localização: Servidor RISC/AIX EXTRAÇÃO e TRANSFORMAÇÂO (programas Dataflex) ÁREA DE ORGANIZAÇÃO DE DADOS Servidor AIX Servidor NT Arquivos : Lançamento e Recebimento Formato : Texto detalhado CÓPIA programa FTP Arquivos : Lançamento e Recebimento Formato : Texto detalhado MS-Excel SERVIDORAPLICAÇÃO Servidor NT Conexão proprietária Via ODBC SERVIDOR BANCO DE DADOS Servidor NT AGREGAÇÃO E CARGA (programa PL/SQL) CONSULTA Repositório metadados DW Figura 30 Arquitetura funcional do protótipo Os principais aspectos observados durante o módulo projeto BD foram: a participação do DBA com profundos conhecimentos no SGBD Oracle foi de fundamental importância para a conclusão desta atividade; a alocação de espaço em disco magnético acima do esperado, para um protótipo que armazena apenas dados sumarizados, deveu-se às várias atividades de organização de dados realizadas com as tabelas auxiliares, que não integram diretamente o esquema dimensional adotado; e foram realizados muitos testes e experimentações, até se chegar à configuração mais adequada. 141

153 Extração e transformação As transformações necessárias para determinados atributos dimensionais foram definidas no módulo Modelagem dimensional e validadas neste módulo. Além desta atividade foram realizadas mais as seguintes atividades: desenvolvimento dos programas de extração em DATAFLEX; e definição da política de extração para o contínuo uso do DW População As atividades realizadas neste módulo foram: desenvolvimento de programa de carga em PL/SQL que fará a leitura do arquivo tipo texto gerado pelo programa de extração e gravará os dados na tabela auxiliar; desenvolvimento de um script em PL/SQL para ler os dados armazenados na tabela auxiliar e gravar nas tabelas fato correspondente; teste e execução dos programas; e definição da política de carga para o contínuo uso do DW Disponibilização Desde a subfase Planejamento inicial, ficou decidido que a apresentação dos dados seria através do Microsoft Excel, pois os usuários do DW já estavam familiarizados com a ferramenta. No entanto, foram necessários um estudo mais aprofundado por parte dos desenvolvedores e um treinamento avançado para os usuários, de forma que estes aprendessem a utilizar todas as potencialidades analíticas do MS-Excel. O MS-Excel contém um software cliente que permite que o usuário trabalhe com dados de bancos de dados OLAP criando e interagindo com relatórios de tabela e gráficos dinâmicos. Este banco de dados OLAP é criado a partir do banco de dados relacional, que neste caso é o Oracle, através da conexão ODBC (figura 30). A seguir estão descritos os passos necessários para a disponibilização das consultas: (1) configurar uma fonte de dados, que fornece as informações necessárias para que o Excel se conecte ao Oracle. Para configurar esta fonte de dados OLAP para o Excel foi utilizado o Microsoft Query. 142

154 (2) criar o cubo OLAP através de um provedor OLAP. Foi utilizado o Microsoft OLE DB Provider for OLAP Services; (3) criar tabela dinâmica utilizando planilha do MS-Excel. Durante o treinamento, foram validadas, junto aos usuários, as últimas consultas disponibilizadas. O anexo D apresenta algumas consultas do sistema SAAI Resultados obtidos na subfase Desenvolvimento 1 0 Protótipo No final desta subfase, pode-se observar na prática os seguintes resultados: os módulos desta subfase praticamente foram executados em paralelo, havendo uma dependência intrínseca entre algumas atividades; mesmo que não houvesse ocorrido a interrupção do projeto, a maioria das atividades desta subfase seria repetida, principalmente para ajudar no fator inexperiência em DW, da equipe de desenvolvimento; e no final do desenvolvimento das atividades desta subfase, houve mais uma mudança administrativa de grande impacto na PMF. Especificamente na SEFIN, além de substituições de diretores, a estrutura organizacional foi bastante alterada. Para alívio da equipe, foi designado novo usuário para integrar a equipe do projeto e o projeto não foi comprometido Decisão Após a conclusão de todas as atividades propostas na primeira fase da metodologia X-Meta, o DW entrou em produção. Desde abril/2002, os usuários estão utilizando o sistema e puderam comprovar sua eficiência. Dentre algumas atividades realizadas nesta subfase, ressalta-se a preocupação da equipe de desenvolvimento em fornecer contínuo suporte aos usuários na utilização do sistema e a publicação do sucesso do DW no jornal da SEFIN que circula internamente. O Secretário de Finanças tomou conhecimento dos sucessos obtidos em razão do uso do DW, paulatinamente, principalmente quando alguns relatórios chegavam a sua mesa, mais rapidamente do que o costume. No entanto, a informação oficial aconteceu durante uma apresentação formal, na qual também estavam presentes os diretores de outras áreas como, por exemplo, ISS, ITBI e Dívida Ativa. Nesta apresentação foi disponibilizado 143

155 o sistema SAAI para execução de consultas ad hoc ao DW e foi entregue o relatório final do projeto, com a avaliação da equipe de desenvolvimento. Espera-se que até julho/2002 o Secretário autorize o projeto de viabilidade do DW corporativo, para atender às necessidades de toda a SEFIN. Este projeto deverá ser apresentado ao Prefeito para aprovação, em decorrência da necessidade de elaboração de edital de licitação para contratação de assessoria técnica e serviços terceirizados Resultados obtidos na subfase Decisão A utilização efetiva do protótipo apresentou ainda os seguintes resultados: a comunidade de negócio passou a dar valor às informações analíticas, reconhecendo a importância de tomar decisões baseadas em fatos; constatou-se que, nos próximos exercícios, as simulações dos novos lançamentos poderão ser mais bem analisadas, a partir de comparações com os lançamentos anteriores armazenados no DW; avaliação sistemática dos resultados da arrecadação do IPTU, visando a uma administração fiscal mais eficiente; o conhecimento sobre as mudanças nas regras do negócio arrecadação do IPTU agora estão numa forma facilmente acessível àqueles que precisam delas; e o sistema foi utilizado para fornecer informações para órgãos externos, como, por exemplo, as solicitações da ABRASF (Associação Brasileira de Secretários de Finanças) e BNDES (Banco Nacional de Desenvolvimento Econômico e Social), banco que financiou o PMAT (Programa de Modernização Administrativa Tributária). 5.4 Análise da Metodologia X-Meta Ao longo deste capítulo, foram apresentadas as diversas atividades realizadas durante o desenvolvimento do primeiro projeto de DW da SEFIN. Procurou-se destacar os resultados obtidos e aprendizagens adquiridas, com o objetivo de validar a primeira fase da metodologia proposta no capítulo

156 Ao finalizar o desenvolvimento deste projeto, pôde-se destacar ainda alguns aspectos observados na prática: certa dificuldade na elaboração dos cronogramas, em razão da falta de experiência neste assunto; é fundamental que, no mínimo, um membro da equipe tenha dedicação total ao projeto, para que não aconteça sua descontinuidade; a disponibilização dos metadados de negócio aos usuários comprovou a grande necessidade da comunidade por estas informações; e a equipe conseguiu gerar os mesmos relatórios gerenciais produzidos atualmente pelo sistema de tributos, assim como outros solicitados pelos diretores, com a grande vantagem da geração da informação no momento oportuno e pelo usuário do negócio. Os resultados obtidos com a utilização do sistema SAAI foram além das expectativas. Um aspecto que ficou evidenciado foi a facilidade e rapidez na obtenção das informações gerenciais pelos administradores, o que os surpreendeu sobremaneira. Outra evidência foi a sinalização, por parte dos usuários, de análises mais detalhadas dos imóveis, inclusive para possibilitar detectar irregularidades, que atualmente ainda ocorrem na SEFIN. Finalmente, cabe analisar a metodologia X-Meta em face dos critérios destacados na seção 3.2.5, identificados como fundamentais para uma metodologia direcionada ao ambiente organizacional com o perfil da SEFIN. (1) Abordagem Evolucionária e Incremental: a existência de vários pontos de entrada na metodologia enfatiza sua iteratividade, sendo utilizados para o crescimento normal do DW. Cada novo projeto é construído sobre seu predecessor, através de refinamentos sucessivos. (2) Formação da Equipe de Desenvolvimento: a sociedade entre o departamento de TI e os usuários do negócio é formada desde o primeiro projeto. Além disso, a metodologia possui características especiais, como, por exemplo, a fase Introdução, que permite o desenvolvimento de DW por equipe inexperiente. (3) Definição dos Produtos Resultantes do Processo de Desenvolvimento: a divisão da metodologia em fases, subfases, grupos e módulos, como destacado na seção 145

157 4.2, permite que os produtos integrantes do ambiente DW estejam intimamente ligados à estrutura da metodologia; isto é, os produtos do processo de desenvolvimento estão destacados na estrutura da metodologia e podem ser facilmente visualizados. (4) Detalhamento das Fases: as diversas fases, subfases e módulos foram devidamente apresentados e detalhados. Além disso, o detalhamento das atividades facilita a execução das diversas fases, subfases e módulos, desde a fase inicial de cada projeto até a sua conclusão. (5) Projeto piloto: a fase Introdução possui uma sistemática completa para a construção do primeiro projeto piloto, com detalhamento de todas as atividades a serem executadas. Além disso, a metodologia permite a criação de sistemáticas próprias de desenvolvimento de outros projetos piloto, que podem ser necessários para atender a finalidades específicas. (6) Criação e Gerenciamento de Metadados: para garantir a criação e o gerenciamento de metadados integrados ao processo de desenvolvimento, uma fase ( Gerenciamento de metadados ) e dois módulos ( modelagem de metadados e infra-estrutura de metadados ) foram especialmente definidos e incorporados à metodologia. A utilização de metadados está especificada desde o primeiro projeto piloto, quando é definida uma solução de metadados para o primeiro protótipo. Comprova-se que o objetivo principal destacado no início deste trabalho foi atingido - introduzir a tecnologia de DW em organizações sem tradição no uso de sistemas de apoio à decisão. Foi possível a uma equipe inexperiente nesta tecnologia, mas com conhecimento sobre DW e capacitada tecnicamente em desenvolvimento de sistemas em geral e tecnologia de banco de dados, executando somente a primeira fase da metodologia proposta, construir um DW e gerar informações corretas e no momento oportuno aos usuários decisores. Além disso, eles puderam, através dos metadados, obter informações claras sobre as mudanças nas regras do negócio ocorridas nos últimos cinco anos, o que permitiu uma análise mais precisa das informações. Portanto, conclui-se que a metodologia proposta é adequada, sendo possível sua utilização em organizações com o contexto destacado no capítulo

158 6 CONCLUSÃO 6.1 Considerações Finais e Contribuições Dentro do ambiente de negócio atual, as pessoas ainda tentam responder às questões de negócio baseando-se nas limitações da infra-estrutura dos sistemas de informações existentes. Data Warehousing, como visto, enfatiza a qualidade, integração e utilidade dos dados, a fim de prover informações para suportar as muitas necessidades de tomada de decisões nas organizações. Ao longo deste trabalho, destacou-se que, para estruturar um ambiente ideal para apoiar a tomada de decisão e obter sucesso em projetos DW, o elemento essencial é a escolha de uma metodologia de desenvolvimento de DW adequada às características e necessidades da organização onde o DW será implantado. A realização deste trabalho de dissertação envolveu uma análise dos principais conceitos relacionados ao ambiente de DW e metodologias de desenvolvimento de DW já propostas, com o intuito de escolher uma estratégia adequada para organizações com o perfil observado na SEFIN, extensivo a outras organizações, onde: as decisões são tomadas sem contar com sistemas informatizados de apoio à decisão, mas existe infra-estrutura computacional mínima necessária para a construção de um DW; a contratação de equipes externas nem sempre é viável, por causa de fatores como custos, legislação e sigilo dos dados, mas contam em seus quadros com pessoal capacitado tecnicamente em desenvolvimento de sistemas convencionais e tecnologia de banco de dados; e 147

159 normalmente existe pouco conhecimento do negócio por parte dos dirigentes, principalmente históricos, dada a constante rotatividade nos cargos de nível gerencial e estratégico. Isto dificulta o uso da intuição e experiência na tomada de decisão. Observou-se que as metodologias analisadas não atendiam totalmente às corporações com o perfil acima descrito. Este trabalho propôs uma metodologia de desenvolvimento de DW com características especiais, tais que permitem utilizar pessoal interno sem experiência prática na construção de DW e oferece um tratamento especial aos metadados integrados ao processo de desenvolvimento. A tabela 10 apresenta um resumo comparativo das metodologias estudadas ([GAR98] [POE98] [KIM98a] [PER00]), assim como as principais características da metodologia proposta (X-Meta), segundo os critérios descritos no capítulo 3. Tabela 10 Comparativo das metodologias investigadas e proposta Critérios [GAR98] [POE98] [KIM98a] [PER00] X-Meta Abordagem evolucionária e incremental Formação da equipe de desenvolvimento Produtos resultantes do Processo de desenvolvimento Detalhamento das fases Projeto piloto Criação e Gerenciamento de metadados Sim Sim Não Sim Sim Equipe experientes e usuários do negócio - Arquitetura de dados - Projeto da base de dados - Metadados Equipe experiente e usuário facilitador - Arquitetura de dados - Arquitetura funcional - Infra-estrutura técnica - Esquemas dimensionais - Projeto da base de dados - Aplicações de usuário final - Metadados Equipe experiente Equipe inexperiente Equipe inexperiente e usuários do negócio - Arquitetura de dados - Arquitetura funcional - Infra-estrutura técnica - Esquemas dimensionais - Projeto da base de dados - Aplicações de usuário final - Metadados - Arquitetura de dados - Arquitetura funcional - Infra-estrutura técnica - Esquemas dimensionais - Projeto da base de dados - Aplicações de usuário final - Arquitetura de dados - Arquitetura funcional - Infra-estrutura técnica - Esquemas dimensionais - Projeto da base de dados - Aplicações de usuário final - Metamodelo - Repositório de metadados Pouco detalhada Detalhado Bem detalhado Bem detalhado Bem detalhado Não Pouco detalhado "prova de concepção" e "arquitetura e infraestrutura", antes do desenvolvimento do DW Detalhado, mas não integrado à metodologia "prova de concepção", na fase de "Seleção e instalação de produtos" Detalhado, mas não integrado à metodologia "arquitetura e infraestrutura", na fase "experimentação" Não detalhado Primeiro protótipo, na fase Introdução e projeto piloto, na fase Desenvolvimento Detalhado e integrado à metodologia A metodologia X-Meta apóia-se primeiramente no desenvolvimento de um primeiro protótipo para provar a viabilidade e o valor de DW para a corporação, utilizando apenas a fase Introdução. Dessa forma, a metodologia X-Meta viabiliza a inserção do 148

160 uso automatizado de sistemas de apoio à decisão na organização. Através deste primeiro protótipo e utilizando-se as iterações suportadas na metodologia, permite-se que a equipe de desenvolvedores adquira conhecimento e experiência com novas ferramentas e tecnologias, tornando possível a construção de um DW corporativo, utilizando pessoal inexperiente nesta tecnologia, contudo conhecedores do negócio e capacitados tecnicamente em sistemas convencionais e tecnologia de banco de dados. O tratamento dispensado aos metadados é o grande diferencial desta metodologia, estando presente desde a fase Introdução e por todo o processo de desenvolvimento e produção do DW. A fase Introdução foi realizada com grande sucesso na SEFIN, utilizando a área de arrecadação do IPTU como estudo de caso. Ao encerrar o desenvolvimento do primeiro protótipo, e analisar cuidadosamente os resultados obtidos na prática, alguns deles citados na seção 5.3, pôde-se concluir que a metodologia proposta é adequada e consistente na solução dos problemas que motivaram este trabalho, os quais foram citados na seção 1.1 e também abordados neste segmento. O estudo de caso elaborado neste trabalho foi de fundamental importância para validar a metodologia proposta, pois possibilitou o desenvolvimento de um DW e a efetiva utilização de um sistema automatizado de apoio à decisão na SEFIN. A introdução da tecnologia de DW chamou a atenção para as informações valiosas que a organização possui, relativas ao seu cotidiano de maneira informal, ou seja, agregados apenas à memória de seus funcionários e, portanto, difíceis de preservar, gerenciadas e difundidas. Estas informações podem ser vistas como conhecimento organizacional e são de fundamental importância para a instituição. Através dos metadados, os usuários podem confiar nas informações armazenadas no DW, interpretar corretamente o conteúdo de suas consultas e ampliar seu conhecimento organizacional. Espera-se que o projeto de desenvolvimento do DW corporativo que ora está sendo formulado possa ser disponibilizado o mais rapidamente possível e que este venha a contribuir efetivamente para acompanhar e dimensionar os gastos, reduzir custos e alavancar recursos. Mais do que isso, que a PMF possa evoluir e projetar uma imagem favorável perante os cidadãos, para atender as necessidades deles. 149

161 6.2 Trabalhos Futuros Como trabalhos futuros sugere-se: a validação da fase Introdução em outros contextos; a validação completa da metodologia X-Meta através do desenvolvimento do DW corporativo da SEFIN; estender a outras secretarias da PMF o uso de sistemas automatizados de apoio à decisão, principalmente na área de saúde e educação; desenvolvimento de um sistema baseado em conhecimento, utilizando o repositório de metadados, para introduzir a gestão do conhecimento nas organizações; incorporar a tecnologia de patterns às atividades de gerenciamento de metadados; aplicação da tecnologia de Mineração de Dados (Data Mining) sobre a base analítica do DW; e extensão da metodologia proposta para o desenvolvimento de DW XML. 150

162 REFERÊNCIAS BIBLIOGRÁFICAS [ATG97] [BAR97a] [BAR97b] ATG s Data Warehousing - Technology Guide Series. Putting Metadata to Work in the Warehouse Capturado na Internet em Maio, BARQUIN, Ramon C.; EDELSTEIN, Herb. Planning and Designing the Data Warehouse. New Jersey, Prentice Hall PTR, BARQUIN, Ramon C.; EDELSTEIN, Herb. Building, Using, and Managing the Data Warehouse. New Jersey, Prentice Hall PTR, [BEN97] BENETT, Gordon. Introducing Intranets. QUE Corporation, [BER97] [BON98] [BUR88] BERSON, Alex; SMITH, Stephen J. Data Warehousing, Data Mining and OLAP. McGraw Hill, BONTEMPO, Charles; ZAGELOW, George. The IBM Data Warehouse Architeture. Communications of the ACM, v. 41, n. 9, p Setembro, BURD Informática. Dataflex, O Banco de Dados de Quarta Geração. McGraw Hill, [BUS00] Business Intelligence. Mister BI. E-Manager, p Julho, [CAM00] CAMPOS, Maria Luiza M. Data Warehouse. João Pessoa-PB: XV Simpósio Brasileiro de Banco de Dados Mini-cursos / tutoriais,

163 [CAM98] [CAZ98] [CHA97] [CON01] [DAV98] CAMPOS, Maria Luiza M.; Filho, Arnaldo V. Rocha. Data Warehouse. Capturado na Internet em Janeiro, CAZARINI, E. W. Data Warehouse. Capturado na Internet em Fevereiro/ CHAUDHURI, Surajit; DAYAL, Umeshwar. An Overview of Data Warehousing and OLAP Technology. ACM SIGMOD Record v. 26, n. 1, p Março, Consolidação da Legislação Tributária Municipal. AUDIF - Associação dos Auditores Fiscais do Município de Fortaleza. Abril, DAVENPORT, Thomas H., PRUSAK, Larry. Working Knowledge How Organizations Manage What They Know. Harvard Business School Press, [DTB96] Data Warehousing Tools Bulletin. What is Metadata. ComputerWire, Capturado na Internet em Dezembro, [DYC98] [FOW00] [GAR98] [GLA98] [GRA98] DYCHÉ, Jill. Scoping Your Data Mart Implementation. DBMS magazine. Agosto, Capturado na Internet em novembro, FOWLER, Martin; SCOTT, Kendall. UML Distilled - A Brief Guide to the Standard Object Modeling Language. Addison Wesley Longman, GARDNER, Stephen R. Building the Data Warehouse. Communications of the ACM, v. 41, n. 9, p Setembro, GLASSEY, Katherine. Seducing the End User. Communications of the ACM, v. 41, n. 9, p Setembro, GRAY, Paul; Watson, HUGH J. Decision Support in the Data Warehouse. New Jersey, Prentice Hall PTR,

164 [HAR98] [INM97] [INM98] HARRISON, Thomas H. Intranet Data Warehouse. São Paulo, Berkeley Brasil, INMON, William H. Como Construir o Data Warehouse. Rio de Janeiro, Editora Campos, INMON, William H. Enterprise Meta Data. Data Management Review Magazine. Novembro, Capturado na Internet em Março, [INM99] INMON, William H.; WELCH, J. D.; GLASSEY Katherine L. Gerenciando Data Warehouse. São Paulo, Makron Books, [KIM98a] [KIM98b] [LIM01] [LIM02] [MAR00] KIMBALL, Ralph; REEVES, Laura; ROSS, Margy; THORNTHWAITE, Warren. The Data Warehouse lifecycle toolkit: expert methods for designing, developing, and deploying data warehouse. New York, John Wiley & Sons, KIMBALL, Ralph. Data Warehouse Toolkit. São Paulo, Makron Books, LIMA, Liane C. B.; BRAYNER, Angelo R. A. Metadados Integração do ambiente transacional com o ambiente analítico. I Encontro de Pós- Graduação e Pesquisa da UNIFOR, Fortaleza, LIMA, Liane C. B.; BRAYNER, Angelo R. A. X-META - A Methodology for Data Warehouse Design with Metadata Management. 4 th International Workshop on Design and Management of Data Warehouses (DMDW),. Canadá, MARCO, David. Building and Managing the Metadata Repository A Full Lifecycle Guide. New York, John Wiley & Sons, [MEL98] MELYMUKA, Kathleen. Walking with the User, Computerworld, Capturado na Internet em Setembro,

165 [PER00] [POE98] [PRE97] PEREIRA, Walter Adel Leite. Uma metodologia direcionada a inserção da tecnologia de data warehouse nas corporações. Dissertação de MSc.- PUCRS, Porto Alegre, POE, Vidette; KLAUER, Patricia; BROBST, Stephen. Building a data warehouse for decision support. New Jersey, Prentice Hall PTR, PRESSMAN, Roger S. Software Engineering: A Practitioner s Approach. McGraw Hill, [SCH96] SCHMIDT, Douglas C., FAYAD, Mohamed, JOHNSON, Ralph E. Software Patterns. Communications of the ACM, v. 39, n. 10, p Outubro, [SEN98] SEN, Aru; JACOB, Varghese S. Industril Strenght Data Warehousing. Communications of the ACM, v. 41, n. 9, p Setembro, 1998 [SIN01] SINGH, Harry S. Data Warehouse Conceitos, Tecnologias, Implementação e Gerenciamento. São Paulo, Makron Books, [TGS98] The Technology Guide Series. The DNA of Data Warehousing Capturado na Internet em Maio, [WAT98] WATSON, Hugh J. Managerial Considerations. Communications of the ACM, v. 41, n. 9, p Setembro,

166 ANEXO A Relatório Inadimplentes IPTU no Exercício 155

167 Prefeitura Municipal Fortaleza * ADM. MUNICIPAL - IPTU * Inadimplentes IPTU 2002 * Emissao : 29/01/2002 IP RINAE PIP L A N C A D O R E A L I Z A D O I N A D I M P L E N C I A PREVISTO OUTROS COTA UNICA PAGO PARCELAS EM DIA PAGO PARCELAS EM ATRASO INADIMP TOTAL INADIMP A VENCER Qtde Valor Qtde Valor Qtde Perc Valor Qtde Perc Valor Qtde Perc Valor Qtde Perc Valor IPTU Qtde Perc Valor IPTU TIPO DE USO RESIDENC 233,163 71,298, ,617 9,458, , ,749, , , , ,581, , ,919, Ate ,177 4,604, ,711 5,188, , , , , ,581, , ,930, ,702 5,610, , , , , , , , ,628, ,198 24,917, ,696 1,431, , , , , , ,642, Acima ,086 36,165, ,011 2,404, , , , ,718, NAO RESIDEN 74,216 70,401, , , , , , , , ,669, Ate ,087 3,253, , , , , , , , ,887, ,082 2,668, , , , , ,604, ,805 6,705, , , , , ,609, Acima ,242 57,772, , , , , ,568, TERRENOS 70,369 22,237, ,007 6,639, , , , , , , ,819, Ate ,703 3,552, ,738 1,266, , , , , , , ,807, ,509 1,518, , , , ,830, ,610 3,122, , , , ,906, Acima ,547 14,044, ,239, , , ,274, TOTAL GERAL 377, ,664 16,106, , ,183, , , , ,758, , ,408, VALOR VENAL Ate ,967 11,410, ,474 6,455, , , , , ,758, , ,626, ,293 9,797, , , , , , , , ,063, ,613 34,745, ,666 2,236, , , , , , ,158, Acima , ,415 6,644, , , , ,560, TOTAL GERAL 377, ,664 16,106, , ,183, , , , ,758, , ,408, ** Criterios: 1-) Valores expressos em UFIR. 2-) Os imoveis sao alocados nas faixas pelo Valor Venal(R$) do ano da emissao deste relatorio. 3-) No Valor LANCADO esta considerado o valor do IPTU dos imoveis com a reducao para pagos como COTA UNICA (20% ou 30% conforme o ano). 4-) Na Coluna OUTROS estao considerados os imoveis nao cobraveis: sem endereco, isentos, cancelados. 5-) A Coluna REALIZADO esta' dividida em: 5.1-) COTA UNICA: Quantidade e valor pago como cota unica; 5.2-) PARCELAS EM DIA: Quantidade e valor pago em parcelas, estando em dia ou ja liquidado o debito; 5.3-) PARCELAS EM ATRASO: Quantidade e valor pago em parcelas, estando em atraso algum pagamento; 6-) A Coluna INADIMPLENCIA esta' dividida em: 6.1-) INADIMP TOTAL: Quantidade e valor do IPTU, quando nao foi efetuado nenhum pagamento e nao resta parcelas a vencer; 6.2-) INADIMP A VENCER: Quantidade e valor do IPTU, quando nao foi efetuado nenhum pagamento e ainda resta parcelas a vencer. 7-) No Calculo dos Percentuais esta sendo considerada as reducoes para pagamento parcelado (10% a partir de 1999). 8-) Valores recebidos de lancamentos cancelados nao estao no Realizado. 156

168 ANEXO B Projeto Introdução da Tecnologia DW na SEFIN 157

169 Apresentação A maioria das organizações já reconhece a necessidade de ter informações corretas, no momento oportuno e facilmente acessíveis, de forma a permitir detectar tendências, prever mudanças e analisar desempenho. Na área pública, embora não se apliquem os critérios de competitividade, observa-se a necessidade de utilizar sistemas de informações que auxiliem na formulação de políticas públicas eficientes e na avaliação sistemática dos resultados obtidos. Dessa forma, melhorar a qualidade do serviço prestado à população. A Secretaria de Finanças (SEFIN) encontra-se inserida no seguinte cenário: a capacidade da administração em coletar e armazenar dados ultrapassou, em muito, a habilidade de resumir e analisar tais dados com o objetivo de extrair informação. Por isso, faltam informações apropriadas para a tomada de decisão e os administradores são levados a confiar em sua experiência e a tomar decisões baseadas muitas vezes na intuição, quando a objetividade também deveria estar presente. Data Warehousing vem se consolidando, dentro da área de tecnologia da Informação, como provedor de informações para atender às necessidades dos usuários decisores, permitindo a análise de situações e à tomada de decisões. Sistemas que permitem o processamento analítico de informações são denominados Sistemas de Apoio à Decisão (SAD), ao contrário dos sistemas tradicionais, que são desenvolvidos para suportar as atividades diárias da organização. Este projeto consiste em construir um Data Warehouse (DW), que é um banco de dados analítico, usado como base para os SAD, e disponibilizar uma ferramenta que possibilite à alta direção realizar consultas e obter informações, que normalmente não são possíveis nos sistemas atuais da SEFIN. Considerando à falta de conhecimento no uso de SAD, pretende-se iniciar com um projeto simples, de forma a adquirir experiência, e mostrar aos usuários o valor da informação para o processo de suporte à decisão e num segundo momento, partir para a construção do DW corporativo da PMF. Esperamos que todas as informações contidas neste documento sejam úteis para a compreensão do assunto. Temos a convicção de que, com a construção do seu primeiro DW, a SEFIN dará um grande passo rumo à modernização, podendo efetuar um tratamento adequado para a gestão da informação e direcionar a formação do seu capital intelectual. Objetivo Geral Experimentar a tecnologia Data Warehousing na otimização do processo decisório da SEFIN, buscando sensibilizar administradores/gestores da sua importância no gerenciamento da informação. Com o sucesso deste projeto, pretende-se a aprovação da direção da instituição para o desenvolvimento de um Data Warehouse corporativo para atender às necessidades de toda a SEFIN. Objetivos Específicos Desenvolver um projeto piloto que permita a construção de um banco de dados consolidado e consistente, orientado para o assunto/negócio da SEFIN, somente para leitura, e variável em relação ao tempo, Data Warehouse, permitindo aos administradores, consultas interativas, rápidas e objetivas. 158

170 Aplicar uma metodologia de desenvolvimento DW de forma a construir um protótipo que disponha de ferramentas de análise e acompanhamento, com enfoque na área da arrecadação de IPTU. Realidade Atual da SEFIN Os sistemas de informações, especificamente o Sistema de Tributos, dão suporte ao cotidiano do negócio garantindo a operação da organização. Ao longo do tempo, uma enorme quantidade de dados foi armazenada. Embora essa base constitua um bom recurso, raramente pode ser utilizada como recurso estratégico no seu estado original. O Sistema de Tributos não foi projetado para gerar e armazenar as informações estratégicas, o que torna os dados vagos e sem valor para o apoio ao processo de tomada de decisões da SEFIN. Além disso, existe o acúmulo de dados inconsistentes, que foram gerados ao longo dos 12 anos de existência do sistema. Atualmente, o Sistema de Tributos possibilita um limitado suporte à decisão através de relatórios pré-formatados. Normalmente os relatórios de natureza gerencial referem-se a um único ano e não apresentam padrões e tendências. Quando um novo relatório é solicitado pela diretoria, a equipe de informática leva de 2 a 4 dias para implementar, testar e validar o documento, o que, por muitas vezes, impossibilita ao gestor tomar decisão no momento oportuno. As decisões normalmente são tomadas com base na experiência dos administradores, quando poderiam também ser baseadas em fatos históricos armazenados pelos diversos sistemas de informação e pelas informações externas. Metodologia A construção de um Data Warehouse é um processo complexo, composto por vários itens como metodologia de desenvolvimento, técnicas, máquinas, banco de dados, ferramentas de front-end, extração, metadados, refinamento de dados, replicação, e recursos humanos. A complexidade aumenta de acordo com a quantidade e detalhamento de dados históricos que são armazenados. Em muitos casos o volume de dados pode chegar à casa dos terabytes. Para suportar um DW de grande porte, os investimentos em hardware e software são elevados, bem como consultorias especializadas. A figura abaixo mostra uma visão simplificada da estrutura de um Data Warehouse e seus principais componentes. Os dados operacionais, que são manipulados pelos Sistemas Legados da empresa, bem como os dados de diversas fontes externas são extraídos, transformados e carregados para o banco de dados. Os gestores poderão acessar este DW através das ferramentas de consultas e aplicativos para a obtenção de informações que será o seu auxílio no processo de tomada de decisão. A construção de um DW a partir de um projeto piloto possibilitará que os administradores e decisores de mais alto nível tenham uma visão de como o DW pode ser viável e valioso para a SEFIN. Neste tipo de projeto piloto, os usuários podem interagir com o sistema, obtendo algumas informações úteis para suporte a decisão, possibilitando entender como essas informações poderão ajudá-los. O banco de dados do projeto piloto terá enfoque na arrecadação de IPTU, e a partir deste, serão implementadas as consultas e relatórios para tomada de decisão. Este enfoque foi estabelecido com o intuito de obter 159

171 resultados em curto prazo para um assunto de grande interesse e necessidade dos administradores no contexto atual. O ponto de partida será a análise de relatórios gerados pelo sistema de tributos, como o relatório Demonstrativo do Parcelamento IPTU, em conjunto com os assessores do planejamento, para levantar as necessidades de informações. A partir deste levantamento serão definidos a estrutura do DW, os dados que serão carregados, e os relatórios e consultas que serão gerados. A metodologia de desenvolvimento do DW consistirá nas seguintes fases: Planejamento Inicial: definição do escopo do projeto, atendendo as necessidades mais prementes de informações gerenciais. Modelagem dimensional: definição da modelagem dos dados visando o processamento para a obtenção das informações sumariadas e consolidadas. Projeto da Base de Dados: construção das estruturas lógicas do modelo dimensional, com as definições de tabelas Fatos e Dimensão, relacionamentos, atributos, índices e implantação de regras. Extração e Transformação: definição dos processos requeridos de transformação e extração da base dados dos sistemas tradicionais. População (Carga dos dados): definição dos processos para carga dos dados extraídos e transformados para a base de dados do DW. Disponibilização do DW: definição de política de testes, validação, treinamento e implantação das aplicações desenvolvidas em conjunto com os usuários(gestores/analistas). Recursos O DCPD já vêm realizando pesquisas na área da Gestão da Informação através do Mestrado de Informática Aplicada MIA, e da Diretoria de Pesquisa e Pós - Graduação DIPPG, ambos da UNIFOR, sendo a primeira uma dissertação abordando o Desenvolvimento de uma Metodologia de Construção de DW, e a segunda como Projeto da Utilização do DW no Setor Público. Portanto para viabilizar a execução deste projeto serão utilizados recursos próprios, e já disponíveis na SEFIN. Inicialmente não haverá desembolso ou investimento financeiro. Os recursos necessários estão descritos a seguir: 160