• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
38664419 artigo-data warehouse
 

38664419 artigo-data warehouse

on

  • 2,390 views

 

Statistics

Views

Total Views
2,390
Views on SlideShare
2,390
Embed Views
0

Actions

Likes
0
Downloads
60
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    38664419 artigo-data warehouse 38664419 artigo-data warehouse Document Transcript

    • Luis Fernando Panegassi R.A. 0305057DATA WAREHOUSE Jaguariúna 2006
    • Luis Fernando Panegassi R.A. 0305057DATA WAREHOUSE Monografia apresentada à disciplina Trabalho de Conclusão de Curso, do Curso de Ciência da Computação da Faculdade de Jaguariúna, sob a orientação do Prof. Odair Jacinto da Silva, como exigência parcial para conclusão do curso de graduação. Jaguariúna 2006
    • Panegassi, Luis Fernando. Data Warehouse. Monografia defendida e aprovada na FAJ em 11de dezembro de 2006 pela banca examinadora constituída pelos professores:______________________________________________________________________Prof. Odair Jacinto da SilvaFAJ – Orientador______________________________________________________________________Prof. Silvio Petroli NetoFAJ – Prof. Convidado______________________________________________________________________LivioFAJ - Convidado
    • DEDICATÓRIAÀs minhas filhas Audrey Carolina Panegassi e Adrielly Fernanda PanegassiPelos momentos compartilhados juntos e pela alegria que me proporcionam. A vida se tornamuito mais adorável quando temos “inspiração” para vivê-la.
    • AGRADECIMENTOS Ao Prof. Odair Jacinto da Silva pela orientação dedicada em todas as fases darealização deste trabalho. A todos os professores do curso de Ciência da Computação da Faculdade deJaguariúna que também contribuíram para o meu crescimento pessoal e profissional.
    • EPÍGRAFE"O valor das coisas não está no tempo em que elas duram, mas na intensidade com queacontecem. Por isso existem momentos inesquecíveis, coisas inexplicáveis e pessoasincomparáveis". (Fernando Pessoa)
    • Lista de SiglasDSS – Decision Support SystemsDASD – Direct Access Storage DeviceEIS – Executive Information SystemsE/S – Entradas/SaídasER – Entidade/RelacionamentosETL – Extract, Transform and LoadIDC – International Data CorporationI/O – Imput/OutputID – IdentificationKDD – Knowledge Discovery in DatabasesL4Gs – Linguagens de quarta geraçãoMIS – Management information systemsMIT – Massachusetts Institute of TechnologyMOLAP – Multidimensional On-Line Analytical ProcessingMPP – Matching Pursuit ProjectionOLAP – On-Line Analytical ProcessingOLTP – On-line Transaction ProcessingPCs – Personal Communications ServicesROLAP – Relational On-Line Analytical ProcessingSGBD – Sistema de gerenciamento de banco de dadosSAD – Sistemas de Apoio à DecisãoSQL – Structured Query LanguageSMP – Symmetric Multi-ProcessingTI – Tecnologia da Informação
    • Lista de FigurasFigura 1 – Os tipos de consultaFigura 2 – Comparação entre Banco de Dados Operacionais e Data WarehouseFigura 3 – Níveis de granularidadeFigura 4 – Arquitetura genérica do Data WarehouseFigura 6 – Arquitetura de três camadas.Figura 5 – Arquitetura de duas camadas.Figura 7 – Modelo EstrelaFigura 8 – A dimensão do produto normalizada.Figura 9 – Relacional versus BidimensionalFigura 10 – Remoção dos dados puramente operacionais.Figura 11 – Adição de um elemento de tempo.Figura 12 – Introdução de dados derivadosFigura 13 – Relacionamento entre tabelas no modelo E-R.Figura 14 – Inclusão de artefatos no data warehouse.Figura 15 – Alteração do nível de granularidade.Figura 16 – União dos dados de diferentes tabelasFigura 17 – Modelo corporativoFigura 18 – Selecionando os dados a serem varridos.Figura 19 – Introdução intencional de dados redundantes.Figura 20 – A tabela de fatos e suas dimensões.
    • INMON, William H.. Como construir o Data warehouse. 2ª ed. New York: Editora Campus,1997.RESUMO O ambiente de dados para suporte aos processos de gerência e tomada de decisão éfundamentalmente diferente do ambiente convencional de processamento de transações. Nocoração deste ambiente está a idéia do Data Warehouse, integrando e consolidando dadosdisponíveis em diferentes acervos para fins de exploração e análise, ampliando o conteúdoinformacional destes acervos para atender às expectativas e necessidades de nível estratégicona empresa. Esta monografia tem por objetivo apresentar o estado da arte da tecnologia deData Warehouse, introduzindo os principais conceitos na área e discutindo as diferenças desteambiente para os ambientes e ferramentas usuais de gerenciamento e tratamento deinformações, alem de mostrar duas formas de extração de seus dados: a OLAP e o DataMining, cada uma com suas características, podendo ser usadas separadamente ou emconjunto para um melhor resultado.Palavras-chave: tomada de decisão, integrando e consolidando dados, tratamento deinformações.
    • SUMÁRIOINTRODUÇÃO........................................................................................................................12CAP. 1 - EVOLUÇÃO DOS SISTEMAS DE APOIO À DECISÃO ......................................13 1.1 – Histórico ....................................................................................................................13 1.2 – O Ambiente projetado ...............................................................................................14CAP. 2 – O QUE É DATA WAREHOUSE.............................................................................16 2.1 – Histórico ......................................................................................................................16 2.1.1 – Origem ..................................................................................................................16 2.2 – Definições....................................................................................................................17 2.3 - Características de um Data Warehouse........................................................................17 2.3.1 - Orientado para áreas de interesse ..........................................................................19 2.4 – Integrado......................................................................................................................19 2.5 - Variante no tempo ........................................................................................................19 2.6 - Não volátil ....................................................................................................................20 2.7 – Granularidade ..............................................................................................................20 2.7.1 – Níveis duais de granularidade ..............................................................................21 2.8 – Metadados....................................................................................................................22CAP. 3 – ARQUITETURA DO DATA WAREHOUSE.........................................................23 3.1 – Arquitetura genérica do Data Warehouse....................................................................23 3.2 – Outras arquiteturas.......................................................................................................25 3.2.1 – Arquitetura de duas camadas................................................................................25 3.2.2 – Arquitetura de três camadas .................................................................................26CAP. 4 – MODELO DE DADOS DO DATA WAREHOUSE ...............................................28 4.1 - A Questão das Dimensões............................................................................................28 4.2 - Esquemas do tipo Estrela e Floco de Neve ..................................................................29 4.2.1 – Vantagens do modelo estrela................................................................................31 4.2.2 - Bancos de Dados Multidimensionais ....................................................................32 4.3 – Conversão do modelo E-R para o modelo do Data Warehouse ..................................32 4.3.1 - Remoção dos dados puramente operacionais........................................................33 4.3.2 - Adição de um elemento de tempo na estrutura da chave ......................................33 4.3.3 - Introdução de dados derivados..............................................................................34 4.3.4 - Transformação de Relacionamentos entre dados em artefatos dos dados ............34 4.3.5 - Acomodação dos diferentes níveis de granularidade ............................................36 4.3.6 - União dos dados comuns de diferentes tabelas .....................................................36 4.3.7 - Criação de arrays de dados....................................................................................37 4.4 Data Marts ......................................................................................................................38CAP. 5 – DESENVOLVIMENTO DO DATA WAREHOUSE..............................................39 5.1 - Estratégia Evolucionária ..............................................................................................40 5.2 - Aspectos de Modelagem ..............................................................................................40 5.3 – Técnicas de gerenciamento da quantidade de dados operacionais pesquisados..........41 5.4 – Técnicas para incrementar a performance ...................................................................43 5.5 - Etapas do Desenvolvimento de um Data Warehouse ..................................................46 5.6 – Relacional versus multidimensional............................................................................47 5.6.1 - Um ou mais bancos ...............................................................................................48CAP. 6 – CARREGANDO O DATA WAREHOUSE ............................................................50 6.1 – Extração .......................................................................................................................50 6.2 – Transformação e filtros................................................................................................51 6.3 - Derivação e Sumarização .............................................................................................52
    • CAP. 7 – EXTRAINDO INFORMAÇÕES DO DATA WAREHOUSE ................................53 7.1 - Ferramentas OLAP.......................................................................................................53 7.1.1 - MOLAP x ROLAP................................................................................................55 7.2 - Ferramentas Data Mining.............................................................................................57CONCLUSÃO..........................................................................................................................59BIBLIOGRAFIA ......................................................................................................................61
    • INTRODUÇÃO Hoje em dia uma organização precisa utilizar toda informação disponível para criar emanter vantagem competitiva. Sai na frente à organização que consegue tomar decisõescorretas e rápidas. Com esta importante tarefa nas mãos, profissionais tomadores de decisão tais comoexecutivos, gerentes e analistas, exigem dos sistemas de suporte à decisão DSS (DecisionSupport Systems) mais recursos para análise, front-ends que suportem consultas ad hoc,interfaces gráficas apropriadas, etc. A idéia de Data Warehouse é integrar os dados internos e externos de umaorganização em uma estrutura única permitindo uma melhor utilização dos dados pelosanalistas, gerentes e executivos. Uma vez obtida a integração, sistemas como OLAP (On-Line Analytical Processing) eData Mining fornecem mecanismos sofisticados para análise dos dados. Estudar e conhecer a tecnologia de Data Warehouse pode ajudar os empresários adescobrir novas formas de competir em uma economia globalizada, trazendo melhoresprodutos ou serviços para o mercado, mais rápido do que os concorrentes, sem aumentar ocusto do produto ou do serviço. Não existem ainda metodologias formais para implementaçãode um Data Warehouse, ela deve ser adaptada às características e às expectativas de cadaempresa, mas o principal objetivo em todas elas é o de descobrir maneiras diferentes de atuarno mercado e quais as mudanças internas que devem ocorrer para atender as novas realidades. Este trabalho tem como objetivo fazer um estudo dos principais conceitos necessáriospara o desenvolvimento de um ambiente de Data Warehouse. No capítulo I é apresentada aevolução dos sistemas de apoio à decisão e o motivo do surgimento da necessidade do DataWarehouse. No capítulo II iniciam-se os conceitos sobre o Data Warehouse, mostrando suascaracterísticas básicas. O capítulo III mostra as arquiteturas disponíveis para construção deData Warehouses, e no capítulo IV os modelos de dados. O capítulo V mostra alguns detalhesdo desenvolvimento propriamente dito do Data Warehouse. O capítulo VI mostra as técnicaspara extrair as informações dos sistemas existentes e transforma-las adequadamente para oData Warehouse. E finalmente no capítulo VII são apresentadas as técnicas para extração eanalise dos dados de um Data Warehouse que são: OLAP e Data Mining.
    • CAP. 1 - EVOLUÇÃO DOS SISTEMAS DE APOIO À DECISÃO1.1 – Histórico A evolução dos sistemas de apoio à decisão pode ser dividida em cinco fases entre1960 e 1980. No início da década de 1960 o mundo da computação consistia na criação deaplicações individuais que eram executadas sobre arquivos mestres, caracterizadas porprogramas e relatórios. Aproximadamente em 1965 o crescimento dos arquivos mestres e das fitas magnéticasexplodiu, surgindo problemas como: a complexidade de manutenção dos programas; acomplexidade do desenvolvimento de novos programas; a quantidade de hardware paramanter todos os arquivos mestres e a necessidade de sincronizarem dados a serem atualizados. Por volta de 1970, surgiu a tecnologia DASD (Direct Access Storage Device),substituindo as fitas magnéticas pelo armazenamento em disco. Com o DASD surgiu um novotipo de software conhecido como SGBD (Sistema de Gerenciamento de Banco de Dados), quetinha o objetivo de tornar o armazenamento e o acesso a dados no DASD mais fáceis para oprogramador. E com o SGBD surgiu a idéia de um “banco de dados” que foi definido como:uma única fonte de dados para todo o processamento. Aproximadamente em 1975 surgiu o processamento de transações on-line. Com oprocessamento de transações on-line de alta performance, o computador pôde ser usado paratarefas que antes não eram viáveis como controlar sistemas de reservas, sistemas de caixasbancários, sistemas de controle de produção e outros. Até o início da década de 1980, novas tecnologias, como os PCs (PersonalCommunications Services) e as L4Gs (Linguagens de Quarta Geração), começaram aaparecer. O usuário final passou a controlar diretamente os sistemas e os dados, descobrindoque era possível utilizar os dados para outros objetivos além de atender ao processamento detransações on-line de alta performance. Foi nesse período também que se tornou viável aconstrução dos MIS (Management Information Systems), hoje conhecidos como SAD(Sistemas de Apoio à Decisão) eles consistiam em processamento utilizado para direcionardecisões gerenciais [INM97].
    • 1.2 – O Ambiente projetado A arquitetura de desenvolvimento espontâneo não era suficiente para atender asnecessidades do futuro das empresas, fazendo-se necessário uma mudança de arquitetura,surgindo o ambiente projetado de Data Warehouse. Neste ambiente há duas espécies de dados – dados primitivos e dados derivados. Háquatro níveis no ambiente projetado – o operacional, a atômico ou Data Warehouse, odepartamental e o individual. O nível operacional de dados contém apenas dados primitivos eatende à comunidade de processamento de transações de alta performance. O DataWarehouse contém dados primitivos que não são atualizados e dados derivados. O níveldepartamental de dados praticamente só contém dados derivados. E o nível individual dedados é onde a maior parte das análises heurísticas é feito [INM97]. A Figura 1 mostra os tipos de consulta para os quais os diferentes níveis de dadospodem ser usados.Figura 1 – Os tipos de consulta.Nos tipos de consultas as informações ficam à disposição com as seguintes características: • Dados primitivos: baseados em aplicações, detalhados, podem ser atualizados, exatos em relação ao momento do acesso e são processados repetitivamente.
    • • Dados derivados: baseados em assuntos ou negócios, resumidos, ou refinados, não são atualizados, representam valores de momentos já decorridos ou instantâneos e são processados de forma heurística.
    • CAP. 2 – O QUE É DATA WAREHOUSE2.1 – Histórico O Data Warehouse é um banco de dados contendo dados extraídos do ambiente deprodução da empresa, que foram selecionados e depurados, tendo sido otimizados paraprocessamento de consulta e não para processamento de transações. Em geral, um DataWarehouse requer a consolidação de outros recursos de dados além dos armazenados embanco de dados relacionais, incluindo informações provenientes de planilhas eletrônicas,documentos textuais, etc. A função do Data Warehouse é tornar as informações corporativas acessíveis para oseu entendimento, gerenciamento e uso. Como o Data Warehouse está separado dos Bancosde Dados operacionais, as consultas dos usuários não impactam nestes sistemas, que ficamresguardados de alterações indevidas ou perdas de dados. O Data Warehouse não como umsoftware, que pode ser comprado e instalado em todos os computadores da empresa emalgumas horas. Na realidade, sua implantação exige a integração de vários produtos eprocessos. Nos últimos anos o Data Warehouse vem oferecendo às organizações uma maneiraflexível e eficiente de obter as informações que os gestores necessitam, nos processosdecisórios e de caracteriza como uma função de apoio à decisão.2.1.1 – Origem Segundo Haisten (1999), a origem do Data Warehouse vem dos estudos do MIT(Massachusetts Institute of Technology) nos anos 70 que focavam o desenvolvimento de umaarquitetura técnica mais eficiente para sistemas de informações. Pela primeira vez foi feitauma distinção entre sistemas operacionais e aplicações analíticas e surgiu o princípio deseparar esse dois tipos de processamentos em projetos e armazéns de dados diferentes. Para Ballard & Herreman (1998) e Teresko (1999), o conceito de Data Warehousesurgiu no inicio dos anos 80 quando os sistemas gerenciais de banco de dados (SGBD)emergiram como produtos comerciais com facilidades para a computação de apoio a decisão(SAD). Teresko (1999) comenta que Bill Inmon, observou que estes repositórios deinformações poderiam ser organizados em um bem corporativo que ele chamou de Data
    • Warehouse e por causa disso Inmon é considerado o “pai do Data Warehouse”. No inicio, oData Warehouse consistia de instantâneos, ou subconjuntos dos dados operacionais que eramcarregados em banco de dados de apoio a decisão em períodos regulares que costumavam sersemanais ou mensais (Ballard & Herreman, 1998).2.2 – Definições A definição clássica de Data Warehouse criada por Inmon (1997) é a seguinte:“Data Warehouse é uma coleção de dados orientada por assuntos, integrada, variante notempo, e não volátil que tem por objetivo dar suporte aos processos de tomada de decisão.” Knowles (1996) utiliza um lógica interessante para dizer como o Data Warehouse éimportante para a empresa: “Poder faz dinheiro. Conhecimento é poder. Data Warehouseaumenta o conhecimento. Portanto, Data Warehouse faz dinheiro.”. Gurovitz (1999) cita um estudo do IDC (International Data Corporation) que coloca oData Warehouse como a melhor chance para a TI (Tecnologia da Informação) mostrar ao queveio gerando ganhos de tempo e dinheiro com informações acessíveis aos executivos quandoe como eles quiserem. Segundo Ralph Kimball (1998), uma autoridade nesse assunto, Data Warehouse “é olugar onde as pessoas podem acessar seus dados.” Já Wang (1998) tem uma definição umpouco mais elaborada quando diz que Data Warehouse “é o processo pelo qual os dadosrelacionados de vários sistemas operacionais são fundidos para proporcionar uma única eintegrada visão de informação de negócios que abrange todas as divisões de empresa.”.2.3 - Características de um Data Warehouse Herdlein (1996) coloca que construir um Data Warehouse provavelmente envolverámais recurso humanos e de capital que qualquer outro projeto de TI que a organização jápossui. Nessas proporções, as chances de falhas não são pequenas. Muitos projetos de DataWarehouse param por causa de infra-estrutura técnica ineficiente, falta de suporte executivo,inexperiência das equipes de projeto e longo prazo para apresentação de resultados. Conforme Singh (1997), o Data Warehouse, não é simplesmente um produto ouprocesso, mas uma estratégia que reconhece a necessidade de consolidar os dados
    • armazenados em sistemas de informações dedicados a ajudar os profissionais de negócio atomarem decisões mais rápidas e efetivas. Para entender melhor o que é um Data Warehouse vamos fazer uma comparação entreele e os bancos de dados operacionais [DAL99].Figura 2 – Comparação entre Banco de Dados Operacionais e Data Warehouse. O Data Warehouse é um banco de dados contendo dados extraídos do ambiente deprodução da empresa, que foram selecionados e depurados, tendo sido otimizados paraprocessamento de consulta e não para processamento de transações. Em geral, um DataWarehouse requer a consolidação de outros recursos de dados além dos armazenados embanco de dados relacionais, incluindo informações provenientes de planilhas eletrônicas,documentos textuais, etc. É importante considerar, no entanto, que um Data Warehouse não contém apenasdados resumidos, podendo conter também dados primitivos. É desejável prover ao usuário acapacidade de aprofundar se num determinado tópico, investigando níveis de agregaçãomenores ou mesmo o data primitivo, permitindo também a geração de novas agregações oucorrelações com outras variáveis. Além do mais, é extremamente difícil prever todos ospossíveis dados resumidos que serão necessários:
    • limitar o conteúdo de um Data Warehouse apenas a dados resumidos significa limitar osusuários apenas às consultas e análises que eles puderem antecipar frente a seus requisitosatuais, não deixando qualquer flexibilidade para novas necessidades.2.3.1 - Orientado para áreas de interesse Refere-se ao fato do Data Warehouse armazenar informações sobre temas específicosimportantes para o negócio da empresa. Exemplos típicos de temas são: produtos, atividades,contas, clientes, etc. Em contrapartida, o ambiente operacional é organizado por aplicações funcionais. Porexemplo, em uma organização bancária, estas aplicações incluem empréstimos, investimentose seguros. A principal área de interesse termina sendo fisicamente implementada como uma sériede tabelas relacionadas inseridas no Data Warehouse. Por exemplo: vendas, compras,produção, marketing, clientes e produtos.2.4 – Integrado Refere-se à consistência de nomes, das unidades das variáveis, etc., no sentido de queos dados foram transformados até um estado uniforme. Por exemplo, considere-se sexo comoum elemento de dado. Uma aplicação pode codificar sexo como M/F, outra como 1/0 e umaterceira como H/M. Conforme os dados são trazidos para o Data Warehouse, eles são convertidos para umestado uniforme, ou seja, sexo é codificado apenas de uma forma. Da mesma maneira, se umelemento de dado é medido em centímetros em uma aplicação, em polegadas em outra, eleserá convertido para uma representação única ao ser colocado no Data Warehouse.2.5 - Variante no tempo Refere-se ao fato do dado em um Data Warehouse referir-se a algum momentoespecífico, significando que ele não é atualizável, enquanto que o dado de produção éatualizado de acordo com mudanças de estado do objeto em questão, refletindo, em geral, oestado do objeto no momento do acesso. Em um Data Warehouse, a cada ocorrência de umamudança, uma nova entrada é criada, para marcar esta mudança.
    • O tratamento de séries temporais apresenta características específicas, que adicionamcomplexidade ao ambiente do Data Warehouse. Processamentos mensais ou anuais sãosimples, mas dias e meses oferecem dificuldades pelas variações encontradas no número dedias em um mês ou em um ano, ou ainda no início das semanas dentro de um mês. Alémdisso, deve-se considerar que não apenas os dados têm uma característica temporal, mastambém os metadados, que incluem definições dos itens de dados, rotinas de validação,algoritmos de derivação, etc. Sem a manutenção do histórico dos metadados, as mudanças dasregras de negócio que afetam os dados no Data Warehouse são perdidas, invalidando dadoshistóricos.2.6 - Não volátil Significa que o Data Warehouse permite apenas a carga inicial dos dados e consultas aestes dados. Após serem integrados e transformados, os dados são carregados em bloco para oData Warehouse, para que estejam disponíveis aos usuários para acesso. No ambienteoperacional, ao contrário, os dados são, em geral, atualizados registro a registro, em múltiplastransações. Esta volatilidade requer um trabalho considerável para assegurar integridade econsistência através de atividades de rollback, recuperação de falhas, commits e bloqueios. Um Data Warehouse não requer este grau de controle típico dos sistemas orientados atransações.2.7 – Granularidade Granularidade diz respeito ao nível de detalhe ou de resumo contido nas unidades dedados existentes no Data Warehouse. Quanto maior o nível de detalhes, menor o nível degranularidade. O nível de granularidade afeta diretamente o volume de dados armazenado noData Warehouse e ao mesmo tempo o tipo de consulta que pode ser respondida. Quando se tem um nível de granularidade muito alto o espaço em disco e o número deíndices necessários se tornam bem menores, porém há uma correspondente diminuição dapossibilidade de utilização dos dados para atender a consultas detalhadas [DAL99]. Há, portanto, um bom motivo para a compactação de dados em um Data Warehouse.Quando os dados são compactados ocorre uma economia incomum sobre o total de DASD
    • utilizado, o número de índices necessários e os recursos de processador necessários para otratamento dos dados. No entanto, há um outro aspecto da compactação de dados que ocorre à medida que onível de granularidade é elevado. À medida que o nível de granularidade se eleva, há umacorrespondente diminuição da possibilidade de utilização dos dados para atender a consultas.Já com um nível mais baixo de granularidade é possível responder a qualquer consulta[INM97]. Devemos lembrar, porém que em um ambiente de Data Warehouse, dificilmente umevento isolado é examinado. É mais comum ocorrer a utilização de uma visão de conjunto dosdados.2.7.1 – Níveis duais de granularidade O chamado nível duplo de granularidade, ilustrado na Figura 3, se enquadra nosrequisitos da maioria das empresas. Na camada de dados levemente resumidos ficam os dadosque fluem do armazenamento operacional e são resumidos na forma de campos apropriadospara a utilização de analistas e gerentes. Na segunda camada, ou nível de dados históricos,ficam todos os detalhes vindos do ambiente operacional, como há uma verdadeira montanhade dados neste nível, fazem sentido armazenar os dados em um meio alternativo como fitasmagnéticas. Com a criação de dois níveis de granularidade no nível detalhado do Data Warehouse,é possível atender a todos os tipos de consultas, pois a maior parte do processamento analíticodirige-se aos dados levemente resumidos que são compactos e de fácil acesso e para ocasiõesem que um maior nível de detalhe deve ser investigado existe o nível de dados históricos. Oacesso aos dados do nível histórico de granularidade é caro, incômodo e complexo, mas casohaja necessidade de alcançar esse nível de detalhe, lá estará ele. Alto nível de detalhe Baixo nível de detalhe Diário Mensal Baixa granularidade Alta granularidade
    • Figura 3 – Níveis de granularidade.2.8 – Metadados Os metadados são de grande importância para o processo de controle das operaçõesem um Data Warehouse. Os metadados são dados acerca dos dados constantes no DataWarehouse. Durante todas as fases do projeto de um Data Warehouse, e também após o iníciode sua operacionalização, metadados devem ser armazenados. Existem no mercadoferramentas próprias para armazenar e gerenciar metadados, dos quais o Sybase WarehouseControl Center e o Prism Warehouse Directory são exemplos. Segundo Inmon (1997), os metadados são informações sobre “o que está aonde” noData Warehouse. Os aspectos sobre os quais os metadados mantém informações são:• “A estrutura dos dados, segundo a visão do programador;• A estrutura dos dados segundo a visão dos analistas de sistemas de apoio à decisão;• A fonte de dados que alimenta o Data Warehouse;• A transformação sofrida pelos dados no momento de sua migração para o Data Warehouse;• O modelo de dados;• O relacionamento entre o modelo de dados e o Data Warehouse;• O histórico das extrações de dados.”
    • CAP. 3 – ARQUITETURA DO DATA WAREHOUSE Para ser útil o Data Warehouse deve ser capaz de responder a consultas avançadas demaneira rápida, sem deixar de mostrar detalhes relevantes à resposta. Para isso ele devepossuir uma arquitetura que lhe permita coletar, manipular e apresentar os dados de formaeficiente e rápida. Mas construir um Data Warehouse eficiente, que servirá de suporte adecisões para a empresa, exige mais do que simplesmente descarregar ou copiar os dados dossistemas atuais para um banco de dados maior. Deve-se considerar que os dados provenientesde vários sistemas podem conter redundâncias e diferenças, então antes de passá-los para oData Warehouse é necessário aplicar filtros sobre eles. O estudo de uma arquitetura permite compreender como o Data Warehouse faz paraarmazenar, integrar, comunicar, processar e apresentar os dados que os usuários utilizarão emsuas decisões. Um Data Warehouse pode variar sua arquitetura conforme o tipo de assuntoabordado, pois as necessidades também variam de empresa para empresa. É possível definiruma arquitetura genérica onde praticamente todas as camadas necessárias são apresentadas,conforme a arquitetura genérica vista a seguir, ou arquiteturas que utilizam somente algumasdas camadas definidas, como as arquiteturas em duas e três camadas.3.1 – Arquitetura genérica do Data Warehouse A seguir é descrita uma arquitetura genérica proposta por [DAL99] e ilustrada naFigura 4. Esta descrição genérica procura apenas sistematizar papéis no ambiente de DataWarehouse, permitindo que as diferentes abordagens encontradas no mercado atualmentepossam ser adaptadas a ela devesse considerar que esta arquitetura tem o objetivo derepresentar a funcionalidade de um Data Warehouse sendo que várias camadas propostaspodem ser atendidas por um único componente de software. Esta arquitetura é composta pela camada dos dados operacionais e outras fontes dedados que são acessados pela camada de acesso aos dados. As camadas de gerenciamento deprocessos, transporte e Data Warehouse formam o centro da arquitetura e são elas asresponsáveis por manter e distribuir os dados. A camada de acesso à informação é formadapor ferramentas que possibilitam os usuários extrair informações do Data Warehouse. Todasas camadas desta arquitetura interagem com o dicionário de dados (metadados) e com ogerenciador de processos:
    • • Camadas de bancos de dados operacionais e fontes externas: É composto pelos dados dos sistemas operacionais das empresas e informações provenientes de fontes externas que serão integradas para compor o Data Warehouse;• Camada de acesso à informação: Envolve o hardware e o software utilizado para obtenção de relatórios, planilhas, gráficos e consultas. É nesta camada que os usuários finais interagem com o Data Warehouse, utilizando ferramentas de manipulação, análise e apresentação dos dados, incluindo-se as ferramentas de Data Mining e visualização;• Camada de acesso aos dados: Esta camada faz a ligação entre as ferramentas de acesso à informação e os bancos de dados operacionais. Esta camada se comunica com diferentes sistemas de bancos de dados, sistemas de arquivos e fontes sob diferentes protocolos de comunicação, o que se chama acesso universal de dados;• Camada de metadados (Dicionário de dados): Metadados são as informações que descrevem os dados utilizados pela empresa, isto envolve informações como descrições de registros, comandos de criação de tabelas, diagramas Entidade/Relacionamentos (ER), dados de um dicionário de dados, etc. É necessário que exista uma grande variedade de metadados no ambiente de Data Warehouse para que ele mantenha sua funcionalidade e os usuários não precisem se preocupar onde residem os dados ou a forma com que estão armazenados;• Camada de gerenciamento de processos: É a camada responsável pelo gerenciamento dos processos que contribuem para manter o Data Warehouse atualizado e consistente. Está envolvida com o controle das várias tarefas que devem ser realizadas para construir e manter as informações do dicionário de dados e do Data Warehouse;• Camada de transporte: Esta camada gerencia o transporte de informações pelo ambiente de rede. Inclui a coleta de mensagens e transações e se encarrega da entrega em locais e tempos determinados. Também é usada para isolar aplicações operacionais ou informacionais, do formato real dos dados nas duas extremidades;• Camada do Data Warehouse: É o Data Warehouse propriamente dito, corresponde aos dados utilizados para obter informações. Às vezes o Data Warehouse pode ser simplesmente uma visão lógica ou virtual dos dados, podendo não envolver o armazenamento dos mesmos ou armazenar dados operacionais e externos para facilitar seu acesso e manuseio.
    • Figura 4 – Arquitetura genérica do Data Warehouse.3.2 – Outras arquiteturas3.2.1 – Arquitetura de duas camadas Uma opção de arquitetura para o Data Warehouse é utilizar um computador de altacapacidade como servidor. Isto é uma incorporação das aplicações utilizadas pelos usuários(front end) com os componentes do servidor (back end). Aplicações front end construídascom ferramentas cliente/servidor fornecem uma interface gráfica amigável, suportam funçõesespecíficas da empresa, possibilitam o acesso transparente aos dados dos sistemas jáexistentes e escondem a complexidade e a falta de consistência dos bancos de dados atuaisalém de facilitar a utilização e a visualização dos resultados. Os sistemas operacionais de umaempresa podem estar em uso por 15 ou 20 anos e podem ter altas taxas de redundância. Aredundância e a falta de consistência dos dados podem dificultar a administração da empresa eo acesso aos dados e impede o desenvolvimento de novas aplicações front end. Uma dasmaneiras de tratar com esta situação é partir de um só sistema e construir uma espécie de"sistema guarda-chuva" que tenha facilidade de acesso aos dados do servidor principal.
    • Figura 5 - Arquitetura de duas camadas. A arquitetura ilustrada na Figura 4 pode ser usada para construir um Data Warehouseem duas camadas que consiste de componentes dos clientes (front end) e componentes doservidor (back end). Esta arquitetura é atrativa porque ela utiliza os sistemas existentes bemcomo os servidores de bancos de dados existentes e requer um investimento mínimo emhardware e software. Entretanto, a arquitetura em duas camadas não é escalonável e nãosuporta um grande número de usuários simultaneamente. Isto estimula o desenvolvimento deestações clientes muito pesadas, pois muito processamento é alocado para processar nestasestações [DAL99].3.2.2 – Arquitetura de três camadas Uma alternativa é utilizar a arquitetura de informação em múltiplas camadas, comomostrado na Figura 5. Esta arquitetura flexível suporta um grande número de serviçosintegrados, na qual a interface do usuário, as funções de processamento do negócio e asfunções de gerenciamento do banco de dados são separadas em processos que podem serdistribuídos através da arquitetura de informação. A arquitetura em três camadas é amplamente utilizada para Data Warehouse. Naterceira camada ficam as fontes de dados. Dados e regras de negócio podem sercompartilhados pela organização, assim como os bancos de dados para o Data Warehouse,ficam armazenados em servidores de alta velocidade na segunda camada. Na primeira camadaficam as aplicações de interface com os usuários que devem ser gráficas e baseadas em rede. No ambiente do Data Warehouse, os servidores de banco de dados e os servidores deaplicações da segunda camada fornecem um acesso eficiente e veloz aos dadoscompartilhados. Os dados de um Data Warehouse são tipicamente estáticos, por exemplo, nãovariam com o tempo e devem ser integrados, de natureza histórica e sumarizados ouagregados para que sejam significantes para os analistas de negócios. Como mostrado naFigura 5, dados operacionais e bancos de dados para o Data Warehouse são freqüentementearmazenados em servidores fisicamente separados. Bancos de dados operacionais sãootimizados para ter alto desempenho no processamento de transações on-line, em inglêsconhecido como On-line Transaction Processing (OLTP). Bancos de dados para Data
    • Warehouse são otimizados para ter alto desempenho em consultas e análises, em inglêsconhecido como On-line Analytical Processing (OLAP).Figura 6 – Arquitetura de três camadas. É importante reconhecer que não existe uma arquitetura "correta" para DataWarehouse. Para algumas organizações pode ser atrativo utilizar a arquitetura em duascamadas, por que ela minimiza o custo e a complexidade de construção do Data Warehouse.Para outras que requerem grande performance e escalabilidade, a arquitetura em três camadaspode ser mais apropriada. No planejamento do Data Warehouse, as organizações devemexaminar as alternativas disponíveis de arquiteturas e selecionar aquela que satisfaça os seurequisitos estratégicos e organizacionais [DAL99].
    • CAP. 4 – MODELO DE DADOS DO DATA WAREHOUSE O modelo de dados tem um papel fundamental para o desenvolvimento interativo doData Warehouse. Quando os esforços de desenvolvimentos são baseados em um únicomodelo de dados sempre que for necessário unir estes esforços os níveis de sobreposição detrabalho e desenvolvimento desconexo serão muito baixos, pois todos os componentes dosistema estarão utilizando a mesma estrutura de dados. Existe um grande número de enfoques sobre modelagem de dados já desenvolvidospor vários autores, a maioria deles pode ser usada para construir um Data Warehouse. Dentreestes modelos apenas o multidimensional será apresentado neste trabalho.4.1 - A Questão das Dimensões Obter respostas a questões típicas de análise dos negócios de uma empresa geralmenterequer a visualização dos dados segundo diferentes perspectivas. Como exemplo, imagine-seuma agência de automóveis que esteja querendo melhorar o desempenho de seu negócio, Paraisso, necessita examinar os dados sobre as vendas disponíveis na empresa. Uma avaliaçãodeste tipo requer uma visão histórica do volume de vendas sob múltiplas perspectivas, comopor exemplo: volume de vendas por modelo, volume de vendas por cor, volume de vendas porfabricante, volume de vendas por período de tempo. Uma análise do volume de vendasutilizando uma ou mais destas perspectivas, permitiria responder questões do tipo: Qual atendência em termos de volume de vendas para o mês de dezembro para modelos VolvoSedan preto?A capacidade de responder a este tipo de questão em tempo hábil é o que permite aos gerentese altos executivos das empresas formular estratégias efetivas, identificar tendências emelhorar sua habilidade de tomar decisões de negócio. O ambiente tradicional de bancos dedados relacional certamente pode atender a este tipo de consulta. No entanto, usuários finaisque necessitam de consultas deste tipo via acesso interativo aos bancos de dados, mostram-seseguidamente frustrados por tempos de resposta ruins e pela falta de flexibilidade oferecidapor ferramentas de consulta baseadas no SQL (Structured Query Language). Daí anecessidade de utilizar abordagens específicas para atender a estas consultas. Para compreender melhor os conceitos envolvidos, examinemos em maior detalhe oexemplo acima.
    • Chamaremos de dimensões as diferentes perspectivas envolvidas, no caso, modelo,loja, fabricante, mês. Estas “dimensões” usualmente correspondem a campos não numéricosem um banco de dados. Consideremos também um conjunto de “medidas”, tal como vendas ou despesas compromoção. Estas medidas correspondem geralmente a campos numéricos em um banco de dados.A seguir, avaliam-se agregações destas medidas segundo às diversas dimensões e asarmazenamos para acesso futuro. Por exemplo, calcula-se a média de todas as vendas portodos os meses por loja. A forma como estas agregações são armazenadas pode ser vista emtermos de dimensões e coordenadas, dando origem ao termo multidimensional. Intuitivamente, cada eixo no espaço multidimensional é um campo/coluna de umatabela relacional e cada ponto um valor correspondente à interseção das colunas. Assim, ovalor para o campo vendas, correspondente a mês igual a maio e loja igual a Iguatemi é umponto com coordenada [maio, Iguatemi]. Neste caso, mês e loja são duas dimensões e vendasé uma medida. Teoricamente, quaisquer dados podem ser considerados multidimensionais.Entretanto, o termo normalmente se refere a dados representando objetos ou eventos quepodem ser descritos, e, portanto, classificados por dois ou mais de seus atributos. Estruturas relacionais podem ser usadas para a representação e o armazenamento dedados multidimensionais. Neste caso, as abordagens encontradas incluem desde a adoção deformas específicas de modelagem (os chamados esquemas estrela e floco de neve) atémecanismos sofisticados de indexação.4.2 - Esquemas do tipo Estrela e Floco de Neve Em um esquema do tipo estrela ou "star" as instâncias são armazenadas em uma tabelacontendo o identificador de instância, valores das dimensões descritivas para cada instância, evalores dos fatos, ou medidas, para aquela instância (tabela de fatos). Além disso, pelo menosuma tabela é usada, para cada dimensão, para armazenar dados sobre a dimensão (tabela dedimensão). No caso mais simples, a tabela de dimensão tem uma linha para cada valor válidoda dimensão. Esses valores correspondem a valores encontrados na coluna referente àqueladimensão na tabela de fatos.
    • Este esquema é chamado de estrela, por apresentar a tabela de fatos "dominante" nocentro do esquema e as tabelas de dimensões nas extremidades. A tabela de fatos é ligada àsdemais tabelas por múltiplas junções, enquanto as tabelas de dimensões se ligam apenas àtabela central por uma única junção. A Figura 7 mostra um exemplo de um modelo tipoestrela.Figura 7 – Modelo Estrela. A tabela de fatos é onde as medidas numéricas do fato representado estãoarmazenadas. Cada uma destas medidas é tomada segundo a interseção de todas asdimensões. No caso do exemplo, uma consulta típica selecionaria fatos da figuraFATOSVENDAS a partir de valores fornecidos relativos a cada dimensão. Outro tipo de estrutura bastante comum é o esquema do tipo floco de neve ou"snowflake", que consiste em uma extensão do esquema estrela onde cada uma das "pontas"da estrela passa a ser o centro de outras estrelas. Isto porque cada tabela de dimensão serianormalizada, "quebrando-se" a tabela original ao longo de hierarquias existentes em seusatributos. No caso do exemplo, a dimensão produto possui uma hierarquia definida ondecategoria se divide em marca e marca se divide em produtos (Figura 8). Da mesma forma, adimensão tempo inclui ano que contem mês e mês que contem dia do mês. Cada um destesrelacionamentos geraria uma nova tabela em um esquema floco de neve.
    • Figura 8 – A dimensão do produto normalizada.4.2.1 – Vantagens do modelo estrela • O modelo Estrela tem uma arquitetura padrão e previsível. As ferramentas de consulta e interfaces do usuário podem se valer disso para fazer suas interfaces mais amigáveis e fazer um processamento mais eficiente; • Todas as dimensões do modelo são equivalentes, ou seja, podem ser vistas como pontos de entrada simétricos para a tabela de fatos. As interfaces do usuário são simétricas, as estratégias de consulta são simétricas, e o SQL gerado, baseado no modelo, é simétrico; • O modelo dimensional é totalmente flexível para suportar a inclusão de novos elementos de dados, bem como mudanças que ocorram no projeto. Essa flexibilidade se expressa de várias formas, dentre as quais temos: • Todas as tabelas de fato e dimensões podem ser alteradas simplesmente acrescentando novas colunas a tabelas; • Nenhuma ferramenta de consulta ou relatório precisa ser alterada de forma a acomodar as mudanças; • Todas as aplicações que existiam antes das mudanças continuam rodando sem problemas; • Existe um conjunto de abordagens padrões para tratamento de situações comuns no mundo dos negócios. Cada uma destas tem um conjunto bem definido de alternativas que podem então ser especificamente programadas em geradores de relatórios, ferramentas de consulta e outras interfaces do usuário. Dentre estas situações temos: • Mudanças lentas das dimensões: ocorre quando uma determinada dimensão evolui de forma lenta e assíncrona; • Produtos heterogêneos: quando um negócio, tal como um banco, precisa controlar diferentes linhas de negócio juntas, dentro de um conjunto comum de
    • atributos e fatos, mas ao mesmo tempo esta precisa descrever e medir as linhas individuais de negócio usando medidas incompatíveis; • Outra vantagem é o fato de um número cada vez maior de utilitários administrativos e processo de software serem capazes de gerenciar e usar agregados, que são de suma importância para a boa performance de respostas em um Data Warehouse [DAL99].4.2.2 - Bancos de Dados Multidimensionais Embora seja viável utilizar estruturas relacionais na representação de dadosmultidimensionais, a solução não é ideal. Na Figura 9, é fácil verificar como uma matrizbidimensional representa mais claramente os dados armazenados na forma relacionaltradicional. Na matriz, os valores de vendas estão localizados nas interseções dos eixos X e Yda matriz 3x3. Cada eixo corresponde a uma dimensão, e cada elemento dentro de umadimensão corresponde a uma posição. Um array agrupa informações semelhantes em colunase linhas.Figura 9 – Relacional versus Bidimensional. Além disso, na representação multidimensional, totais consolidados são facilmenteobtidos e armazenados, bastando simplesmente adicionar totais de colunas e fileiras.4.3 – Conversão do modelo E-R para o modelo do Data Warehouse Para tal, W. H. Inmon fornece então alguns passos que podem ser seguidos, não seesquecendo de que o fundamental é que as decisões de transformação devem ser tomadaslevando-se em consideração os requisitos específicos da empresa. Os passos básicos são:
    • 4.3.1 - Remoção dos dados puramente operacionais A primeira ação consiste em remover os dados que são usados apenas no ambienteoperacional, como vemos no exemplo da Figura 10. Neste, atributos tais como mensagem,descrição e status são retirados, pois é muito pouco provável que estes sejam utilizados noprocesso de tomada de decisão. Neste momento, pode ser que se pense em manter todos os atributos, pois talvez algumdestes seja necessário para alguma decisão específica. Entretanto, deve-se levar em conta ocusto para gerenciar grandes volumes de dados [DAL99].Figura 10 – Remoção dos dados puramente operacionais.4.3.2 - Adição de um elemento de tempo na estrutura da chave A segunda modificação a ser feita no modelo corporativo é adicionar um elemento detempo a chave das tabelas, se estas já não o tiverem. No exemplo da Figura 11, o campo Data Snapshot foi adicionado como parte dachave. Enquanto no modelo corporativo a chave é apenas a identificação do consumidor, nomodelo do Data Warehouse a data do instantâneo deve fazer parte da chave, já que com opassar do tempo os dados do consumidor podem se alterar. Esta técnica é apenas uma formade tirar instantâneos dos dados. Outra forma de fazê-lo é adicionar dois campos do tipo data, um marcando o início eoutro o fim de um determinado intervalo de tempo. Esta técnica é melhor por representarfaixas contínuas de tempo ao invés de pontos ou datas específicas [DAL99].
    • Figura 11 – Adição de um elemento de tempo.4.3.3 - Introdução de dados derivados O próximo passo é adicionar dados derivados ao modelo, como mostrado na Figura12, já que por regra geral estes não existem no modelo corporativo. Devem ser adicionados osdados derivados que serão usados habitualmente de forma que estes sejam calculados apenasuma vez. Dessa forma, haverá uma redução no processamento que deve ser feito para acessaros dados derivados ou sumarizados. Outra razão para o armazenamento de dados derivados é que uma vez calculados earmazenados, a integridade destes aumenta, uma vez que se torna impossível a utilização dediferentes algoritmos para o cálculo destes derivados [DAL99].Figura 12 – Introdução de dados derivados.4.3.4 - Transformação de Relacionamentos entre dados em artefatos dos dados Os relacionamentos encontrados nas modelagens de dados clássicas assumem que háum e somente um valor de negócio no relacionamento. Levando-se em consideração que nossistemas operacionais o dado estar integro no momento da transação, esta abordagem écorreta. Entretanto, o Data Warehouse por sua característica de armazenar dados históricos,tem muitos valores para um dado relacionamento entre duas tabelas. Dessa forma a melhor
    • maneira de representar o relacionamento entre duas tabelas no Data Warehouse é através dacriação de artefatos. Um artefato de um relacionamento é somente a parte do relacionamento que é óbvia etangível no momento do instantâneo. Em outras palavras, quando o instantâneo é feito osdados associados com o relacionamento que são úteis e óbvios serão colocados no DataWarehouse. O artefato pode incluir chaves estrangeiras e outros dados relevantes, tais comocolunas de tabelas associadas, ou este pode incluir somente os dados relevantes, sem incluir aschaves estrangeiras. Como exemplo, consideremos as tabelas e o relacionamento entre estas na Figura 13.Nesta existe um relacionamento entre produto e fornecedor, onde cada produto tem umfornecedor principal. Se fossemos fazer então um instantâneo deste relacionamento, teríamosque considerar a informação do fornecedor principal que está relacionado ao produto. Alémdisso, outras informações de artefato relacionadas com o fornecedor deveriam então sercapturadas. A tabela de produtos no modelo do Data Warehouse ficaria então como amostrada na Figura 14 [DAL99].Figura 13 – Relacionamento entre tabelas no modelo E-R.Figura 14 – Inclusão de artefatos no Data Warehouse.
    • 4.3.5 - Acomodação dos diferentes níveis de granularidade Dependendo do caso, o nível de granularidade do sistema transacional pode ser omesmo do Data Warehouse ou não. Quando o nível de granularidade se altera, o modelo doData Warehouse deve representar esta mudança, como no exemplo da Figura 15. No exemplo, o modelo de dados corporativo mostra dados da atividade de envio deum determinado produto que são armazenadas toda vez que uma entrega é feita. Quando esteé passado para o Data Warehouse, duas agregações são feitas, alterando então agranularidade. Na primeira, o total de entregas é agregado mensalmente, fazendo com que agranularidade seja o mês, já na segunda, existe uma agregação das entregas feitas por mês elocal de origem, fazendo então com que a granularidade seja o mês associado ao fornecedor[DAL99].Figura 15 – Alteração do nível de granularidade.4.3.6 - União dos dados comuns de diferentes tabelas Nesta fase, deve-se considerar a possibilidade de combinar duas ou mais tabelas domodelo corporativo em uma única tabela do modelo do Data Warehouse. Para que estajunção possa ser feita, as seguintes condições devem ser verdadeiras: • As tabelas compartilham uma chave comum (ou chave parcial); • Os dados das diferentes tabelas geralmente são usados juntos; • Padrão de inserção nas tabelas é o mesmo.
    • Como exemplo, consideremos a Figura 16, onde temos as tabelas NOTAS e ITENSDAS NOTAS. Quando estas são colocadas no modelo do Data Warehouse, estas vão para umamesma tabela. Dessa forma, a junção entre estas tabelas passa a não ser mais necessáriaquando uma consulta for feita. Neste caso, podemos ver que as três condições são atendidas: as tabelas compartilhamparte da chave, ID da Nota; estas duas tabelas geralmente são usadas juntas; e o padrão deinserção é o mesmo, ou seja, sempre que uma nota é inserida seus itens também o são[DAL99].Figura 16 – União dos dados de diferentes tabelas.4.3.7 - Criação de arrays de dados Os dados no modelo corporativo geralmente estão normalizados, onde a existência degrupos repetitivos não é permitida. Entretanto, em algumas situações no ambiente de DataWarehouse pode haver grupos repetitivos de dados. As condições para existência destes são: • Quando o número de ocorrências do dado é previsível; • Quando a ocorrência do dado é relativamente pequena (em termos de tamanho físico); • Quando as ocorrências do dado geralmente são usadas juntas; • Quando o padrão de inserção e remoção dos dados é estável;
    • A Figura 17 mostra uma tabela no modelo corporativo com as previsões de gastomensais. Quando esta é colocada no modelo do Data Warehouse, os dados são armazenadosde forma que cada mês do ano é uma ocorrência no array [DAL99].Figura 17 - Modelo corporativo.4.4 Data Marts Da mesma forma que o Data Warehouse, o Data Mart ainda não possui uma definiçãouniversalmente aceita e também esta em fase de aperfeiçoamento. Os Data Marts sãosubconjuntos de dados, dentro de um Data Warehouse, projetados para dar suporte a negóciosde unidade organizacionais especificas (NIMER, 1998). Segundo o autor, os Data Marts são muito interessantes para resolver certosproblemas, mas não são necessariamente substitutos de um projeto de Data Warehouse. UmData Mart não deve ser um pequeno Data Warehouse, com a finalidade de ser rápido oupossuir dados ainda não suportados para o Data Warehouse (KIMBALL, 1997). Os projetos de Data Marts se justificam em poucos casos, basicamente naqueles ondea alta gerência ainda não esta convencida quanto a viabilidade e vantagens que a tecnologiado Data Warehouse pode prover as organizações. Neste caso, os Data Marts são viáveis, porapresentarem resultados mais rápidos, demoram entre 4 a 12 meses para seremimplementados e, em conseqüência, começam a dar resultados mais rápidos. Os DataWarehouses têm prazos que variam entre 1 a 5 anos para implementação completa.
    • CAP. 5 – DESENVOLVIMENTO DO DATA WAREHOUSE O sucesso do desenvolvimento de um Data Warehouse depende fundamentalmente deuma escolha correta da estratégia a ser adotada, de forma que seja adequada às característicase necessidades específicas do ambiente onde será implementado. Existe uma variedade deabordagens para o desenvolvimento de Data Warehouses, devendo-se fazer uma escolhafundamentada em pelo menos três dimensões: escopo do Data Warehouse (departamental,empresarial, etc.), grau de redundância de dados, tipo de usuário alvo. O escopo de um Data Warehouse pode ser tão amplo quanto aquele que inclui todo oconjunto de informações de uma empresa ou tão restrito quanto um Data Warehouse pessoalde um único gerente. Quanto maior o escopo, mais valor o Data Warehouse tem para a empresa e mais carae trabalhosa sua criação e manutenção. Por isso, muitas empresas tendem a começar com umambiente departamental e só após obter um retorno de seus usuários expandir seu escopo. Quanto à redundância de dados, há essencialmente três níveis de redundância: o DataWarehouse virtual, o Data Warehouse centralizado e o Data Warehouse distribuído. • O Data Warehouse virtual consiste em simplesmente prover os usuários finais com facilidades adequadas para extração das informações diretamente dos bancos de produção, não havendo assim redundância, mas podendo sobrecarregar o ambiente operacional. • O Data Warehouse central constitui-se em um único banco de dados físico contendo todos os dados para uma área funcional específica, um departamento ou uma empresa, sendo usados onde existe uma necessidade comum de informações. Um Data Warehouse central normalmente contém dados oriundos de diversos bancos operacionais, devendo ser carregado e mantido em intervalos regulares. • O Data Warehouse distribuído, como o nome indica, possui seus componentes distribuídos por diferentes bancos de dados físicos, normalmente possuindo uma grau de redundância alto e por conseqüência, procedimentos mais complexos de carga e manutenção. Os padrões de uso de um Data Warehouse também constituem um fator importante naescolha de alternativas para o ambiente. Relatórios e consultas pré-estruturadas podemsatisfazer o usuário final,
    • e geram pouca demanda sobre o SGBD e sobre o ambiente servidor. Análises complexas, porsua vez, típicas de ambientes de suporte à decisão, exigem mais de todo o ambiente.Ambientes dinâmicos, com necessidades em constante mudança, são mais bem atendidos poruma arquitetura simples e de fácil alteração, ao invés de uma estrutura mais complexa quenecessite de reconstrução a cada mudança. A freqüência da necessidade de atualizaçãotambém é determinante: grandes volumes de dados que são atualizados em intervalosregulares favorecem uma arquitetura centralizada.5.1 - Estratégia Evolucionária Data Warehouses, em geral, são projetados e carregados passo a passo, seguindo,portanto uma abordagem evolucionária. Os custos de uma implementação "por inteiro", emtermos de recursos consumidos e impactos no ambiente operacional da empresa justificamesta estratégia. Muitas empresas iniciam o processo a partir de uma área específica da empresa, quenormalmente é uma área carente de informação e cujo trabalho seja relevante para osnegócios da empresa, criando os chamados Data Marts (um Data Warehouse departamental),para depois ir crescendo aos poucos, seguindo uma estratégia "botton-up" ou assunto-por-assunto. Outra alternativa é selecionar um grupo de usuários, prover ferramentas adequadas,construir um protótipo do Data Warehouse, deixando que os usuários experimentem compequenas amostras de dados. Somente após a concordância do grupo quanto aos requisitos efuncionamento, é que o Data Warehouse será de fato carregado com dados dos sistemasoperacionais na empresa e dados externos. Data marts também podem ser criados como subconjunto de um Data Warehousemaior, em busca de autonomia, melhor desempenho e simplicidade de compreensão.5.2 - Aspectos de Modelagem A especificação de requisitos do ambiente de suporte à decisão associado a um DataWarehouse é fundamentalmente diferente da especificação de requisitos dos sistemas quesustentam os processos usuais do ambiente operacional de uma empresa.
    • Os requisitos dos sistemas do ambiente operacional são claramente identificáveis apartir das funções a serem executadas pelo sistema. Requisitos de sistemas de suporte àdecisão são, por sua vez, indeterminados. O objetivo por trás de um Data Warehouse é proverdados com qualidade; os requisitos dependem das necessidades de informação individuais deseus usuários. Ao mesmo tempo, os requisitos dos sistemas do ambiente operacional sãorelativamente estáveis ao longo do tempo, enquanto que os dos sistemas de suporte à decisãosão instáveis: dependem das variações das necessidades de informações daquelesresponsáveis pelas tomadas de decisões dentro da empresa. No entanto, embora as necessidades por informações específicas mudem comfreqüência, os dados associados não mudam. Imaginando-se que os processos de negócio deuma empresa permaneçam relativamente constantes, existe apenas um número finito deobjetos e eventos com as quais uma organização está envolvida. Por esta razão, um modelo dedados é uma base sólida para identificar requisitos para um Data Warehouse. De qualquer forma, é um erro pensar que técnicas de projeto que servem para sistemasconvencionais serão adequadas para a construção de um Data Warehouse. Os requisitos paraum Data Warehouse não podem ser conhecidos até que ele esteja parcialmente carregado e jáem uso. Outra questão interessante é a adequação do modelo Entidade-Relacionamento ao tipode transação de sistemas OLTP (On-line Transaction Processing). O principal objetivo damodelagem, neste caso, é eliminar ao máximo, a redundância, de tal forma que uma transaçãoque promova mudanças no estado do banco de dados, atue o mais pontualmente possível.Com isso, nas metodologias de projeto usuais, os dados são "fragmentados" por diversastabelas, o que traz uma considerável complexidade à formulação de uma consulta por umusuário final. Por isso, esta abordagem não parece ser a mais adequada para o projeto de umData Warehouse, onde estruturas mais simples, com menor grau de normalização devem serbuscadas.5.3 – Técnicas de gerenciamento da quantidade de dados operacionaispesquisados
    • Existem algumas técnicas que podem ser usadas para limitar a quantidade de dadospesquisados, conforme demonstrado na Figura 18, as técnicas expostas a seguir devem seranalisadas e deve-se escolher a que melhor represente as necessidades da empresa. [DAL99].Figura 18 – Selecionando os dados a serem varridos. A primeira técnica consiste em pesquisar dados que apresentem marcas de tempo. Paraisso é necessário que as aplicações registrem o momento da última alteração ou atualizaçãoem um registro para que ao ser executada a varredura para o Data Warehouse só sejamexaminados os registros que tenham a data de atualização igual ou maior do que a data daúltima pesquisa. A segunda técnica utiliza um arquivo de registros de alterações efetuadas. Estearquivo, também chamado arquivo “delta”. É criado por uma aplicação e contém apenas asalterações efetuadas por esta nos dados operacionais. Quando é possível contar com umarquivo delta o processo de varredura se torna muito eficiente uma vez que os dados que nãosofreram alterações não serão acessados. O problema é que poucas aplicações geram arquivosdelta. A terceira técnica consiste em varrer um arquivo de auditoria ou de log. Basicamente oarquivo de log possui os mesmos dados de um arquivo delta, todavia, há algumas diferençassignificativas. Uma delas é que por ser o arquivo utilizado para a recuperação dos dados do
    • banco de dados operacional em uma eventual falha não é interessante que se utilize estearquivo com outros propósitos. Outra diferença é que os arquivos de log normalmentepossuem uma estrutura interna voltada aos objetivos de um sistema e não estãocompletamente preparados para a recuperação de dados por um Data Warehouse. A quarta técnica empregada no gerenciamento da quantidade de dados pesquisadosdurante a extração para o Data Warehouse consiste em modificar o código da aplicaçãooperacional. Essa pode ser a pior escolha, sobretudo quando o código da aplicação é antigo oucomplexo. A última opção consiste em moldar um arquivo de imagem "anterior" e "posterior".Segundo esta opção, uma cópia do banco de dados é tirada no momento da extração e quandofor realizada outra extração, outra cópia será tirada. As duas cópias serão comparadasserialmente entre si para que seja detectada a atividade transcorrida neste período e entãoresgatadas às diferenças entre as duas copias. Esse método é pesado, complexo e demanda uma quantidade excessiva de recursos.5.4 – Técnicas para incrementar a performance O grande desafio de um sistema de apoio a decisão é que ele possua uma interfaceamigável e tempo de resposta satisfatório. Existem algumas técnicas que podem ser aplicadasno desenvolvimento de um Data Warehouse para incrementar sua performance. Essastecnologias podem ser divididas em duas áreas: aquelas que propõem soluções baseadas emhardware e outras baseadas em software. Algumas destas técnicas baseadas em software são amplamente utilizadas no ambienteoperacional e outras são específicas do ambiente de Data Warehouse, algumas técnicas sãocitadas a seguir, conforme [DAL99] e [PER99]. Uma proposta ao nível de hardware seria dividir o trabalho entre vários processadores.Porém, o sistema gerenciador de banco de dados deve ser capaz de dividir seu processamentoentre esses processadores. Com o processamento paralelo, a percepção de melhora nodesempenho é imediata, mas a tendência, ao longo do tempo, é voltarmos ao mesmo ponto,devido ao crescimento constante do Data Warehouse, atrelado às grandes mudanças queocorrem freqüentemente no mundo dos negócios. A distribuição do Data Warehouse, por vezes, é similar à abordagem doprocessamento paralelo: dividir a base de dados em subconjuntos de dados e coloca-los em
    • unidades de processamento separadas. A análise a respeito desse conceito vem novamente aoencontro de mesma atribuída ao processamento paralelo: dividir o trabalho. Portanto,podemos chegar à mesma conclusão, em termos de desvantagem, apresentada noprocessamento paralelo, ou seja, à medida que o número de dados aumentar, teremos semprede buscar maneiras de subdividir o conjunto de dados. Data marts são outra forma de distribuir os dados contidos no Data Warehouse. Osdata marts, geralmente, contêm dados específicos de uma determinada área ou departamento.Dessa forma, podemos dizer que os data marts são “mini” Data Warehouses, armazenadosprovavelmente em plataformas diferentes. O processo de particionamento melhora odesempenho no resgate de informações, fazendo uso da segmentação dos dados em áreaslógicas diferentes. Recursos sofisticados de indexação são a maneira mais eficiente de redução de I/O dedisco, necessária para resgatar um subconjunto de dados. Com técnicas avançadas deindexação, a seleção de registros por qualquer critério é executada usando-se poucas leiturasdo disco. Dessa forma, obtemos, em segundos, seleções complexas em enormes bases dedados. Existem várias formas de indexação. Há índices nativos da estrutura de banco de dadosrelacionais: primários, B-tree (árvore B) e hash/hashing. Há também índices especializados,independentes da estrutura dos bancos de dados relacionais: invertidos, bitmap, combinados,R-tree (árvores R) e alguns outros específicos para determinadas aplicações. Uma técnica relativa a estrutura do Data Warehouse que pode ser utilizada é aintercalação de tabelas onde o projetista deve procurar intercalar as tabelas afins em ummesmo local físico, diminuindo assim a quantidade de E/S (entradas/saídas), tanto em termosde acesso aos dados, como em termos de acessos aos índices para a localização dos dados. Amelhor estratégia de intercalação de tabelas deve ser defina com base nos tipos de dados epossíveis consultas que podem ser realizadas. Outra técnica importante aplicada especialmente no ambiente de Data Warehouseconsiste na introdução intencional de dados redundantes. A Figura 19 mostra um exemplo noqual a introdução deliberada de dados redundantes proporciona um excelente retorno. Naparte superior da Figura 19 o campo – descrição – está normalizado e não apresentaredundância. Dessa maneira todos os processos que precisam ver a descrição precisam acessara tabela básica. Na parte inferior da Figura 19 o campo – descrição – foi intencionalmentecolocado nas diversas tabelas em que ele precisa ser usado. O problema da replicação dedados é somente o aumento do volume do Data Warehouse, já que praticamente não existe apreocupação com atualizações neste ambiente.
    • Figura 19 – Introdução intencional de dados redundantes. A terceira técnica que pode ser utilizada para aumentar a velocidade de acesso aosdados é chamada de "separação de dados" que consiste em transformar uma tabelanormalizada e que apresente probabilidades de acesso muito diferentes em duas tabelasseparadas. Para a construção de um Data Warehouse pode ser usada também uma técnicachamada de “índice criativo”. Um índice criativo é gerado quando os dados passam doambiente operacional para o ambiente de Data Warehouse. O índice criativo gera um perfil dedados de interesse do usuário final, como informações sobre os produtos mais vendidos,clientes inativos e outras informações que possam antecipar os interesses da gerencia, comoesta antecipação nem sempre é possível é necessário avaliar com cautela sobre quais os dadosem que será aplicada esta técnica. Por último deve-se esclarecer que a tentativa de reproduzir a integridade referencial noData Warehouse constitui uma abordagem incorreta pois os dados em um Data Warehousenão são atualizados e representam informações ao longo do tempo, com isso osrelacionamentos não permanecem iguais impossibilitando a criação de relacionamentos.
    • 5.5 - Etapas do Desenvolvimento de um Data Warehouse Na verdade, é difícil apontar no momento, uma metodologia consolidada eamplamente aceita para o desenvolvimento de Data Warehouses. O que se vê na literatura enas histórias de sucesso de implementações em empresas, são propostas no sentido deconstruir um modelo dimensional a partir do modelo de dados corporativo ou departamental(base dos bancos de dados operacionais da empresa), de forma incremental. De fato, um DataWarehouse é construído de uma maneira "heurística", confirmando a estratégia evolucionáriadiscutida no item anterior. De qualquer forma, a metodologia a ser adotada é ainda bastante dependente daabordagem escolhida, em termos de ambiente, distribuição, etc. A seguir, apresentamos, atítulo de exemplo, as etapas sugeridas para um desenvolvimento do tipo estrela. Desenvolver um Data Warehouse é uma questão de casar as necessidades dos seususuários com a realidade dos dados disponíveis. Abaixo podemos analisar um conjunto denove pontos fundamentais no projeto da estrutura de um Data Warehouse. São os seguintes oschamados pontos de decisão, que constituem definições a serem feitas e correspondem, defato, a etapas do projeto: • Os processos, e por conseqüência, a identidade das tabelas de fatos; • A granularidade de cada tabela de fatos; • As dimensões de cada tabela de fatos; • Aos fatos, incluindo fatos pré-calculados; • Os atributos das dimensões; • Como acompanhar mudanças graduais em dimensões; • As agregações, dimensões heterogêneas, minidimensões e outras decisões de projeto físico; • Duração histórica do banco de dados; • A urgência com que se dá a extração e carga para o Data Warehouse. Recomenda-se que estas definições se façam na ordem acima. Esta metodologia seguea linha topdown, pois começa identificando os grandes processos da empresa. Como exemplo, temos os processos de uma empresa revendedora de produtos: planosde estoque, ordens de compra, inventário, pedidos de clientes, expedição de pedidos, créditos,etc. Quando os processos estiverem identificados, cria-se uma ou mais tabelas de fatos a partirde cada um deles.
    • Neste ponto é necessário então decidir o a um fato individual naquela tabela (esta é agranularidade da tabela). Exemplos de granularidade são: uma linha sobre um produto, umperfil de venda diário do produto, ou um perfil de venda mensal do produto. Após definir agranularidade da tabela de fatos, o próximo passo é definir as dimensões e suasgranularidades. Neste exemplo, considera-se a tabela de fatos vendas acumuladas do produto.Uma vez definida a granularidade, as dimensões e suas respectivas granularidades podem seridentificadas. Assim, as dimensões tempo, produto e vendedor são criadas, além de outrasdimensões descritivas como local-de-expedição, local-derecebimento, modo-de-envio. Aadição destas dimensões descritivas não altera o número de instâncias na tabela de fatos. A Figura 20 mostra a tabela de fatos com as dimensões identificadas. Cada dimensão pode ser vista como um ponto de entrada para a tabela de fatos. Aescolha das dimensões é o ponto chave no projeto. O passo seguinte consiste em detalhartodos as medidas que constarão da tabela de fatos e finalmente completar as tabelas dedimensões. Neste instante, tem-se a estrutura do projeto lógico completa. A partir de então, passa-se a trabalhar questões relativas ao projeto físico, avaliandomudanças graduais em dimensões e discutindo-se a inclusão de agregações, minidimensões edimensões heterogêneas.Figura 20 - A tabela de fatos e suas dimensões.5.6 – Relacional versus multidimensional Bancos de dados relacionais encontram em sua flexibilidade e potencial para consultasad-hoc, um de seus pontos fortes. Bancos de dados relacionais são sabidamente mais flexíveisquando são usados com uma estrutura de dados normalizada. Uma típica consulta OLAP, noentanto, "atravessa" diversas relações e requer diversas operações de junção para reunir estes
    • dados. O desempenho dos sistemas de banco de dados relacionais tradicionais é melhor paraconsultas baseadas em chaves do que consultas baseadas em conteúdo. Para atender os requisitos deste tipo de transações, fornecedores de SGBDs relacionaistêm adicionado funcionalidades a seus produtos. Estas funcionalidades incluem extensões àsestruturas de armazenamento e aos operadores relacionais e esquemas de indexaçãoespecializados. Estas técnicas podem melhorar o desempenho para recuperações por conteúdoatravés da pré-junção de tabelas usando índices ou pelo uso de listas de índices totalmenteinvertidas. A maioria das ferramentas de acesso a Data Warehouses explora a naturezamultidimensional dos dados. Por isso, estruturar os dados em bancos de dados relacionaistradicionais em esquemas do tipo estrela ou floco de neve tornou-se uma abordagem bastantecomum. Estes esquemas podem usar múltiplas tabelas e ponteiros para simular uma estruturamultidimensional. Também é possível usar algum outro mecanismo não relacional paraarmazenar algumas das agregações pré-calculadas enquanto outras são obtidasdinamicamente. Esta abordagem goza dos benefícios de um mecanismorelacional, tirando vantagem do cálculo prévio de algumas agregações. Normalmente a tabelacentral de fatos é bem grande enquanto as das demais dimensões são bem menores. Por sua vez, bancos de dados multidimensionais permitem manipular diretamenteobjetos multidimensionais. As dimensões são identificadas ao criar a estrutura do banco, deforma que adicionar uma nova dimensão pode ser trabalhoso. Alguns bancosmultidimensionais requerem uma completa recarga do banco quando uma reestruturaçãoocorre. Portanto, são mais recomendados para ambientes mais estáveis onde os requisitossobre os dados não estejam em constante mudança.5.6.1 - Um ou mais bancos Embora se discuta o banco de dados de um Data Warehouse como se fosse um únicorepositório de dados, em grande parte dos casos isto não acontece. Na verdade, os dadospodem estar distribuídos por múltiplos bancos de dados, inclusive sob diferentes sistemas degerenciamento de banco de dados. Bancos de dados multidimensionais fornecem uma visãoespecífica dos dados da empresa. Cada área pode, no entanto, requerer que a organização dos dados segundo um arraymultidimensional seja ditada pela sua visão do negócio, atendendo a suas necessidades. É
    • muito pouco provável que o mesmo projeto de banco de dados multidimensional atendaigualmente bem a questões de tomada de decisão das diversas áreas da empresa. Neste caso,um sistema de banco de dados relacional é usualmente mais adequado para gerenciar umbanco de dados integrado, provendo uma estrutura mais neutra com relação às necessidadesde cada área. Uma solução freqüentemente encontrada é a separação do gerenciamento dos dadosentre o Data Warehouse relacional integrado da empresa e os seus data marts satélitesmultidimensionais. Esta alternativa introduz a necessidade de uma estratégia de distribuiçãode dados que coordene a alimentação de novos dados aos bancos multidimensionais. Umasolução semelhante é adotada no caso em que o Data Warehouse possui diferentes níveis dedetalhe: a camada atômica, de maior nível de detalhe, é mantida em formato relacional,enquanto a camada contendo dados resumidos, pode ser mantida em formatomultidimensional.
    • CAP. 6 – CARREGANDO O DATA WAREHOUSE A extração, limpeza, transformação e migração de dados dos sistemas existentes naempresa para o Data Warehouse constituem tarefas críticas para o seu funcionamento efetivoe eficiente. Diversas técnicas e abordagens têm sido propostas, algumas bastante genéricas eoutras especialmente voltadas para a manutenção de integridade dos dados num ambientecaracterizado pela derivação e replicação de informações. Os produtos oferecidos no mercado procuram automatizar processos que teriam de serfeitos manualmente ou utilizando ambientes de programação de mais baixo nível. De fato,não existe uma ferramenta única capaz de oferecer suporte aos processos de extração,limpeza, transformação e migração dos dados: diferentes ferramentas especializam-se emquestões específicas. O grande desafio por trás da alimentação de dados das fontes para o Data Warehousenão é técnico, mas gerencial. Muitos dos processos envolvidos - como mapeamento,integração e avaliação de qualidade - ocorrem de fato durante a fase de análise e projeto doData Warehouse. Especialistas afirmam que identificar fontes, definir regras detransformação e detectar e resolver questões de qualidade e integração consomem cerca de 80% do tempo de projeto. Infelizmente, não é fácil automatizar estas tarefas. Embora algumasferramentas possam ajudar a detectar problemas na qualidade dos dados e gerar programas deextração, a maioria das informações necessária para desenvolver regras de mapeamento etransformação existe apenas na cabeça dos analistas e usuários. Fatores que certamente influem na estimativa de tempo para estas tarefas são onúmero de fontes e a qualidade dos metadados mantidos sobre estas fontes. As regras denegócio associadas a cada fonte - tais como validação de domínios, regras de derivação edependências entre elementos de dados – são outra fonte de preocupações. Se estas regrastiverem de ser extraídas do código fonte das aplicações, o tempo para mapeamento eintegração pode dobrar.6.1 – Extração As várias alternativas para extração permitem balancear desempenho, restrições detempo e de armazenamento. Por exemplo, se a fonte for um banco de dados on-line, pode-sesubmeter uma consulta diretamente ao banco para criar os arquivos de extração. Odesempenho das aplicações ligadas às fontes pode cair consideravelmente se transações on-
    • line e as consultas para extração competirem entre si. Uma solução alternativa é criar umacópia corrente dos dados das fontes a partir da qual se fará então a extração. Comodesvantagem desta solução, podemos citar o espaço adicional de disco necessário paraarmazenar a cópia. Outra alternativa é examinar o ciclo de processamento de algumas transações off-lineque atuem nas fontes. Os programas que criam os arquivos de extração para a carga do DataWarehouse podem ser incorporados a um ponto apropriado deste esquema de processamento. As rotinas de extração devem ser capazes de isolar somente aqueles dados que foraminseridos e atualizados desde a última extração, este processo é conhecido como refresh. Amelhor política de refresh deve ser avaliada pelo administrador do Data Warehouse, que develevar em conta características como as necessidades dos usuários finais, tráfego na rede eperíodos de menor sobrecarga, tanto das origens dos dados quanto do Data Warehouse, deve-se considerar que os períodos de sobrecarga podem variar para cada origem de dados[DAL99].6.2 – Transformação e filtros Uma vez que os dados são extraídos e colocados na área de trabalho temporária, estesdevem passar por uma série de tratamentos. O primeiro destes tratamentos refere-se a limpezaou filtragem dos dados onde o objetivo é garantir a integridade dos dados através deprogramas ou rotinas especiais que tentam identificar anomalias e resolvê-las, deixando osdados em um estado consistente antes de serem instalados no Data Warehouse. A correção deerros de digitação, a descoberta de violações de integridade, a substituição de caracteresdesconhecidos, a padronização de abreviações, podem ser exemplos de limpeza de dados. O segundo passo é colocar os dados em uma forma homogênea aplicando umametodologia de comparação de representações, que inclua os critérios a serem utilizados naidentificação de semelhanças e conflitos de modelagem. Conflitos de modelagem podem serdivididos em: semânticos e estruturais. Conflitos semânticos são todos aqueles envolvendo onome ou palavra associado às estruturas de modelagem, por exemplo, mesmo nome paradiferentes entidades ou diferentes nomes para a mesma entidade. Conflitos estruturaisenglobam os conflitos relativos às estruturas de modelagem escolhidas, tanto no nível deestrutura propriamente dito como no nível de domínios. Os principais tipos de conflitos
    • estruturais são os conflitos de domínio de atributo que se caracterizam pelo uso de diferentestipos de dados para os mesmos campos. Conflitos típicos de domínio de atributo são: • Diferenças de unidades: quando as unidades utilizadas diferem, embora forneçam a mesma informação (como distância em metros ou quilômetros); • Diferenças de precisão: quando a precisão escolhida varia de um ambiente para outro (como quando o custo do produto é armazenado com duas posições ou com seis posições decimais); • Diferenças em códigos ou expressões: quando o código utilizado difere um do outro (como no caso de sexo representado por M ou F e por 1 e 2); • Diferenças de granularidade: quando os critérios associados a uma informação, embora utilizando uma mesma unidade, são distintos (como quando horas trabalhadas) correspondem às horas trabalhadas na semana ou às horas trabalhadas no mês; • Diferenças de abstração: quando a forma de estruturar uma mesma informação segue critérios diferentes (como com endereço armazenado em um atributo único, ou subdividido em rua e complemento). Depois de identificados os conflitos de modelagem, deve-se criar as regras demapeamento de representações equivalentes e de conversão para os padrões estabelecidospelo Data Warehouse [DAL99].6.3 - Derivação e Sumarização Diferentes alternativas também existem para prover suporte a dados. Uma abordagemé derivar os dados durante o processo de carga e armazená-los no ambiente relacionalcorporativo. Uma alternativa é fazer a derivação quando o servidor de replicação distribui osdados para os Data Warehouses. Ou então, derivar os dados "on-the-fly" quando o usuáriosubmeter uma consulta ou lançar uma simulação.
    • CAP. 7 – EXTRAINDO INFORMAÇÕES DO DATA WAREHOUSE Existem várias maneiras de recuperar informações de um Data Warehouse, as formasde extração mais comuns no mercado hoje são: • Ferramentas de consulta e emissão de relatórios; • EIS (Executive Information Systems); • Ferramentas OLAP; • Ferramentas Data Mining. A nova tendência dessas soluções é a integração com o ambiente Web, permitindomaior agilidade em consultas estáticas e dinâmicas.Nesta monografia veremos de forma básica e separadamente os conceitos das tecnologiasOLAP e Data Mining. A diferença básica entre ferramentas OLAP e Data Mining está namaneira como a exploração dos dados é abordada. Com ferramentas OLAP a exploração éfeita na base da verificação, isto é, o analista conhece a questão, elabora uma hipótese e utilizaa ferramenta para confirmá-la. Com Data Mining, a questão é total ou parcialmentedesconhecida e a ferramenta é utilizada para a busca de conhecimento.7.1 - Ferramentas OLAP OLAP (On-Line Analytical Processing) representa um conjunto de tecnologiasprojetadas para suportar análise e consultas ad hoc. Sistemas OLAP ajudam analistas eexecutivos a sintetizarem informações sobre a empresa, através de comparações, visõespersonalizadas, análise histórica e projeção de dados em vários cenários de "e se...". SistemasOLAP são implementados para ambientes multi-usuário, arquitetura cliente-servidor eoferecem respostas rápidas e consistentes às consultas iterativas executadas pelos analistas,independente do tamanho e complexidade do banco de dados. A característica principal dos sistemas OLAP é permitir uma visão conceitual multi-dimensional dos dados de uma empresa. A visão multi-dimensional é muito mais útil para osanalistas do que a tradicional visão tabular utilizada nos sistemas de processamento detransação. Ela é mais natural, fácil e intuitiva, permitindo a visão em diferentes perspectivasdos negócios da empresa e desta maneira tornando o analista um explorador da informação[BIS99]. A modelagem dimensional é a técnica utilizada para se ter uma visão multi-dimensional dos dados.
    • Nesta técnica os dados são modelados em uma estrutura dimensional conhecida porcubo. 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 interseção das dimensõesé chamada de medida e geralmente representa dados numéricos tais como "unidadesvendidas", "lucro" e "total de venda". Além dos componentes dimensão e medida outroimportante aspecto do modelo multidimensional é a consolidação dos dados uma vez que paraa tarefa de análise são mais úteis e significativas as agregações (ou sumarização) dos valoresindicativas dos negócios. A expressão Decision Cube refere-se a um conjunto de componentes de suporte àdecisão, que podem ser utilizados para cruzar tabelas de um banco de dados, gerando diversasvisões através de planilhas ou gráficos. Envolve o cálculo, quando da carga do DataWarehouse, de dados que o usuário virá a solicitar, mas que podem ser derivados de outrosdados. Quando o usuário solicita os dados, estes já estão devidamente calculados, agregadosem um Cubo de Decisões [DAL99]. Além da visão multi-dimensional dos dados da empresa, outras importantescaracterísticas dos sistemas OLAP são: • Análise de tendências. A tecnologia OLAP é mais do que uma forma de visualizar a história dos dados. Deve, também, ajudar os usuários a tomar decisões sobre o futuro, permitindo a construção de cenários ("e se...") a partir de suposições e fórmulas aplicadas, pelos analistas, aos dados históricos disponíveis; • Busca automática (reach-through) de dados mais detalhados que não estão disponíveis no servidor OLAP. Detalhes não são normalmente importantes na tarefa de análise, mas quando necessários, o servidor OLAP deve ser capaz de buscá-los; • Dimensionalidade genérica; • Operação trans-dimensional. Possibilidade de fazer cálculos e manipulação de dados através diferentes dimensões; • Possibilidade de ver os dados de diferentes pontos de vista (slice and dice), mediante a rotação (pivoting) do cubo e a navegação (drill-up/drill-down) entre os níveis de agregação; • Conjunto de funções de análise e cálculos não triviais com os dados.
    • Existe também um conjunto de 12 regras que servem para avaliar as ferramentasOLAP conforme [BIS99]:1. Visão conceitual multidimensional2. Transparência3. Acessibilidade4. Desempenho consistente de fornecimento de informações5. Arquitetura cliente/servidor6. Dimensionalidade genérica7. Manipulação dinâmica da matriz esparsa8. Suporte multiusuário9. Operações irrestritas com dimensões cruzadas10. Manipulação intuitiva dos dados11. Relatórios flexíveis12. Dimensões e níveis de agregação ilimitados Uma arquitetura OLAP possui três componentes principais: um modelo de negóciospara análises interativas, implementado numa linguagem gráfica que permita diversas visões eníveis de detalhes dos dados; um motor OLAP para processar consultas multidimensionaiscontra o dado-alvo; e um mecanismo para armazenar os dados a serem analisados. A base dedados usada define se o pacote é um ROLAP, que interfaceia com um banco de dadosrelacional de mercado, ou um MOLAP, que se liga a um servidor OLAP, através de um bancode dados multidimensional e dedicado [DAL99].7.1.1 - MOLAP x ROLAP Multidimensional OLAP (MOLAP) é uma classe de sistemas que permite a execuçãode análises sofisticadas usando como gerenciador de dados um banco de dadosmultidimensional. Em um banco de dados MOLAP os dados são mantidos em arranjos eindexados de maneira a prover uma ótima performance no acesso a qualquer elemento. Oindexamento, a antecipação da maneira como os dados serão acessados e o alto grau deagregação dos dados fazem com que sistemas MOLAP tenham uma excelente performance.Além de serem rápidos, outra grande vantagem destes sistemas é o rico e complexo conjuntode funções de análise que oferecem.
    • A maneira de se implementar os arranjos de dados pode variar entre fornecedores desoluções MOLAP. Existem as arquiteturas hiper-cubos e multi-cubos. Na arquitetura hiper-cubo existe um único cubo onde cada medida é referenciada por todas as outras dimensões.Por exemplo, um cubo onde a medida "vendas" é referenciada pelas dimensões "produto","ano", "mês", "estado" e "cidade". Além da dificuldade em visualizar tal "cubo" (com cincodimensões!). Outros problemas desta abordagem são a maior necessidade de espaço em discoe a existência de um mecanismo para controlar a esparsidade dos dados que ocorre quandonão existe uma medida na interseção das dimensões. Por exemplo, quando um produto não évendido em determinado estado. A grande vantagem é a consistência no tempo de respostaque é independente do número de dimensões envolvidas na consulta. Na arquitetura multi-cubos uma medida é referenciada por dimensões selecionadas.Em um cubo, a medida "vendas" é referenciada pelas dimensões "semestre", "estado" e"produto" e em outro cubo, a medida "custo" é referenciada pelas dimensões "mês" e"departamento". Esta arquitetura é escalável e utiliza menos espaço em disco. A performanceé melhor em cada cubo individualmente, no entanto, consultas que requerem acesso a mais deum cubo podem exigir processamentos complexos para garantir a consistência do tempo deresposta. Sistemas ROLAP fornecem análise multidimensional de dados armazenados em umabase de dados relacional. Atualmente existem duas maneiras de se fazer este trabalho: fazertodo o processamento dos dados no servidor da base de dados. O servidor OLAP gera oscomandos SQL em múltiplos passos e as tabelas temporárias necessárias para oprocessamento das consultas; ou executar comandos SQL para recuperar os dados, mas fazertodo o processamento (incluindo joins e agregações) no servidor OLAP.Além das características básicas de sistemas OLAP, servidores ROLAP devem também:utilizar metadados para descrever o modelo dos dados e para auxiliar na construção dasconsultas. Desta maneira um analista pode executar suas análises utilizando seus própriostermos; e criar comandos SQL otimizados para os bancos de dados com o qual trabalha. A principal vantagem de se adotar uma solução ROLAP reside na utilização de umatecnologia estabelecida, de arquitetura aberta e padronizada como é a relacional,beneficiando-se da diversidade de plataformas, escalabilidade e paralelismo de hardware(SMP e MPP).
    • 7.2 - Ferramentas Data Mining Nos primórdios do Data Warehouse, Data Mining era visto como um subconjunto dasatividades associadas com o Data Warehouse. Mas atualmente os caminhos do DataWarehouse e do Data Mining estão divergindo. Enquanto o warehouse pode ser uma boafonte de dados para minerar, o Data Mining foi reconhecido como uma tarefa genuína, e nãomais como uma colônia do warehouse [PAR99]. Apesar de o termo Data Mining ter se tornado bastante popular nos últimos anos,existe ainda certa confusão quanto à sua definição. Data Mining (ou mineração de dados) é oprocesso de extrair informação válida, previamente desconhecida e de máxima abrangência apartir de grandes bases de dados, usando-as para efetuar decisões cruciais. Data Mining vaimuito além da simples consulta a uma banco de dados, no sentido de que permite aos usuáriosexplorar e inferir informação útil a partir dos dados, descobrindo relacionamentos escondidosno banco de dados. Pode ser considerada uma forma de descobrimento de conhecimento embancos de dados KDD (Knowledge Discovery in Databases), área de pesquisa de bastanteevidência no momento, envolvendo Inteligência Artificial e Banco de Dados. Um ambiente de apoio à tomada de decisões, integrando técnicas de Data Miningsobre um ambiente de Data Warehousing, possibilita um grande número de aplicações, que jávêm sendo implementadas em diversos segmentos de negócios, como manufatura, automaçãode pedido de remessas, varejo, gerenciamento de inventários, financeiro, análise de risco,transporte, gerenciamento de frotas, telecomunicação, análise de chamadas, saúde, analise deresultados, markenting, estabelecimento do perfil dos consumidores, seguros, detecção defraude, dentre outros [PIN99].Data Mining pode ser utilizado com os seguintes objetivos: • Explanatório: explicar algum evento ou medida observada, tal como porque a venda de sorvetes caiu no Rio de Janeiro; • Confirmatório: confirmar uma hipótese. Uma companhia de seguros , por exemplo, pode querer examinar os registros de seus clientes para determinar se famílias de duas rendas tem mais probabilidade de adquirir um plano de saúde do que famílias de uma renda; • Exploratório: analisar os dados buscando relacionamentos novos e não previstos. Uma companhia de cartão de crédito pode analisar seus registros históricos para determinar que fatores estejam associados a pessoas que representam risco para créditos.
    • Quando determinados padrões de comportamento, como associação de produtosdurante um processo de compras, por exemplo, começam a se repetir com freqüência, asferramentas Data Mining indicam a presença de oportunidades e "insights" em relação àquelepúblico consumidor. O diferencial do Data Mining está no fato de que as descobertas depadrões de consumo se dão por uma lógica de algoritmos com base em uma rede neural deraciocínios. São ferramentas de descobertas matemáticas feitas sobre os registros corporativosjá processados contra descobertas empíricas [POL99].
    • CONCLUSÃO Para concluir, vale dizer que o desenvolvimento de um Data Warehouse constitui umavanço em relação as metodologias anteriores, pois apresenta uma sistemática maisapropriada baseada na realidade dos sistemas existentes nas empresas. Essa metodologiatambém valoriza a experiência da equipe no desenvolvimento de sistemas transacionais, poisas fases que a compõem já são largamente utilizadas no desenvolvimento dos mesmos.Também é importante que a metodologia seja suportada por uma ferramenta dedesenvolvimento que aumente a produtividade, simplificando e automatizando tarefascomplexas no processo de data warehousing. Isto evidencia algumas questões que merecemuma avaliação mais aprofundada. É o caso da metodologia. Considerando diferentesarquiteturas de data warehouse e a exploração detalhada dos níveis conceitual e lógico. Os processos de extração, filtragem, carga e recuperação dos dados são bastantecomplexos, exigindo que pessoas altamente capacitadas façam parte do projeto para que osobjetivos sejam atingidos no menor espaço de tempo possível e sem gastos de recursosdesnecessários. Como o Data Warehouse não é um sistema ou programa, mas sim um ambiente quenecessita ser adaptado as necessidades das empresas é normal que cada ambiente de DataWarehouse possua características próprias, inviabilizando seu uso para outros objetivos quenão os descritos no início do projeto. Para a informática o ambiente de Data Warehouse mostrou ser um desafio aosprocessos que normalmente são utilizados para desenvolver um software. Um dos desafios éconseguir modelar os dados de maneira que todas as informações estejam disponíveis deforma clara e rápida para os usuários que a estão requisitando, outro desafio é disponibilizaras informações sobre os dados (metadados), para que os usuários possam saber quaisinformações estão disponíveis. Também pode ser considerado um desafio aos profissionais de informática a melhormaneira de extração dos dados do Data Warehouse, de forma que ele realmente se torne umsistema de apoio a decisão. As duas maneiras estudadas neste trabalho foram a analise multidimensional atravésdo OLAP e o Data Mining. OLAP fornece para organizações um método de acessar, visualizar, e analisar dadoscorporativos com alta flexibilidade e performance. No mundo globalizado de hoje as
    • empresas estão enfrentando maior concorrência e expandindo sua atuação para novosmercados. Portanto, a velocidade com que executivos obtêm informações e tomam decisõesdetermina a competitividade de uma empresa e seu sucesso de longo prazo. OLAP apresentainformações para usuários via um modelo de dados natural e intuitivo. Através de um simplesestilo de navegação e pesquisa, usuários finais podem rapidamente analisar inúmeroscenários, gerar relatórios "ad-hoc", e descobrir tendências e fatos relevantes independente dotamanho, complexidade, e fonte dos dados corporativos. De fato, colocar informação embancos dados corporativos sempre foi mais fácil do que retirá-los. Quanto maior e complexa ainformação armazenada, mais difícil é para retirá-la. A tecnologia OLAP acaba com estasdificuldades levando a informação mais próxima ao usuário que dela necessite. Portanto, oOLAP é freqüentemente utilizado para integrar e disponibilizar informações gerenciaiscontidas em bases de dados operacionais, sistemas ERP e CRM, sistemas contábeis, e DataWarehouses. Estas características tornaram-no uma tecnologia essencial em diversos tipos deaplicações de suporte à decisão e sistemas para executivos. Sobre a ferramenta de Data Mining, obviamente, ainda há muito a se falar sobre oassunto (clustering, redes neurais, métodos genéticos, mineração em textos, roll up/drill down.etc), mas é importante notar que em praticamente todos esses casos o que se deseja édescobrir padrões em volumes de dados. É importante ressaltar também que o Data Miningnão é o final da atividade de descoberta de conhecimentos, mas é tão somente o início. Éimprescindível (ao menos com a tecnologia atual) dispor de analistas capacitados que saibaminteragir com os sistemas de forma a conduzí-los para uma extração de padões úteis erelevantes. A diferença básica entre ferramentas OLAP e Data Mining está na maneira como aexploração dos dados é abordada. Com as ferramentas OLAP a exploração é feita na base daverificação, isto é, o analista conhece a questão, elabora uma hipótese e utiliza a ferramentapara confirmá-la. Com Data Mining, a questão é total ou parcialmente desconhecida e aferramenta é utilizada para a busca de conhecimento. Por fim, é importante destacar que este trabalho contribuiu muito para a ampliação dosconhecimentos do autor em relação aos ambientes de suporte a decisão. O que com certezapoderá ser aplicado na sua futura vida profissional.
    • BIBLIOGRAFIA[BIS99] BISPO, Carlos Alberto F. & CAZARINI, Edson Walmir. Análises sofisticadas com oOn-Line Analytical Processing. Developer’s Magazine, São Paulo, n.32, p.28-31, abril de1999.[INM97] INMON, William H.. Como construir o Data Warehouse. 2ª ed. New York:Editora Campus, 1997.[PER99] PEREIRA, Max Roberto. Data Warehouse: otimizando seudesempenho.Developer’s Magazine, São Paulo, n.32, p.22-26, abr de 1999.[PIN99] PINHEIRO, Carlos André Reis. Data Mining: obtendo vantagens com seu DataWarehouse.[HAISTEN99], M. Real time data warehouse: the next stage in data warehouse evolution, part1. DM Review, June 1999.[KIMBALL98], R. Data Warehouse Toolkit. São Paulo: Makron Books, 1998.