FACULDADE CATÓLICA DE ADMINISTRAÇÃO E ECONOMIA
Propaganda
FACULDADE CATÓLICA DE ADMINISTRAÇÃO E ECONOMIA CENTRO DE DESENVOLVIMENTO EMPRESARIAL CURSO DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO PROJETO DE CURSO PROPOSTA DE UM ROTEIRO PARA PROJETAR UM DATA WAREHOUSE CURITIBA FEVEREIRO DE 2000 CLAUCIA MARQUES COSTA FABIANO AUGUSTO PEREZ LIMA FERNANDO ARAÚJO FIGUEIREDO HENRIQUE SALATINO MIORELLI MARCOS VIEIRA DE SOUZA PROPOSTA DE UM ROTEIRO PARA PROJETAR UM DATA WAREHOUSE Monografia apresentada à disciplina Projeto de Curso para obtenção do título de Especialista no Curso de Pós-Graduação em Tecnologia da Informação e Comunicação no Centro de Desenvolvimento Empresarial da Faculdade Católica de Administração e Economia. Orientador: Prof. Luís Pedro Zambon. CURITIBA FEVEREIRO DE 2000 AGRADECIMENTOS Ao professor e orientador Luís Pedro Zambon, que durante os nossos estudos, nos direcionou à qualidade fazendo críticas e sugestões, dando-nos apoio no trabalho, bem como pelos conhecimentos que nos foram transmitidos. Agradecimentos especiais à nossa equipe de desenvolvimento deste projeto, tanto pelo interesse comum em atingir o sucesso quanto pela grande amizade e companheirismo que fortaleceu-se durante este trabalho. ii RESUMO O data warehouse, literalmente , é um “armazém de dados” . É uma base de dados carregada de forma incremental em um período de tempo. O data warehouse organiza e armazena os dados necessários para processamento informatizado e analítico sobre perspectivas históricas ao longo do tempo, tendo como principal objetivo transformar o dado em informação. É uma arquitetura que utiliza banco de dados desenvolvido para análise e tomada de decisões em bases sumarizadas e também detalhadas, com o intuito de contemplar os segmentos da empresa ou organização. O data warehouse pode revolucionar os negócios da empresa. Ao ser bem elaborado e implementado, e caso seja cuidadosamente direcionado para a chamada “inteligência de negócio”, ele pode tornar-se uma vantagem competitiva. Essa ferramenta está fazendo surgir novos conceitos de gestão da informação , tipos de consultas e análises dos negócios. Os principais conceitos que norteiam essa tecnologia serão abordados e analisados como pré-requisitos que, direta ou indiretamente, são necessários para o desenvolvimento do projeto. O enfoque principal do trabalho é reunir grande parte da fundamentação teórica referente ao assunto data warehouse , organizando essas informações através de um roteiro que especifica as etapas necessárias no desenvolvimento do projeto. Um outro item importante é amenizar o grau de dificuldade encontrado por profissionais da Tecnologia da Informação quando iniciam um projeto de data warehouse, bem como prover o conhecimento mínimo necessário àqueles profissionais que não têm referência alguma sobre esse assunto. Apresentaremos o que é importante entender e considerar para alcançar o sucesso do projeto, através de etapas que auxiliem o desenvolvimento do mesmo e exemplos de cenários reais para a sua utilização, onde a tecnologia de data warehouse pode suprir as necessidades de informação da empresa ou organização. iii SUMÁRIO LISTA DE TABELAS .................................................................................................viii LISTA DE FIGURAS .................................................................................................viii LISTA DE SIGLAS ...................................................................................................... x MÉTODO DE TRABALHO ........................................................................................ xv PLANO DE TRABALHO ........................................................................................... xvi 1. FUNDAMENTOS TEÓRICOS ................................................................................ 1 1.1 CONCEITOS ........................................................................................................ 1 1.1.1 Dado x Informação ............................................................................................ 1 1.1.2. Data Warehouse (Armazém de Dados)............................................................ 1 1.1.3. Data Mart (Mercado de Dados) ........................................................................ 3 1.1.4. Engenharia da Informação ............................................................................... 4 1.1.5. Sistemas de Suporte à Decisão (DSS-Decision Support Systems) ................. 5 1.1.6. Inteligência Do Negócio (Business Intelligence)............................................... 5 1.1.7. Modelagem De Dados ...................................................................................... 6 1.1.8. Banco De Dados Relacional............................................................................. 8 1.1.8.1. Tabelas.......................................................................................................... 8 1.1.9. Banco De Dados Multidimensional ................................................................... 9 1.1.10. Análise Multidimensional ............................................................................... 9 1.1.11. OLTP (Online Transaction Processing) ........................................................ 10 1.1.12. OLAP (Online Analytical Processing) ........................................................... 10 1.1.12.1. ROLAP (Relacional OLAP) ........................................................................ 12 1.1.12.2. MOLAP (Multidimensional OLAP) ............................................................. 13 1.1.12.3. HOLAP (Híbrido OLAP) ............................................................................. 13 1.1.12.4. WOLAP (Web OLAP) ................................................................................ 13 1.1.13. Operações Olap ........................................................................................... 13 iv 1.1.14. Modelagem Dimensional Dos Dados ........................................................... 14 1.1.14.1. Fatos ......................................................................................................... 15 1.1.14.2. Dimensões De Um Cubo ........................................................................... 16 1.1.14.3. Agregações ............................................................................................... 16 1.1.14.4. Técnica star schema (esquema estrela).................................................... 17 1.1.14.5. Técnica snow flake (floco de neve) .......................................................... 18 1.1.15. Metadados.................................................................................................... 18 1.1.16. Ferramenta CASE (Computer Aided Software Engineering) ........................ 20 1.1.17. SQL (Structured Query Language) ............................................................... 21 1.1.17.1. Stored procedure (sp)................................................................................ 22 1.1.18. Indexação ..................................................................................................... 23 1.2. ASPECTOS ESTRATÉGICOS PARA A CONSTRUÇÃO DE UM DATA WAREHOUSE ........................................................................................................... 24 1.2.1. Planejamento ................................................................................................. 24 1.2.2. Necessidades Das Empresas ........................................................................ 25 1.2.3. Hierarquia Clássica Da Informação Na Empresa ........................................... 28 1.2.4. Motivação Da Empresa No Mercado .............................................................. 29 1.2.5. Necessidades e Benefícios Para o Usuário ................................................... 30 1.2.6. Perfil Do Usuário Na Empresa Que Utiliza O Data Warehouse ..................... 31 1.2.7. Análise Do Ambiente Legado ......................................................................... 34 1.2.8. Equipe De Desenvolvedores .......................................................................... 36 1.2.9. Aspectos Da Implementação Física (Rolap/Molap) ........................................ 38 1.2.10. Performance ................................................................................................. 40 1.2.11. Segurança .................................................................................................... 40 2. DESENVOLVIMENTO.......................................................................................... 41 2.1. FATORES CRÍTICOS DE SUCESSO ............................................................... 41 2.2. DEFINIÇÃO DA TÉCNICA DE DESENVOLVIMENTO DE SISTEMAS A SER ..... UTILIZADA ................................................................................................................ 42 v 2.3. VISUALIZAR AS NECESSIDADES DO USUÁRIO ........................................... 43 2.4. NOVA VISÃO DA INFORMAÇÃO PARA A TOMADA DE DECISÕES ............. 44 2.5. ANÁLISE DO NEGÓCIO A SER MODELADO .................................................. 45 2.6. ANÁLISE DO AMBIENTE LEGADO .................................................................. 47 2.7. MODELAGEM DIMENSIONAL DOS DADOS ................................................... 49 2.7.1. Dimensões ..................................................................................................... 50 2.7.2. Fatos .............................................................................................................. 50 2.7.3. Exemplo de uma análise dimensional. ........................................................... 50 2.7.4. Agregações .................................................................................................... 53 2.7.5. Metadados...................................................................................................... 54 2.7.6. Resumo das etapas para a modelagem dimensional. .................................... 54 2.8. ASPECTOS DA IMPLEMENTAÇÃO FÍSICA ..................................................... 55 2.8.1. Levantamento de volumes de dados .............................................................. 55 2.8.2. Periodicidade de Carga .................................................................................. 56 2.8.3. Tempo de Armazenagem dos Dados ............................................................. 57 2.8.4. Controle de Backup’s ..................................................................................... 57 2.8.5. Análise de Performance ................................................................................. 58 2.8.6. Segurança ...................................................................................................... 59 2.9. ASPECTOS DA VISUALIZAÇÃO DAS INFORMAÇÕES .................................. 60 2.9.1. Queries Simples ............................................................................................. 60 2.9.2. Stored Procedures (sp) .................................................................................. 61 2.9.3. Ferramentas OLAP......................................................................................... 61 2.9.4. Aplicativos de Consulta .................................................................................. 65 2.10. ESTUDOS DE CASOS REAIS (NECESSIDADES DO NEGÓCIO E MODELAGEM DIMENSIONAL). ............................................................................... 66 2.10.1. TAP – Termo de Acordo de Parcelamento ................................................... 67 2.10.2. Arrecadação Estadual de ICMS do Paraná .................................................. 69 2.10.3. CONPREVI................................................................................................... 71 vi CONCLUSÃO............................................................................................................ 73 ANEXOS ................................................................................................................... 76 ALGUNS FORNECEDORES DE FERRAMENTAS OLAP ATUAIS .......................... 76 SUGESTÃO DE UMA TABELA DIMENSÃO TEMPO DETALHADA ......................... 77 FIGURAS .................................................................................................................. 78 REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................... 80 vii LISTA DE TABELAS 1. EXEMPLO DE GERENCIAMENTO DE AGREGAÇÕES ...................................56 2. EXEMPLO DE STAR SCHEMA PARA TERMO DE ACORDO DE PARCELAMENTO ................................................................................................................67 3. EXEMPLO DE STAR SCHEMA PARA ARRECADAÇÃO ESTADUAL DE ICMS.....................................................................................................................68 4. DEFINIÇÃO DE AGREGAÇÃO NA TABELA FATOS ARRECADAÇÃO..............69 5. EXEMPLO DE STAR SCHEMA CONPREVI........................................................71 6. FORNECEDORES DE FERRAMENTAS OLAP ATUAIS.....................................75 7. SUGESTÃO DE UMA TABELA DIMENSÃO TEMPO DETALHADA....................76 LISTA DE FIGURAS 1. CUBO PARA MODELAGEM DIMENSIONAL DOS DADOS COM TRÊS DIMENSÕES....................................................................................................................49 2. EXEMPLO DA TÉCNICA STAR SCHEMA...........................................................52 3. AGREGAÇÃO COM DUAS DIMENSÕES............................................................53 4. VISUALIZAÇÃO DAS DIMENSÕES E FATOS ATRAVÉS DA FERRAMENTA OLAP BUSINESS OBJECTS................................................................................62 5. SOLICITAÇÃO DAS INFORMAÇÕES DAS DIMENSÕES E FATOS ATRAVÉS DE COMANDOS DRAG AND DROP....................................................................63 6. HIERARQUIA IMPLEMENTADA EM UM BANCO DE DADOS MULTIDIMENSIONAL............................................................................................... .....................64 7. EXEMPLO DE UM CUBO DIMENSONAL............................................................77 8. EXEMPLO DE UMA ESTRUTURA STAR SCHEMA............................................77 viii 9. EXEMPLO DE UMA ESTRUTURA SNOW FLAKE..............................................78 10. EXEMPLO DE UM MODELO DE DADOS (MER)................................................78 ix LISTA DE SIGLAS ANSI - American National Standards Institute API - Aplication Program Interface CASE - Computer Aided Software Engenering CELEPAR - Companhia de Informática do Paraná CONPREVI - Conselho de Previdência dos Serventuários do Estado do Paraná DATA MARTS - Mercados de Dados DCL - Linguagem de controle de dados DDL - Linguagem de definição de dados DER - Diagrama Entidade Relacionamento DM - Dimensional Modeling DML - Linguagem de manipulação de dados DSS - Decision Support Systems DSS - Sistema de Apoio à Decisão DW - Data Warehouse DWA - Administrador de Data Warehouse EIS - Sistema de Informações Executivas ER - Entity Relation ERP - Enterprise Resource Planning FIPS - Federal Information Processing Standards HOLAP - Híbrido On Line Analytical Processing IB - Business Intelligence ICMS - Imposto sobre Circulação de Mercadorias e Serviços IMS - Information Management System IS - Sistemas de Informações ISO - International Organization for Standardization MER - Modelo Entidade Relacionamento x MOLAP - Multidimensional On Line Analytical Processing NIST - National Institute of Standards and Techonology ODS - Operational Data Store OLAP - On Line Analytical Processing OLTP - On Line Transaction Processing RDBMS - Relational Data Base Management System ROLAP - Relacional On Line Analytical Processing RPC - Remote Procedure Call SDLC - Ciclo de Vida de Desenvolvimento de Sistemas Clássico SEFA/PR - Secretaria da Fazenda do Estado do Paraná SGBD - Sistema de Gerenciamento de Banco de Dados SGBDR - Sistema Gerenciador de Banco de Dados Relacional SQL - Structured Query Language SQL/MM - Structured Query Language Multimídia TAP - Termo de Acordo de Parcelamento VSAM - Virtual Storage Access Method WOLAP - Web On Line Analytical Processing xi INTRODUÇÃO 1. Problema Hoje constata-se freqüentemente nas Empresas que as informações estão desorganizadas, pouco integradas e de difícil acesso pelos usuários quando os mesmos necessitam analisá-las para tomar decisões. São freqüentes as perguntas feitas pelos executivos das empresas com relação às informações: “Nós temos montanhas de dados nesta empresa mas não temos acesso aos mesmos”. “Nós queremos cruzar informações de todas as maneiras possíveis”. “Apenas me mostre o que é importante”. Estas perguntas poderão ser respondidas mais rapidamente se a empresa possui um data warehouse consistente e integrado porém, não é uma tarefa simples o desenvolvimento de um projeto desse nível. Para tanto, as premissas abaixo devem ser observadas: De que maneira agilizar o processo de tomada de decisão na Empresa utilizando a Tecnologia da Informação? De que forma o data warehouse realmente possibilita agilizar o processo de tomada de decisão na Empresa? Quais etapas um profissional da Tecnologia da Informação deve seguir para desenvolver um projeto de data warehouse? 2. Importância e Justificativa Atualmente, a informação é o principal patrimônio de uma empresa ou organização e a mesma é utilizada no processo de tomada de decisões importantes e estratégicas. Portanto, a informação deve ser tratada como fator primordial com relação à competitividade do mercado. No entanto, muitas empresas necessitam integrar seus dados de forma a visualizar todo o escopo operacional da empresa xii para que análises possam ser efetuadas de uma forma rápida, confiável e que o usuário possa solicitar suas consultas às bases de dados sem necessitar de ajuda do analista de informática. A integração destas bases de dados é um problema complexo quando se visualizam várias fontes de informação distribuídas na empresa em um mesmo ambiente computacional ou em ambientes distintos. O conceito de data warehouse surge com a finalidade de organizar a integração das informações e disponibilizá-las através de várias dimensões de consulta, permitindo que todos os dados da Empresa possam estar disponíveis em uma única base para consulta e auxílio à tomada de decisão. O crescimento atual do conceito de data warehouse ocasionou muitas fundamentações teóricas e, até certo ponto, dificultou a organização das etapas necessárias desde o início do projeto até sua implementação física. Essa necessidade que muitos analistas têm em visualizar um roteiro para o desenvolvimento de data warehouse nos impulsionou em desenvolvermos este trabalho, reunindo no mesmo os principais aspectos que , obrigatoriamente, devem ser considerados no projeto. A importância da aplicação de um roteiro para desenvolvimento de um projeto de data warehouse baseia-se, fundamentalmente, em planejar as etapas necessárias. O roteiro estrutura o que deve ser feito, apresenta uma seqüência lógica das etapas e enfatiza a importância e necessidade de análise de cada fase do desenvolvimento do projeto. 3. Objetivo Geral Baseado em fundamentação teórica, desenvolver, para os profissionais de Tecnologia da Informação, um roteiro suscinto e claro de como projetar um data warehouse e aplicação deste roteiro em cenários reais de utilização. 4. Objetivos Específicos xiii 4.1) Elaborar fundamentação teórica para suportar o assunto: prover conhecimentos teóricos, técnicos e conceituais básicos referentes ao desenvolvimento de projetos de construção de data warehouse; aplicar os referidos conhecimentos aos profissionais da área de Tecnologia da Informação; demonstrar as fases necessárias que deverão ser consideradas no desenvolvimento do referido projeto até a parte de projeto do modelo de dados abrangendo: aspectos estratégicos, conceitos gerais, levantamento das informações, modelagem dimensional dos dados, planejamento do data warehouse, aspectos da implementação física, consultas, além de outros assuntos também importantes que são conseqüência dos itens principais e muitas vezes, pré-requisitos de outros. 4.2) Identificar situações reais de necessidade de análise da informação através de alguns estudos de caso que serão apresentados, utilizando as etapas principais do roteiro para a construção de data warehouse para atender estas necessidades, demonstrando principalmente a parte de negócio do cliente e projeto do modelo de dados dimensional. xiv MÉTODO DE TRABALHO O método utilizado é a pesquisa bibliográfica. As fontes bibliográficas utilizadas foram Livros de Leitura Corrente, por constituírem conhecimentos técnicos e Publicações Periódicas que proporcionam informações recentes e atualizadas. Outra classificação de pesquisa bibliográfica utilizada é consultas à sites da Internet. Os autores William H. Inmon e Ralph Kimball nortearam a fundamentação teórica como referências bibliográficas principais. Para o detalhamento do conhecimento adquirido através da pesquisa bibliográfica, também foi utilizado o método de estudo de caso, que permite o estudo profundo e exaustivo de um ou mais objetos de análise. A técnica utilizada para o desenvolvimento de sistemas de informação com o enfoque em data warehouse, foi a da Engenharia da Informação em virtude de o foco principal desta técnica ser os dados, armazenados e mantidos por computadores e as informações deles extraídas. Também foi inserida no contexto do trabalho a experiência profissional dos colaboradores que compõem a equipe. xv PLANO DE TRABALHO Basicamente o trabalho está dividido em três partes distintas: 1ª Parte: Embasamento teórico através de pesquisa bibliográfica que dará o suporte necessário à elaboração do roteiro para a construção de data warehouse, visualizando conceitos e considerações necessárias para o desenvolvimento do projeto. 2ª Parte: Início do desenvolvimento do trabalho onde será proposto o conteúdo do roteiro para projetar um data warehouse, aspectos considerados, a quem se destina, a elaboração do mesmo com todas as etapas necessárias e o porquê definimos o roteiro na ordem especificada. 3ª Parte: Continuação do desenvolvimento do trabalho voltado à aplicação do roteiro desenvolvido no que se refere às necessidades do cliente para a análise do negócio e modelagem dimensional em estudos de casos reais, referentes ao ambiente profissional dos integrantes desse projeto. Primeiramente iremos organizar os assuntos em ordem seqüencial, podendo os mesmos serem trabalhados separadamente e referenciados ao longo do trabalho. Muitos dos itens que serão contemplados, ao menos em uma referência resumida, são importantes no desenvolvimento do projeto para o pleno entendimento do assunto. Nosso plano contempla o desenvolvimento de um roteiro com as etapas principais iniciando pelos conceitos básicos da tecnologia de data warehouse até exemplos práticos de utilização. Nestes exemplos práticos serão apresentados problemas na obtenção de informações para a tomada de decisão pelos usuários e como a construção de modelos de dados utilizando a tecnologia de data warehouse pode solucionar estes problemas. xvi 1 1. FUNDAMENTOS TEÓRICOS 1.1 CONCEITOS 1.1.1 Dado x Informação Dado é um registro de fatos, conceitos ou instruções para a comunicação, recuperação e processamento por meios automáticos e apresentação na forma de informação compreensível para os seres humanos. Informação são dados que os seres humanos assimilam e validam para resolver problemas ou tomar decisões [13]. Dados são os componentes básicos, a partir dos quais a informação é criada. Informação são dados inseridos em um contexto. Contexto é a situação que está sendo analisada. A partir da informação vem o conhecimento, que permite tomar decisões adequadas, trazendo vantagem competitiva [18]. 1.1.2. Data Warehouse (Armazém de Dados) Data warehouse é uma coleção de dados para suportar o gerenciamento das necessidades de decisão, orientado a um assunto, integrado, variante no tempo e não volátil [14]. Orientado por assunto: A primeira característica de um data warehouse é que ele está orientado ao redor do principal assunto da organização como, por exemplo, clientes, vendas, produtos e atividades. O alinhamento ao redor das áreas de assunto afetam o desenho e implementação do dado criado no data warehouse. A área de assunto mais influente é a parte mais importante da estrutura chave [14]. Integrado: A melhor essência do ambiente de warehouse é que dados contidos dentro dos limites do warehouse estão integrados. A integração mostra-se em muitas diferentes maneiras: na consistência e padronização de nomes, na forma consistente das variáveis, na estrutura consistente de códigos, nos atributos físicos consistente dos dados, e assim por diante [14]. 2 Não Volátil: Atualizações - inclusão exclusão, e alteração - são feitas regularmente no ambiente operacional de um registro básico. Mas a manipulação de dados básicos que ocorre no data warehouse é mais simples. Tem somente três espécies de operações que ocorrem no data warehouse: a carga inicial do dado, o acesso ao dado e atualização temporal (semanal, mensal) conforme necessidades do negócio [14]. Histórico: Todo dado no data warehouse é exato em algum momento do tempo e em conseqüência desta informação, o dado criado no warehouse é dito ser "histórico". Os valores históricos dos dados no data warehouse são mostrados em várias maneiras. O modo mais simples é que o dado no data warehouse representa os dados sobre um horizonte de tempo distante - de 5 até 10 anos [14]. Uma coleção de bancos de dados integrados e orientados a assuntos projetados para apoiar as funções de um Sistema de Apoio de Decisão (Decision Support Systems); onde cada unidade de dados é importante em um momento no tempo. O data warehouse contém dados atômicos e muitas vezes sumarizados [13]. Um data warehouse não é um produto ou mesmo um conjunto de produtos, mas processos suportados por diversas tecnologias: ele coleta dados das várias aplicações operacionais; integra-os em um modelo lógico, por áreas de negócio; armazena as informações de tal maneira que possam ser recuperadas por usuários pouco técnicos; e entrega essas informações aos tomadores de decisão através de ferramentas de fácil utilização, como geradores de relatórios e de consulta [29]. A idéia de data warehouse é integrar os dados de uma organização em uma estrutura única provendo qualidade e melhor acesso aos dados [6]. Base de dados analítica que permite análises e simulações, para suporte às decisões estratégicas de médio e longo prazo. Geralmente é armazenada em ambiente específico, ou seja, separado do ambiente operacional. Características: [25]. 3 Dados históricos: para possibilitar análises combinatórias e simulações. Armazenam grandes quantidades de dados, podendo chegar a dezenas de anos [25]. Sumário estático: decorrente de atualização pontual, as sumarizações são calculadas e fixadas no momento da carga [25]. Dados Corporativos: estrutura de dados das diversas áreas da empresa (Suprimentos, Manufatura, Vendas, Finanças, Recursos Humanos, etc.), permitindo as mais diversas comparações [25]. Data warehouse é uma arquitetura de banco de dados com informações de caráter gerencial voltado para: suporte à decisão, planejamento estratégico, análise do comportamento de clientes e análise da performance de vendas. Funciona como um provedor de informações de uma empresa ou instituição, pois concentra todas as informações estratégicas e históricas, extraídas dos sistemas transacionais relativos aos clientes e produtos. A proposta principal do data warehouse é a democratização das informações para a área de negócios, através do fácil acesso aos dados para análise [1]. 1.1.3. Data Mart (Mercado de Dados) Um data mart não é uma evolução de um data warehouse, mas sim parte das estratégias deste. Um data mart é um subconjunto de dados de um data warehouse, desenhado para suportar uma necessidade de negócio ou uma unidade organizacional específica. A estratégia correta é fazer o data mart incorporar-se à arquitetura de data warehouse, sem perder a visão de conjunto. Essa visão de conjunto é decorrência de um bom projeto de data warehouse [24]. O data mart é similar ao data warehouse com algumas exceções: [13] O data mart opera um conjunto menor de dados [13]. O data mart visualiza o dados com um enfoque departamental enquanto o data warehouse visualiza os dados com um enfoque corporativo [13]. 4 O data mart visualiza os dados em uma base muito mais previsível enquanto o data warehouse freqüentemente faz exploração na base de dados [13]. Características comuns ao data warehouse e data mart são: informação estrutural, fonte de informação e outras informações encontradas ao longo do ambiente [13]. Obedece os mesmos conceitos do data warehouse, diferenciando-se somente no conteúdo, ou seja, os dados são organizados por assunto, permitindo maior independência, agilidade e ganhos de performance [25]. 1.1.4. Engenharia da Informação É um conjunto integrado de técnicas formais pelas quais modelos de negócios, modelos de dados e modelos de processos são construídos a partir de uma base de conhecimento compreensível utilizada para desenvolver e manter sistemas de informação [33]. O foco principal da Engenharia da Informação são os dados, armazenados e mantidos por computadores e as informações deles extraídas [33]. Premissas básicas: [33] Os dados situam-se no centro dos sistemas de informação [33]. Os dados são estáveis, os procedimentos não [33]. Princípios: [33] A análise rigorosa de dados deve ser feita antes do projeto lógico de processos [33]. A análise de dados deve ser feita de forma independente dos arquivos físicos e da distribuição dos dados [33]. Os dados devem ser planejados para toda a empresa [33]. 5 O acesso a base de dados deve ser possibilitado aos usuários finais através de ferramentas que ele não tenha a necessidade de programar [33]. Construir modelos de dados de processos com a visão integral da empresa possibilitando que os sistemas a serem desenvolvidos, mesmo que independentes, integrem-se e ajustem-se à estrutura do modelo corporativo [33]. 1.1.5. Sistemas de Suporte à Decisão (DSS-Decision Support Systems) Um sistema utilizado para gerenciar decisões. Usualmente envolve a análise de muitos dados. Como regra, não envolve a atualização dos dados, somente efetua consultas. Sistemas projetados para os executivos que caracterizam-se pela análise de tendências [13]. Enquanto o resultado de um data warehouse é a possibilidade de auxiliar no suporte a decisões, um DSS pode existir independentemente da arquitetura de data warehouse. Além disso, um DSS é uma solução isolada e que não inclui necessariamente uma arquitetura, uma infra-estrutura e nem mesmo ferramentas de administração ou auditoria, ao contrário de um data warehouse, que deve incluir todos esses componentes [24]. 1.1.6. Inteligência Do Negócio (Business Intelligence) É um processo de coleta, transformação, análise e distribuição de dados para melhorar a decisão de negócios; sua infra-estrutura tecnológica é composta de data warehouses ou data marts, ferramentas OLAP, EIS, data mining, consultas e relatórios e software de visualização dos dados; os bancos de dados são a infraestrutura básica de qualquer sistema de business intelligence. São neles que vão estar armazenados os dados que serão transformados em informações competitivas [17]. 6 1.1.7. Modelagem De Dados Modelagem de dados é uma atividade na qual procuramos construir uma estrutura de dados que reflita a realidade e ao mesmo tempo seja facilmente manuseada por computadores para que os sistemas construídos a partir dela sejam estáveis e sofram o mínimo de manutenção possível. A modelagem é dividida em três etapas ou níveis: Conceitual, Lógico e Físico [27]. Modelo Conceitual: É desenvolvido sem levar em consideração nenhum aspecto de representação lógica ou física dos dados, seja software, hardware ou visão particular de um usuário. É baseado em como funciona o negócio do cliente e ignora detalhes de implementação e performance [27]. Modelo Lógico: É desenvolvido levando-se em consideração a arquitetura de dados suportada pelo sistema gerenciador de banco de dados. Exemplo: Em Rede, Hierárquico, Relacional. Há a definição das tabelas, colunas e chaves. A meta é a redução de redundâncias para simplificação do gerenciamento e aumento da integridade [27]. Modelo Físico : O mapeamento físico leva em consideração características de hardware e software (SGBD) e estimativas de espaço e tempo (performance) [27]. O ponto de começo para o plano de migração é um modelo de dados. O modelo de dados representa as necessidades de informação da corporação. Representa o que a corporação necessita, não necessariamente o que a corporação atualmente possui. É construído sem consideração de tecnologia [12]. O Modelo Entidade-Relacionamento (MER) será a técnica de modelagem de dados utilizada para criação do Modelo Conceitual de Dados [8]. Esta técnica foi criada por Peter Pin-Shan Chen em 1975 e é usada para descrever o mundo real com alto grau de abstração, em termos de entidades (objetos de interesse), relacionamentos (forma como as entidades estão interligadas) e atributos (características das entidades e relacionamentos) [8]. 7 O MER é composto por uma representação gráfica, o chamado Diagrama Entidade-Relacionamento (DER) e um conjunto de informações escritas sobre cada conceito representado (entidades, relacionamentos e atributos) [8]. Apesar de ter surgido junto com a Análise Estruturada, o MER, por sua flexibilidade, foi evoluindo com o aparecimento de novas abordagens de desenvolvimento de sistemas (Engenharia da Informação, Análise Essencial, Análise Orientada a Objetos), e é considerado, ainda hoje, uma linguagem universal para a representação da realidade dos negócios de uma empresa [8]. Modelo de Dados : Estruturas de dados lógicas, providas por um sistema gerenciador de banco de dados utilizado para a representação dos dados [13]. Entidade: Armazena os dados de uma pessoa, lugar ou objeto de interesse em um alto nível de abstração [13]. Todo o objeto, coisa que tem alguma existência no negócio, na vida real. Não são tabelas, são implantadas como tabelas [21]. Relacionamentos: As ações ou fatos que integram as entidades no mundo real [21]. Modelo Entidade-Relacionamento (MER): Um modelo de dados que define entidades, o relacionamento entre entidades e os atributos que tem valores para descreverem as propriedades das entidades e/ou relacionamentos [13]. Um exemplo de um modelo MER está demonstrado na Figura 4 do Anexo. Diagrama de Entidade-Relacionamento (DER): Um modelo de dados de alto nível que demonstra, esquematicamente, todas as entidades dentro do âmbito de integração e a relação direta entre essas entidades [13]. Chave : Um item de dado ou combinação de itens de dados utilizados para identificar ou localizar uma instância de um registro ou algum agrupamento de dados similares [13]. Chave Primária : Um atributo único utilizado para identificar um registro em um banco de dados [13]. 8 Uma ou mais colunas que unicamente identificam uma linha da tabela. Chaves primárias devem ser únicas e não nulas [5]. Chave Estrangeira: Uma ou mais colunas que referenciadas à chave primária de outra tabela [5]. Chave Comum: Uma ou mais colunas que são freqüentemente utilizadas para relacionar tabelas [5]. Chaves não são o mesmo que índices. Uma chave pode ou não ser um índice [5]. Chaves são definidas no projeto lógico enquanto índices são definidos no projeto físico para garantir performance e outras razões [5]. 1.1.8. Banco De Dados Relacional Um Sistema Gerenciador de Banco de Dados Relacional (SGBDR) mantém tabelas que são compostas por colunas que descrevem linhas de dados [13]. Uma base ou banco de dados é uma coleção de dados relacionados e armazenados ( freqüentemente com redundância controlada e limitada) de acordo com um esquema. Um banco de dados pode servir única ou múltiplas aplicações [13]. Os atuais Sistemas Gerenciadores de Bancos de Dados Relacionais oferecem uma solução poderosa e eficiente para o processamento de grandes volumes de transações de uma grande variedade de aplicações comerciais e científicas [7]. 1.1.8.1. Tabelas Tabela é uma relação que consiste em um conjunto de colunas com um título e um conjunto de linhas. Coluna é uma tabela vertical onde são selecionados valores do mesmo domínio. Uma linha é composta de uma ou mais colunas [13]. 9 Em um banco de dados relacional, todos os dados estão em tabelas. Uma tabela mantém dados relacionados com uma classe particular de objetos (uma entidade). Tabelas são compostas por linhas e colunas. Existe exatamente um conteúdo de dado em cada coluna de cada linha [28]. 1.1.9. Banco De Dados Multidimensional Um sistema gerenciador de banco de dados especificamente projetado para suportar várias dimensões de dados em uma arquitetura três camadas. Tipicamente não suportam SQL (Structured Query Language) diretamente e, atualmente, suportam um volume de dados significantemente menor que um Sistema Gerenciador De Banco De Dados Relacional. Entretanto, esse tipo de gerenciador de banco de dados pode ser uma excelente opção para uma implementação departamental se a funcionalidade que ele provê atende à demanda do usuário referente às informações do negócio [13]. “As pessoas falam da necessidade de separar a captura dos dados do acesso aos dados, em termos de bases separadas, movendo informações entre si, ao menos desde o início dos anos 80”, testemunha o especialista da IDC em data warehouse Henry Morris. O que mudou foi a maturação de várias tecnologias-chave: agora não é mais só o banco de dado relacional; mas SGBDR multidimensional, com features especiais para aumento de performance, como indexação bitmap, e novos esquemas para organizar e representar os dados, visando não somente a inserção rápida de novas transações, mas análise e consultas complexas [2]. 1.1.10. Análise Multidimensional Análise multidimensional é a habilidade em manipular dados que foram agregados em várias caregorias ou dimensões. A proposta da análise multidimensional é auxiliar o usuário a sintetizar a informação da empresa através de uma visão comparativa, personalizada e projetada para a análise de dados históricos [13]. 10 Algumas ferramentas de análise multidimensional possuem a habilidade em acessar dados em um sistema gerenciador de banco de dados relacional; outras requerem um esquema estrela (“star schema”) para facilitar o processamento multidimensional [13]. A visão multidimensional é muito mais útil para os analistas do que a tradicional visão tabular utilizada nos sistemas de processamento de transação. Ela é mais natural, fácil e intuitiva, permitindo a visão dos negócios da empresa em diferentes perspectivas e, assim, transformando o analista num explorador da informação [6]. 1.1.11. OLTP (Online Transaction Processing) Processamento de aplicações transacionais [13]. Transações OLTP são extremamente disciplinadas [13]. O ambiente OLTP é previsível e regular em seu tamanho e forma [13]. Transação OLTP consome poucos recursos; pesquisa quantidade reduzida de dados. Como resultado desta disciplina, o tempo de resposta de uma transação é bom (dois a três segundos são o normal) [13]. De maneira geral, um sistema aplicativo está focado na precisão dos processos operacionais [30]. 1.1.12. OLAP (Online Analytical Processing) Processamento Analítico Online é um importante método na arquitetura do data warehouse na qual os dados podem ser transformados em informação. OLAP é uma categoria de tecnologia de software que permite à analistas, gerentes e executivos a obterem perspicácia em dados de uma forma rápida, consistente e com acesso interativo para uma grande variedade de possíveis visões da informação na empresa. Mais suscintamente, OLAP é um conjunto de funcionalidades que tem, como principal objetivo, facilitar a análise multidimensional [13]. 11 OLAP representa um conjunto de tecnologias projetadas para suportar análise e consultas ad hoc (consultas efetuadas pelo usuário de acordo com sua necessidade momentânea) [6]. A característica principal dos sistemas OLAP é permitir uma visão conceitual multidimensional dos dados de uma empresa [6]. A tecnologia OLAP foi definida em 1993 por F. Cood [4]. A criação foi em decorrência da forte necessidade de análises dos dados de forma fácil e flexibilidade, mas ao mesmo tempo, analisando múltiplas visões do negócio em diferentes níveis de detalhes [4]. Os bancos de dados multidimensionais foram a resposta para atender a essas necessidades analíticas. No início dos anos 90 começaram a surgir os primeiros protótipos de bancos de dados multidimensionais. Após alguns anos de aprimoramento da tecnologia, os bancos de dados multidimensionais foram submetidos à análise de CODD e sua equipe em 1993. CODD então definiu 12 regras, padrões, homologou a tecnologia, e batizou os bancos de dados multidimensionais com o nome de OLAP (derivado do termo OLTP - que foi atribuído aos Bancos de Dados Relacionais no início da década de 1970, quando CODD definiu os padrões para modelo Relacional) [4]. A partir da homologação de CODD, a tecnologia começou a ser utilizada e conhecida em 1994, e os fornecedores da tecnologia criaram produtos com cada vez mais capacidade de armazenamento, bem como vários outros recursos para facilitar as análises [4]. Começou então a utilização de Banco de Dados Multidimensionais como Data Marts entre 1995/96 e a tecnologia evoluiu a passos largos[4]. As bases OLAP podem ser acessadas/manipuladas através de aplicações personalizadas ou ainda: [4]. via Internet/Intranet [4]. via aplicações pré-definidas para se fazer análises diversas [4]. 12 A tecnologia OLAP hoje é largamente utilizada na elaboração de Data Marts, com desdobramentos para ROLAP/modelagem NxN no Relacional) e HOLAP (Híbrido OLAP que combina OLAP com ROLAP) [4]. A utilização de OLAP híbrido, o H-OLAP só é necessária quando se trata de bases muito grandes, de grande ocorrência em Varejo, Banco e Seguradoras [4]. Histórico de lançamento de alguns produtos OLAP [17]: Em 1970, Express foi a primeira ferramenta multidimensional usada para aplicações de marketing. Foi adquirida pela Oracle em 1995 [17]; Em 1982, Comshare System W foi a primeira ferramenta OLAP usada para aplicações financeiras [17]; Em 1984, Metaphor foi o primeiro ROLAP. Foi adquirido pela IBM em 1991 [17]; Em 1985, Pilot Command Center foi o primeiro EIS Cliente/Servidor estilo OLAP [17]; Em 1992, Arbor Essbase primeiro OLAP Cliente/Servidor que usa a planilha eletrônica com front-end [17]; Em 1994, MicroStrategy DSS Agent primeiro ROLAP com um engine multidimensional [17]; Em 1995, Holos 4.0 primeiro HOLAP [17]; Em 1996, Business Objects primeira ferramenta que provém ao mesmo tempo relatórios relacionais e multidimensionais de cubos construídos dinamicamente no desktop de dados relacionais [17]; Em 1998 IBM lança o IBM DB2 OLAP [17]; Em 1998 Microsoft lança Microsoft OLAP [17]. 1.1.12.1. ROLAP (Relacional OLAP) Qualquer análise multidimensional efetuada em um sistema gerenciador de banco de dados relacional. A base de um desenho físico ROLAP é, tipicamente, 13 uma combinação de dados apropriadamente normalizados em uma ou mais técnicas star schema [13]. 1.1.12.2. MOLAP (Multidimensional OLAP) Qualquer análise multidimensional efetuada em um sistema gerenciador de banco de dados multidimensional [13]. MOLAP é uma classe de sistemas que permite a execução de análises bastante sofisticadas usando como gerenciador de dados um banco de dados multidimensional [6]. 1.1.12.3. HOLAP (Híbrido OLAP) É um produto de OLAP híbrido que pode prover análise multidimensional simultaneamente de dados armazenados em um banco de dados multidimensional e em um banco de dados relacional [17]. 1.1.12.4. WOLAP (Web OLAP) Representa a migração da tecnologia OLAP para o ambiente da Internet. Tem havido uma grande divulgação sobre o uso de Web browsers para acesso à OLAP, mas ainda são poucos os sites em funcionamento com o uso de OLAP. Segundo alguns institutos de pesquisa o OLAP baseado na Web será a chave para aplicações na Intranet e deverá oferecer um caminho simples e barato no acesso ao data warehouse [17]. 1.1.13. Operações Olap Operações OLAP são as operações de pesquisa e exploração da informação no cubo de dados. São elas: [21]. 14 Slice and Dice: São operações de fatiamento do cubo de dados, permitindo sua visualização em segmentos, assim como a rotação do cubo buscando novas perspectivas de visão de dados [21]. Drill Down e Roll UP: É a capacidade de navegação aprofundando o nível de detalhamento dos dados, ou subindo este nível de detalhe conforme a hierarquia [21]. 1.1.14. Modelagem Dimensional Dos Dados A modelagem dimensional é a técnica utilizada para se ter uma visão multidimensional dos dados. Nessa técnica, os dados são modelados em uma estrutura dimensional conhecida por cubo. As dimensões do cubo representam os componentes dos negócios da empresa, tais como “cliente”, “produto”, “fornecedor” e “tempo”. A célula resultante da intersecção das dimensões é chamada de medida e geralmente representa dados numéricos como “unidades vendidas”, “lucro” e “total de venda” [6]. Além dos componentes dimensão e medida, outro importante aspecto do modelo multidimensional é a consolidação dos dados, uma vez que para a tarefa de análise são mais úteis e significativos à agregação (ou sumarização) dos valores indicativos dos negócios [6]. O próprio desenho do data warehouse leva a novas perspectivas de projeto. Não há necessidade de modelagem na terceira forma normal. Na prática, redundância de dados é bem-vinda nesse ambiente. Para muitos projetistas, é uma maneira diferente de modelar dados [30]. Modelagem Dimensional é um nome novo para uma técnica antiga usada para criar bancos de dados simples e compreensíveis. Quando um banco de dados pode ser visualizado como um “cubo” contendo até três, quatro, cinco ou mais dimensões, as pessoas conseguem visualizar este esse cubo em qualquer de suas dimensões [19]. 15 Outro nome para modelo dimensional é star join schema. Os projetistas de bancos de dados têm utilizado esse nome já há algum tempo para descrever modelos dimensionais porque o diagrama é semelhante a uma estrela com uma tabela no centro rodeada por tabelas auxiliares exibidas em um padrão radial [19]. Dimensional Modeling (DM) é uma técnica lógica de projeto muito utilizada nos data warehouses, diferente e oposta ao entity-relation modeling (ER). O DM é a única técnica viável para os bancos de dados projetados para suportar as consultas de usuário final de um data warehouse. O ER é muito útil na captura de transações e nas fases de administração de dados da construção de um data warehouse, mas deve ser evitado para o usuário final [3]. O DM é uma técnica lógica de projeto que busca apresentar os dados dentro de uma estrutura padrão e intuitiva, permitindo ainda o acesso de alto desempenho. Ele é inerentemente dimensional e adota a disciplina com algumas restrições importantes. Todo modelo dimensional é composto por uma tabela com uma chave de várias partes, denominada tabela de fatos e um conjunto de tabelas menores chamadas tabelas de dimensão. Cada tabela de dimensão possui uma chave de uma única parte, que corresponde exatamente a um dos componentes da chave de várias partes da tabela de fatos. Essa característica de estrutura de “estrela” também é chamada de star join. Este termo remonta os primeiros dias dos bancos de dados relacionais [3]. 1.1.14.1. Fatos São as medidas básicas de informações do negócio. Representa as quantidades e valores dos dados que podem ser agregados sem perderem seu significado. A tabela fato ou fact table armazena as medidas básicas objetos de análise do negócio. O dado na tabela fato é composto de elementos de dados organizados em um nível estruturado. Os valores destes elementos de dados podem 16 ser sumarizados em uma variedade de formas sem por em risco a integridade dos dados [13]. A chave de uma tabela fato é a composição das chaves das tabelas dimensão. O resultado é que existirá uma linha na tabela fato para cada combinação única dos domínios de todas as chaves de todas as tabelas dimensão. Características: [13] Quantifica o dado que foi descrito nas tabelas dimensão [13]. Chave composta de combinação única de valores das chaves das dimensões [13]. Os valores da tabela fato são somente aditivos [13]. Sempre contém uma data [13]. 1.1.14.2. Dimensões De Um Cubo Descrevem ou caracterizam os dados relacionados e organizados na tabela fatos. As tabelas dimensão circundam a tabela fato. Representam as possíveis formas de visualizar e consultar os dados. Características: [13] Chave deve ser única [13]. Permitir gerenciar número de níveis de agregações [13]. Dimensão não precisa ser uma hierarquia, pode ser uma combinação de atributos [13]. (Exemplo demonstrado na Figura 1 do Anexo) [13]. 1.1.14.3. Agregações Agregações são sumarizações de dados com o objetivo principal de melhorar a performance de acesso. Geralmente armazenadas em tabelas fatos separadas [13]. 17 Abstração de dados que, aplicada à modelagem conceitual de dados, permite que objetos venham a formar um novo objeto de mais alto nível. Foi proposto por J. M. Smith em 1977 [27]. Agregações fornecem níveis múltiplos de detalhes do fato [18]. Os resultados das queries (ou seus valores intermediários) são précalculados, o que melhora muito a performance [18]. As agregações podem ser acumuladas através de agrupamentos diferentes, freqüentemente através de várias dimensões ou combinação de dimensões [18]. O único aspecto mais importante de desígn de um data warehouse é o assunto da granularidade. Granularidade se refere ao nível de detalhe contido as unidades de dados no data warehouse [12]. Quanto mais detalhamento há, mais baixo será o nível de granularidade. Quanto menos detalhamento há, mais alto o nível de granularidade [13]. A razão por que granularidade é o assunto de desígn principal no ambiente de data warehouse é que afeta profundamente o volume de dados residente no data warehouse e ao mesmo tempo afeta o tipo de questão que pode ser respondida [12]. 1.1.14.4. Técnica star schema (esquema estrela) A técnica star schema pré-processa os dados em uma tabela fatos central com tabelas de dimensão relacionadas. As chaves únicas de cada tabela dimensão compõem uma chave combinação na tabela fatos. Os benefícios desta técnica são que os dados estão pré-processados em dimensões conhecidas e caracterizadas em um conjunto específico de necessidades de informação do negócio, tornando o acesso pelo usuário mais eficiente (Exemplo demonstrado na Figura 2 do Anexo) [13]. Este modelo é composto por uma tabela com chave de múltiplas partes (dimensões) chamadas de tabela fato e de um conjunto de tabelas pequenas 18 chamadas de dimensões, que formam as pontas das estrela. Cada tabela de dimensão tem uma chave primária simples que corresponde a um dos componentes da chave múltipla da tabela fato. A princípio parece um modelo muito simples de ser construído, porém a determinação das dimensões e do fato tem necessidade de excelente entendimento conceitual para que se obtenha sucesso em uma implantação de data warehouse [21]. 1.1.14.5. Técnica snow flake (floco de neve) A técnica snow flake é uma variante do star schema com as tabelas dimensões normalizadas (Exemplo demonstrado na Figura 3 do Anexo) [21]. As hierarquias tem significado e importância dentro da análise multidimensional. No modelo star, elas estão todas em vista da desnormalização das entidades, um dos conceitos básicos de modelagem multidimensional. Um esquema alternativo é o esquema snow flake, onde normalizando as hierarquias encadeamos relacionamentos e entidades a partir das dimensões. A utilização de esquema snow flake depende da necessidade de otimizações no projeto físico ou nas queries realizadas. Lembramos que sempre um data warehouse tem como objetivo sistemas de apoio a decisão, que necessitam das mais variadas consultas [21]. Um esquema snow flake em nosso entendimento é somente uma alternativa de construção do modelo de dados multidimensional .Todo modelo snow flake pode rapidamente ser transformado em um star, bastando para isto relacionarmos as hierarquias diretamente às tabelas fato, desnormalizando-as completamente [21]. 1.1.15. Metadados São dados sobre dados. Descrição dos dados: estrutura, conteúdo, chaves, índices, detalhes, etc. Sem os metadados, o data warehouse e seus componentes 19 associados seriam meramente componentes não integrados trabalhando independentemente e com objetivos distintos [13]. Para alcançar harmonia e unidade entre os diferentes componentes do ambiente projetado, deve haver uma técnica bem definida e rigorosa para desenvolver os metadados. Existem metadados para: [13] O ambiente operacional [13]. A camada de integração e transformação [13]. Porções detalhadas do data warehouse [13]. Depósitos de dados operacionais [13]. Data mart’s [13]. Ambiente de desenvolvimento [13]. Modelo do negócio da Empresa [13]. Para atingir um grau de segurança na confiabilidade dos dados, o primeiro passo é catalogar os metadados com RDBMS (Relational Data Base Management System), plataforma, fontes de dados, tabelas, campos, índices, chaves primárias, chaves estrangeiras, stored procedures, parâmetros, programas – ou seja, o metadados contém todas as informações que explicam o funcionamento da base de dados [22]. Com os metadados catalogados, as estruturas de dados de todo o ambiente estarão sempre sendo verificadas. Portanto, a cada mudança que ocorra nas bases de dados transacionais, o administrador estará sempre sendo alertado, o que aumenta sua confiança na informação que estará sendo disponibilizada aos tomadores de decisão [22]. Importante utilizar metadados para descrever o modelo dos dados e para auxiliar na construção das consultas. Dessa maneira, um analista pode executar suas análises utilizando seus próprios termos [6]. É o dado sobre um determinado dado. Por exemplo: os metadados poderiam indicar se uma base de dados existe na corporação, quais atributos formam uma 20 determinada tabela, características físicas de um determinado atributo, tais como: tamanho e formato, onde ele é utilizado, etc. As informações do metadado podem ser sobre os dados do legado, dados armazenados em data warehouse ou informações pertinentes a um catálogo. Estas informações são armazenadas em um repositório que tem o objetivo de documentar e administrar estes metadados e fornecer informações para reuso destes dados, melhorando a qualidade e produtividade da empresa [16]. Metadados é a mais importante regra no data warehouse e, é usado em vários aspectos: [14] É direcionado para ajudar na localização analítica do conteúdo no data warehouse para o DSS [14]. É um guia para mapear os dados, como o dado é transformado do ambiente operacional para o ambiente do data warehouse [14]. É um guia para o algoritmo usado para a sumarização entre dado corrente detalhado e o dado “lightly” sumarizado e o dado “highly” sumarizado, etc [14]. 1.1.16. Ferramenta CASE (Computer Aided Software Engineering) São ferramentas individuais que auxiliam o desenvolvedor de software ou gerente de projeto durante uma ou mais fases do desenvolvimento de software (ou manutenção) [10]. Uma combinação de ferramentas de software e metodologias de desenvolvimento estruturado [10]. CASE pode auxiliar diretamente no projeto e suporte do desenvolvimento de sistemas e também provê gerenciamento da informação, documentação e controle de como desenvolver um projeto [10]. Alguns benefícios do CASE: [10] Reduz custos, especialmente manutenção [10]. 21 Melhora a qualidade de software [10]. Acelera o processo de desenvolvimento [10]. Incrementa a produtividade [10]. Tornam práticas as técnicas estruturadas [10]. 1.1.17. SQL (Structured Query Language) É uma linguagem padrão de acesso aos dados em bancos de dados relacionais independente de fornecedor. É dividida em três partes: linguagem de definição de dados (DDL), linguagem de manipulação de dados (DML) e linguagem de controle de dados (DCL). O padrão internacional é estabelecido pela ISO (International Organization for Standardization). A primeira normatização do SQL foi feita pela ANSI (American National Standards Institute) em 1986. O SQL/86 foi um subconjunto das implementações de SQL da IBM. A primeira norma da ISO saiu em 1989. A norma internacional vigente é a versão de 1992 (ISO/IEC 9075:1992(E), também conhecida como SQL92 ou SQL2). Ela se subdivide em 3 partes: Entry Level, Intermediate Level e Full Level. A maioria dos sistemas gerenciadores de banco de dados só implementa o Entry Level completamente. Já existem trabalhos para o SQL/3 e SQL/MM (Multimídia) que devem implementar alguns conceitos da tecnologia de orientação à objeto. Um dos órgãos de certificação de conformidade dos produtos com a norma é o NIST (National Institute of Standards and Technology) que publica o FIPS (Federal Information Processing Standards) que contém uma lista de sistemas gerenciadores de banco de dados que tem conformidade com o padrão e em qual plataforma [27]. Uma linguagem que habilita o usuário a interagir diretamente com o sistema gerenciador de banco de dados para recuperar e/ou modificar dados gerenciados pelo mesmo [13]. Características: [28] É uma forma padrão de especificar conjuntos de dados [28]. 22 É uma forma de recuperar e manipular dados em um banco de dados relacional [28]. É utilizada para todas as funções de bancos de dados, incluindo administração, criação de esquemas e recuperação [28]. Pode ser utilizada na forma de “SQL embutida” em um programa de aplicativo [28]. 1.1.17.1. Stored procedure (sp) Stored Procedure é uma técnica de projeto que permite que um conjunto de instruções SQL sejam compiladas e armazenadas no gerenciador de banco de dados. São rotinas chamadas por aplicações cliente de modo semelhante a RPC (Remote Procedure Call) e são armazenadas e executadas no servidor. A stored procedure fornece uma significante melhora de performance sobre o SQL utilizado diretamente na aplicação [27]. Uma stored procedure é uma coleção de comandos SQL armazenados no banco de dados e que pode ser executada pelo nome. Características: [5] Podem aceitar e retornar parâmetros e podem chamar outras procedures [5]. Processam mais rapidamente que os mesmos comandos SQL executados interativamente [5]. Reduzem o tráfego de dados na rede [5]. A primeira vez que uma stored procedure é executada, um plano de acesso é produzido no banco de dados [5]. Garantem a consistência do banco de dados [5]. Provêem um nível extra de segurança [5]. Sugerem o desenvolvimento de uma aplicação modular [5]. Reduz erro de operação [5]. Exemplo de sintaxe padrão de criação de uma stored procedure: [5] 23 create proc nome da procedure as comandos_SQL Exemplo de sintaxe padrão de execução de uma stored procedure: [5] exec nome da procedure 1.1.18. Indexação É o conceito de índices de acesso. São estruturas de indexação destinadas a otimizar o acesso aos dados. É importante lembrar que em bancos de dados relacionais, uma chave nem sempre tem um índice associado a ela. Chaves são definições de nível lógico e os índices são estruturas físicas para melhorar a performance no acesso aos dados. Há dois tipos de índices: clustered index e nonclustered index. No clustered index os dados de uma tabela são ordenados fisicamente pelo índice. Ele tem um nível a menos de acesso em relação ao nonclustered. O índice nonclustered armazena os valores das chaves e ponteiros para as páginas de dados onde as linhas estão armazenadas [27]. Índice : Porção da estrutura de armazenamento de dados mantida para prover acesso eficiente a um registro quando seu conteúdo chave é conhecido [13]. Índice Invertido : Uma estrutura de índice organizada por meio de uma chave não única que aumenta a velocidade de pesquisa aos dados [13]. Índices: [5] São utilizados para melhorar a performance. (se nenhum índice é definido a uma tabela, a tabela inteira deverá ser pesquisada para satisfazer uma condição de consulta) [5]. Provêem um mecanismo para garantir a unicidade [5]. Clustered: O dado é classificado na ordem do índice. Somente pode existir um único índice clusterizado por tabela (geralmente é a chave primária). Determina a ordem física do dado na tabela [5]. 24 NonClustered: O dado não é classificado na ordem da chave Podem existir vários índices associados à tabela (geralmente são as chaves estrangeiras) [5]. 1.2. ASPECTOS ESTRATÉGICOS PARA A CONSTRUÇÃO DE UM DATA WAREHOUSE 1.2.1. Planejamento Um problema sério em projetos de data warehouse é um planejamento defeituoso. O fato de todos concordarem que o projeto de um data warehouse não se baseia em requisitos bem delimitados não significa que os projetistas não devam planejar minuciosamente cada atividade do processo. E mais, tal planejamento deve levar em consideração o fato de se tratar de um data warehousing mais que um data warehouse: um processo sem fim para todos os efeitos práticos. Deve ser considerado o longo prazo geralmente envolvido. Não se estará projetando uma aplicação operacional, mas sim um repositório de informações gerenciais [9]. A operação do negócio tende a uma estabilidade grande. Um aplicativo voltado para gerir essas atividades tende, portanto, a ser bastante estável, pelo menos quando comparado às necessidades de informação para a tomada de decisão. É aqui que a competitividade do mercado se faz sentir. As perguntas que os executivos precisam ver respondidas hoje para tomarem suas decisões podem ser substancialmente as de amanhã. Desse modo, um planejamento consistente deve prever liberações parciais de dados, em curtos intervalos, de maneira que o usuário cedo possa interagir com o ambiente, facilitando essa mudança inevitável de requisitos. Os planejadores devem identificar muito cedo os alvos do projeto e seus benefícios [9]. Recomenda-se que o data warehouse não comece muito ambiciosamente. O primeiro projeto não deve levar mais que nove meses para estar operacional e deve atingir basicamente as áreas de negócio mais importantes e que tragam 25 retorno direto e tangível. Com o tempo, ele será refinado e aumentado em sua abrangência [29]. Um projeto de data warehouse deve ser conduzido com enfoque diferente de um projeto de aplicações tradicional. A primeira etapa é identificar os objetivos da organização, sob a óptica de seus executivos. A empresa pretende crescer dentro de seu segmento de negócio? Ou pretende expandir seu market-share ? Depois, são identificados os processos de negócio diretamente relacionados com esses objetivos. A seguir, definem-se as informações que são necessárias para suportar esses processos de decisão. Onde essas informações serão obtidas? As especificações técnicas aparecem no final, quando então se desenham as alternativas tecnológicas para a sua total implementação [30]. 1.2.2. Necessidades Das Empresas No princípio haviam sistemas simples de automação. Então vieram sistemas de banco de dados e sistemas on-line. Em um tempo muito pequeno o computador tinha achado seu modo de incorporar-se ao cotidiano das empresas. De quase nenhum computador nos anos cinqüenta para milhões de computadores de todo tipo e tamanho nos anos oitenta, o mundo da tecnologia explodiu além de qualquer previsão a uma taxa de crescimento que parecia ser impossível acreditar [13]. Os sistemas de computação iniciais foram projetados para processar as transações diárias da corporação. Decisões imediatas eram o enfoque destes sistemas pioneiros. Com o advento dos primeiros sistemas, veio um subproduto de dados. Estes dados refletiam as atividades que estavam acontecendo e cresceram à medida que o tempo passava e de como o negócio era administrado [13]. Logo, a quantidade de trabalho exigiu manter as aplicações ao ponto em que 95% do trabalho era dedicado à manutenção de programas. Ao mesmo tempo em que o fardo de manutenção estava crescendo, os usuários finais estavam ficando frustrados com a inabilidade dos sistemas de informação da organização em 26 responder às necessidades de informação. Caso após caso, os usuários finais sabiam que os dados de que eles precisavam estavam disponíveis mas difíceis de serem obtidos. Ainda, em cada caso, o departamento de sistemas de informação dava uma ou outra justificativa do porquê de os dados não poderem ser acessados. Usuários finais sentiam-se abandonados e frustrados [13]. Então, o data warehouse foi criado. O data warehouse transferiu os dados do ambiente transacional, armazenando-os e organizado-os de forma que o usuário final poderia obter a informação pela qual tanto ansiava. Afinal, os dados estavam disponíveis em uma base para que o usuário processasse suas próprias consultas [13]. O data warehouse representou uma troca fundamental na concepção de sistemas de informação e introduziu alguns conceitos novos importantes: [13] Dados devem ser integrados através da empresa [13]. Dados sumarizados tem um grande valor para a organização [13]. Dados históricos são a chave para compreender os dados ao longo do tempo [13]. Metadados representam um papel muito importante na infra-estrutura do data warehouse [13]. Muito importante manter a precisão dos dados históricos com o passar do tempo [13]. Além de resolver alguns problemas muito importantes para a corporação, a criação do data warehouse aliviou o fardo do programador de aplicação em tentar transformar o ambiente de sistemas legado em um sistema para a tomada de decisão. As solicitações dos usuários e a manutenção das aplicações, pela primeira vez, tornaram-se gerenciáveis [13]. O objetivo básico do data warehouse deve ser adicionar valor ao negócio. À medida que as regras do negócio são incorporadas às aplicações, exige-se rapidez cada vez maior nas respostas. O ambiente de negócios é crescentemente dinâmico. 27 Responder com rapidez ao como, quando e quanto passa a ser decisivo para a empresa sobreviver e crescer nesse cenário [30]. As organizações hoje em dia estão enfrentando enormes pressões para prever informações de melhor qualidade para tomada de decisões, em formatos de fácil acesso e manipulação. Em poucas palavras, as empresas precisam se tornar mais ágeis em sua capacidade de utilizar as enormes quantidades de dados no esforço de proporcionar melhor suporte ao cliente [32]. Um data warehouse reconhece o valor estratégico do gerenciamento intencional do bem corporativo de dados. A ênfase no data warehouse reflete o reconhecimento de que a exploração de dados é o caminho para vantagem competitiva, novas oportunidades de negócios, e melhoria no serviço ao cliente. Ela também reconhece que os sistemas tradicionais de gerenciamento de base de dados estão geralmente assoberbados pelo enorme volume de dados que lhes são confiados. Como resultado, os sistemas de extração de informações que trabalham com a totalidade das bases de dados geralmente funcionam mal [32]. O data warehouse e a arquitetura associada a ele providencia o objetivo para lutar contra os mais variados desafios confrontados nos sistemas de informações gerenciais de hoje [14]. Em outras palavras, o data warehouse permite o gerenciamento para considerar resultados no contexto. Sem a armação do data warehouse e sua arquitetura associada é uma tarefa quase impossível formar sentido para os diversos resultados obtidos [14]. Os sistemas de informações (IS) gerenciáveis encontram a noção da arquitetura indispensável no movimento da corporação dentro de um mundo de processamento de informação efetiva. Em particular, o IS gerenciável usa a arquitetura como um guia para o gerenciamento, como o seguinte: [14] uso da armazenagem e aquisição [14] tecnologia adequada com processamento necessário [14] 28 gerenciamento de orçamento [14] mudança de tecnologia e plataforma [14] informações derivadas do ambiente de produção [14] determinação das responsabilidades organizacionais [14] desenvolvimento de relatórios da arquitetura [14] definição da interface entre as diferentes unidades organizacionais [14] gerenciamento de gráficos organizacionais como a responsabilidade no processamento da informação concernida [14] gerenciamento do impacto na arquitetura no desenvolvimento do processo [14]. Afinal, é antigo o enfoque por trás da idéias do depósito, galpão ou armazém de dados extraídos dos muitos sistemas de produção – geralmente “legacy systems” – das companhias: transformar o dado cru em informação, para obtenção de vantagem competitiva. [2] Data warehouse é entendido como uma “enabling technology”; uma tecnologia-meio, que favorece a tomada de decisões ao separar sistemas de informações para decisão dos dados de produção. Essa divisão dos dados permite, dizem os entusiastas, melhor alocação e administração de recursos; enquanto que a proliferação de ferramentas sofisticadas de acesso possibilita combinar várias fontes de dados de estruturas distintas e concretiza, assim, antigas promessas de gerência participativa e menor concentração de poder decisório [2]. 1.2.3. Hierarquia Clássica Da Informação Na Empresa Pirâmide com três níveis: [33] 1º Nível (Topo da Pirâmide) é o Nível Estratégico: EIS-Sistema de Informações Executivas [33]. 2º Nível (Meio da Pirâmide) é o Nível Tático: DSS-Sistema de Suporte a Decisão [33]. 29 3º Nível (Base da Pirâmide) é o Nível Operacional: Sistemas Operacionais [33]. O patrocínio efetivo da alta administração da empresa é crítico. E esse patrocínio não pode se revelar apenas na hora de assinar o cheque. A empresa precisa fornecer os analistas do negócio, aqueles técnicos que conhecem profundamente a informação e o negócio da empresa [9]. Drivers para data warehousing: [31] Operacional [31] Substituir relatórios feitos no mainframe [31]. Dar ao usuário o acesso direto aos dados [31]. Atualizar o sistema [31]. Tático [31] Explorar novos recursos e funcionalidades de análise de dados [31]. Fornecer melhores informações para o processo de decisão gerencial [31]. Melhorar o conhecimento da empresa sobre seus dados [31]. Estratégico [31]. - - Competitividade [31]. Time-to-market [31]. Qualidade de produtos e serviços [31]. Mercado global (pressionando preço e qualidade) [31]. Quebra de paradigmas [31]. Privatização [31]. Novos mercados [31]. 1.2.4. Motivação Da Empresa No Mercado O verdadeiro impulso para a utilização da tecnologia de data warehouse começou quando as pessoas perceberam que as informações disponíveis no data 30 warehouse poderiam ser utilizadas para a obtenção de vantagem competitiva. Esta informação apoiou a habilidade da corporação em atrair e manter parte do mercado, reduzir despesas e aumentar as vendas. Estes atributos elevaram o data warehouse para a vanguarda de sistemas de informação, tornando-o promissor tanto para o profissional técnico da informação quanto para o profissional da área de negócios [13]. Estamos vivendo o início da era da informação. Nela os grandes desafios são a integração dos processos operacionais entre as empresas e o gerenciamento do negócio através da análise dos fatos para identificação de oportunidades [25]. 1.2.5. Necessidades e Benefícios Para o Usuário A necessidade principal do usuário é a transformação dos dados em informações [13]. Embora o seu uso ainda seja incipiente, alguns resultados positivos parecem demonstrar que realmente o data warehouse produz um alto retorno sobre o investimento. A grande vantagem de um data warehouse é permitir a tomada de decisões baseadas em fatos. Na verdade, ele busca disponibilizar à organização o grande volume de dados que foram e estão sendo armazenados em bases de dados operacionais, espalhadas por toda a empresa [29]. O principal resultado de um data warehouse é, indiscutivelmente, a facilidade de os gestores da empresa poderem tomar decisões rápidas, baseados em informações mais consistentes [29]. Levantamentos realizados junto a usuários em âmbito mundial e local atestam o sucesso dos projetos já implantados, nos quais os primeiros resultados apontaram para: aumento do tempo dos tomadores de decisão (decision makers) para a análise e tomada de decisão; eliminação de tarefas operacionais como pesquisa e identificação dos dados necessários ao processo decisório; melhor confiabilidade das informações devido à implantação de um elo integrador dos 31 dados transacionais; racionalização do fluxo de informações da empresa; padronização dos conceitos de negócio; democratização das informações sobre o desempenho do negócio [22]. 1.2.6. Perfil Do Usuário Na Empresa Que Utiliza O Data Warehouse O usuário, o formulador de perguntas, é o ponto mais crítico nos projetos de data warehouse. Idealmente, os usuários devem ser membros da equipe de projeto, desde o seu nascimento [9]. Os usuários finais do data warehouse tem alguns papéis específicos a cumprir. Estes geralmente dividem-se em duas categorias: Suporte aos Papéis e Tipos de Usuário [13]. Suporte aos Papéis: [13] Cada interação do data warehouse deve ter um “Patrocinador Executivo” da área de negócios da comunidade usuária que serão os primeiros beneficiários da funcionalidade destas interações. O Patrocinador Executivo é especialmente importante para o data warehouse. Ele define o escopo e requisitos do negócio e analisa as necessidades de informação da organização para a tomada de decisão. Existem, também, dois importantes papéis adicionais na comunidade de usuários finais: Especialista do Assunto e Técnico de Apoio ao Usuário [13]. O Especialista do Assunto é quem facilita a comunicação entre os usuários finais e a equipe técnica do data warehouse. Provê as informações para definir o escopo de uma interação do data warehouse. Participa no projeto e revisão da aquisição e capacidade de acesso aos dados. Assiste o treinamento de outros usuários em seus grupos funcionais. Atua como suporte a outros usuários em suas áreas [13]. O Técnico de Apoio ao Usuário provê apoio técnico global para os usuários do seu departamento, grupo, linha de negócio, etc.; entende o ambiente técnico de 32 uma área específica do data warehouse, presta apoio como administrador de banco de dados local e apoio técnico aos usuários locais [13]. Tipos de Usuário: [13] São categorizados como: Usuários de Aplicações Pré-definidas, Usuários com Acesso Limitado e Usuários com Acesso Ilimitado [13]. Os Usuários de Aplicações Pré-definidas não possuem um nível alto de experiência técnica mas estão, tipicamente, em um nível relativamente alto dentro da estrutura de administração de uma organização. Eles também são, freqüentemente, assistentes administrativos. Acessam o data warehouse através de consultas prédefinidas que atendem aos seus requisitos de negócio [13]. Os Usuários com Acesso Limitado são a maioria dos usuários analíticos. Requerem caminhos pré-definidos de acesso ao data warehouse como, por exemplo, uma ferramenta OLAP para facilitar o acesso e tem conhecimento em drillup/down. Tipicamente oferecem apoio aos pedidos de informação da administração superior [13]. Os Usuários com Acesso Ilimitado são os “exploradores”, altamente habilitados tecnicamente no acesso aos dados, precisam de ferramentas poderosas, procedurais e não ferramentas simples e limitadas. Freqüentemente desenvolvem aplicações para uso por outros tipos de usuários e, tipicamente, são um número pequeno de usuários. Oferecem apoio às exigências organizacionais para relatórios complexos [13]. Pode parecer desnecessário identificar os papéis chaves que os usuários executam no desenvolvimento e gerenciamento de um data warehouse. Entretanto, muitas organizações não têm reconhecido a importância que os usuários exercem durante esse desenvolvimento e, conseqüentemente, perderam a visão da importância em conduzir a evolução do data warehouse através das necessidades de negócio do usuário. O resultado é normalmente um enfoque tecnológico ao data warehouse e não um enfoque do usuário, resultando em um ambiente de informação 33 que não atinge as necessidades da organização para a análise e suporte à decisão [13]. De patrocinador da funcionalidade de negócio para um executivo que precisa monitorar as tendências em uma métrica importante do negócio; de perito de assunto para um usuário técnico altamente qualificado para a obtenção ocasional da informação, usuários têm papéis distintos e importantes a executar na evolução do data warehouse de forma que podem continuar satisfazendo suas exigências de informação sobre o negócio. Usuários também tem uma responsabilidade significativa como “bons cidadãos corporativos” para trabalhar com a equipe do data warehouse para assegurar-se de que o data warehouse continuará agregando valor à organização através de uma importante ferramenta tática e estratégica de análise e acesso à informação [13]. Um ingrediente essencial para o sucesso do ambiente do data warehouse é o fator humano. O melhor projeto e a melhor arquitetura no mundo não são bem usadas se não existirem pessoas capazes e preparadas para colocarem os planos em ação [14]. O ambiente do data warehouse é administrado por uma unidade organizacional chamada grupo de arquitetura de dados. O grupo de arquitetura de dados algumas vezes faz parte da administração de dados. [14]. Em outros casos, o grupo de arquitetura de dados permanece sozinho. O grupo de arquitetura de dados está próximo do grupo de sistemas ou do grupo de aplicações [14]. O grupo de arquitetura de dados possui interface com o topo gerencial, gerência do IS, da organização do IS e com o usuário final. O grupo de arquitetura de dados ultimamente é responsável para o sucesso ou falha do data warehouse [14]. 34 1.2.7. Análise Do Ambiente Legado Situada entre o ambiente operacional, o data warehouse e o depósito de dados operacionais está a interface de integração e transformação dos dados. Esta interface é o local onde o dados não integrados do ambiente operacional são integrados e enviados ao data warehouse [13]. As tecnologias de sistemas gerenciadores de bancos de dados que normalmente alojam as aplicações do legado mais antigas, usualmente requerem que os dados sejam acessados na forma de um registro por vez. Esta abordagem requer lógica de programa que é familiarizada com a maneira com que os dados são armazenados. Em muitos casos, o dados provenientes de muitas áreas de assunto diferentes são amarrados e controlados pelas aplicações. A execução da integração e transformação dos dados torna-se um problema complexo decorrente do grande volume de dados armazenados no ambiente de aplicações do legado. A integração e transformação dos dados a serem carregados no data warehouse são um dos aspectos mais importantes e devem ser cuidadosamente gerenciados [13]. Como todo o data warehouse depende dos dados disponíveis nas bases de dados operacionais da empresa, o primeiro passo para sua construção é o mapeamento dessas bases, sua limpeza e sincronização com as demais camadas. Para isso, é extremamente necessário conciliar em um único ambiente a administração de todas as bases de dados operacionais que são fonte de alimentação para o data warehouse com a administração do data warehouse em si [22]. Criar um data warehouse não é uma simples questão de escolha de banco de dados ou ferramentas, mas envolve planejamento e modelagem (aspectos que garantem a qualidade dos dados, fator crítico para o sucesso do projeto), escolha de ferramentas e atualização e refinamento contínuos. É, de fato, uma arquitetura completa e que se compõe dos seguintes elementos principais: bases de dados operacionais, que são as fontes primárias das informações; processos de extração e 35 conversão de dados; bancos de dados específicos para data warehouse; recursos de administração e ferramentas de inteligência de negócios, que facilitam o acesso, manipulação e análise dos dados contidos no data warehouse [24]. Um armazém de dados é composto de três áreas funcionais distintas, cada uma das quais deve ser customizada para satisfazer as necessidades do negócio. O primeiro componente é a aquisição de dados, podendo ser de sistemas legados ou de outras fontes quaisquer. Lá o dado é identificado, copiado, formatado e preparado para ser carregado no armazém. O segundo componente do armazém é o espaço de armazenamento e o terceiro é a área de acesso aos dados [26]. A busca pelas informações espalhadas pelas diversas aplicações e plataformas tecnológicas, pode ser um problema muito sério. Mesmo que as informações que vão preencher o data warehouse venham apenas de sistemas legados baseados em mainframes, o que nem sempre ocorre, a diversidade de tecnologias envolvidas é grande. Uma recente pesquisa mostrou que apenas 25% das informações desses sistemas estão em bancos de dados relacionais, como o DB2. A grande maioria está espalhada por bancos de dados não relacionais, arquivos VSAM, etc [29]. Um armazém de dados se propõe compatibilizar um número grande de sistemas desintegrados oriundos do legado a uma coleção igualmente diversa de tipos de estações de trabalho de usuário final. Os ambientes existentes normalmente se compõem de um conjunto de hardware sortido, software e sistemas operacionais incompatíveis e com características únicas a cada organização [26]. A maioria dos “armazéns de armazenamento” está sendo administrada por bancos de dados relacionais sob plataformas Unix. De acordo com o Meta Group Inc., Oracle, Sybase Inc., IBM Corp. e Informix controlam 65% do mercado de “armazéns de armazenamento”; os vendedores de outros bancos de dados relacionais e bancos de dados especializados são secundários nesse contexto [26]. 36 Uma questão relevante será como integrar as diversas fontes de dados legadas ou não, arquivos VSAM, DB2, CA-IDMS, CA-DATACOM, OpenIngres, Oracle, Informix, Sybase e mais uma infinidade de outras fontes. A resposta: utilizando gateways que tenham as características de transparência e confiabilidade para sustentar o ambiente de data warehouse [20]. O assunto mais óbvio relativo à interface de integração e transformação refere-se às tecnologias utilizadas pelos sistemas transacionais encontradas no ambiente legado (às vezes chamado de ambiente fonte) como, por exemplo, as tecnologias que são, na maioria dos casos antigas, orientadas à transações e complexas: IMS (Information Management System) – um sistema gerenciador de banco de dados hierárquico desenvolvido pela IBM para ambientes mainframe, VSAM (Virtual Storage Access Method) – arquivo indexado desenvolvido pela IBM para ambientes mainframe, IDMS, Adabas, Oracle, Sybase, Informix, Arquivos Seqüenciais, etc [13]. 1.2.8. Equipe De Desenvolvedores O crescimento do data warehouse criou a necessidade de disciplinar o gerenciamento do mesmo que é o papel do administrador do data warehouse (DWA). O DWA é parte administrador de dados, parte administrador de banco de dados, deve posicionar-se um pouco como usuário final, um pouco programador de sistemas e muito de programador e projetista de aplicação [13]. O administrador do data warehouse é um disciplinador organizacional que apareceu com o advento do data warehouse e dos sistemas de apoio à decisão. Ele é o principal responsável para o sucesso contínuo do armazém de dados [13]. O administrador do data warehouse deve conhecer as várias habilidades abaixo descritas: [13] Projetista da Base de Dados: projeta e constrói o data warehouse [13]. 37 Modelador de Dados: integra um novo data warehouse em um já existente [13]. Desenvolvedor : que mantém, nos programas, novas integrações e transformações de dados [13]. Político: solicita e negocia os recursos necessários para a construção do data warehouse [13]. Programador de Sistemas: capacidade de planejamento e refinamento do data warehouse [13]. Usuário final: deve entender as necessidades das áreas de negócio da empresa como, por exemplo, financeira, gerência de vendas, atuarial, engenharia, etc. [13]. Em alguns casos, o administrador do data warehouse não somente deve possuir as habilidades acima mas estar apto a executá-las. Em suma, o administrador do data warehouse é responsável por um ambiente inteiro de suporte à decisão que é o fator crucial para o sucesso da corporação [13]. O Administrador de Data warehouse (DWA) é o responsável pelo data warehouse, envolvendo obter, agendar e coordenar o trabalho entre os recursos humanos, preparando relatórios de situação, orientando revisões de design, garantindo que membros de equipes de trabalho e usuários finais estão sendo efetivamente treinados, e gerenciando outras atividades relacionadas ao Data warehouse como especificado pela gerência da organização [13]. O Administrador de Banco de Dados é essencial na organização da equipe de data warehouse, em número suficiente e dedicados em tempo integral. As diferenças entre os sistemas de informação e operacional da empresa devem ser acompanhadas pelo Administrador de Banco de Dados [13]. O Gerenciador de Metadados deve assegurar que os metadados no Subdiretório de Informações está sincronizado com a produção de recursos, regras de negócio na obtenção de dados, e regras de negócio norteando o acesso dos 38 dados, bem como fontes de conceito de metadados como ferramentas CASE e novas aplicações em desenvolvimento [13]. 1.2.9. Aspectos Da Implementação Física (Rolap/Molap) Quanto à localização dos dados a serem utilizados na análise, atualmente existem duas abordagens: [6] Um banco de dados multidimensional especializado [6]. Um data warehouse implementado com a tecnologia de banco de dados relacional, mas otimizado para a tarefa de análise: Nesse caso, os dados são modelados utilizando um esquema projetado para balancear desempenho e volume de dados. Normalmente é utilizada uma representação desnormalizada da conhecida por esquema estrela [6]. Sistemas OLAP que implementam a primeira abordagem são chamados de MOLAP (Multidimensional OLAP) e aqueles que implementam a segunda são chamados de ROLAP (Relacional OLAP) [6]. Em um banco de dados MOLAP, os dados são mantidos em arranjos e indexados de maneira a prover um ótimo desempenho no acesso a qualquer elemento. O indexamento, a antecipação da maneira como os dados serão acessados e o alto grau de agregação dos dados fazem com que sistemas MOLAP tenham um excelente desempenho. Além de serem rápidos, outra grande vantagem desses sistemas é o rico e complexo conjunto de funções de análise que oferecem [6]. Existem algumas limitações nos sistemas MOLAP. Bancos de dados multidimensionais são sistemas proprietários que não seguem padrões (linguagem, Application Program Interface, etc.) estabelecidos pela indústria de banco de dados. Isso se torna uma desvantagem para tais sistemas, uma vez que a arquitetura não é aberta. A utilização das estruturas dimensionais adotadas também traz algumas desvantagens. Mudanças do modelo dimensional requerem uma reorganização do 39 banco de dados, e a estrutura de cubos não suporta a criação ad hoc de visões multidimensionais. Além dessa falta de flexibilidade, sistemas MOLAP enfrentam problemas quanto à escalabilidade porque um dos recursos para garantir o excelente desempenho é manter os índices dos arranjos na memória e isso acaba limitando banco de dados multidimensionais a 20 ou 30 gigabytes de dados, tornando-se, dessa maneira, mais apropriados para data marts ou organizações com pequenos data warehouses [6]. Sistemas ROLAP fornecem análise multidimensional de dados armazenados em uma base de dados relacional [6]. A principal vantagem de se adotar uma solução ROLAP reside na utilização de uma tecnologia estabelecida, de arquitetura aberta e padronizada como é a relacional, beneficiando-se da diversidade de plataformas, escalabilidade e paralelismo de hardware [6]. Quanto às limitações, podemos citar o pobre conjunto de funções para análise, a inadequação do esquema estrela para atualização dos dados e as soluções proprietárias para metadados que acaba por anular muitas das vantagens da tecnologia relacional [6]. MOLAP ou ROLAP? Qual escolher? Atualmente existe um grande debate sobre essa questão e, se possível, esse debate deve ser deixado para os fornecedores. Para quem utilizará a tecnologia, o mais importante é entender os negócios da empresa para então decidir pela solução que melhor atende o volume de dados e as necessidades de análise da empresa [6]. Provavelmente esse debate não terá um vencedor. Já se percebe que existe uma convergência dessas duas tecnologias. Fornecedores MOLAP têm adicionado funcionalidade ROLAP nos seus produtos e, igualmente, fornecedores ROLAP têm enriquecido a funcionalidade e desempenho de seus servidores [6]. 40 1.2.10. Performance A duração de tempo desde o momento em que um pedido é emitido até o primeiro resultado recebido [13]. A maioria das consultas dos usuários precisam processar rápida e eficientemente. O administrador do data warehouse é responsável pela performance de carga de dados, criação de índices e manutenção de metadados, itens importantes ao analisar a performance [13]. A maioria dos projetos de data warehouse residem em um sistema gerenciador de banco de dados separado do ambiente OLTP, com um processador dedicado, disco e memória. Esta separação é o melhor ambiente porque, certamente, alivia o processamento e proporciona, ao administrador do data warehouse, liberdade para projetar as bases de dados e suporta uma estrutura de acesso específica para um ambiente de data warehouse onde as consultas são variadas [13]. 1.2.11. Segurança Proteção dos dados em um banco de dados que gerencia os acessos com ou sem autorização. Há níveis diferentes de segurança conforme o perfil do usuário [13]. O problema de proteger as informações do data warehouse é normalmente colocado em segundo ou terceiro plano. Temos que saber quem está acessando as informações, de onde e como se está manuseando. Os bancos de dados têm seus esquemas de segurança, porém eles não conseguem resolver todos os problemas. É necessário procurar uma solução que realmente consiga evitar que os intrusos e curiosos consigam tirar proveito dessas informações. Se essa ferramenta for integrada junto com outras soluções de gerenciamento de recursos, será ainda melhor. Uma estrutura por exemplo, que integre em uma única interface todas as disciplinas de gerenciamento, incluindo segurança, backup, redes, distribuição de software e help-desk será uma solução muito próxima do ideal [20]. 41 2. DESENVOLVIMENTO De acordo com o embasamento teórico do nosso trabalho, iniciamos o desenvolvimento das etapas do nosso roteiro. Essas etapas estão em uma ordem seqüencial, algumas delas podem ser realizadas paralelamente a outras ou a ordem pode ser alterada, de acordo com a necessidade; isso será definido pela equipe que está elaborando o projeto. Sugerimos essa seqüência pois facilita o entendimento do objetivo do projeto e descreve etapas interligadas e fundamentais para o sucesso do mesmo. Abaixo apresentaremos o roteiro em uma forma esquemática para prover, ao leitor, uma ampla visualização das etapas do projeto: 1. Fatores críticos de sucesso. 2. Definição da técnica para desenvolvimento de sistemas a ser utilizada. 3. Visualizar as necessidades do usuário. 4. Nova visão da informação para a tomada de decisões. 5. Análise do negócio a ser modelado. 6. Análise do ambiente legado. 7. Modelagem dimensional dos dados. 8. Aspectos da implementação física. 9. Aspectos da visualização das informações. A seguir, iniciaremos o detalhamento de cada uma das etapas acima seqüencializadas. 2.1. FATORES CRÍTICOS DE SUCESSO Primeiramente, é de extrema importância elencar os principais itens que determinarão o sucesso do projeto. Abaixo apresentamos alguns itens importantes: 1. É fundamental planejar o projeto. 2. É importante ter o orçamento aprovado para desenvolver o projeto de acordo com o plano de investimento da empresa. 42 3. É importante que a empresa esteja disposta a modernizar-se para garantir o crescimento e a competitividade. 4. É importante ter o apoio e o empenho dos usuários responsáveis e suas respectivas gerências através de atitudes participativas e cooperativas. 5. É fundamental ressaltar a importância das informações para a empresa e, em especial, o compartilhamento das mesmas, evitando duplicidade de dados e informações proprietárias. 6. É necessário negociar um acordo com a alta administração referente à proposta de implementação do projeto. 7. É importante primeiro analisar as áreas de atuação mais lucrativas da empresa. 8. É importante analisar a contenção de custos. 9. É imprescindível que as informações sejam precisas, consistentes e rápidas de obter. 10. É importante ter a capacidade de adaptação às necessidades de negócio. 11. É necessário apresentar resultados entre as etapas do desenvolvimento do projeto. Após definirmos os fatores críticos de sucesso do projeto, devemos iniciar a análise de qual técnica de desenvolvimento de sistemas mais se integra à construção de um projeto de data warehouse. 2.2. DEFINIÇÃO DA TÉCNICA DE DESENVOLVIMENTO DE SISTEMAS A SER UTILIZADA É de extrema importância utilizar uma técnica para desenvolvimento de sistemas para auxiliar no projeto do data warehouse. Indicamos a técnica da Engenharia da Informação em virtude de os dados serem o enfoque principal desta técnica e em um data warehouse o objetivo principal é a transformação dos dados em informações. 43 Ao utilizar a técnica da Engenharia da Informação, torna-se mais fácil a forma de visualização dos relacionamentos entre os requisitos básicos que estruturam o negócio objeto de análise. Como produto principal desta técnica temos o modelo de entidades e relacionamentos (MER). Um MER é válido e confiável quando consegue responder às perguntas dos processos que serão por ele atendidos. Portanto é um modelo obrigatório em qualquer desenvolvimento de sistemas até porquê é requisito básico para a implementação física das bases de dados. Esta técnica sugere que devemos identificar os objetivos da organização , sob a óptica de seus executivos, por exemplo: “ a empresa pretende crescer dentro do seu segmento de negócio? Devemos identificar os processos de negócio diretamente relacionados a esses objetivos, com base nas prioridades emergentes da empresa sempre associadas com as prioridades reais dos negócios da empresa, por exemplo: clientes, finanças, vendas, produção, etc. Tendo definida e assimilada a técnica de desenvolvimento de sistemas a ser utilizada no projeto, é importante entender quais são as necessidades do usuário, diferenciando-as entre o ambiente analítico e o operacional. 2.3. VISUALIZAR AS NECESSIDADES DO USUÁRIO O usuário é o fator chave para o sucesso do projeto. Sua participação efetiva durante todo o projeto é o requisito mais importante pois ele é quem domina a área a ser analisada e irá dirimir as dúvidas do analista da informação que implementará o projeto. O usuário necessita de um sistema que forneça informações para que decisões sejam tomadas de acordo com a análise destas informações. Um exemplo de decisão estratégica é: analisar os padrões de consumo em um determinado período para decidir a viabilidade ou não de criação de um novo produto. Há a necessidade 44 de entender a diferença entre os sistemas de processamento operacional e o analítico. Sistemas de processamento operacional são sistemas que suportam as operações do dia a dia da empresa. São sistemas de processamento on-line atualizados ao longo do dia. Exemplos: Sistema de Estoque, Sistema Contábil, Folha de Pagamento, etc. As informações refletem o momento atual [15]. Sistemas de processamento analítico disponibilizam informações usadas para analisar um problema ou uma situação. É feito por meio de comparações ou através da análise de padrões ou tendências. As informações refletem um instante específico no tempo. Exemplos: mostrar como uma marca de um produto está sendo vendida em diferentes estados; mostrar como uma marca específica de um produto está sendo vendido desde que foi introduzido nas lojas; comparar as vendas dessa marca de produto em diferentes localidades, etc. [15]. Tendo definidas e assimiladas quais são as necessidades do usuário, é importante entender a mudança de enfoque em um projeto de data warehouse no que se refere às informações para a tomada de decisões. Durante este processo, é fundamental a participação do usuário e o pleno entendimento dele nesse novo processo de análise da informação. 2.4. NOVA VISÃO DA INFORMAÇÃO PARA A TOMADA DE DECISÕES O que buscamos quando estamos modelando sistemas de informação é o entendimento operacional do negócio que está sendo modelado, sem pensar na aplicação em si, sem pensar na tecnologia envolvida, mas com a visão relacional de dados. Quando vamos executar uma modelagem multidimensional, estamos desenhando soluções de gestão de negócios, buscando entender como os executivos e gestores de uma organização avaliam as informações para adoção de estratégias e avaliação de desempenho. A mudança de enfoque de “entendimento operacional do negócio para entendimento da gestão do negócio” concentra e provoca diferença 45 acentuada na forma de se desenvolver um modelo de dados multidimensional. A análise multidimensional requer um modelo de dados que permita que os dados sejam facilmente visualizados através de diversas perspectivas. Mais adiante apresentaremos como aplicar a modelagem dimensional. Abaixo citamos um exemplo de uma nova visão da informação com a utilização do data warehouse: “O data warehouse é parte fundamental da solução, que analisa o comportamento do cliente, informando em caso de desvio padrão. Durante testes em um banco australiano, por exemplo, foi identificado um depósito que fugia aos padrões do correntista. O banco entrou em contato com o cliente e descobriu que o depósito fora um presente de casamento – o valor da quitação de uma casa. A partir dessa informação, desenvolveu promoções para aquele cliente específico, que conseguiu um empréstimo para acabar de montar sua casa [11]”. O passo seguinte é como analisar a área do negócio a ser modelado. 2.5. ANÁLISE DO NEGÓCIO A SER MODELADO Primeiramente definir os objetivos do projeto que podem ser resumidamente descritos nos dois itens abaixo: 1. Disponibilizar as bases de dados do ambiente operacional (OLTP) para um ambiente analítico (OLAP). 2. Permitir aos usuários a extração dos dados através de análise exploratória no ambiente OLAP. Definir o escopo do projeto, observando: Caracterizar o problema: o dado deve ser representado como informação para que a empresa possa tomar decisões. Definir quais processos são mais críticos para o negócio e que precisam de decisões sobre ele. 46 Assimilar o conhecimento e definição da área de atuação (negócio) do cliente específico e tomada de decisão. É importante representar este conhecimento em um modelo de entidades e relacionamentos pois será muito útil na modelagem dimensional. Definir grupo gestor da informação que irá participar durante todo o processo de desenvolvimento do projeto. O grupo gestor pode ser considerado como os usuários que dominam a área de negócio e que tomam decisões, juntamente com o pessoal de informática. É extremamente importante a definição do escopo do projeto pois é a base do mesmo. No escopo deve ser descrito se a implementação será em um data warehouse (base corporativa que atenderá toda a organização) ou em um ou vários data mart`s (base de informação por linha de negócio que contém um sub-conjunto dos dados corporativos da organização). Recomenda-se iniciar com data mart`s integrando-os a um data warehouse ao longo do tempo. Isto justifica-se pelos seguintes aspectos: O custo é bem inferior a implantar um data warehouse de toda a empresa; O tempo de implementação é reduzido; Mais fácil assimilar a atuação de uma área de negócio específica a entender todo o processo da empresa. Optando-se por implementar em data mart`s, deve-se ter o cuidado de não esquecer a integração entre os data mart`s caso contrário o projeto é inviabilizado. Tendo definida a área de negócio da empresa a ser implementada no projeto, deve-se analisar onde estão as informações que alimentarão o data warehouse / data mart(s). A origem destas informações é comumente chamada de “legado”. 47 2.6. ANÁLISE DO AMBIENTE LEGADO Partindo das necessidades de informação por área de negócio já estarem definidas, nesta análise deve-se observar o seguinte: Analisar o ambiente computacional da empresa como, por exemplo: mainframe IBM, ambiente DOS, ambiente windows, ambiente UNIX, etc. Se as informações necessárias estão armazenadas nos aplicativos operacionais ou, caso contrário, manter os aplicativos operacionais para que obtenham os dados que faltam. Verificar viabilidade deste tipo de manutenção para gerar a informação que falta no sistema analítico. Definir como integrar as várias fontes de informação, se houverem. Um fator importante é como analisar as fontes de informação do ambiente legado como, por exemplo: tipos de bancos de dados (relacionais, em rede, hierárquicos), arquivos seqüenciais, planilhas, etc. Também é importante verificar os modelos de dados, dicionários de dados dos sistemas do ambiente operacional, relatórios gerenciais dos aplicativos, etc. Estas informações auxiliam muito a construção do modelo dimensional. É importante separar em quatro itens observando os questionamentos e atividades em cada um deles segundo Felipe Machado [21]: “ 1. Seleção de Dados: Qual dado interessa? Onde estão os dados? Onde mais existe o dado? Qual o ambiente de sistema gerenciador de banco de dados? Qual dado é válido? Qual período de existência ? Qual o formato do dado? Quantos formatos tem o dado? 2. Extração de Dados: 48 Qual a frequência de carga? Validação da carga. Gerência de dimensões: dimensões que sofrem alterações e é necessário manter o histórico. Validação de dado calculado. Agregação de valores, indicadores. Unicidade de extratores ou seja, se vários data mart´s utilizam a mesma dimensão, o processo de carga deve ser único. Gerência do processo. 3. Limpeza de Dados: Redundância de nomes e endereços. Códigos desconhecidos. Unificação de códigos. Validação de valores pré-calculados. Unificação de nomes. Padronização de conceitos. Tratamento de valores nulos. 4. Transformação de Dados: Validação de valores agregados. Consolidação de regras de negócio. Análise de formatos e tipos de dados “. O grande fator de sucesso de projetos incrementais de data marts/ data warehouse está na transformação, extração, preparação e limpeza dos dados. Definir criteriosamente as necessidades, forma, fontes e as regras de mecanismos de transformação como, por exemplo, a padronização do conteúdo dos dados. Supondo que, no ambiente operacional, a informação sexo do cliente está, em alguns sistemas, como “F/M” e em outros “1/2”. Ao carregar esta informação no data 49 warehouse, deve-se definir um único padrão para conteúdo do mesmo dado originário de fontes distintas. A próxima etapa do nosso roteiro é a construção da modelagem dimensional. 2.7. MODELAGEM DIMENSIONAL DOS DADOS Utilizaremos como técnica principal para a modelagem de dados dimensional o star schema que é a técnica mais indicada para projetos de data warehouse. Muito importante é documentar o modelo de dados em uma ferramenta CASE onde definem-se as tabelas, atributos, domínios, enfim, todas as informações necessárias para garantir a plena documentação do modelo e facilitar a geração dos esquemas físicos no banco de dados, principalmente em bancos de dados relacionais. Considere a seguinte afirmativa: “Nós vendemos produtos em vários mercados e nós medimos nosso desempenho ao longo do tempo”. O modelo de dados mais adequado para representar diversas relações entre grandezas é o modelo dimensional. [15] Para melhor visualizar as dimensões, abaixo representamos um “cubo” propriamente dito com 3 dimensões: TEMPO MERCADO Cada ponto do cubo representa uma combinação de Produto, Mercado e Tempo armazenado. 50 PRODUTO A seguir definiremos, os conceitos básicos que norteiam a modelagem dimensional: 2.7.1. Dimensões Representam as possíveis formas de visualizar os dados. São as entradas para as consultas (tempo, região, cliente, etc). A base para entendimento de qualquer negócio é responder às quatro perguntas fundamentais abaixo: 1. QUANDO? (Período de tempo a que se refere a análise) 2. O QUÊ ? (O principal objeto de análise) 3. ONDE? (Localização física ou geográfica para análise) 4. QUEM? (Um objeto específico e detalhado para análise: opcional) Dimensão mascarada: É aquela dimensão com pouquíssimas ocorrências. Exemplo: Dimensão Tipo Cliente – Ativo ou Inativo. Não se cria uma tabela dimensão com essas ocorrências e sim usar esta dimensão como restrição na cláusula where da consulta. No modelo pode ou não ser representada como uma dimensão ligada à tabela fatos. 2.7.2. Fatos É a tabela central que interliga as dimensões e tem os indicadores de análise ou métricas (quantidade, valores,etc). A tabela fato deverá possuir, no mínimo, as três primeiras dimensões. A pergunta “QUEM?” refere-se a um nível de análise mais detalhado. 2.7.3. Exemplo de uma análise dimensional. “Precisamos analisar a quantidade e valor faturado dos produtos de nossa empresa em nossas lojas para medirmos nosso desempenho ao longo do tempo”. Partindo da premissa acima que reflete a necessidade de informação do usuário, o 51 projetista do data warehouse faz o primeiro esboço da modelagem dos dados de acordo com as 4 perguntas fundamentais: 1. QUANDO: Período de tempo. De acordo com a necessidade de análise do usuário. Pode ser: dia, semana, quinzena, mês, bimestre, trimestre, semestre, ano, etc. 2. O QUÊ : Produtos oferecidos pela empresa. 3. ONDE : Lojas da empresa. 4. QUEM : Opcional. No exemplo acima essa pergunta não se encaixaria pois não foi solicitada como objeto de análise. Porém, caso o usuário necessitasse saber quais os maiores clientes que efetuam compras de determinados produtos, aí sim a informação Cliente se enquadraria na pergunta “quem”. Até agora definimos os objetos de análise, no caso as dimensões de consulta. Obviamente nenhum resultado aparente será apresentado combinando as referidas dimensões pois o que está faltando são os fatos ainda não analisados em nosso modelo. Os fatos ou medidas são o elo de ligação entre os vários tipos de combinações de consulta entre as dimensões. É o que será medido, no caso o faturamento e a quantidade de produtos. Sempre são definidos como números que podem ser medidos, sumarizados e calculados. Em nosso exemplo, os fatos são: quantidade de produtos e valor faturado. Em seguida, projetaremos o modelo de dados utilizando a técnica star schema, que consiste em uma tabela central (fatos), relacionada com as dimensões. A estrutura final parece uma estrela, por isso a denominação da técnica. As tabelas dimensões são tabelas independentes, ou seja, possuem uma única chave primária e atributos que a identificam e que são utilizados para a consulta. São tabelas desnormalizadas. A tabela fatos é uma tabela dependente das dimensões ou seja, sua chave primária é a combinação das chaves primárias das dimensões e os atributos 52 para análise são os fatos ou medidas, no nosso exemplo o valor faturado e a quantidade de produtos. Obs: No exemplo abaixo da técnica star schema, as chaves primárias de cada tabela estão em negrito. DIMENSÃO TEMPO DIMENSÃO PRODUTO Chave_tempo Data_Venda Dia_da_Semana Mes Ano ... Chave_produto FATOS VENDAS Chave_tempo Chave_produto Chave_loja Descricao Marca Categoria ... Valor_Faturado Quantidade_Vendida DIMENSÃO LOJA Chave_loja Nome Endereco Cidade UF ... Observação: As chaves primárias das tabelas podem ser, um número seqüencial ou a própria data da venda, código do produto e código da loja, desde que esteja garantida a unicidade da chave primária em cada tabela dimensão e que o conteúdo histórico esteja garantido, ou seja, se houve alteração posterior em uma determinada venda em um determinado dia, é importante, nesse caso, gerar um número seqüencial na chave de tempo para garantir a posição antes da alteração. Caso a chave fosse a própria data da venda, a alteração seria sobreposta. Um outro exemplo seria o cliente em um pedido. Caso o mesmo cliente possua mais de uma ocorrência no cadastro e cada uma em pedidos diferentes, nesse caso justifica-se gerar um número único para identificar cada ocorrência do cliente. É claro 53 que este tipo de análise depende de como é o processo específico do cliente. Fica como sugestão importante a ser analisada. 2.7.4. Agregações É um fator importante a analisar já que o principal objetivo de uma agregação é prever um aumento de performance no acesso aos dados e reduzir o volume de dados na tabela. As agregações (ou sumarizações) consistem em gerar informações redundantes a partir da informação de menor granularidade [15]. As agregações: Fornecem níveis múltiplos de detalhe do fato [18]. Os resultados das queries (ou seus valores intermediários) são précalculados, o que melhora muito a performance [18]. Podem ser acumuladas através de agrupamentos diferentes. Freqüentemente através de várias dimensões ou combinações de Loja dimensões [18]. Tempo Apresentaremos Data da Transação uma agregação com 2 dimensões Júnior [18]: Agregação das Vendas da Loja Número da Loja Nome da Loja segundo Valsoir Tronchin Cidade Estado País Telefone Número da Loja Data da Transação Número de Clientes Quantidade de Produtos Valor das Vendas Agregam-se vários fatos por Loja por Dia: Número de clientes - Quantos clientes fizeram compras? Quantidade de produtos - Quantas unidades de produtos foram vendidas? Valor da venda - Qual foi o faturamento bruto do dia? 54 2.7.5. Metadados Metadados são dados sobre dados que podem ser entendidos como verdadeiros documentadores dos dados que compõem um data warehouse. Os metadados armazenam diversas informações sobre dados armazenados no data warehouse. Estas informações são armazenadas em um repositório que tem como objetivo principal documentar e administrar os metadados. Os metadados englobam o data warehouse e mantém informações sobre a estrutura dos dados, as fontes de dados, a transformação dos dados, as rotinas de extração de dados, o modelo de dados, relacionamentos e demais informações pertinentes a dar significado ao dado. Recomenda-se a utilização de uma ferramenta CASE para documentação dos processos, modelos de dados, dicionário de dados, domínios de atributos e geração dos esquemas físicos no banco de dados. 2.7.6. Resumo das etapas para a modelagem dimensional. A seguir apresentamos, resumidamente, as etapas importantes a serem seguidas na modelagem dimensional. 1. Obter a necessidade executiva: qual o negócio objeto de gestão. 2. Entender quais são os indicadores de valor do negócio definindo as métricas de controle. 3. Descrever em um modelo de dados conceitual o negócio. 4. Se houverem modelos de relatórios do ambiente operacional: simular. 5. Definir o que descreve o negócio: dimensões. 6. Definir a organização da dimensão tempo: qual a menor unidade de tempo. 7. Trabalhar com o conceito de hierarquia nas dimensões de consulta: Por exemplo uma hierarquia na dimensão tempo: Dia -> Mês -> Trimestre -> Semestre -> Ano 55 8. Definir a tabela fatos. 9. Montar o star schema. A modelagem dimensional é aplicada para visualizarmos os dados referentes às necessidades do usuário para obtenção da informação em um sistema analítico. O modelo de dados dimensional independe de qual banco de dados será implementado (ROLAP ou MOLAP). 2.8. ASPECTOS DA IMPLEMENTAÇÃO FÍSICA Um data warehouse exige grande capacidade de armazenamento e processamento dos dados, pois armazena dados analíticos, destinados às necessidades de tomada de decisão. Estes dados podem ser armazenados tanto em um banco de dados relacional (ROLAP) quanto em um multidimensional (MOLAP). A diferença básica é que em uma estrutura ROLAP devemos criar vários índices atrelados às tabelas fatos e dimensões para um acesso mais rápido e eficiente ao banco de dados enquanto que em um banco multidimensional somente precisamos informar quais são as dimensões e os fatos e o próprio banco encarrega-se de gerar os cubos. A seguir levantaremos alguns aspectos importantes a serem considerados prevendo a implementação física do data warehouse. 2.8.1. Levantamento de volumes de dados Como visto anteriormente, é necessário analisar a necessidade de sumarizar os dados (agregações). Um fator importante é que as agregações reduzem o volume de dados considerando que um sistema para tomada de decisões geralmente não analisa o dado em nível detalhado pois esta informação já se encontra no ambiente operacional (OLTP). O volume de dados a ser carregado e a previsão de crescimento é fator importante ao decidir qual tipo de banco de dados 56 será utilizado (MOLAP ou ROLAP). Um banco MOLAP não suporta eficientemente um volume muito grande de dados. Abaixo está representado um exemplo de gerenciamento de agregações com relação ao volume de dados segundo Valsoir Tronchin Júnior [18]: Evite a explosão exponencial. Por exemplo: explosão do número de linhas da tabela de agregação (n!) em um caso de análise com as seguintes informações: 100 lojas, 25 categorias de produtos, 50 tipos de clientes e dados de 1 ano. Agregação Vendas Vendas Vendas Vendas mensais da loja diárias da loja diárias da loja por categoria diárias da loja por categoria e tipo de cliente Nº. de Linhas da Tabela 1.200 36.500 912.500 45.625.000 Ao analisar o volume de dados na tabela fatos, há de considerar o crescimento no número de linhas na tabela, número de dimensões associadas e qual o nível de detalhe desejado. Muitas vezes, é importante analisar a necessidade de separar a tabela fatos em outras tabelas menores ou em agregações em nível mais alto. Abaixo exemplificaremos o volume de dados na tabela fatos considerando somente o valor das vendas diárias por loja e produto: Armazenar, no mínimo, os últimos 3 anos (previsão de 1.095 dias). Número de Lojas: 100 Número de Produtos: 400 Fatos = 1.095 x 100 x 400 => 43.800.000 linhas na tabela fatos. 2.8.2. Periodicidade de Carga As rotinas de extração dos dados do ambiente operacional devem ser executadas de acordo com um esquema de processamento pré-definido. A 57 periodicidade de execução pode ser diária (inviável quando a extração necessita de muitas fontes externas), semanal, quinzenal, mensal, etc. Um fator importante a ser analisado com relação à periodicidade de carga é a forte dependência com a área de negócio do usuário e da real necessidade de análise da informação pois a informação urgente de hoje pode estar obsoleta amanhã. O volume de processamento é fator primordial para a criação de um esquema de carga. Como o data warehouse possui carga incremental, recomendase que criem-se os movimentos de dados originários do ambiente operacional e carga no data warehouse fora do horário comercial de trabalho. 2.8.3. Tempo de Armazenagem dos Dados De acordo com o volume de dados carregados de forma incremental no data warehouse, é importante estimar por quanto tempo estes dados deverão estar disponíveis na base de dados. O principal objetivo do data warehouse é manter o histórico dos dados por um período de tempo necessário para a análise. Tudo depende do tipo de negócio do cliente. Geralmente a carga inicial do data warehouse corresponde a um volume histórico de 3 anos (no mínimo) para dar um respaldo necessário ao processo analítico. De acordo com o crescimento do banco de dados, é necessário gerenciar o expurgo das informações não mais utilizadas em um determinado período de tempo. Caso o usuário quiser manter as informações por um período de tempo longo, deve-se deixar claro que o custo de manutenção de hardware e software aumentará. 2.8.4. Controle de Backup’s O administrador do data warehouse deve controlar como o backup bases de dados será efetuado (periodicidade, volume, dispositivos das de armazenamento, etc.). É importante verificar se há necessidade de copiar todo o 58 banco de dados ( visto que, em projetos de data warehouse muito grandes, o custo desta atividade é alto e torna-se inviável) ou apenas um determinado período de tempo. É claro que o backup é importante e deve ser analisado. Vale a pena verificar se as informações originárias dos sistemas transacionais para carga do data warehouse são facilmente recuperáveis pelas rotinas de extração, aproveitando o backup das bases operacionais (bancos de dados, arquivos sequenciais, etc) em caso de problemas. Neste caso pode-se utilizar como backup os próprios arquivos oriundos do sistema transacional com os movimentos (diários, semanais, mensais, etc) carregados no data warehouse. Tudo depende de como gerenciar este processo e analisar por quanto tempo o data warehouse pode ficar indisponível em caso de recuperação do banco de dados e estimar quanto tempo levará a recarga a partir dos backup’s operacionais. Este gerenciamento envolve os administradores do data warehouse diretamente. 2.8.5. Análise de Performance Indica-se a técnica star schema pelos principais motivos na implementação física em um servidor ROLAP: As tabelas fato contém a maioria das linhas de dados. As tabelas dimensão tendem a ter um número menor de linhas. Os joins (junções, relacionamentos) em um star schema tipicamente envolvem uma tabela fato grande e uma ou mais tabelas dimensão pequenas, o que torna a operação de consulta mais rápida. Sempre consultar as tabelas fatos pelas entradas que são as dimensões. Esquema altamente desnormalizado para melhorar performance. A desnormalização provoca redundância e duplicação de dados, o que privilegia a performance em detrimento do consumo de espaço. 59 Uma análise importante refere-se aos índices a serem criados nas tabelas fatos e dimensões quando da implementação em uma estrutura ROLAP. Os índices são extremamente importantes pois permitem o acesso às informações de uma maneira rápida visto que o processo de tomada de decisão pode envolver consultas complexas que necessitem acessar um grande número de registros. Geralmente criam-se índices das chaves primárias nas tabelas dimensão e fatos mais outros atributos das dimensões necessários às consultas e também a combinação de dimensões na tabela fatos. Ao criarmos índices em bancos de dados relacionais devemos considerar a granularidade das informações, seletividade e outros fatores pertinentes à estrutura do banco pois os bancos relacionais analisam seu próprio plano de acesso antes de decidir acessar a estrutura de índices ou se é mais eficiente dar um scan table (pesquisa em toda a tabela). Geralmente definemse índices clustered para cada chave primária. Este tipo de suporte é fornecido pelo administrador do banco de dados (DBA). Ao utilizarmos um servidor MOLAP (com um banco multidimensional), não é necessário criar índices visto que a própria estrutura deste tipo de banco de dados cria os cubos com todas as combinações possíveis das dimensões. Devemos informar ao banco de dados quais são as dimensões e quais são os fatos. Esta tecnologia multidimensional têm alta performance porém ocupa um alto espaço de armazenamento dependendo do volume de dados da tabela fatos. A tendência dos bancos de dados é reunir funcionalidades ROLAP e MOLAP. 2.8.6. Segurança Além de utilizar o esquema de segurança de logins do próprio banco de dados (chaves autorizadas e o nível de acesso de cada uma), é importante que o administrador do data warehouse tenha um controle do perfil de usuários com autorização de acesso. Muitas ferramentas OLAP possuem um controle de 60 segurança próprios. Outra alternativa é o desenvolvimento de um aplicativo específico de controle de usuários autorizados antes de executarem uma consulta ao banco de dados onde reside o data warehouse/ data mart. Após considerarmos os aspectos de implementação física mais importantes do projeto, apresentaremos como as informações podem ser visualizadas pelo usuário e como são as consultas. 2.9. ASPECTOS DA VISUALIZAÇÃO DAS INFORMAÇÕES As ferramentas OLAP de visualização dos dados transformam números enfadonhos em excitantes apresentações visuais. Provavelmente, as ferramentas de visualização mais populares caem sob o título de sistemas de informação geográficos. Estes transformam dados sobre lojas, indivíduos ou qualquer outra coisa em mapas dinâmicos e de fácil compreensão [26]. A seguir exemplificaremos várias formas de fazer uma consulta ao banco de dados através de queries simples, stored procedures e o exemplo de como uma ferramenta OLAP monta o SQL para acesso ao banco de dados. 2.9.1. Queries Simples São comandos SQL simples desenvolvidos pelo usuário fazendo o acesso diretamente ao SGBDR e retornando as linhas acessadas em uma forma tabular. Este usuário deve possuir um perfil técnico avançado na criação de consultas SQL. Abaixo exemplificamos um comando SQL simples para acesso às informações de um cliente específico. select NomeCliente, Endereco, Telefone, Email from CADASTRO_CLIENTES where CodigoCliente = “XYZ” Obs: Colunas com as informações Tabela do banco de dados Critério de seleção : NomeCliente, Endereco, Telefone, Email. : CADASTRO_CLIENTES : CodigoCliente = XYZ 61 2.9.2. Stored Procedures (sp) Apresentaremos a mesma consulta acima efetuada com comandos SQL simples, porém organizadas em uma stored procedure que fica armazenada no banco de dados relacional e o acesso é mais rápido. Recomenda-se desenvolver stored procedures quando as consultas são pré-definidas pelo usuário. No exemplo abaixo transferimos o parâmetro de entrada (código do cliente) para a rotina e ele retorna as colunas como parâmetros de saída. Obviamente várias consistências devem ser feitas mas o exemplo é somente para entender a estrutura de uma stored procedure. O nome da função será SP_ObterInformacaoCliente. use <banco_de_dados onde a sp está armazenada> go if exists (select name from sysobjects where name = "SP_ObterInformacaoCliente") drop procedure SP_ObterInformacaoCliente go create procedure SP_ObterInformacaoCliente @codigo_cliente char(10), @nome_cliente char(35) output, @endereco varchar(50) output, @telefone char(10) output, @email char(30) output, @msg_erro varchar(100) output as declare @qtdlinhas int, @erro int select @nome_cliente = NomeAtivEconomica, @endereco = Endereco, @telefone = Telefone, @email = Email from CADASTRO_CLIENTES where CodCliente = @codigo_cliente return 0 go 2.9.3. Ferramentas OLAP Abaixo exemplificamos como uma consulta é feita pelo usuário através da ferramenta OLAP Business Objects e o comando SQL gerado automaticamente pela ferramenta. O banco de dados a ser acessado, no exemplo, é um ROLAP. O 62 projetista do banco de dados utilizou a técnica star schema como demonstrado na ferra 63 menta para que o usuário possa visualizar as dimensões e os fatos conforme apresentaremos na figura abaixo. A referida consulta refere-se a uma base de dados da Secretaria Estadual da Fazenda do Estado do Paraná onde o usuário pretende visualizar as informações de quantidade e saldo por mês e atividade econômica no ano de 1999 no município de Curitiba (101). O usuário solicita as informações das dimensões e dos fatos através de comandos drag and drop (arraste e solte). 64 Dimensões: Delegacia Regional, Município, Atividade Econômica, Tempo Fatos: GIA Gerencial Comando SQL gerado automaticamente pela ferramenta na consulta: SELECT TB_Tempo.MesRefGIA, TB_AtividadeEconomica.CodAtivEconomica, TB_AtividadeEconomica.NomeAtivEconomica, sum(TB_F_GIA_Gerencial.QuantidadeGIA), sum(TB_F_GIA_Gerencial.C11_VlrContabEntrEstado) FROM TB_Tempo, TB_AtividadeEconomica, TB_F_GIA_Gerencial, TB_Municipio WHERE (TB_F_GIA_Gerencial.CodAtivEconomica = TB_AtividadeEconomica.CodAtivEconomica ) AND ( TB_F_GIA_Gerencial.CodMunicipio=TB_Municipio.CodMunicipio ) AND ( TB_F_GIA_Gerencial.AnoBase=TB_Tempo.AnoRefGIA ) AND ( TB_Tempo.AnoRefGIA = 1999 AND TB_Municipio.CodMunicipio = 101 ) GROUP BY TB_Tempo.MesRefGIA, TB_AtividadeEconomica.CodAtivEconomica, TB_AtividadeEconomica.NomeAtivEconomica 65 Abaixo demonstraremos uma hierarquia implementada em um banco de dados multidimensional (Arbor Essbase – MOLAP) segundo Felipe Machado [21]: 2.9.4. Aplicativos de Consulta Muitas vezes o usuário solicita queries pré-definidas que, podem ser armazenadas no banco de dados na forma de stored procedures ou gravadas de acordo com o tipo de ferramenta OLAP. Por exemplo, na ferramenta Business Objects, as queries dos usuários podem ser salvas em arquivos. Quando da necessidade de consulta através da mesma query, o usuário abre o arquivo e faz um refresh no banco de dados, retornando as informações atualizadas. 66 A viabilidade de construir um aplicativo de consulta é diretamente relacionada às necessidades de informação do alto escalão da empresa (presidência, diretoria, gerências). Obviamente estes funcionários não irão desenvolver queries e sim desejam somente clicar em um ícone para obter a informação. Nestes casos, um aplicativo de consulta que integra as queries prédefinidas deve ser implementado prevendo a integração de novas consultas que são executadas freqüentemente. Consultas esporádicas não se justificam implementar em um aplicativo pois o usuário pode desenvolvê-las de acordo com sua necessidade. Depende da análise do usuário se quer ou não implementar determinada consulta em um aplicativo. 2.10. ESTUDOS DE CASOS REAIS (NECESSIDADES DO NEGÓCIO E MODELAGEM DIMENSIONAL). Nos estudos de caso que serão apresentados a seguir, demonstraremos as necessidades de análise da informação sobre o negócio do cliente e a modelagem dimensional utilizando a técnica star schema. Estas duas etapas do roteiro podem ser consideradas como as mais críticas e complexas para o projeto, motivo pelo qual estamos exemplificando o roteiro nestas etapas específicas. Nosso escopo, neste exemplo de estudos de caso, parte do princípio de que a fase de modelo dimensional dos dados é a que garante o sucesso do projeto pois o modelo deve responder às necessidades do negócio. As demais fases também são importantes porém são específicas de acordo com os objetivos tecnológicos de cada empresa. Os estudos de caso referem-se a dois tipos de organizações: A SEFA/PR e o CONPREVI . A SEFA/PR possui vários sistemas de informação desenvolvidos e mantidos pela CELEPAR. Muitos usuários necessitam de informações gerenciais referentes aos parcelamentos de ICMS (Sistema TAP) e Arrecadação de ICMS. 67 O CONPREVI é uma instituição que serve aos tabeliâes do Estado do Paraná para assegurar alguns benefícios como aposentadoria e pensões, através de um sistema de recolhimentos mensais sobre o movimento de cada cartório. O programa que gerencia a CONPREVI foi criado e é mantido pela Datatítulo Sistemas Informatizados, com sede em Curitiba e especializada em ofícios de protesto de títulos em todo o Paraná. As necessidades de informação gerencial sobre estes sistemas serão modeladas nos estudos de casos abaixo: 2.10.1. TAP – Termo de Acordo de Parcelamento Necessidades do usuário: “Precisamos analisar e acompanhar a evolução da concessão de parcelamentos de ICMS dos últimos 5 anos sob vários aspectos: tipo, modalidade e situação do parcelamento, município, agência de rendas e delegacia regional a que pertencem, bem como a atividade econômica dos contribuintes que efetuam parcelamento. A análise, sobre os referidos aspectos acima mencionados, considerará os valores parcelados, quantidade de parcelas concedidas, pendentes em dia, pendentes em atraso, pagas em dia e pagas com atraso em um período de tempo que refere-se a data de assinatura do parcelamento e a data da situação do parcelamento para os casos de parcelamentos já baixados.” Observação: Neste estudo de caso, a tabela fatos será única e conterá o item mais baixo de detalhe que é a informação referente ao próprio parcelamento e não agregações em outras tabelas fatos visto que o usuário têm necessidade de saber quais são os parcelamentos específicos. Esta definição levou em conta um volume de parcelamentos registrados no ambiente operacional nos últimos 5 anos, suficiente para ser armazenado detalhadamente no ambiente OLAP. Este fator em migrar ou não o dado detalhado deve sempre levar em conta o volume de dados e 68 crescimento dos mesmos ou então separar em outras tabelas fatos com agregações pertinentes às consultas mais efetuadas. DIMENSÃO ATIVIDADE ECONÔMICA DIMENSÃO TEMPO Código_Ativ_Economica Data_Assinatura Data_Situação Mês_Situação Ano_Assinatura Ano_Situação DIMENSÃO DELEGACIA REGIONAL Código_Delegacia Nome_Delegacia Endereco Cep Fone Município DIMENSÃO MUNICÍPIO Código_Municipio Nome_Municipio Ano_Instalacao Associação Microregião DIMENSÃO CONTRIBUINTE Código_Contribuinte Nome_Contribuinte CPF CNPJ CadICMS Endereco Município Início_Atividade Fim_Atividade ... Descrição FATOS_TAP DIMENSÃO REGIME PAGAMENTO Data_Assinatura Data_Situação Código_Delegacia Código_Município Código_Ag_Rendas Código_Ativ_Economica Código_Regime_Pgto Código_Modalidade Código_Situacao_TAP Código_Tipo_TAP Código_Contribuinte Código_Regime_Pgto DE PAGAMENTO Número_TAP Qtd_Parc_Concedidas Qtd_Parc_Pendentes Qtd_Parc_Pagas Qtd_Parc_Vencidas Qtd_Parc_Pagas_Atraso Valor_Imposto_Parcelado Valor_CM_Imposto_Parcelado Valor_Multa_Parcelado Valor_CM_Multa_Parcelado Valor_Juro_Vencido_Parcelado Valor_Juro_Vincendo_Parcelado Valor_Imposto_FCA_Parcelado Valor_Multa_FCA_Parcelado Valor_Atraso_Parc_Pendente Saldo_Residual_Imposto Saldo_Residual_Multa Saldo_Residual_Juros Valor_Imposto_Pago Valor_Multa_Pago Valor_Juro_Pago Descrição Descrição DIMENSÃO SITUAÇÃO PARCELAMENTO Código_Situacao_TAP DIMENSÃO TIPO PARCELAMENTO Código_Tipo_TAP Descrição DIMENSÃO MODALIDADE Código_Modalidade Descrição DIMENSÃO AGÊNCIA RENDAS Código_Ag_Rendas Nome Endereco Fone Município 69 2.10.2. Arrecadação Estadual de ICMS do Paraná Necessidades do usuário: “Precisamos analisar e acompanhar a evolução da arrecadação de ICMS dos últimos 3 anos por data de pagamento por várias regiões do Estado considerando os aspectos de tipos de receita e produtos, bem como a atividade econômica e regime de pagamento dos contribuintes que recolhem ao Estado. A análise, sobre os referidos aspectos acima mencionados, considerará a quantidade de recolhimentos e os valores de imposto, multa, acréscimo, juros e total recolhido.” DIMENSÃO TEMPO DIMENSÃO REGIME DE PAGAMENTO Data_Pagamento Dia Mês Trimestre Semestre Ano DIMENSÃO MUNICÍPIO Código_Municipio Nome_Municipio Ano_Instalacao Associação Microregião DIMENSÃO CONTRIBUINTE Código_Contribuinte Nome_Contribuinte CPF CNPJ CadICMS Endereco Município Início_Atividade Fim_Atividade ... Código_Regime_Pgto Descrição FATOS ARRECADAÇÃO Data_Pagamento Código_Receita Código_Ativ_Econômica Código_Regime_Pgto Código_Produto Código_Delegacia Código_Município Código_Contribuinte Qtd_Recolhimentos Valor_Receita Valor_Multa Valor_Acrescimo Valor_Juros Valor_Total_Recolhido DIMENSÃO DELEGACIA REGIONAL Código_Delegacia Nome_Delegacia Endereco Cep Fone Município DIMENSÃO RECEITA Código_Receita Descrição DIMENSÃO PRODUTO Código_Produto Descrição DIMENSÃO ATIVIDADE ECONÔMICA Código_Ativ_Econômica Descrição 70 Analisando o perfil de consultas do usuário de acordo com suas necessidades, percebeu-se que mais de 60% das consultas referem-se ao movimento mensal de arrecadação, não sendo uma necessidade imediata a análise por contribuintes nestas consultas, portanto decidiu-se por criar outra tabela fatos da arrecadação com os valores agregados mensais. Ao construir uma agregação ganha-se em performance pois os dados já estáo sumarizados mas perde-se em espaço no banco de dados visto que as informações sumarizadas poderiam ser obtidas na tabela fatos em nível de detalhe. Cria-se nesse caso, um tipo de “redundância” de dados. DIMENSÃO TEMPO DIMENSÃO REGIME DE PAGAMENTO AnoMês_Pagamento Mês Trimestre Semestre Ano DIMENSÃO MUNICÍPIO Código_Municipio Nome_Municipio Ano_Instalacao Associação Microregião DIMENSÃO ATIVIDADE ECONÔMICA Código_Ativ_Econômica Descrição Código_Regime_Pgto FATOS ARRECADAÇÃO MENSAL AnoMês_Pagamento Código_Receita Código_Ativ_Econômica Código_Regime_Pgto Código_Produto Código_Delegacia Código_Município Qtd_Recolhimentos Valor_Receita Valor_Multa Valor_Acrescimo Valor_Juros Valor_Total_Recolhido Descrição DIMENSÃO DELEGACIA REGIONAL Código_Delegacia Nome_Delegacia Endereco Cep Fone Município DIMENSÃO RECEITA Código_Receita Descrição DIMENSÃO PRODUTO Código_Produto Descrição 71 2.10.3. CONPREVI O CONPREVI tem como negócio o recolhimento de contribuições mensais de cartórios no estado do Paraná. Essas contribuições visam a manutenção de um sistema previdenciário para os cartorários garantindo aposentadoria para os mesmos e pensões para suas respectivas famílias. O recolhimento é feito via declaração da movimentação mensal de cada cartório e correspondente percentual. Como as contribuições são preenchidas pelos próprios cartorários a detecção de sonegação fica difícil. A única forma atual de se verificar uma irregularidade é através de fiscalização no próprio cartório, uma prática além de demorada, dispendiosa financeiramente. Com a implantação da técnica de data warehouse será possível, pelo próprio usuário do sistema, ou até, pelo corpo decisor da instituição CONPREVI detectar os sonegadores e decidir sobre parcelamentos, por exemplo, com um custo muito menor e com ganho em eficácia. O uso do data warehouse através de comparativos entre cartórios de mesma instãncia ou do mesmo cartório no decorrer do tempo, por exemplo, podem disponibilizar a CONPREVI uma ferramenta poderosa para análise de seus contribuintes e agilidade na tomada de decisões. Os dados estão em um micro usado como servidor, a base de dados é Access e periodicidade de carga das informações é mensal. Necessidades do Usuário: “Precisamos analisar e acompanhar a arrecadação de nossa carteira de previdência por parte dos servidores. Os valores a serem analizados dizem respeito ao valor destinado ao CONPREVI e Associações. O comparativo vai ser em relação a épocas distintas, pela data de pagamento, respeitando a sazonalidade para detectar possíveis sonegações. As consultas devem ser tanto evidenciando as serventias, como os titulares das serventias. Deve-se, tambem, comparar-se cartórios de mesmo tipo e de mesma entrância em todas as cidades do Paraná.” 72 DIMENSÃO TEMPO Dt_Pagamento Mês Trimestre Semestre Ano DIMENSÃO TITULAR Cod_Titular Nome Tel(Ramal) Endereço Cidade CEP Estado CPF DIMENSÃO TIPO DE CARTÓRIO Código_Tipo_Cartorio Classificação FATOS RECOLHIMENTO MENSAL Dt_Pagamento Cod_Titular Cod_Serventia Cod_Cidade Cod_Tipo_Cartorio Valor_Certidao Valor_CPC Valor_Total_Assoc Valor_Multa Valor_Juros Valor_Correcao DIMENSÃO SERVENTIA Código_Serventia Nome_Serventia Endereco Cep Tel(Ramal) Cidade Entrancia DIMENSÃO CIDADE Cod_Cidade Cidade Estado 73 CONCLUSÃO Este trabalho forneceu-nos fundamentação teórica e embasamento suficientes para projetar um data warehouse. O roteiro mostrou que é possível, de forma esquemática, elaborar um data warehouse sem maiores problemas. Com ele, muitas das principais dúvidas que surgem, principalmente, àqueles profissionais que estão tendo o seu primeiro contato com a ferramenta, são apontadas e sanadas no decorrer do desenvolvimento do projeto de data warehouse. Outra grande virtude do roteiro é unir, de forma mais harmoniosa, através de correlação, o que foi exposto na teoria com os casos práticos apresentados. Através da exposição de uma seqüência de etapas, tornou-se possível uma visualização mais organizada e sistemática da construção de um data warehouse. Acreditamos que o objetivo proposto foi amplamente atingido dando condições a um profissional da área de informática, sem nenhum conhecimento em data warehouse, a se familiarizar com os novos termos, planejar e desenvolver um projeto desse nível. De acordo com a estrutura lógica da seqüência apresentada envolvendo: 1 º Fundamentação Teórica, 2º Desenvolvimento do Roteiro e 3º Casos práticos com validação de algumas partes do roteiro de acordo com a necessidade de cada situação, acreditamos termos apresentado um texto de fácil leitura, com raciocínio lógico e bem estruturado. Considerações: Data warehouse não é modismo, tornou-se uma necessidade para a organização. Data warehouse não resolve os problemas da organização se não houver o fator humano para analisar os resultados e tomar as decisões. 74 É fundamental o envolvimento do usuário em todo o processo (usuário que atua na análise de informações para a tomada de decisão). São poucos os usuários com este perfil. Evitar trabalhar em nível operacional (detalhe) e sim em nível estratégico (dados consolidados/ agregados) a não ser que seja muito necessária a análise detalhada. A técnica mais adequada para a modelagem dimensional é a star schema. Evitar utilizar a técnica snow flake visto que é uma técnica onde as dimensões são normalizadas, degradando a performance de acesso à tabela fatos. Utilizar a modelagem dimensional. A utilização do MER somente para visualizar a área de negócio para então analisar como obter as informações fontes para o data warehouse. O analista de Tecnologia da Informação deve possuir o conhecimento da tecnologia utilizada no projeto principalmente em: SGBD, Modelagem de Dados Tradicional e Multidimensional. A estação cliente deve ter alto desempenho. As consultas demandam um alto consumo de recursos (tanto do servidor quanto da rede de comunicação de dados). A avaliação da necessidade de implantar tal sistema deve levar em conta: A necessidade da empresa de responder continuamente às mudanças de mercado. A existência ou não de uma base consistente de informações oriundas dos bancos de dados operacionais. A inviabilidade de obter as informações de suporte a decisão diretamente dos bancos de dados operacionais da empresa. À medida que a infra-estrutura de informações das empresas amadurece, aumenta a necessidade de qualidade dos dados e de sistemas eficientes e eficazes de suporte a decisão. Esse tipo de sistema e o uso corporativo 75 que se faz dele alavancam o conhecimento de negócio ou sua inteligência, resultando em vantagem competitiva. No cenário atual onde os administradores das empresas precisam tomar decisões rápidas e certeiras em resposta aos diversos eventos que ocorrem a todo instante em suas empresas, faz-se necessário construir todo um mecanismo de suporte rápido e eficiente aos processos decisórios. O data warehouse é uma ferramenta apropriada para este tipo se situação. Se bem projetado, permite aos gerentes obter informações rápidas e confiáveis que lhe servirão de suporte para a solução de seus problemas e para atingir os objetivos propostos para os negócios. 76 ANEXOS ALGUNS FORNECEDORES DE FERRAMENTAS OLAP ATUAIS Existem, no mercado, vários fornecedores de produtos OLAP cada um dentro de uma categoria, isto é, classificado como um tipo de produto MOLAP, ROLAP, HOLAP e Cliente/Servidor. A seguir relacionamos alguns fornecedores de produtos OLAP: [17] Fornecedores Produto Tipo de Produto Andyne Computing Ltd. PaBLO HOLAP Client Applix TM1 Software Applix TM/1 MDDB Server Arbor Software Corp. Essbase MDDB Client Brio Technology Inc. Brio Query MDDB Client Business Objects Inc. Business Objects ROLAP Client Cognos Corporation PowerPlay HOLAP Client Comshare Inc. Decision MDDB Client Dimension Insight Cross Target MDDB Server Gentia Software GQL MDDB Client/Server Hyperion Software Corp. Pillar MDDB Client/Server IBM DB2 OLAP Server HOLAP Server Information Advantage Inc. Decision Suite ROLAP Server Informix MetaCube ROLAP Server Microsoft Microsoft OLAP Server HOLAP Server MicroStrategy Inc. DSS Server / DSS Agent ROLAP Client/Server Oracle Express MDDB Server Pilot Software Pilot Analysis Server MDDB Server Platinum Technology InfoBeacon ROLAP Server SAS Institute Inc. SAS MDDB Client/Server Seagate Software IMG Holos HOLAP Client/Server Speedware Corp. Inc. Media/MR MDDB Client/server Sybase PowerDimensions ROLAP Server WhiteLight Systems Inc. WhiteLight ROLAP Server 77 SUGESTÃO DE UMA TABELA DIMENSÃO TEMPO DETALHADA [21]. Data da Transação Indicador de último dia do mês Ano Quartil (Trimestre) Mês Semana Dia da Semana Dia do Mês Dia do Quartil Dia do Ano Indicador de Feriado Semana do Mês Semana do Quartil Semana do Ano Indicador de última semana do mês Indicador de última semana do quartil Mês do Quartil Ano Fiscal Quartil Fiscal Mês Fiscal Semana Fiscal Dia da semana fiscal Dia do mês fiscal Dia do quartil fiscal Dia do ano fiscal Indicador de último dia do ano fiscal Semana do mês fiscal Semana do quartil fiscal Semana do ano fiscal Indicador de última semana do mês fiscal Indicador de última semana do quartil fiscal Indicador de última semana do ano fiscal Mês do quartil fiscal 78 FIGURAS Vendemos 1 Milhão de Reais ! Quando ? O quê ? O Q uê ? Onde ? Tomate Região Região Região Laranja Arroz Chocolate 2 3 4 1996 1997 1998 1999 Tempo [21] Figura 1 – Exemplo de um Cubo Dimensional [21] Figura 2 – Exemplo de uma Estrutura Star Schema 79 [21] Figura 3 – Exemplo de uma Estrutura Snow-Flake [21] Figura 4 – Exemplo de um Modelo de Dados (MER) 80 REFERÊNCIAS BIBLIOGRÁFICAS [1] ASSUNÇÃ0, Luis. Data Warehousing. Disponível na Internet. http:// www.luis.assuncao.eti.br/luisdwh.htm#item1. 15/12/1999. [2] COMPUTERWORLD. Data warehouse: depósito de boas oportunidades. Rio de Janeiro. n.173, p. 17, julho,1996. [3] DBMS – TOOLS & STRATEGIES FOR I.S. PROFESSIONAIS. Um Manifesto do Dimensional Modeling. Rio de Janieiro. Ed. Mantelmedia, n. 7, p. 44-50, 7 novembro,1997. [4] EXECPLAN. Apresentação. Disponível na Internet. http: // www.execplan.com.br/apresent/apresent.htm. 28/12/1999. [5] Fast Track to Sybase – Student Guide. 1992, Sybase Inc. [6] FIGUEIREDO, Adriana Maria C.M.. MOLAP x ROLAP: Embate de Tecnologias para Data warehouse. Developer’s Magazine. Rio de Janeiro: Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.24. [7] FILHO, Trayahú R.Moreira. On-Line Analytical Processing Server (Servidor OLAP). Developer’s Magazine. Rio de Janeiro: Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.28-29. [8] FORMA INFORMÁTICA LTDA. Técnicas de Modelagem de Dados. São Paulo, 26 maio, 1994. [9] GUTIERREZ, Marco Antônio. Developer’s Magazine. Rio de Janeiro: Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.7. [10] http://osiris.sunderland.ac.uk/sst/case2/welcome.html em 20/01/2000 [11] INFORMATION WEEK. O Poder do Data warehouse. São Paulo.Ed.Itmidia n.12, p. 12, 20 outubro,1999. [12] INMON, W. H. Building the Data warehouse. New York : Wiley Computer Publishing, 1996. [13] INMON, W. H., WELCH, J. D. e GLASSEY,Katherine L. Managing the Data warehouse. New York : Wiley Computer Publishing, 1997. [14] INMON, Willian H. e HACKATHORN, R. D. Using the Data warehouse. New York : J. Wiley, 1994. [15] JAMHOUR, Edgar. Sistemas de Banco de Dados. Curitiba,Agosto de 1999. Disciplina do Curso de Especialização em Gestão da Tecnologia da Informação e Comunicação da Faculdade Católica de Administração e Economia. [16] JORNAL BATE BYTE – CELEPAR ( Companhia de Informática do Paraná). Administração de Metadados. Curitiba, edição nº 76 em junho de 1998. 81 [17] JORNAL BATE BYTE – CELEPAR ( Companhia de Informática do Paraná). Tecnologia OLAP. Curitiba, edição nº 87 em junho de 1999. [18] JÚNIOR TRONCHIN, Valsoir. Apresentação Sybase : Data Warehousing : Aspectos Estratégicos e de Implementação. Curitiba,1997. [19] KIMBALL, Ralph. Data warehouse Toolkit. 1.ed. São Paulo: Makron Books, 1998. 388p. [20] KONDRATIUK, Edgardo Ruben. Data warehouse: Detalhes que Fazem a Diferença. Developer’s Magazine. Rio de Janeiro: Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.22. [21] MACHADO, Felipe. Modelagem de Dados Multidimensional. DBA Engenharia de Sistemas. Rio de Janeiro, 1999. [22] MANNI, Luiz Carlos & DORSA, Luiz Fernando A. Data warehouse: Gerenciando a Qualidade dos Dados. Developer’s Magazine. Rio de Janeiro: Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.20. [23] MANZONI JR, Ralphe. A inteligência é a Alma do Negócio. ComputerWorld Business Inteligence, Rio de Janeiro, n. 285, p.2, 8 março, 1999. [24] NIMER, Fernando.Analisando o Retorno Sobre o Investimento de Data warehouse. Developer’s Magazine. Rio de Janeiro : Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.16-17. [25] OLIVEIRA LEITE., Argemiro A. Informação à Prova de Equívocos. ComputerWorld Business Inteligence, Rio de Janeiro, n. 285, p.7, 8 março, 1999. [26] PALMA, Sérgio. Os Componentes Funcionais de um Data warehouse. Developer’s Magazine. Rio de Janeiro:Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.18-19. [27] PORTFÓLIO DE TECNOLOGIAS CELEPAR ( Companhia de Informática do Paraná). SQL, Índices, Modelo de Dados, Banco de Dados. Curitiba,30 de junho de 1998. [28] Sybase System 10: Introduction to SQL- Student Guide.1993, Sybase Inc. [29] TAURION, Cezar. Data warehouse : Vale a Pena Gastar Milhões Investindo em Um?. Developer’s Magazine. Rio de Janeiro: Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.10-11. [30] TAURION, Cezar. Data warehouse Será Útil Para a Sua Organização ? Developer’s Magazine. Rio de Janeiro : Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.26-27. [31] VASCONCELLOS, João Marcos. Apresentação Informix: Do Data Mart ao Data warehouse, O Caminho para o Acesso às Informações Gerenciais Estratégicas, Curitiba,1997. [32] WANG, Charles B., Techno Vision II, ed. Makron Books, 1998. [33] ZAMBON, Luís Pedro. Desenvolvimento de Sistemasde Informação. Curitiba,Setembro de 1999.Disciplina do Curso de Especialização em Gestão 82 da Tecnologia da Informação e Comunicação da Faculdade Católica de Administração e Economia.
