MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO SECRETARIA DE CIÊNCIA E TECNOLOGIA INSTITUTO MILITAR DE ENGENHARIA

Transcrição

1 MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO SECRETARIA DE CIÊNCIA E TECNOLOGIA INSTITUTO MILITAR DE ENGENHARIA (Real Academia de Artilharia, Fortificação e Desenho, 1792) DISSERTAÇÃO DE MESTRADO USO DE METADADOS NO SUPORTE À TRANSFORMAÇÃO E LINHAGEM DE DADOS EM AMBIENTES DE WAREHOUSING AURISAN SOUZA DE SANTANA Rio de Janeiro Junho de 2003

2 INSTITUTO MILITAR DE ENGENHARIA AURISAN SOUZA DE SANTANA USO DE METADADOS NO SUPORTE À TRANSFORMAÇÃO E LINHAGEM DE DADOS EM AMBIENTES DE WAREHOUSING Dissertação de Mestrado apresentada ao Curso de Mestrado em Sistemas e Computação do Instituto Militar de Engenharia, como requisito parcial para a obtenção do título de Mestre em Ciências em Sistemas e Computação. Orientadora: Profª Ana Maria de Carvalho Moura Dr. Ing. Rio de Janeiro

3 C2003 INSTITUTO MILITAR DE ENGENHARIA Praça General Tibúrcio, 80 Praia Vermelha Rio de Janeiro RJ CEP: Este exemplar é de propriedade do Instituto Militar de Engenharia, que poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar qualquer forma de arquivamento. É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja ou venha a ser ficado, para pesquisa acadêmica, comentários e citações, desde que sem a finalidade comercial e que seja feita a referência bibliográfica completa. Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es) e do(s) orientador(es). SC01108 Santana, Aurisan Souza de Uso de Metadados no Suporte à Transformação e Linhagem de Dados em Ambientes de Warehousing /Aurisan Souza de Santana Rio de Janeiro, p.: il. Dissertação (mestrado) Instituto Militar de Engenharia, Formação. 2

4 Folha de Rosto 3

5 Aos meus pais Dona Val e a Dr. Delrio por me amarem. À Ricamar, Riocemar, Pedro Henrique e Angélica, pessoas essenciais na minha vida. 4

6 AGRADECIMENTOS Agradeço a DEUS, fonte de toda a vida, pela realização de mais um sonho. À minha família, especialmente à minha mãe, sem a qual está vitória não seria alcançada. Ao Exército Brasileiro e ao Instituto Militar de Engenharia, em particular, pela excelência dos ensinamentos proporcionados. À minha orientadora, Profª Ana Maria de Carvalho Moura, pela dedicação, paciência e valiosos ensinamentos fornecidos. Às Professoras Maria Luiza de Machado Campos e Karin Becker, pela gentileza em compor a Banca Avaliadora, e pelos enriquecedores comentários. Aos meus amigos, colegas e mestres que ao longo de minha vida, contribuíram, direta ou indiretamente, em minha formação profissional. 5

7 Se clamares por conhecimento, e por inteligência alçares a tua voz, assim como buscas a prata e os tesouros escondidos, então entenderás o temor do SENHOR, e acharás o conhecimento de DEUS. Provérbios,

8 RESUMO Sistemas de Data Warehouse são uma prática adotada no âmbito corporativo em função de tais sistemas responderem a questões estratégicas de negócio, que visam a tomada de decisão. Neste contexto, a gerência de metadados torna-se um fator crucial para o sucesso de projetos de Data Warehouse. Sua implementação, quando realizada no âmbito de um padrão de metadados, viabiliza a interoperabilidade de dados e metadados neste ambiente, caracterizado sobretudo pela forte heterogeneidade de fontes de dados. A implementação de mecanismos de linhagem de dados e metadados melhora a qualidade na geração da informação, pois é possível conhecer todo o processo de extração, transformação e carga dos dados. Este trabalho apresenta o conceito de linhagem de dados, formaliza o processo de linhagem de metadados propondo para isso algoritmos de linhagem de metadados e linhagem de dados para hipercubos, implementados sob um esquema estrela. Todo o trabalho é realizado no contexto de um padrão de metadados, o Common Warehouse Metamodel (CWM). De modo a consolidar este estudo foi desenvolvida uma ferramenta que implementa tais funcionalidades. 7

9 ABSTRACT Data Warehouse (DW) systems represent a technology usually adopted in a corporative environment, as these systems answer for strategic business issues, which aim at decision support. In this context metadata management turns out to be a crucial issue of success in DW projects. Its implementation, when achieved using a metadata standard, enables data and metadata interoperability in a DW environment, which is strongly characterized by data sources heterogeneity. The implementation of data and metadata lineage mechanisms improves the information generation quality, as it makes it possible to know all the steps of data extraction, transformation and load processes. This work presents data lineage concepts, formalizes metadata lineage process and proposes data and metadata lineage algorithms applied for cubes under the star schema. The work is implemented using a metadata standard, the common Warehouse Metamodel (CWM). In order to consolidate this study we developed a tool that implements such functionalities. 8

10 SUMÁRIO LISTA DE ILUSTRAÇÕES LISTA DE TABELAS INTRODUÇÃO Posicionamento Justificativa para o Trabalho Objetivo do Trabalho Organização da Dissertação PROCESSOS DE EXTRAÇÃO, TRANSFORMAÇÃO E CARGA Processo ETL Higienização de Dados Ferramentas ETL Oracle9i Warehouse Builder (OWB) SAS/Warehouse Administrator Microsoft Data Transformation Service (DTS) Estudo Comparativo de Ferramentas ETL ETL como um Ambiente de Workflow Considerações Finais GERÊNCIA DE METADADOS NO AMBIENTE DE WAREHOUSING Metadados: Conceituação Áreas de Aplicação de Metadados Benefícios do Uso de Metadados Classificação de Metadados Critério tipo Critério níveis de abstração Critério visão do usuário Critério origem Critério proposta Critério tempo de produção/consumo Requisitos para Gerência de Soluções de Metadados

11 3.6 Padrões de Metadados para Data Warehouse Common Warehouse Metamodel (CWM) Padrões para o CWM Arquitetura do CWM Escopo do CWM Pacotes do CWM para Representação de Transformações e Linhagem de Dados Considerações Finais LINHAGEM DE DADOS E METADADOS EM AMBIENTES DE WAREHOUSING Qualidade em Data Warehouse Linhagem de Dados Derivação de Tuplas de Visões Transformações e Linhagem de Dados Transformações Linhagem de Dados Classes de Transformação Extensão do Metamodelo CWM para Linhagem de Dados Linhagem de Metadados ou Linhagem de Dados Vertical Conceituação Considerações Finais DESENVOLVIMENTO DA FERRAMENTA DE TRANSFORMAÇÃO E LINHAGEM Arquitetura do Sistema Relação entre os Pacotes Diagrama de Use Cases (Casos de Uso) Ferramenta Módulo de Cadastro Módulo de Processos ETL Módulo de Linhagem de Dados e Metadados Módulo de Interoperabilidade e Visualização de Indicadores Considerações Finais

12 6. ESTUDO DE CASO Cenário de Aplicação Módulo de Cadastro Módulo de Processos ETL Módulo de Linhagem de Dados e Metadados Módulo de Interoperabilidade Considerações Finais CONCLUSÃO Considerações Gerais Contribuições Sugestões para Trabalhos Futuros REFERÊNCIAS BIBLIOGRÁFICAS ANEXOS ANEXO ANEXO ANEXO ANEXO

13 LISTA DE ILUSTRAÇÕES FIG 2.1 Warehousing e Processos ETL FIG 2.2 Módulo de Interoperabilidade do OWB FIG. 2.3 Mapeamento de Campos no DTS FIG. 2.4 Cenário de um Fluxo de Dados no DTS FIG. 2.5 Diagrama de Linhagem de Metadados no OWB FIG. 2.6 Um Workflow para o processo ETL FIG. 3.1 Dado, informação e conhecimento extraído de (Tannenbaum, 2002) FIG. 3.2 Classificação Tridimensional do DW extraído de (DO e RAHM, 2000) FIG. 3.3 Gerência de Metadados em DW FIG. 3.4 CWM organizado em níveis funcionais (OMG, 2000) FIG. 3.5 Metamodelo Relacional para Tabelas, Colunas e Tipos de Dados (OMG, 2000). 61 FIG. 3.6 Árvore de Expressão CWM para a fórmula E=mc 2 (OMG, 2000) FIG. 3.7 Metamodelo de Expressões FIG. 3.8 Metamodelo de Transformações FIG. 3.9 Metamodelo OLAP FIG. 4.1 Derivação da Tupla t FIG. 4.2 Derivação de Tupla por Agregação FIG. 4.3 Grafo de Transformações FIG. 4.4 Classes de Transformação FIG. 4.5 Algoritmo de Linhagem para Transformações Tipo Despachante FIG. 4.6 Algoritmo de Linhagem para Agregadores Livres de Contexto FIG Algoritmo de linhagem de dados para hipercubos FIG. 4.8 Extensão do CWM para suportar mecanismos de linhagem FIG. 4.9 Níveis de Abstração: Dados e Metadados FIG Algoritmo para Geração de Linhagem de Metadados FIG. 5.1 Relação dos Metadados do DW com os Metamodelos do CWM FIG. 5.2 Relacionamento das Transformações com o Expression Metamodel FIG. 5.3 Dependências entre os Pacotes do CWM e extensão FIG Metamodelo Integrado FIG. 5.5 Diagrama de Casos de Uso FIG. 5.6 Tela de Cadastro de Esquema

14 FIG. 5.7 Tela de Cadastro de Tabelas FIG. 5.8 Diagrama de Seqüência para Instanciação do Relational Package FIG. 5.9 Atividades, Passos, Tarefas e Transformações, extraído de (OMG, 2000) FIG Tela de criação de tarefas FIG Tela de Transformações de Dados FIG Diagrama de Seqüência para Instanciação do Transformation Package FIG Tela de Cadastro de cubos para a execução de linhagem de dados FIG Tela de Linhagem de Dados para Cubos FIG Linhagem de Metadados no nível de granularidade de tabela FIG Tela de Detalhamento de Transformação FIG. 6.1 Esquema Estrela do DW do Cliente ACME FIG. 6.2 Telas de Cadastro de Tabelas FIG. 6.3 Tela de Cadastro de Colunas FIG. 6.4 Tela de Transformações e Visualização de expressões FIG. 6.5 Linhagem de Metadados: Nível de Tabelas FIG. 6.6 Linhagem de Metadados: Nível de Atributos FIG. 6.7 Tela de Cadastro de Agregadores (KPAggregator) FIG. 6.8 Linhagem de dados para agregadores KPAggregators FIG. 6.9 Tela de Indicadores de Transformações FIG Interoperabilidade de metadados no CWM

15 LISTA DE TABELAS TAB 2.1 Classificação de Problemas de Qualidade de Dados TAB 2.2 Quadro Comparativo de Ferramentas ETL TAB 3.1 Arquitetura de 4 níveis MOF TAB 3.2 Áreas funcionais do Transformation Package TAB 4.1 Tabela LOJAS TAB 4.2 Tabela ITENS TAB 4.3 Tabela VENDAS TAB 4.4 Visão vbahia TAB 4.5 Tupla original da tabela Lojas TAB 4.6 Tupla original da tabela Itens TAB 4.7 Tupla original da tabela Vendas TAB 4.8 Tabela Vendas TAB 4.9 Tabela de Lojas TAB Relação Resultante TAB 4.11 Sub-Relação da Tabela Loja que originou a tupla t TAB 4.12 Sub-Relação da Tabela Vendas que originou a tupla t TAB 6.1 Template de representação de processos ETL

16 a a 1. INTRODUÇÃO CAPÍTULO Posicionamento A competitividade existente hoje no mundo corporativo exige decisões cada vez mais rápidas, eficientes e precisas. Tal exigência, aliada à evolução no modelo de negócios das empresas, cada vez mais focado na gestão de cliente, tem feito dos sistemas de Data Warehouse (DW) componentes importantes no processo de tomada de decisão. Sistemas de DW armazenam os dados que representam fatos, os quais revelam tendências para um planejamento estratégico dos negócios de uma empresa. Tais dados serão utilizados para a geração do artefato primordial no contexto da tomada de decisão, o conhecimento. Para que isso seja possível, um processo consistente e confiável de integração de dados precisa ser definido dentro de um Warehousing Justificativa para o Trabalho O processo de aquisição de dados para o DW é uma atividade complexa, pois abrange tarefas de igual modo complexas que estão inter-relacionadas: extração de dados dos sistemas transacionais, transformações e carga dos dados para o DW. A complexidade do processo de extração de dados está intimamente relacionada com a diversidade de tecnologias (banco de dados, plataformas, paradigmas de programação, dispositivos de armazenamento) envolvidas num ambiente de sistemas legados. Basicamente, para a criação de um processo de extração de dados, é preciso que se especifiquem mapeamentos entre dados do sistema de origem e de destino, ou seja, a escolha das fontes de dados dos sistemas operacionais cujos itens serão instâncias de algum campo do DW. Logo em seguida ao processo de extração, processos de transformação serão definidos para refinar (converter, categorizar e higienizar ) os dados extraídos. 1 Warehousing é uma coleção de conceitos e ferramentas que visam prover e manter um conjunto de dados integrados (Data Warehouse) no surporte a decisões de negócio dentro de uma corporação. 15

17 A integração de dados através do processo de transformação é um aspecto inerente e importante para a criação de um DW, pois nos sistemas transacionais a estrutura, localização, formato e semântica dos dados foram implementados sob a ótica de cada sistema, ou seja, atendendo aos requisitos de negócio de cada domínio de aplicação, e por isso um novo processo deve ser definido com a finalidade de atender às exigências de implementação de um sistema de DW. Transformações de dados incluem conversão, cálculo de novos valores através de fórmulas, especificação de valores default, formatação, e definição de categorias. Tais transformações podem ser categorizadas em classes genéricas de transformações, de modo a representar cerca de 95% de todas as transformações existentes no processo de criação de DW (CUI et al, 2001). A aplicação dos processos de transformação fornece aos dados a semântica apropriada para a sua utilização num sistema de DW. Esse processo de aplicação de transformações nos dados pode ser feito com base em scripts Shell, programas escritos numa determinada linguagem de programação, ou através de procedimentos armazenados que podem ser aplicados, por exemplo, a fontes de dados contidas em flat files, ou em banco de dados relacionais. Outra abordagem para a criação de procedimentos é a utilização de ferramentas de transformação de dados ou a utilização de geradores de código. Em todas as opções propostas como solução a um processo de transformação de dados, o conhecimento das transformações se encontra espalhado nos códigos fontes dos programas, procedimentos, ou armazenado como alguma informação proprietária e de uso exclusivo da ferramenta de transformação de dados. Neste ponto, surge um problema: como realizar o acompanhamento do item de dado desde seu sistema de origem até o mesmo ser parte integrante de um dado no DW? Tal problema é conhecido como Linhagem de Dados. As soluções atuais de transformação de dados não fornecem mecanismos de linhagem de dados, e nem tampouco de Back Tracing, ou seja, o trajeto inverso dos itens de dados em qualquer nível de granularidade (tabela, arquivo, coluna, registro, documento ou elemento). Isto torna o processo de transformação de dados complexo no sentido de que quando existe a necessidade de conhecer todas as transformações pelas quais um determinado item de dado passou até fazer parte de um hipercubo, por exemplo, é preciso fazer uma engenharia reversa manual do processo de transformação, através da inspeção dos programas, scripts, procedimentos e/ou ferramentas de transformação. 16

18 Dada a heterogeneidade do ambiente transacional e a liberdade de combinação de soluções de transformações de dados, faz-se necessária a utilização de um padrão de metadados que forneça os meios adequados para representar o processo de transformação de dados que permita a criação de mecanismos capazes de realizar a linhagem de dados e metadados e Back Tracing. O Common Warehouse Metamodel (CWM) (OMG, 2000) (OMG, 2001) é um padrão de metadados específico para o domínio de DW, e que fornece os pacotes e metamodelos essenciais para a representação de processos de transformação de dados e a implementação de mecanismos de linhagem. 1.3 Objetivo do Trabalho Este estudo visa explorar o uso do CWM no suporte à transformação e linhagem típicas do ambiente de DW, o que será feito com a integração dos recursos providos pelo CWM necessários à criação de uma solução de transformação e linhagem de dados num DW, organizado sob um esquema estrela. Adicionalmente à análise do CWM, este estudo propõe uma formalização do problema de linhagem de metadados como extensão ao problema de linhagem de dados. Além da formalização referida, tal estudo apresenta um algoritmo para a implementação de uma solução de linhagem de metadados segundo o padrão CWM e um algoritmo que gera uma árvore de expressões para funções de linha em cláusulas SQL e que instancia o metamodelo de expressões do CWM. Embora a linhagem de metadados seja entendida muitas vezes como o acompanhamento da evolução dos elementos de metadados ao longo do tempo, neste trabalho o termo será usado para denotar o acompanhamento das transformações (metadados) que são aplicadas aos dados ao longo de um processo de extração, transformação e carga de dados para a construção de um Data Warehouse. A diferença parece sutil, mas é fundamental para a compreensão da proposta apresentada, que é feita sob o ponto de vista de um padrão de metadados. De modo o validar o estudo proposto, é desenvolvida uma ferramenta para visualizar a linhagem de dados com base no metamodelo CWM, que permite aplicar a linhagem de dados e metadados, fornecendo recursos que garantam a interoperabilidade de metadados num ambiente de DW durante o processo de transformação de dados. 17

19 1.4 Organização da Dissertação Além da introdução, o restante desta dissertação contém seis capítulos adicionais. O Capítulo 2 apresenta as várias abordagens de solução para extração, transformação e carga de dados. Além disso, apresenta um estudo comparativo entre algumas das principais ferramentas de mercado (ETL), segundo métricas relacionadas a metadados e linhagem. O Capítulo 3 descreve a importância e o papel do metadado no âmbito da gerência e construção de DWs, e apresenta o padrão CWM com seus respectivos pacotes, utilizados como base para o desenvolvimento deste trabalho. O Capítulo 4 discute o problema de linhagem de dados e propõe adicionalmente uma formalização ao problema de linhagem de metadados, especificando um algoritmo para a sua implementação sob o ponto de vista do padrão adotado. O Capítulo 5 apresenta a especificação da ferramenta proposta para a realização da gestão de metadados (transformação e linhagem), onde são discutidas as funcionalidades, características e algoritmos básicos. O Capítulo 6 realiza um estudo de caso aplicado ao contexto de gestão de metadados, onde são apresentadas as principais telas da ferramenta. O Capítulo 7 encerra o trabalho, apresentando suas principais contribuições e propostas para trabalhos futuros. 18

20 A A CAPÍTULO 2 2. PROCESSOS DE EXTRAÇÃO, TRANSFORMAÇÃO E CARGA A construção de um DW é um processo complexo e de uso intensivo do dado que integra múltiplas fontes de dados heterogêneas e transforma em uma representação multidimensional, sendo útil na tomada de decisão. O processo de extração, transformação e carga dos dados (ETL) envolve diferentes subprocessos como higienização, transformações, agregações que objetivam extrair os dados brutos do ambiente operacional, transformar (converter, refinar, higienizar) os mesmos e carregá-los no DW. Esse capítulo apresenta abordagens de representação de processos ETL, além disso será apresentado um estudo comparativo de algumas das principais ferramentas ETL do mercado, sob o ponto de vista de metadados e linhagem de dados. 2.1 Processo ETL Processos ETL consistem em extrair os dados dos sistemas legados, transformá-los e carregá-los no DW. FIG. 2.1 Warehousing e Processo ETL 19

21 A FIG. 2.1 ilustra os componentes existentes num processo ETL. Itens de dados são extraídos dos sistemas legados; transformação, formatação e Linhagem são implementadas para assegurar a qualidade dos dados, e um processo de carga é executado para disponibilização dos dados no DW. Esse processo envolve ainda validação, conversão, agregação, cálculo de novos valores e especificação de valores Default. Scripts, Programas e Ferramentas ETL são os recursos utilizados nesse contexto. Esse processo é tanto complexo quanto necessário, pois os sistemas operacionais estão associados a diferentes repositórios, diferentes paradigmas de programação e tecnologias envolvidas, e além do mais correspondem a distintos, e até às vezes, obsoletos requisitos de negócio. Tendo em vista toda essa diversidade de tecnologias, fica claro que a migração de dados do ambiente operacional para o DW não é uma tarefa resolvida através de um mapeamento direto. Tal é a importância do processo ETL, e segundo Mimmo (MIMMO, 2002), muitos fracassos em projetos de DW são atribuídos às falhas cometidas no processo de migração de dados do ambiente operacional para o DW. Requisitos de negócios mal especificados, carga de dados sujos no DW e escolha de uma arquitetura incorreta são alguns dos erros cometidos na etapa de ETL que podem provocar falha no projeto de DW. A qualidade na conversão de dado é importante para o DW, pois este armazena a informação que é a chave do processo de tomada de decisão de uma corporação. A integração e a transformação são muito mais do que mover dados de um lugar para o outro. Segundo Inmon (INMON, 2002), esses dois fatores consomem de 75% a 80% de todo o recurso de desenvolvimento no projeto e construção de um DW. A razão para o consumo de tanto recurso é que o processo de transformação é muito complexo, em função de vários motivos: Um dado item de dados no DW pode ser originário de uma variedade de aplicações; A estrutura básica do dado é muito diferente. A origem do dado pode ter uma estrutura hierárquica e o destino ser relacional; Os sistemas operacionais podem ser diferentes. De um lado pode-se ter uma plataforma Unix e o outro utilizar uma plataforma MVS; O formato básico de armazenamento é diferente. A origem pode estar na forma EBCDIC e o dado de destino pode estar no formato ASCII; 20

22 Diferenças no nível de sumarização. Registros de origem podem estar detalhados e registros de destino podem estar sumarizados; Diferenças no modo de operação. Dados de origem podem sofrer atualização, enquanto dados de destino podem estar armazenados em Snapshots; Necessidade de conversão. Dados dos sistemas legados precisam ser transformados antes de serem armazenados no DW; Valores default precisam antes ser especificados para as estruturas de dados de destino; Necessidade de seleção de dados. Nem todos os dados dos sistemas legados precisam estar no DW; Segundo Bohn (BOHN, 1997), o processo de conversão de dados em ambiente de DW envolve especialistas técnicos e de negócios que projetam a estrutura do Warehouse e trabalham de forma conjunta para garantir o sucesso do projeto, e para isso executam as seguintes atividades: Análise dos Dados de Origem Os dados que originarão os dados no DW são de grande importância, e por isso devem estar consistentes. Uma análise criteriosa deve ser feita por especialistas que conheçam a semântica de cada item de dado no ambiente transacional. Identificação do Mapeamento de Dados Este ponto define a tarefa de mapeamento de dados que representa a transformação aplicada aos mesmos. Essa é uma tarefa também crítica para o sucesso do DW, pois um mapeamento incorreto pode gerar dados inconsistentes a partir de dados consistentes. Junção e/ou Criação de Dados Externos Esse aspecto considera a incorporação de dados oriundos de interfaces externas que não pertencem ao ambiente transacional. Definição de uma Lógica de Conversão de Dados Uma lógica de conversão que represente todo o processo deve ser definida afim de garantir o conhecimento do negócio como um todo. Planejamento e Geração das Rotinas de Conversão de Dados Nessa etapa as rotinas de conversão são geradas e aplicadas aos dados. Garantia da Qualidade dos Dados A qualidade de dados deve ser garantida durante todo o processo de conversão, pois a falta de qualidade em alguma 21

23 etapa tende a se propagar para as próximas etapas, podendo ter impacto direto nos dados do DW e conseqüentemente na tomada de decisão. O processo de conversão deve considerar o fluxo seguido por cada item de dado, e para isso deve considerar os seguintes aspectos: Como migrar os dados dos sistemas legados para a área temporária de trabalho (Staging Area)? Como transformar, integrar e limpar os dados na Área Temporária? Como gerenciar as chaves primárias e estrangeiras no DW? Como migrar os dados da Staging Area para o DW? Como carregar e indexar os dados no DW? Como assegurar a qualidade dos dados ao longo do processo de conversão? 2.2 Higienização de Dados Higienização de Dados (Data Cleaning) objetiva a detecção e remoção de erros e inconsistências de dados a fim de melhorar a qualidade de dados (RAHM e DO, 2000). Problemas de qualidade de dados estão presentes em coleção de dados únicas, tais como arquivos e banco de dados. Quando múltiplas fontes de dados precisam ser integradas, a necessidade de higienização de dados aumenta significativamente. Isso porque as fontes de dados freqüentemente contêm redundâncias em diferentes representações. Para prover acesso consistente e preciso aos dados, uma consolidação de diferentes representações de dados e eliminação de duplicidades é necessária. Durante o processo ETL, transformações de dados adicionais são executadas para a integração e tradução de esquema e dados, além de realizações de filtragens e agregações de dados a serem armazenados no DW. Uma abordagem de higienização de dados detecta e remove todos os grandes erros de fontes de dados quando ocorre a integração de múltiplas fontes. Tal abordagem deve ser amparada por ferramentas para limitar a inspeção manual e os esforços de programação, e ser extensível o suficiente para cobrir fontes adicionais. A TAB 2.1 identifica diferenças entre problemas de fonte única e múltiplas fontes e entre problemas relativos a esquema e instância (RAHM e DO, 2000). Problemas a nível de esquema são refletidos a nível de instância; problemas a nível de instância, por outro lado, se 22

24 referem a erros e inconsistências no conteúdo do dado atual, o qual não é visível no nível de esquema. Problemas de Qualidade de Dados Fonte Única Múltiplas Fontes Nível de Esquema Nível de Instância Nível de Esquema Nível de Instância Restrições de Duplicidades Modelos Inconsistência de Integridade Heterogêneos Dados Unicidade Redundância Conflitos de Nomes Agregação Inconsistente Integridade Referencial Valores Contraditórios Conflitos Estruturais Inconsistência Temporal TAB 2.1 Classificação de Problemas de Qualidade de Dados De maneira geral, a higienização de dados envolve várias fases:! Análise de Dados: Para detectar quaisquer tipos de erro e inconsistências que deverão ser removidos, uma análise de dados detalhada é exigida. Além disso, a inspeção manual da amostra de dados e dos programas de análise são necessários para obter metadados sobre propriedades de dados e detectar problemas na qualidade dos mesmos;! Definição de um Fluxo de Trabalho (Workflow) de Transformações e Regras de Mapeamento. Dependendo do número de fontes de dados, do seu grau de heterogeneidade e sujeira do dado, um vasto número de transformações de dados e passos de higienização precisam ser executados. Algumas vezes, um esquema de tradução é usado para mapear as fontes para um modelo de dados comum. Em DW, geralmente utiliza-se uma representação relacional. Para o DW, o controle e fluxo de dados para as tarefas de higienização e transformação devem ser especificados dentro de um Workflow que defina o processo ETL;! Verificação. A correção e efetividade de um Workflow de transformações e suas definições devem ser testadas e avaliadas, como por exemplo, uma cópia ou amostra de uma fonte de dados para melhorar sua definição, se necessário. Múltiplas iterações de análise e verificação das tarefas podem ser necessárias, pois alguns erros só aparecem depois de se aplicar algumas transformações; 23

25 ! Transformação. Os passos de execução e transformação implementados por Workflow ETL para carga e atualização do DW precisam ser avaliados para garantir qualidade nesta etapa do processo. DW são sistemas complexos e de uso intensivo de dados que integram dados de múltiplas fontes de informações heterogêneas e transformam numa representação multidimensional, a qual é útil para a tomada de decisão. Um DW é caracterizado por um ciclo de vida complexo. A construção de um DW envolve a fase de projeto, onde são produzidos vários construtores de modelagem, acompanhado por detalhes físicos de projeto. Além disso, esta fase considera os processos de data warehouse também, os quais são estruturalmente complexos, volumosos e difíceis de codificar. O processo de atualização do DW é composto de diferentes sub-processos como higienização dos dados, arquivamento, transformações e agregações interconectadas. A administração do DW é também uma tarefa complexa. Dada a complexidade do processo de carga e atualização do DW, faz-se necessário o uso de ferramentas que automatizem e otimizem os recursos utilizados para este fim. 2.3 Ferramentas ETL Ferramentas ETL são definidas como um conjunto integrado de funcionalidades de software com o objetivo de extrair, transformar e carregar os dados no DW a partir dos dados existentes no ambiente operacional. Atualmente essas ferramentas dispõem de front-ends amigáveis ao usuário, de acesso à Web e aos principais Sistemas Gerenciadores de Banco de Dados Relacionais (SGBDRs), como por exemplo, DB2, Oracle, SQL Server. As ferramentas ETL, de um modo geral, permitem a definição dos elementos envolvidos num processo ETL e o gerenciamento das transformações aplicadas aos itens de dados. Essas transformações são geradas a partir de scripts e programas que implementam o mapeamento de um dado de origem num dado de destino. Um item de dado pode ser visto em diversos níveis de granularidade. Desta forma, tabelas, visões, visões materializadas, arquivos, campos e colunas podem participar na definição de mapeamentos para a extração, transformação e carga dos dados. Uma restrição conceitual implementada em todas as ferramentas é que apenas itens de origem e de destino devem ser de um mesmo nível de granularidade. A seguir serão apresentadas algumas das características mais importantes de cada ferramenta. 24

26 2.3.1 Oracle9i Warehouse Builder (OWB) O OWB [OWB01,OWB02] é uma ferramenta que possibilita o projeto e desenvolvimento de DW corporativos, DMs e aplicações de BI (Bussiness Intelligence). A ferramenta é componente do Oracle9i Development Suite. O OWB permite aos usuários criar modelos dimensionais, projetar processos ETL, integrar múltiplas fontes, e através do uso extensivo dos relatórios de metadados, integrar a ferramenta a outras tais como Oracle9iAS Discoverer, Oracle Workflow e Oracle Enterprise Manager SAS/Warehouse Administrator O SAS/Warehouse Adiminstrator (SAS, 2002) é uma ferramenta completamente integrada aos produtos SAS e oferece uma forma de criar e manter múltiplos DW. Dentre suas características mais importantes pode-se destacar: manutenção de relacionamentos de metadados; armazenamento de regras de negócio e de estrutura dos dados; gerência do processo de carga; pesquisa e navegação por descrições de negócios; exportação de metadados para outras aplicações e provimento de gerador de código de acordo com uma API padrão Microsoft Data Transformation Service (DTS) O DTS (MICROSOFT, 1999) permite aos usuários mover dados de múltiplas fontes e dados de fontes heterogêneas em um ou mais banco de dados. É possível manipular o dado durante o processo, tornando-o consistente. Além disso, o DTS permite criar dados sumarizados, definindo uma ou mais tarefas que executam seqüencialmente a importação, exportação e transformação de dados. Além disso, possibilita a execução de pacotes (DTS Import and Export Wizards), especificar transformações de dados e editar especificações de pacotes complexos através de um Workflow gráfico (DTS Designer). O utilitário dtsrun fornece uma interface via prompt que recupera, executa e sobreescreve pacotes DTS pré-definidos. 25

27 2.4 Estudo Comparativo de Ferramentas ETL Nesta seção será apresentado um quadro comparativo entre três ferramentas que se propõem a ser uma solução ETL : Oracle Warehouse Builder (OWB), Data Transformation Service (DTS) e SAS Administrator. Várias características das ferramentas foram analisadas. Os itens relativos ao seu aspecto executor foram abordados, mas principalmente as funcionalidades associadas à gerência de metadados e linhagem foram identificadas e registradas. Funcionalidade OWB DTS SAS 1. Suporta algum Padrão Sim,CWM Common Sim, OIM (Open Sim, CWM de Metadados? Qual? Warehouse Metamodel). Information Model). (Common Warehouse Metamodel). 2. Completa em relação Sim Sim Não ao padrão utilizado? 3. Independente de Sim Sim Sim SGBDR? 4. Permite Sim Sim Sim interoperabilidade com outras ferramentas? 5. Usa algum padrão Sim, XMI. Sim, XML. Sim, XMI. para interoperabilidade de metadados? 6. Implementa Linhagem Sim, Relatórios de Sim, Interface Não. de Dados? De que forma análise de impacto e programável em? diagramas e VBScript Mapeamento de (Específicos para Transformações. repositórios Microsoft). 7.Usa algum Repositório Sim. Warehouse Sim. Sim. Metabase de Metadados? Builder Repository. 8. É extensível? De que Sim, APIs Java Sim, APIs ActiveX Sim, APIs C e C++ 26

28 forma? (VBScript, JScript, ou PerlScript) 9. Permite visualização Não. Não. Não. de dados na linhagem? 10. Implementa Não. Não. Não. Linhagem de Metadados? De que forma? TAB 2.2 Quadro comparativo de ferramentas ETL A tabela 2.2 apresenta o quadro comparativo entre as principais ferramentas ETL do mercado. Em relação ao item 1 do quadro, verificou-se vantagem das ferramentas SAS e OWB, já que utilizam o padrão de metadados CWM, que é um padrão voltado para a representação de metadados de DW, ao contrário do padrão utilizado pelo DTS, o OIM, que é voltado para sistemas de informação de um modo geral. Além disso os padrões de metadados CWM e OIM sofreram fusão, o que indica a qualidade, especificidade e consistência dos metamodelos implementados no CWM e sua aplicabilidade ao Warehousing. O item 2 considera a completeza da ferramenta em relação ao padrão adotado, o que indica que a adoção de um padrão não garante a gerência global dos metadados envolvidos no processo ETL. Neste aspecto, todas as ferramentas são completas em relação ao padrão adotado. A restrição de aplicação da solução ETL associada a um SGBDR específico revela um ponto de deficiência da ferramenta, já que o ambiente operacional é caracterizado pela existência de diversas fontes de dados, e por vezes, diversos SGBDs. Logo o item 3 do quadro comparativo é importante para a análise e mostra que todas as ferramentas são genéricas nesse sentido. Em função da existência de diversas ferramentas de fabricantes diferentes num mesmo ambiente, a funcionalidade de interoperabilidade entre ferramentas ETL é considerada uma característica relevante, tópico esse analisado no item 4, indicando que as ferramentas avaliadas levaram essa característica em consideração. No contexto de um processo ETL é bastante significativo no que diz respeito à interoperabilidade de dados e metadados a utilização de um padrão (item 5). XML têm sido uma linguagem universalmente aceita para intercâmbio de dados e metadados. A FIG. 2.2 mostra que o OWB permite interoperabilidade de metadados entre ferramentas da Oracle e entre qualquer outra ferramenta que seja baseada no padrão de metadados CWM. 27

29 FIG. 2.2 Módulo de Interoperabilidade do OWB. O item 6 trata do problema de linhagem de metadados. A ferramenta OWB supera as demais em relação à propriedade de linhagem de metadados, pois implementa parcialmente tal funcionalidade através de diagramas de linhagem voltados para o nível de granularidade de tabelas. O DTS permite acesssar o repositório de metadados, e através de uma interface programável é possível exibir algumas propriedades de linhagem. A FIG. 2.3 ilustra o mapeamento campo a campo entre duas fontes de dados relacionais. Neste exemplo, cada seta representa uma transformação aplicada num determinado item de dado. A FIG. 2.4 ilustra um cenário hipotético de geração de fluxo no DTS. As fontes de dados são conectadas por scripts que representam extração, transformação e carga de dados. O processo tem uma seqüência lógica que representa o fluxo de dados seguido durante a criação do DW. A FIG. 2.5 mostra que o OWB implementa linhagem de metadados no nível de granularidade de tabela através de um diagrama. Metadados relativos a colunas, chaves, índices podem ser visualizados clicando nos hyperlinks de detalhamento de cada tabela. 28

30 FIG. 2.3 Mapeamento de Campos no DTS FIG. 2.4 Cenário de um Fluxo de Dados no DTS. 29

31 FIG. 2.5 Diagrama de Linhagem de Metadados no OWB O item 7 mostra que todas as ferramentas são acopladas a um repositório de metadados que também pertence ao mesmo fabricante de cada ferramenta. Outro aspecto importante por parte da ferramenta é a possibilidade de criação de mecanismos de extensão da aplicação, o que é garantido muitas vezes por meio de APIs (Application Program Interface) que buscam estender alguma funcionalidade da ferramenta. As ferramentas analisadas são extensíveis e fornecem APIs programáveis para o usuário criar novas funcionalidades, conforme observado no item 8. Nenhuma das ferramentas apresenta uma solução de linhagem de dados com visualização dos dados e esse aspecto aponta uma carência significativa que pode ter impacto na qualidade de dados. Este estudo comparativo mostrou que a ferramenta da Oracle se sobressaiu em relação às demais, pois apesar de parcialmente, a ferramenta implementa mecanismos de linhagem de metadados, e, além disso, a ferramenta é baseada num padrão de metadados que é específico para DW (CWM). As ferramentas analisadas implementam processos ETL representando-os como Workflows, o que têm se mostrado como uma alternativa eficiente de gerência de tais processos. 30

32 2.5 ETL como um Ambiente de Workflow Uma abordagem eficaz para o gerenciamento de um processo ETL é a sua representação como um modelo de Workflow, indicando logicamente o fluxo seguido por um item de dado desde que este sai do ambiente operacional até chegar no DW. Algumas definições desse conceito podem ser encontradas na literatura: Um Workflow é um sistema no qual os elementos são atividades relacionadas entre si por uma relação de evento, condição e ação e que é acionado por agentes externos, os quais representam processos de negócio (JOOSTEN, 1995). Um Workflow é um conjunto de atividades que podem ser manuais ou automáticas e são executadas por atores (SCHAEL, 1998). Um Sistema de Gerência de Workflow (SGW) é um sistema que define, gerencia e executa fluxos de trabalho através da execução de software e cuja ordem de execução é orientada por uma representação lógica de processos de negócio (JOOSTEN, 1995). Um SGW aplicado a um DW é conhecido como WDW (Workflow Data Warehouse). As definições acima ajudam a compreender a modelagem do processo ETL como um Workflow, pois as atividades de extração, transformação e carga estão interligadas por uma lógica de conversão e condicionadas a uma série de eventos que possibilita o conhecimento global de criação dos dados no DW. Um agente externo aciona o processo ETL através da execução de uma determinada atividade. Algumas das atividades seguintes tomarão como base os dados gerados pela atividade anterior. Dessa forma cria-se um fluxo de trabalho automatizado. A abordagem de Sistemas de Workflow na implementação de processos ETL oferece uma série de vantagens:! Simplificação das atividades de armazenamento e recuperação de informação;! Rapidez na pesquisa de informações armazenadas;! As informações dos responsáveis por cada atividade do processo são mantidas sempre (automaticamente) atualizadas;! Conhecimento e status do processo a cada instante, possibilitando saber-se quais elementos estão atuando, quais são os próximos a atuar, e quando começaram a atuação;! O SGW coordena a execução das atividades automaticamente com o uso de agendas e trocas de mensagens entre os elementos do fluxo; 31

33 ! A eficiência é melhorada, uma vez que a automação de muitos processos de negócios resulta na eliminação de muitos passos desnecessários;! Um melhor gerenciamento de processos de negócio é atingido por meio da padronização dos métodos de trabalho e da disponibilidade de registros para auditoria;! Melhor atendimento a clientes, já que a consistência nos processos levam à uma maior previsibilidade nos níveis de resposta;! Maior flexibilidade, pois o controle dos processos via software permite o reprojeto alinhado com as necessidades de mudança do negócio; e! Melhoria nos processos de negócio, já que o foco nos processos de negócio levam à obtenção de processos mais eficientes e simples. Sistemas de Gerência de Workflow estão sendo usados para melhorar a eficiência dos processos.tais sistemas possuem a capacidade de gerar logs (notificações) de eventos que ocorrem durante a execução de muitos processos incluindo o tempo de início e término de cada atividade, seus dados de entrada e saída e o recurso que o executou. A análise de tais informações permite aos diretores de TI (Tecnologia de Informação) detectar problemas e identificar soluções. Todavia, a maioria dos Sistemas de Workflow apenas oferece funcionalidades básicas de análise de logs, tais como a habilidade de recuperar o número de processos finalizados em um dado período de tempo e sua média de execução. A disponibilidade do processo e do nó de informações no WDW permite funcionalidades de análise de dados Sistemas de Workflow permitem alto grau de flexibilidade para recursivamente decompor e unir atividades. Essas características são úteis no contexto de DW, cujas atividades podem ser organizadas segundo um fluxo de atividades. A fase de Carga do DW consiste numa instanciação que computa o conteúdo do DW. Essa carga (BOUZEGHOUB et al, 1999) pode ser definida como uma seqüência de quatro passos : i) preparação, ii) integração, iii) agregação e iv) customização. O primeiro passo, denominado preparação, consiste da extração e higienização do dados. O segundo passo consiste na integração dos dados oriundos de fontes heterogêneas e derivadas das relações do Operational Data Store (ODS). O terceiro passo consiste na computação de visões agregadas. Enquanto os dados dos sistemas legados são de baixo nível de agregação, os dados instanciados nas estruturas dos hipercubos são altamente sumarizados. 32

34 O quarto passo consiste da derivação e customização das visões de usuários, as quais definem os Data Marts (DM). A FIG. 2.6 ilustra um processo ETL como um conjunto de eventos coordenados. Nesse tipo de modelo, atividades são coordenadas por um fluxo de controle de forma que agentes de software ou eventos temporais certifiquem cada passo do fluxo. A modelagem de processsos ETL como um grafo é outro modo eficaz que permite acompanhar todo a conversão de dados. Em (VASSILIADIS et al, 2002), é proposta uma arquitetura de um grafo que descreve todo o processo ETL. Além disso, são propostos algoritmos de redução da complexidade do grafo a fim de eliminar passos redundantes e avaliar a qualidade dos dados gerados de uma forma mais eficiente. FIG. 2.6 Um Workflow para o processo ETL 2.6 Considerações Finais Este capítulo discutiu algumas das abordagens de gerência de processos ETL. Além disso, apresentou um estudo comparativo entre três ferramentas ETL do mercado sob a ótica de metadados e linhagem. Com isso ficou claro que as ferramentas ainda são carentes de uma solução completa de metadados e que implemente mecanismos de linhagem. A ferramenta que mais se aproximou de uma solução de linhagem foi o OWB, que é baseado no CWM 33

35 padrão adotado e utilizado ao longo deste trabalho, e portanto foi considerada a melhor ferramenta ETL entre as analisadas. Observada a ausência de funcionalidades de linhagem nas ferramentas analisadas e dada a importância deste mecanismo, será proposta e implementada uma ferramenta que atenda aos requisitos essenciais de linhagem e suporte à transformação de dados. Todas as ferramentas implementam processos ETL através de sistemas de Workflow que podem ser representados por um grafo. Em qualquer das abordagens de representação do processo ETL, é indispensável a sua implementação sob o ponto de vista de metadados, cujo estudo é tema do próximo capítulo. 34

36 a a CAPÍTULO 3 3. GERÊNCIA DE METADADOS NO AMBIENTE DE WAREHOUSING Apesar do inegável valor associado aos metadados no intuito de descrever, identificar, localizar, recuperar e utilizar recursos de informação em ambientes corporativos, sua implementação não tem sido feita de forma eficaz. O ambiente corporativo é marcado por heterogeneidade de componentes de software (Sistemas, Banco de Dados, Plataformas), em função da característica independente e tendenciosamente especialista de cada atividade operacional dentro de uma empresa. Isto leva a aquisições e implementações de softwares cada vez mais voltadas para uma área específica de um processo transacional, haja visto os Sistemas Especialistas, de Faturamento, ou ainda os sistemas que tratam de relacionamentos com clientes (CRM Customer Relationship Manager) e das soluções que são responsáveis pelo controle da cadeia de suprimentos de uma empresa (SCM Supply Chain Management). Tais sistemas implementam formas proprietárias de uma solução de metadados (quando existem), o que torna o ambiente corporativo também heterogêneo nesse sentido. Uma solução de metadados deve ser integrada, de modo que qualquer item de metadado possua representação em qualquer ferramenta. Tal fato se dá através de uma solução integrada de metadados representada através de um metamodelo comum, que garanta a interoperabilidade entre as ferramentas existentes neste contexto. Além disso, é possível garantir a equivalência semântica para todo metadado existente num metamodelo (modelo de metadados), ou seja, qualquer elemento de metadados possui a mesma semântica em qualquer fonte de dados. No contexto de um DW, metadados assumem um papel de extrema importância na gestão do processo de extração, transformação e carga dos dados do ambiente transacional para o DW, pois possibilitam a representação das transformações, sumarizações e refinamentos pelos quais passam os dados. Metadados dão suporte à manutenção dos processos existentes para a construção e manutenção do DW. Conseguem extrair o conhecimento que está disseminado entre pessoas, programas, scripts e criam uma representação única para tal conhecimento. Desta forma, é 35

37 possível construir soluções fáceis de manter e de maior qualidade, pois existe uma representação integrada de metadados. Metadados podem ser vistos sob diferentes pontos de vista, visando descrever recursos de informação para diferentes tipos de usuário (KIMBALL, 1998). Desta forma, uma solução integrada de metadados atende a necessidades de praticamente todos os usuários (DBAs, Desenvolvedores, Analistas de Negócio, Gerentes e Analista de Sistemas) de um DW, por exemplo. Este capítulo aborda os aspectos aqui expostos de forma introdutória. Primeiramente serão apresentados metadados em termos de conceitos, áreas de aplicação, benefícios, classificação e gerência de soluções, contextualizando-os no domínio de DW. Em seguida será apresentado o padrão CWM, um padrão de metadados aceito para a representação e interoperabilidade de metadados em ambientes de DW, proposto pelo OMG (Object Management Group) (OMG, 2000), com os respectivos pacotes utilizados neste trabalho. 3.1 Metadados: Conceituação Metadado em sua conotação mais simplória, é definido como sendo dado sobre dado (INMON, 2001), podendo também ser entendido como a informação necessária para analisar, projetar, construir, implementar e usar sistemas de computação (STAUDT et al, 2000). Além disso, pode ser visto como uma descrição detalhada de uma instância do dado (Tannenbaum, 2002), ou ainda, como a informação que torna o dado útil (MOURA et al, 1998). Em todas as definições fica claro que metadado é a informação que descreve o dado em relação a alguns aspectos (estrutura, origem, localização, processos de geração, meios de acesso), transformando-o dessa forma em informação, isto é, dado com significado. Em outras palavras, metadado é um recurso que transforma um item de dado num item de informação. O conceito de metadados foi muito aplicado no contexto de banco de dados relacionais, onde metadados continham a descrição dos dados nos catálogos, com a especificação das tabelas, colunas, restrições e tipos de dados existentes num banco de dados. No entanto, seu uso é bastante diversificado e empregado em múltiplos domínios, a exemplo de: Banco de Dados Multimídia, DW, Sistemas de Informação Geográfica (SIG), Interoperabilidade de recursos heterogêneos, Hypermidia e Web Semântica. Metadados fornecem mecanismos de representação semântica dos dados, além de fornecer meios de se conhecer a sua origem. Este tipo de abordagem possibilita o 36

38 conhecimento total do dado, ou seja, suas restrições, seu significado e as transformações aplicadas a cada item de dado, facilitando a implementação de novos projetos e melhorando os aspectos de qualidade de dados. Num Warehousing, dados estão armazenados em sua forma binária, formando a matéria-prima do processo. A partir daí, aplicações processam esses dados gerando informação dado com significado e usuários de negócios convertem essa informação em conhecimento informação especializada, como mostra a FIG A qualidade no processo de tomada de decisão está intimamente relacionada com a qualidade de dados. Isto implica em garantir qualidade em todo o processo de geração de conhecimento a partir do dado bruto, evitando assim que estes dados gerem informações inconsistentes, que estas informações gerem conhecimentos imprecisos, e que por sua vez estes conhecimentos gerem decisões incorretas. Metadados fornecem, portanto, meios de representar todo o processo de geração de conhecimento, sendo um recurso essencial e de grande utilidade em sistemas de suporte a decisão. FIG. 3.1 Dado, informação e conhecimento extraído de (Tannenbaum, 2002). 3.2 Áreas de Aplicação de Metadados Diferentes comunidades de usuários empregam metadados para realizar suas tarefas nas áreas mais diversificadas, que variam desde as ciências da terra e do espaço, como na medicina, leis e negócios. Com relação às características de metadados, identificam-se três classes de domínio de aplicação de metadados (STAUDT et al, 2000): 37

39 1) Sistemas de Gerenciamento de Informações Dentro desta classificação estão os tradicionais Sistemas de Gerenciamento de Banco de Dados (SGBDs), integração de BDs e sistemas de recuperação de informação.! Integração de Banco de Dados Neste aspecto, metadados são utilizados para dois propósitos: acompanhamento (gestão) do processo de integração de dados e como um recurso documental para usuários finais entenderem e acessarem as informações integradas.! Sistemas de Recuperação de Informações Neste tipo de abordagem os metadados surgem como um elemento importante para representar as informações necessárias para recuperação da informação (definição dos critérios de busca, técnicas de indexação). Além disso, vocabulários (linguagem dependente de um conjunto de palavras usadas em contexto local), tesauros (gerência de sinônimos e termos relativos) e ontologias (descrições precisas de um conceito primitivo relativos a um domínio particular) são usados como metadados para a extração de informações a partir de documentos textuais (FRIDMAN e HAFNER, 1997).! Web Metadados no contexto da Web enriquecem os critérios de busca provendo maior representação semântica do conteúdo pesquisado.! Engenharia de Software Na área de Engenharia de Software, a noção de metadado surge em relação às ferramentas CASE (Computer Aided Software Engineering) que incluem documentação sobre o projeto e seu desenvolvimento, modelo da aplicação, arquitetura do sistema, definições de interface, código fonte ou conteúdo dos makefiles (scripts de compilação de programas). Em projetos de software que usam ferramenta CASE, o compartilhamento de metadados é indispensável. Metadados produzidos por uma ferramenta podem ser usadas por outras ferramentas no sistema. No processo de desenvolvimento de software, metadados tornam possível a criação de um processo de desenvolvimento de software bem documentado, consistente, e de qualidade. 2) Multimídia Comparada às outras áreas, a gerência de dados multimídia impõe novas exigências, e, metadado, neste caso, consiste de palavras-chave que representam informações relevantes 38

40 quanto ao aspecto de acesso, consulta e recuperação. Desta forma, características como texturas de imagens, freqüências de gravação de áudio, tamanho da fonte ou texto, propriedades de vídeo como iluminação, vetor câmera de visão, e outras métricas relativas à visão computacional podem ser geradas. 3) Telecomunicações Neste sentido, telecomunicações se referem à transmissão de todos tipos de dados (voz, texto e vídeo) de um computador ou serviço para outro computador ou serviço. Exemplos incluem mensagem eletrônica ( , fax, notícias via dispositivos móveis) ou entrega de documentos utilizando o padrão EDI (Electronic Data Intechange). Assim, metadados são utilizados para especificar formatos, modos de transferência, dimensões de pacotes, além de controle de acesso utilizando metadados como nome, senha e chave criptográfica pública. Desta forma, metadado é usado para envio de mensagens eletrônicas, para autenticação de dados e gerência de sistemas de telecomunicações de um modo geral. 3.3 Benefícios do Uso de Metadados Metadado provê uma documentação consistente sobre a estrutura, definição e localização dos dados, e com isso muitos benefícios podem ser identificados: interação maior com o sistema, pela representação das terminologias de negócios; integração, através do potencial de representação de ambientes heterogêneos; melhoria na qualidade de dados, pela facilidade da identificação da origem da informação e do seu significado; suporte ao projeto, análise e manutenção de sistemas, pois metadado oferece um maior controle e confiabilidade ao processo de desenvolvimento de novas aplicações, documentando os aspectos estáticos e dinâmicos do sistema; flexibilidade, pois metadado possibilita flexibilizar sistemas de computação através da documentação de componentes, pacotes e módulos de fontes criando com isso padronização de desenvolvimento, manutenção e extensão de funcionalidades de software. Dada a complexidade e heterogeneidade do ambiente de Warehousing, facilmente os benefícios de metadados foram incorporados ao DW com o objetivo de minimizar os esforços para a administração do DW e melhorar o processo de extração de informação. A geração e gerência de metadados geralmente servem para duas propostas (STAUDT et al, 1999): (1) minimizar os esforços para a administração de DW (caracterizado pela dinamicidade de seus processos); e (2) melhorar o processo de extração da informação, o qual deve garantir dados confiáveis para a tomada de decisão. O primeiro objetivo diz respeito a: 39

41 ! Automação de vários processos de administração de sistemas de informação. Metadados são gerados e acessados durante a definição e execução de processos (como carga e atualização do sistema de data warehouse) num DW.! Aplicação de mecanismos complexos de segurança. O controle de acesso ao sistema de DW pode exigir métodos sofisticados. Por exemplo, as fontes operacionais podem conter informações não confidenciais para alguns usuários, mas a sumarização de valores armazenados no DW pode conter informações sigilosas, as quais são diretamente responsáveis pela tomada de decisão. Metadado pode prover regras de acesso e direitos de usuário para o sistema de DW como um todo.! Suporte à análise e projeto de novas aplicações e modelagem de processos de negócio. Metadado aumenta o controle e confiabilidade no processo de desenvolvimento de novas aplicações para o DW, provendo informações sobre o significado dos dados, sua estrutura e origem.! Melhoria na flexibilidade do sistema e reuso de módulos de software existentes. Aspectos semânticos que são alterados freqüentemente (regras de negócio) são explicitamente armazenados como metadados fora dos programas de aplicação (scripts, aplicações de usuários final, etc). Essas regras de negócio podem ser atualizadas sem muito esforço, de acordo com possíveis requisitos, podendo ser reusadas em contextos diferentes, tanto a nível de código quanto para o conhecimento de projeto. Como conseqüência, a manutenção de sistemas torna-se substancialmente fácil, e o software pode ser estendido e adaptado sem dificuldades. Em tempo de execução, um mecanismo de busca acessa e interpreta o metadado no intuito de realizar as tarefas particulares de manipulação, limpeza, transformação e uso do dado. O segundo objetivo se refere à extração do dado e geração de informação:! Melhoria na qualidade dos dados. Qualidade de dados inclui métricas como consistência (se a representação do dado é uniforme e sem duplicidades, e se nenhum dado apresenta sobreposição com definições pré-existentes); 40

42 completeza (se algum dado está faltando); precisão (conformidade do valor armazenado com o valor atual, incluindo precisão e sigilo do dado); periodicidade (se o valor armazenado está atualizado). Além disso, qualidade de dados requer exatidão que tem sido definida de acordo com uma dada aplicação (por exemplo, se atributos possuem valores esperados). Por fim, qualidade de dados assegura que regras seriam definidas, armazenadas como metadados e checadas a todo instante em que o DW é atualizado. Além disso, a alta qualidade de dados permite o suporte à sua localização. Metadados provêm informações sobre o momento de criação do dado e o responsável pela informação, fonte de origem e significado no momento da sua captura, além de fornecer meios de seguir o dado da sua origem até o local mais atual. Deste modo usuários podem reconstruir o caminho seguido pelo dado durante o processo de transformação e verificar a precisão da informação retornada.! Melhoria na qualidade de consulta, resposta e recuperação. Metadado permite precisar o tempo de consultas e reduzir o custo para usuários acessarem, avaliarem e usarem a informação apropriada. Além disso, fornece associações esclarecedoras entre elementos de dados.! Melhoria na análise de dados. Métodos para análise de dados cobrem um amplo espectro, iniciando com simples relatórios de aplicações que incluem sumarizações, continuando com OLAP, e finalizando com aplicações de mineração de dados complexas. Neste contexto, o metadado é necessário para entender o domínio de aplicação e sua representação no modelo de dados (no caso clássico de esquema de banco de dados) no intuito de aplicar adequadamente e interpretar os resultados. Além disso, metadado pode ser automaticamente acessado por aplicações analíticas e usadas para realizar processamentos específicos. 3.4 Classificação de Metadados Dada a diversidade de funcionalidades atribuídas aos metadados, existem muitos esforços na tentativa de classificá-los [SVV99, Wi98]. Nenhuma dessas classificações é, portanto, genérica o suficiente para abranger qualquer tipo de metadados. 41

43 De maneira geral, metadados no contexto do DW podem ser representados através de um cubo, conforme ilustrado na FIG FIG. 3.2 Classificação Tridimensional do DW extraído de (DO e RAHM, 2000) A dimensão dados classifica metadados de acordo com o local onde o dado está sendo descrito. Baseado na arquitetura de DW, é possível distinguir metadados associados a sistemas operacionais, ao DW propriamente dito, e ao DM. Esta dimensão representa metadados sob uma visão estática do ambiente, pois nesta visão são descritas as características estruturais dos dados, que são, por natureza, estáticas. A dimensão processos cobre os aspectos dinâmicos do ambiente, através da representação dos quatro processos principais do DW, a saber: projeto, carga, administração e análise do DW. O processo de projeto é implementado através de ferramentas de modelagem, onde são definidas visões, modelos conceituais, arquitetura e infra-estrutura do DW e DM. Esse processo requer uma integração de metadados obtidos das fontes de dados. O processo de carga é tipicamente suportado por ferramentas ETL, responsáveis por carregar os dados consistentes, transformados, e sem redundância para o DW e DM, conforme visto no capítulo 2. Neste ponto, nota-se a necessidade de obtenção dos metadados existentes na dimensão dados para a geração dos metadados da dimensão processos. O processo de administração constitui-se de operações, manutenções e otimizações do DW. Os processos de análise representam toda a dinamicidade desta dimensão, já que são responsáveis pelo uso dos dados do DW para navegação, consulta, e mineração de dados, ou seja, todos os recursos disponíveis e necessários para a tomada de decisão. 42

44 A dimensão usuários se refere a dois grupos importantes de usuários que fazem uso do DW: os usuários técnicos e de negócio. Usuários técnicos incluem administradores de banco de dados, programadores, arquitetos de infra-estrutura, e projetistas. Esses usuários executam tarefas de projeto, desenvolvimento e manutenção do sistema. Usuários de negócios incluem os gerentes, analistas, etc., e como tais utilizam toda a infraestrutura criada pelos usuários técnicos para realizar a análise de dados. A seguir são identificados seis critérios para a classificação de metadados em Data Warehousing (POOLE et al, 2002) Critério tipo Nesse critério, o termo metadado é visto sob a ótica de dados primários no DW e de processamento de dados. Metadado de dados primários Dados primários consistem de todos aqueles gerenciados pelas fontes de dados, isto é, DW, DM, e aplicações. Assim, o metadado correspondente inclui informações relativas à estrutura das fontes de dados. Neste contexto, existe distinção entre metadados referentes ao esquema inteiro e metadados associados à parte do esquema. Metadados de dados primários também são conhecidos como metadados técnicos, de modo que podem também ser vistos como metadados administrativos ou estruturais e cobrem informações sobre: arquitetura e esquema de sistemas operacionais, DW e sistemas OLAP. Isso inclui, por exemplo, informações sobre tabelas e estruturas de registros, restrições de atributos, gatilhos de banco de dados e definições de visões; dependências e mapeamentos entre fontes de dados operacionais, DW e os bancos de dados OLAP no nível de implementação e físico, o que inclui filtros, movimentos de dados, transformações e agregações; dados temporais e dados sobre ações do usuário (MÜLLER et al, 1999). Metadado técnico é relevante para todos os componentes do Warehousing (sistemas operacionais, DW e DM), e permite representar esquemas de banco de dados ou estrutura de arquivos. Fornece também descrições detalhadas dos sistemas usados no processo ETL (nomes de servidores, endereços de rede, nomes de banco de dados, nomes de arquivos) e torna possível o entendimento da dependência entre dados existentes nos vários níveis do 43

45 Warehousing (dados operacionais, dados do warehouse, objetos de análise de dados tais como cubos, consultas e relatórios). Metadado para processamento de dados Essa informação é associada ao processamento de dados: informações que contemplam os processos de carga e atualização, processos de análise e administração. Nesse caso o objetivo é a geração de informações de gerência que incluem estatísticas do sistema para otimização de desempenho (padrões de uso, exigências de CPU e I/O, etc), como, por exemplo, para definir estruturas de índices ou agregações pré-computadas (DO e RAHM, 2000). A atualização de dados é baseada em metadados técnicos através do schedule de carga e de informação sobre o status de andamento dos processos Critério níveis de abstração Analogamente aos passos de projeto de banco de dados, o conhecimento pode ser provido em três níveis de abstração: conceitual, lógico e físico. A perspectiva conceitual inclui a descrição completa do negócio usando linguagem natural. Por exemplo, entidades principais de negócios como cliente e parceiro são definidas, enquanto suas características e relacionamentos com outras entidades são consolidadas. Regras que regem a extração/transformação são descritas por meio de linguagem natural para entendimento de qualquer usuário do sistema. Informações relativas ao uso do sistema, consultas definidas, visões e aplicações de análise existente estão neste nível. Metadados lógicos mapeiam a perspectiva conceitual em um nível mais baixo que inclui, por exemplo, o esquema relacional de banco de dados, e a descrição das regras de extração/transformação em pseudocódigo (ou usando uma linguagem matemática). A perspectiva física fornece o nível de implementação. Ela contém o código SQL correspondente à regra de negócio, índice de arquivos de relações e código de aplicações de análise Critério visão do usuário Esse critério é relativo ao objetivo informacional do metadado. A mesma informação e estrutura pode ser vista sob diferentes perspectivas, dependendo dos usuários que as utilizam. 44

46 Como conseqüência, metadado pode ser dividido em subclasses que satisfazem o interesse de certos grupos de usuários. Por exemplo, alguns metadados podem ser relevantes para certos departamentos, gerentes de conhecimento, usuários de negócio, ou usuários técnicos (administradores de DW, programadores de aplicações analíticas). Neste contexto, existe uma distinção entre metadados técnicos e de negócio. Metadados de negócio são necessários para usuários finais entenderem melhor a aplicação e assim usarem melhor a informação do sistema. Inclui documentação específica da aplicação (perfis de usuário, mapas de acesso, dicas de uso, ajuda navegacional), conceitos de negócio e terminologia, detalhes sobre consultas e relatórios pré-definidos. Outras informações também estão incluídas neste contexto como metadados, tais como: especificação de unidades de medidas, formato de dados ou dicionários, enciclopédia, e conhecimentos ontológicos de domínio específico. Em contraste, metadado técnico é usado por administradores de banco de dados que desenvolvem e mantêm o sistema e por programadores de aplicações analíticas Critério origem Essa classificação leva em consideração a origem do metadado: a ferramenta que o produziu (o componente ETL, uma ferramenta CASE usada durante o projeto do warehouse) e a fonte que o forneceu (o dicionário de dados dos sistemas operacionais, do DW ou DM). Metadados podem ser produzidos por alguns usuários do sistema (usuário de negócios, administrador de banco de dados), os quais seriam individualmente identificados Critério proposta Como um contraponto do critério anterior, um critério proposta ou uso pode ser usado para classificar os metadados de acordo com as atividades que exerce tais como: extração ou transformação, construção de uma visão multidimensional, mineração de dados, etc. Todavia, a distinção entre as diferentes classes é vaga, já que um metadado pode ser usado para a maioria das propostas: administração, manutenção, atualização e análise Critério tempo de produção/consumo 45

47 O metadado pode ser dividido de acordo com o tempo em que foi capturado ou gerado: # Metadado coletado em tempo de projeto (definição de esquema de banco de dados, direitos de acesso, regras de transformação, etc); # Metadado gerado em tempo de construção (arquivo de logs, métricas de qualidade de dados, etc); # Metadados gerados em tempo de execução (arquivos de logs, schedules, estatísticas de uso, etc). Outros esquemas de classificação também são encontrados na literatura. Embora com outras nomenclaturas, estes acabam se encaixando no esquema de classificação apresentado. Por exemplo, na visão de Erhard Rahm em (DO e RAHM, 2000), metadados são classificados segundo duas abordagens: metadados técnicos que está relacionado ao critério tipo da classificação anterior e metadados de negócio (critério visão do usuário ), associados à descrição de modelos e processos orientados a negócios. Ainda nesta visão, metadados de negócio incluem: modelos de informação para a representação de regras de negócio; modelos de negócio para a representação e associação de termos de negócio. Estes descrevem entidades relevantes em linguagem natural neste contexto, permitindo assim que o usuário crie consultas ad-hoc complexas usando apenas tais termos; modelos representativos que visualizam linhagem de dados (de onde o dado vem), precisão de dados (como o dado foi transformado), ou periodicidade de dados (quando ocorreu a última atualização). Ainda na visão de Erhard Rahm em (DO e RAHM, 2000) metadados (técnicos e de negócio) podem ser identificados dentro de uma arquitetura de Warehousing simplificada. Nesta abordagem utiliza-se uma arquitetura de três camadas, como ilustrado na FIG Na camada de mais alto nível encontra-se o nível de negócio, onde está situado o modelo conceitual corporativo. Nesse modelo estão representações de alto nível de um modelo de dados de negócio, seus conceitos e relacionamentos. Um importante componente deste nível é o modelo conceitual, que fornece ao usuário de negócio metadados de dimensões, categorias e agregações. 46

48 Consulta Navegação Mineração de OLAP Adhoc Dados FIG. 3.3 Gerência de Metadados em DW Na camada de DW estão os metadados que representam mapeamentos (processos ETL) entre elementos de negócio e elementos operacionais. Este tipo de arquitetura implementa o mapeamento entre os metadados técnicos e semânticos através de um repositório de metadados. Na camada do nível operacional estão os metadados técnicos, também chamados de metadados operacionais, onde coexistem as mais variadas fontes de dados, a exemplo de sistemas implementados num SGBD relacional e sistemas batch, que são baseados em arquivos. 3.5 Requisitos para Gerência de Soluções de Metadados A implementação de uma solução integrada de metadados deve considerar todos os aspectos da gerência estratégica de dados e metadados, uma vez que o objetivo é a garantia da qualidade de dados segundo métricas de qualidade pré-estabelecidas (POOLE et al, 2002). A seguir são enunciadas algumas estratégias a serem tomadas quando da implementação de uma solução de metadados: 47

49 ! Métricas de qualidade na implementação de metadados A estratégia de gerência de metadados se aplica a qualquer política de integração de dados em ambientes heterogêneos, de modo que todas as características estáticas e dinâmicas do ambiente estejam bem representadas por um metamodelo consistente. Dentro deste contexto, várias métricas precisam ser identificadas e definidas na implementação de uma solução de metadados.! Políticas de Segurança de Metadados Segurança é um aspecto importante da gerência de metadados (MARCO, 2000) e, conforme abordado anteriormente, é responsável por garantir o controle de acesso aos mesmos. Metadados registram informações importantes, sigilosas e estratégicas de negócio próprias para a tomada de decisão, requerendo, portanto, uma política de segurança adequada. Esta é independente de tecnologia, e como tal, deve ser implementada em qualquer tipo de sistema e plataforma.! Identificação de todos os metadados de origem e destino A gerência estratégica de metadados deve identificar todos os componentes dos sistemas possíveis que podem servir como produtores e/ou consumidores de metadados, além de definir todas as situações possíveis nas quais um produto ou ferramenta pode gerar. Segundo Poole et al (POOLE et al, 2002), a noção de um metadado de origem e de destino não é uma propriedade estática de um produto ou de uma ferramenta, mas um papel específico que pode ser assumido por um componente de software, em diferentes momentos e por diferentes razões. Para isso, cinco funções de metadados podem ser assumidas por componentes de software: Autor, Publicador, Proprietário, Consumidor e Gestor. O papel do Autor está relacionado à geração de metadados por componentes de software. Um exemplo de autor de metadados é uma ferramenta de modelagem de dados, que, através de sua funcionalidade, gera metadados referentes a um esquema pré-definido. Publicador torna elementos de metadados disponíveis a outros componentes de software, como por exemplo, a publicação dos metadados num repositório central. Propriedade é uma característica dinâmica, de modo que em um determinado instante, um componente de software assume a propriedade daquele elemento de metadados. Consumidor é qualquer componente de software que obtém uma cópia do elemento de metadados e a utiliza para alguma proposta. Gestor é o componente de software que assume a responsabilidade contínua de controle dos metadados.! Identificação de todos os elementos de metadados 48

50 A gerência estratégica de metadados deve considerar a forma pela qual um elemento de metadados pode ser unicamente identificado. Em geral, elementos de metadados podem ser rotulados com algum tipo de identificador único. Assim, uma estratégia de gerência de metadados deve definir uma política coerente, considerando como os elementos específicos podem ser identificados.! Acordo na definição semântica de cada elemento de metadados Um acordo completo deve existir em relação à semântica de cada elemento de metadados usado pelos componentes de software no Warehousing. Caso contrário, as ferramentas e produtos podem não ter um padrão comum de entendimento sobre o significado de um determinado elemento. Essa propriedade é algumas vezes referida como equivalência semântica. Um dado elemento de metadados é dito ser semanticamente equivalente ao dado que descreve, se todos os consumidores dos elementos de metadados podem usá-los para atingir algum entendimento do dado descrito.! Regras para compartilhar e modificar elementos de metadados A estratégia de gerência de metadados deve prover um conjunto geral de regras para o compartilhamento e atualização de metadados. Compartilhamento de metadados apenas para leitura é permitido, dentro de restrições de acesso bem definidas. Por exemplo, consumidores podem solicitar acesso a metadados a partir de certos repositórios ou a partir de certos publicadores de metadados.! Versionamento de metadados Durante a implementação de uma solução de metadados, um mecanismo de controle de versões de metadados deve ser aplicado com o objetivo de controlar suas atualizações. De maneira geral, a arquitetura de integração de metadados precisa controlar e publicar várias versões do metamodelo e metadados disponíveis no ambiente, além de prover meios para que componentes de software possam identificar e efetuar cópias das versões existentes.! Reuso de elementos de metadados Dentro do contexto de implementação de uma solução de metadados, torna-se necessária a config.ção dos elementos de metadados em um grau de equivalência semântica apropriado para reuso. A equivalência semântica garante a cultura de reuso em projetos de metadados, de forma que muitas redundâncias possam ser evitadas, assim como processos manuais possam ser substituídos por processos automatizados.! Eliminação de Metadados Redundantes 49

51 Um dos objetivos da estratégia de gerência de metadados é maximizar o compartilhamento e reuso de metadados. Deve-se garantir a unicidade do metadado ao longo do ambiente da solução, pois desta forma é possível aplicar uma boa política de proprietário do metadado. Assim, componentes de software podem criar cópias privadas de determinados elementos de metadados com o objetivo de melhor obter melhor desempenho da ferramenta. Os requisitos citados anteriormente são aplicados segundo alguma abordagem de implementação de metadados. Vaduva A. (STAUDT et al, 1999) apresenta três abordagens de implementação de metadados: # Ativa. Neste tipo de implementação, aspectos semânticos são armazenados e interpretados em tempo de execução. Diz-se para isso que o processo de DW é orientado a metadados. Para tanto, torna-se necessário o uso intensivo de um repositório de metadados. # Passiva. Neste tipo de implementação, metadado é usado sob forma de uma documentação consistente sobre a estrutura, processo de desenvolvimento e uso do DW. A documentação existente neste caso suporta todos os atores do sistema de DW (gerentes, administradores de banco de dados, desenvolvedores de aplicação) na realização de suas tarefas. # Semi-Ativa. Numa implementação semi-ativa, as informações estáticas do sistema (estruturas, definições, configurações e especificações) são armazenadas por componentes de software durante a execução. Por exemplo, interpretadores de consultas verificam metadados para avaliarem a existência de um atributo. Desta forma, metadado, em tempo de execução, é lido e não executado. Qualquer que seja a abordagem, a implementação de uma solução de metadados torna-se consistente quando é realizada sob a ótica de um padrão. Outras questões relativas à interoperabilidade e integração de esquemas surgem neste contexto, já que uma das grandes dificuldades no ambiente de Warehousing é garantir a equivalência semântica entre os metadados existentes nas diversas fontes de dados que caracterizam este mundo tão heterogêneo. 3.6 Padrões de Metadados para Data Warehouse No ambiente corporativo, muitas decisões são tomadas com base em informações imprecisas, e muito tempo tem sido gasto no entendimento de documentações incompletas. 50

52 Decisões estratégicas de negócios são baseadas no conhecimento gerado pelos sistemas de suporte à decisão (DSS Decision Suport System), e se tais sistemas geram conhecimento impreciso, as decisões de igual modo serão incoerentes. Metadados fornecem meios de representar o conhecimento dos processos de um DW, possibilitando a criação de mecanismos mais confiáveis de geração de informação para a tomada de decisão. Assim, com a crescente complexidade dos ambientes heterogêneos de computação que existem nas empresas, o termo metadado tem tomado novas formas e adquirido novos significados, ou seja, metadados são responsáveis agora não apenas por descrever catálogos de sistemas, mas também são responsáveis diretos pela criação de um ambiente integrado, propício para a geração de informações e gestão de conhecimento. Os sistemas estão cada vez mais sofisticados, e, nesse contexto, aparecem diversos tipos de solução (BARBIERI, 2001): SCM (Supply Chain Management). Sistemas responsáveis pela gerência de suprimentos, aquisição de insumos básicos e de componentes, fabricação e montagem, armazenamento, controle de estoque, gerência de requisições, distribuição através de canais e entrega ao cliente. Esse tipo de sistema controla toda a cadeia de suprimentos da empresa. CRM (Customer Relationship Manager). São sistemas responsáveis pelo tratamento com o cliente de uma empresa. Tais sistemas são responsáveis pela melhoria na qualidade das ações de marketing, vendas e serviços. Siebel é um tipo deste sistema. Billing. São os sistemas corporativos específicos para o faturamento. São muito usados por empresas que emitem grandes volumes de faturas, como é o caso de empresas no ramo de energia, gás e telecomunicações. Arbor é um exemplo deste tipo de sistema. ERP (Enterprise Resource Planning). Sistemas Integrados de Gestão. Um pacote de gestão ERP contempla a maioria dos sistemas operacionais da empresa, que são aplicados a áreas específicas da empresa (finanças, material, contabilidade, vendas). SAP R/3, BAAN e J.D. Edwards são exemplos deste tipo de sistema. EAI (Enterprise Application Integration). São sistemas que fazem uso da tecnologia de mediadores (middlewares) e lançam mão de recursos servidores de aplicação, gerentes de mensagens (message brokers), classes, objetos, interfaces, protocolos distribuídos para integrar as diversas aplicações existentes. 51

53 Tais soluções tendem a gerar verdadeiras ilhas de dados, pois cada uma possui sua forma particular de representar, acessar, gerar e manter os dados com segurança. Apesar de alguns dos sistemas citados se configurem como soluções de integração (ERP, EAI), acabam por gerar metadados proprietários que são exclusivos e apropriados para as próprias soluções, não criando assim um ambiente que proveja interoperabilidade de metadados. O problema de integração de metadados de DW é certamente complexo, uma vez que o ambiente de Warehousing é caracterizado por uma variedade de sistemas, tecnologias, plataformas, ferramentas e banco de dados. Assim, inúmeros metadados são gerados por diversas ferramentas, para diversos propósitos e para serem usados por diferentes usuários. Cada produto de software existente num Warehousing cria, modela e armazena um formato específico de metadados. Desta forma, cada produto cria interfaces de acessos aos seus metadados, o que também não garante que o metadado que está sendo acessado tem o mesmo significado em todas as ferramentas. Por exemplo, um servidor OLAP de um determinado fabricante foi projetado com uma definição interna de metadados que é ideal para o próprio servidor, mas não necessariamente apropriado para as várias ferramentas de relatório que precisam trabalhar com o mesmo. Na prática, ferramentas com diferentes metadados são integradas através de conectores (bridge) complexos de metadados (software de tradução de metadados). Tal conector precisa ter um conhecimento detalhado das estruturas de metadados e interfaces de cada produto que está tentando se integrar. Neste modo de implementação, configura-se um tipo de arquitetura de metadados conhecida como arquitetura de metadados ponto-a-ponto, onde cada ferramenta cria seu conector para acessar os metadados de outra ferramenta. Um ponto importante a ser garantido é a equivalência semântica de metadados, ou seja, embora utilizados para diferentes propósitos, metadados devem ter a mesma conotação em qualquer ferramenta. Essa restrição pode facilmente ser violada em ambientes marcados pela heterogeneidade de fontes de dados, pois diversas ferramentas criam e gerenciam metadados proprietários, e tal implementação, geralmente não é feita sob uma visão de integração. A necessidade por uma definição de metadados que seja universalmente entendido e que esteja globalmente disponível é parcialmente suprida através do uso de um Repositório de metadados. Este é um banco de dados de propósito especial que armazena, controla, e torna disponível ao resto do ambiente todos os componentes relevantes de metadados. Um Repositório de metadados contém uma definição única e global de metadado. Cada produto deve implementar seu próprio nível de acesso ao repositório (ainda sob a forma de 52

54 conectores), que entende a estrutura de metadados e sabe como mapear as estruturas específicas do repositório para a estrutura de metadados específico de cada ferramenta. Esse modo de implementação é chamado de arquitetura de metadados Hub-and-Spoke (POOLE et al, 2002). Nesse ponto, o repositório acaba se tornando um componente importante que precisa ser integrado. Nesse contexto, surge a necessidade de um padrão de metadados que forneça um modelo de metadados genérico, independente de plataforma, que possibilite a representação integrada dos metadados existentes no DW, e que garanta a equivalência semântica de metadados existentes neste ambiente. Atualmente, dois esforços de padronização de modelos de metadados se fundiram: OIM (Open Information Model) do grupo MDC (Metadata Coalition), e o CWM (Common Warehouse Metamodel) liderado pelo grupo de padronização OMG (OMG, 2000). Tal fusão objetiva a criação de um padrão de metadados mais robusto e que seja universalmente aceito. O CWM é um padrão específico, totalmente voltado para atender as necessidades de representação de metadados em ambientes de Warehousing, enquanto o OIM foi um padrão de metadados criado para uso de sistemas de informação de modo geral. Em função da importância do CWM no contexto deste trabalho, suas características e funcionalidades serão apresentadas nas próximas seções. 3.7 Common Warehouse Metamodel (CWM) O CWM [PCT + 02, OMG00] se propõe à integração e interoperabilidade de metadados segundo uma abordagem baseada num metamodelo. Essa abordagem elimina e reduz significativamente a complexidade associada à arquitetura de integração de metadados pontoa-ponto, baseada em conectores de metadados, além de prover o mesmo benefício de uma arquitetura hub-and-spoke. A abordagem baseada em metamodelo elimina a necessidade de construir múltiplos conectores com o propósito de integração. Ao invés disso, cada produto de software implementa um adaptador (um nível lógico de software) que entende o metamodelo comum. O adaptador é uma forma de conector, mas que precisa ser escrito apenas uma vez para cada produto. 53

55 A principal proposta do CWM é facilitar o intercâmbio de metadados comuns existentes no Warehousing entre ferramentas e repositórios em um ambiente distribuído e heterogêneo. Este padrão provê um framework para representação de metadados oriundos de fontes de dados, transformações, análise, processos e operações que criam e gerenciam o data warehouse, provendo uma linhagem de informação. A meta do CWM é padronizar o formato de troca de metadados para DW e BI (Business Intelligence), padronizando uma API para acesso a tais metadados. Para isso, o CWM usa uma abordagem orientada a modelo que consiste dos seguintes passos: 1. Definir o modelo de metadados compartilhado para o CWM (que é o metamodelo CWM) através da UML (Unified Modeling Language). 2. Gerar a especificação de um formato de troca para os metadados CWM em XML (extensible Markup Language). 3. Gerar a especificação de uma API para acessar os metadados CWM através da IDL (Interface Definition Language) CORBA (OMG, 2000). Os passos 2 e 3 são possíveis pelo uso do OMG MOF (Meta Object Facility) (OMG, 2000), e mais especificamente, o passo 2 é feito através do XMI (XML Meta data Interchange). O Metamodelo CWM consiste de um número de sub-metamodelos que representam metadados comuns de DW dentro dos principais focos de interesse de Business Intelligence: # Recursos de Dados Incluem metamodelos que representam recursos de dados orientado a objetos, relacional, registro, multidimensional e XML. # Análise de Dados Incluem metamodelos que representam transformações de dados, nomenclatura OLAP, Data Mining e visualização da informação. # Gerência de Warehouse Inclui metamodelos que representam processos e resultados de operações Padrões para o CWM 54

56 O CWM é baseado nos seguintes padrões do grupo OMG: UML, MOF (Meta Object Facility) uma metamodelagem padrão e XMI, um padrão baseado em XML para intercâmbio de metadados. Unified Modeling Language (UML) UML provê uma linguagem de modelagem orientada a objetos que pode ser usada para modelar diferentes aspectos de um sistema, tais como : # Modelagem Estrutural Enfatiza a estrutura dos objetos do sistema, incluindo suas classes, relacionamentos, atributos e operações. A modelagem estrutural consiste em modelar a estrutura estática pelo uso de diagramas de classes e de objetos, e a modelagem de implementação utiliza-se de diagramas de componentes; # Modelagem de Caso de Uso Enfatiza a funcionalidade do sistema tal como aparece aos usuários; # Modelagem de comportamento Enfatiza o comportamento de objetos do sistema, incluindo suas interações, eventos, controle e fluxo de dados. Os vários elementos da UML suportam os aspectos estáticos e comportamentais de sistemas discretos e orientados a objetos. Modelos estáticos da UML incluem a definição de classes, seus atributos, operações e interfaces. Relacionamentos comuns entre classes tais como generalização, associação, dependência e agregação podem ser especificados em UML e usados nos construtores de diagrama de classes. A linguagem UML é formalmente definida através de um metamodelo (ou modelo semântico), o qual é auto-definido, usando UML. O metamodelo CWM inclui um pacote Object Model, o qual é baseado em UML. Esse pacote abrange os aspectos mais relevantes no cenário de metadados. Meta Object Facility (MOF) MOF é um framework de objetos distribuídos orientado a modelo para especificar, construir, gerenciar, trocar e integrar metadados em sistemas de software. A meta do framework é suportar qualquer tipo de metadados e permitir que novos tipos sejam adicionados quando necessário. Para que isso aconteça, o MOF usa uma arquitetura de metadados de quatro níveis, como apresentado na TAB 1. Essa arquitetura trata metadados (M1) relativos a dado (M0) e formalmente modela cada tipo distinto de metadado. Esses 55

57 modelos formais, também chamados de Metamodelos (M2), são expressos usando os construtores de meta-metamodelagem (M3), o qual é chamado de meta-metamodelo MOF. A especificação MOF consiste das seguintes partes: # Modelo MOF Define os elementos de meta-metamodelagem, incluindo as regras para seu uso, os quais podem ser usados para construir metamodelos; # Interfaces MOF Permite um programa para criar, atualizar, acessar, navegar e executar operações nos metadados sem usar interfaces específicas do metamodelo; # Mapeamento MOF para IDL Estabelece o mapeamento padrão a partir de um metamodelo padrão definido usando o modelo MOF sobre IDL CORBA. Meta Nível Termos MOF Exemplos M3 Meta-metamodelo Modelo MOF M2 Metamodelo, Meta-meta dado Metamodelo UML, Metamodelo CWM M1 Modelo Modelos UML M0 Objetos, dados Sistemas Modelados, Dados Warhouse/BI TAB 3.1 Arquitetura de 4 níveis MOF Os três principais construtores de modelagem de metadados providos pelo MOF são classes, associações e pacotes. Classes podem ter atributos e operações. Atributos representam metadados. Operações dão suporte a um metamodelo específico à aplicação de funções sobre os metadados; Associações permitem ligações binárias entre instâncias de classes. Cada associação possui duas associações finais que podem especificar uma semântica de ordenação ou agregação, além de restrições estruturais de cardinalidade e unicidade; Pacotes são coleções de classes e associações relacionadas. Pacotes podem ser compostos pela importação ou herança de outros pacotes; O metamodelo CWM é projetado para maximizar o reuso do modelo de objetos (um subconjunto da UML) e compartilhar os construtores comuns quando possível. Este padrão 56

58 cobre grande parte dos metadados envolvidos num ambiente de DW provendo um framework com uma linguagem padrão, que permite definir a estrutura e semântica dos metadados de uma maneira formal. Além disso, define um mecanismo padrão de intercâmbio de metadados para resolver os problemas de integração e gerenciamento dos mesmos. Xml Metadata Interchange (XMI) A proposta de XMI é permitir o intercâmbio de modelos de uma forma serializada. O XMI pode ser visto como um formato de intercâmbio de metadados, independente de tecnologia. O XMI provê uma maneira possível de troca de metadados com repositórios que não possuem metamodelos baseados em MOF. Esse intercâmbio pode ser feito através de mapeamentos entre os documentos XMI e os metamodelos nativos de cada repositório. Além disso, o XMI suporta qualquer intercâmbio de metadados, desde que estes sejam expressos usando a especificação MOF. O CWM usa XMI como mecanismo de intercâmbio de metadados. Uma Definição de Tipo de Documento (DTD) padrão é gerada usando as regras de produção de DTD s XMI Arquitetura do CWM No seu núcleo, o CWM é um conjunto de extensões da arquitetura de metamodelos do OMG, que é otimizado para as necessidades e propostas do domínio de um Warehousing e Bussiness Intelligence. O CWM possui uma arquitetura modular, em pacotes (packages), construída sob os fundamentos da orientação a objetos, e projetado para representar uma grande faixa de metadados em ambientes de Warehousing com alto grau de heterogeneidade. A primeira versão do CWM continha 200 classes, 21 pacotes e centenas de relacionamentos. Para melhor entendimento dos pacotes o CWM foi organizado em cinco níveis funcionais, como ilustrado na FIG

59 FIG. 3.4 CWM organizado em níveis funcionais (OMG, 2000) O nível mais baixo da FIG. 3.4 se refere ao nível de objeto (Object Layer). Esse nível é herdado da UML e usado no CWM como metamodelo base. O nível de objeto consiste de quatro metamodelos: Core (Núcleo), Behavioral (Comportamental), Relationships (Relacionamento), e Instance (Instância). O metamodelo Core inclui a infraestrutura básica da UML necessária para definir repositórios de dados não orientados a objetos, tais como banco de dados relacionais e arquivos. O metamodelo Behavioral estende as estruturas estáticas para definir comportamentos, tais como operações e procedimentos. O metamodelo Relationships define os relacionamentos entre os elementos do modelo, tais como associações entre tabelas e colunas. O metamodelo Instance define os elementos de modelagem para representar as instâncias atuais de elementos de um metamodelo (por exemplo, a associação entre uma classe e um objeto específico, como uma instância de uma classe, podendo ser modelada usando construtores do metamodelo Instance). O CWM usa o conceito de herança para estender os elementos de modelagem desse subconjunto da UML e para definir novos elementos de modelagem representando conceitos de DW e Análise de Negócios. O próximo nível, denominado Foundation, consiste de metamodelos que estendem os elementos de modelagem do nível de objetos para produzir representações de serviços comuns exigidos pelos componentes do Warehousing. Este nível é constituído de metamodelos que suportam a modelagem de elementos estruturais básicos, como por exemplo, chaves, índices, expressões, tipos de dados e componentes de software. Por exemplo, o metamodelo Data Types estende certos elementos de modelagem para definir novos elementos que permitem representar tipos de dados expressos como metadados. 58

60 O nível Resource define metamodelos de vários tipos de recursos de dados contidos num Warehousing. Os metamodelos Relational, Record, Multidimensional e XML estendem os níveis Object e Foundation para definir novos elementos de modelagem usados para construir definições de metadados oriundas de banco de dados relacionais, servidores multidimensionais, e recursos de dados baseados em documentos XML. Conceitos de Análise de Negócio são representados por metamodelos contidos no quarto nível do CWM, o nível Analysis. O metamodelo mais importante deste nível é o metamodelo Transformation. Esse metamodelo define elementos que podem ser usados para especificar mapeamentos de transformações de dados entre elementos de origem e destino. Finalmente, o nível Management define metamodelos essenciais para definir metadados para gerência dos processos do Warehousing como um todo. Um deles é o Warehouse Operation, que define elementos usados para construir metadados específicos e operações de rotina, tais como eventos escalonados e suas interdependências. Esses metadados são de interesse para ferramentas ETL, Schedules, e outras ferramentas de gerência do Warehousing Escopo do CWM O CWM identifica todos os aspectos orientados a modelo para a integração de metadados, porém certos aspectos da integração estão além do seu escopo, a saber: CWM não prescreve qualquer arquitetura de implementação. CWM é um modelo de uso, e não um modelo de implementação. Como modelo de uso, os vários elementos de modelagem do CWM são usados para definir interfaces padrões (em termos de XML ou na forma de interfaces programáveis) de acesso aos metadados que representam. CWM não define qualquer arquitetura de repositório. Todavia, a derivação do CWM a partir do MOF implica que um repositório de metadados baseado em CWM deve suportar certos serviços de metadados exigidos por todos repositórios baseados em MOF. CWM não define uma estratégia para gerência de metadados. Apesar de uma estratégia de gerência de metadados ser a chave do sucesso da aplicação de uma solução integrada, o CWM não define esse aspecto. CWM não define uma arquitetura de integração de dados. A arquitetura de metadados segue a mesma idéia da estratégia de gerência de metadados. 59

61 3.7.4 Pacotes do CWM para Representação de Transformações e Linhagem de Dados Tendo em vista o objetivo deste trabalho, alguns pacotes do CWM serão apresentados em seguida com maior nível de detalhes. Estes pacotes serão utilizados como metamodelos base para representação de transformações e linhagem de dados em ambientes de Warehousing. Relational Package O Pacote Relacional do CWM, componente do nível Resource (FIG. 3.4), fornece um metamodelo capaz de representar metadados de interfaces relacionais, através do mapeamento de metadados de um SGDBR (Sistema de Gerência de Banco de Dados Relacional), por exemplo. O Pacote Relacional é baseado no padrão SQL. O repositório de mais alto nível, o Catalog, representa um catálogo de banco de dados, contendo todas as tabelas que usuários podem acessar com uma única cláusula SQL. Um catálogo (Catalog) também é a unidade que é gerenciada pelos recursos de dados. Um Catálogo contém esquemas (Schemas), os quais contêm tabelas (tables). Tabelas são formadas por colunas (columns), as quais possuem um tipo de dado (data type) associado. O Pacote Relacional também aborda as características de indexação, chaves primárias e chaves estrangeiras através da extensão aos conceitos correspondentes dos pacotes fundamentais do CWM (CWM Foudation Package). A FIG. 3.5 apresenta o metamodelo do Pacote Relacional que expressa metadados para tabelas, colunas e tipos de dados. A classe ColumnSet (conjunto de colunas) representa qualquer forma de dado relacional. Uma tabela é catalogada como sendo uma versão de um NamedColumnSet. Uma tabela pode ser uma visão lógica (View) ou uma tabela física (BaseTable). A classe ColumnSet possui também como subclasse a classe QueryColumnSet, que representa o resultado de uma consulta SQL. Colunas são associadas a um tipo de dado, representado pela classe SQLDataType. Esta classe é especializada em duas subclasses: SQLSimpleType e SQLDistinctType. A primeira classe representa os tipos simples definidos pela maioria dos SGBDRs, a segunda representa tipos distintos formados a partir de tipos simples. 60

62 FIG. 3.5 Metamodelo Relacional para Tabelas, Colunas e Tipos de Dados (OMG, 2000) Expression Metamodel O metamodelo de expressões provê suporte básico para a definição de árvores de expressão no CWM. O objetivo do metamodelo de expressões é prover um meio a outros pacotes do CWM como o Pacote de Transformação (Transformation Package), por exemplo a compartilharem expressões numa forma comum, que possa ser usada para interoperabilidade e linhagem de dados. O conceito de expressão no CWM leva a uma visão funcional de árvores de expressão, resultando na capacidade de expressar diversos tipos de funções. Toda função ou operador matemático que aparece numa expressão hierárquica é representado através da classe FeatureNode. Por exemplo, o operador aritmético + usado na expressão a + b pode ser representado pela função SOMA(a,b). A natureza hierárquica da representação de expressões no CWM é alcançada pela natureza recursiva da associação OperationArgument. A associação permite sub-hierarquias dentro de uma expressão. 61

63 Por exemplo, considere a famosa equação de Einstein E=mc 2. Para melhor entendimento de como a equação é mapeada numa árvore de expressões, a fórmula pode ser reescrita numa notação funcional como: Assign(E,Multiply(m,Power(c,2))). Essa forma funcional da equação é então mapeada em um conjunto de instâncias de uma árvore de expressão como mostra a FIG FIG. 3.6 Árvore de Expressão CWM para a fórmula E=mc 2 (OMG, 2000). Para armazenar uma expressão no pacote de expressões do CWM (Expression Package), ela deve ser convertida para uma forma compatível com a estrutura de classes do pacote, conforme ilustrada na FIG A princípio, qualquer expressão, independente da linguagem em que foi escrita, pode ser convertida para uma seqüência de chamadas de funções (aninhadas). Considere a expressão usada no exemplo anterior. Para colocar uma expressão funcional no CWM, primeiro deve-se definir cada uma das funções como operações de algum classifier. Assim, operações como Assign, Multiply, e Power serão criadas. O segundo passo se refere à criação de atributos para definir as variáveis E, m, e c, e criar instâncias para assegurar seus valores. Finalmente, a criação de instâncias da classe FeatureNode para cada uma das funções e instâncias da classe ConstantNode para armazenar constantes usadas numa expressão. Expressões funcionais podem ser armazenadas através de uma estrutura hierárquica. Uma expressão é gerada através da associação argument entre as classes FeatureNode e 62

64 ExpressionNode. A classe ElementNode se associa com o metamodelo de elementos para representar colunas de tabelas, campos de um Flat File, ou ainda elementos de documento XML, podendo todos esses elementos serem usados no contexto de árvores de expressão. FIG. 3.7 Metamodelo de Expressões Transformation Package O pacote de transformações contém classes e pacotes que representam metadados de transformações usadas num Warehousing. Ele cobre transformações básicas entre todos os tipos de dados de origem e destino: orientado a objetos, relacional, registros, multidimensional, XML, OLAP e Data Mining. O pacote de transformações foi projetado para permitir o intercâmbio de metadados entre ferramentas de transformação e atividades, e especificamente: $ Relacionar transformações com fontes de dados de origem e destino, que podem ser de qualquer tipo (orientado a objetos, relacional) ou granularidade (classe, atributo, tabela, coluna), podendo ser persistentes (armazenados num banco de dados relacional) ou transientes; $ Permitir tanto representação para transformações caixa branca (conhecidas) ou transformações caixa preta (desconhecidas); 63

65 $ Permitir o agrupamento de transformações em unidade lógicas. No nível funcional, uma unidade lógica define uma única unidade de trabalho, com a qual todas as transformações devem ser executadas e finalizadas juntas. No nível de execução, unidades lógicas podem ser usadas para definir um agrupamento de execução e seqüência. Em conjunto com o pacote Warehouse Process, transformações podem ser programadas para a execução. Desse modo, transformações podem operar em seqüência, passando por conjuntos intermediários de transformações subseqüentes. O pacote de transformação contém metamodelos que representam as seguintes funções: Transformação e Linhagem de Dados; Agrupamento e Execução de Transformações; e Transformações especializadas. A TAB 3.2 apresenta as classes relacionadas com as principais funcionalidades do pacote de transformação. Área Funcional Classes Associações Transformação e Linhagem de Transformation / TransformationSource Dados DataObjectSet TransformationUse / TransformationTarget / DataObjectSetElement Agrupamento e Execução de TransformationTask / TransformationTaskElement Transformações TransformationStep TransformationActivity / InverseTransformationTask / TransformationStepTask PrecedenceConstraint StepPrecedence Transformações especializadas TransformationMap ClassifierMap FeatureMap ClassifierFeatureMap TransformationTree / ClassifierMapSource / ClassifierMapTarget / FeatureMapSource / FeatureMapTarget / CFMapClassifier / CFMapFeature TAB 3.2 Áreas funcionais do Transformation Package Uma transformação transforma um conjunto de objetos de origem num conjunto de objetos de destino. Os objetos utilizados numa transformação são representados pela classe DataObjectSet. Os elementos de um conjunto de objetos de dados podem ser quaisquer elementos do modelo de objetos do CWM (ObjectModel), mas geralmente são tabelas, colunas, ou elementos do modelo que representam objetos transientes em memória. Os 64

66 elementos do modelo de objetos podem ser tanto origem quanto destino em diferentes transformações. Transformações permitem uma grande faixa de tipos (e granularidade) a ser definida como elementos de origem e destino. Por exemplo, a origem de uma transformação pode ser um esquema XML enquanto o destino pode ser uma coluna de uma tabela. Transformações podem ser agrupadas em unidades lógicas (FIG. 3.8). No nível funcional, são agrupadas em tarefas (TransformationTasks), que definem um conjunto de transformações que podem ser executadas de forma atômica, como uma unidade lógica. No nível de execução, passos (TransformationSteps) são usados para coordenar o fluxo de controle entre as tarefas. Os passos são agrupados em atividades (TransformationActivities), que representam uma unidade lógica de mais alto nível e que contém a seqüência de execução dos passos de transformação. Transformações podem operar seqüencialmente, passando por resultados intermediários de transformações subseqüentes. Transformações podem ser caixa preta ou caixa-branca. Transformações caixa-preta são aquelas que são aplicadas num alto nível de granularidade, ou seja, aplicadas em componentes ou sistemas inteiros. Transformações caixa-branca são aplicadas num baixo nível de granularidade, transformando classes e atributos. Transformações podem ser aplicadas a objetos de diferentes níveis de granularidade, tais como mover um documento XML inteiro para uma tabela, se a semântica da situação exigir, por exemplo. Transformações podem ser representadas sob o ponto de vista seqüencial através da classe StepPrecedence, onde é possível representar a seqüência de passos e tarefas usadas na aplicação de transformação de dados. 65

67 FIG. 3.8 Metamodelo de Transformações OLAP Package OLAP (Online Analytical Processing) é uma classe de aplicações analíticas que expõe os dados de negócio num formato multidimensional. O objetivo das aplicações OLAP é a construção eficiente de modelos analíticos que transformam dados de negócio brutos em percepções de negócio. As características comuns de sistemas OLAP são: representação multidimensional de dados de negócio; capacidade de navegação pelas hierarquias; suporte à análise de séries temporais 66

68 O OLAP Package (FIG. 3.9) do CWM define um metamodelo para a representação de conceitos essenciais usados pelas aplicações OLAP, além da possibilidade de mapear estruturas multidimensionais em recursos físicos (através do Relational Package). A classe Schema representa um repositório que contém dimensões (classe Dimension) e cubos (classe Cube). Uma dimensão é um ordenada com uma estrutura multidimensional e consiste de uma lista de valores únicos que compartilham da mesma semântica do domínio que está sendo modelado. Um cubo é uma coleção de valores analíticos (métricas), que compartilham a mesma dimensionalidade. CubeDimensionAssociation associa um cubo às dimensões definidas. Uma dimensão possui zero ou mais hierarquias Uma hierarquia (classe Hierarchy) é uma estrutura organizacional baseada no relacionamento pai/filho entre membros de uma dimensão. A classe MemberSelection modela mecanismos capazes de particionar uma coleção de membros de uma dimensão. A classe CubeRegion é usada para representar cubos. Um cubo pode ser construído por um conjunto de CubeRegions que mapeiam porções de um cubo lógico em fontes físicas de dados. Um CubeRegion pode possuir qualquer número de CubeDeployments. CubeDeployment é uma metaclasse que representa uma estratégia de implementação para uma estrutura multidimensional. FIG. 3.9 Metamodelo OLAP 67

69 3.7.5 Considerações Finais Este capítulo abordou as questões pertinentes ao aspecto de gerência de metadados no contexto de DW através da apresentação de tópicos relevantes como: conceituação, benefícios, requisitos de implementação e padrões de metadados. Esta abordagem tenta resolver problemas de interoperabilidade de metadados e integração de dados num DW através da utilização de um padrão de metadados que seja completo o suficiente para representar os metadados no domínio de um Warehousing e garantir a equivalência semântica com relação aos metadados representados. Através de um padrão de metadados como o CWM, é possível também definir mecanismos de linhagem de dados e, dessa forma, conduzir o processo de gerência de processos de um DW de modo mais transparente e confiável. O CWM foi o padrão adotado por ser específico para DW (diferentemente do OIM, que é voltado para sistemas de informação de um modo geral), e por possuir os pacotes essenciais para a representação dos metadados existentes num processo ETL, tão crucial no processo de linhagem de dados. Porém, para que esses metadados possam ser utilizados neste processo, precisam ainda ser trabalhados a partir da integração de pacotes disponibilizados pelo CWM. A formalização e estudo dos problemas relativos à linhagem de dados serão vistos no próximo capítulo. 68

70 A CAPÍTULO 4 A 4. LINHAGEM DE DADOS E METADADOS EM AMBIENTES DE WAREHOUSING O objetivo deste capítulo é apresentar a abordagem de linhagem de dados e estender este conceito para propor uma abordagem de linhagem de metadados através de transformações existentes no ambiente de DW. Para isso serão usados os metamodelos do CWM vistos no capítulo 3, aplicados aqui de forma integrada. Além disso, será apresentada uma extensão aos metamodelos dos pacotes de transformação e relacional para atenderem às novas exigências de visualização de linhagem de dados no espaço ASPJ (Agregação, Seleção, Projeção e Junção), e linhagem de metadados aplicada a transformações categorizadas. 4.1 Qualidade em Data Warehouse Um DW pode ser entendido (Vassiliadis, 2000) como um conjunto integrado de tecnologias que visa a geração de conhecimento para a tomada de decisão. Pesquisadores e práticos da área de DW entendem que a arquitetura de um DW pode ser definida como níveis de visões materializadas, de forma que dados pertencentes a um nível são derivados de um nível inferior. As fontes de dados operacionais correspondem ao primeiro nível, onde se encontram sistemas legados, com dados estruturados, semi-estruturados ou não-estruturados encontrados em arquivos. O nível principal desta arquitetura é o DW propriamente dito, onde são mantidos os dados históricos necessários à tomada de decisão. Tais dados são resultado de transformação, integração e agregação de dados detalhados encontrados nas fontes de dados operacionais. Usualmente um depósito de dados volátil, de baixa granularidade, é utilizado para a integração de dados de várias fontes: o Depósito de Dados Operacionais (ODS Operational Data Store). Este depósito serve como um buffer para a transformação e higienização de dados. O último nível de visões é a visão cliente, na qual dados altamente sumarizados são acessados pelos usuários do DW. Considerando a arquitetura de um DW como uma arquitetura de visões dependentes, faz-se necessário garantir a qualidade dos dados gerados em cada uma das visões a fim de se evitar que um erro na geração de um item de dado numa visão se propague para as visões subseqüentes, gerando agregados inconsistentes. 69

71 Qualidade de dados tem sido definida como a fração de desempenho sobre a expectativa (BESTERFIELD, 1995). Apto para o uso, é outra definição para qualidade de dados (ORR, 1998). Essas definições tornam o conceito de qualidade de dados relativo, de modo que cada usuário interpreta a informação de maneira distinta, de acordo com o seu escopo de atuação. Cada usuário distinto do DW enxerga uma visão específica, e, para cada um deles, pode-se definir um conjunto de métricas que garantam a qualidade total do DW. Precisão, disponibilidade, acessibilidade e desempenho são métricas de qualidade exigidas pelos usuários finais do DW. Detecção de mudanças, acesso aos metadados, relatórios de erros são algumas das métricas com as quais os administradores do DW asseguram a qualidade. Dada a complexidade relativa ao aspecto de qualidade de um DW, modelos e ferramentas para a gerência de qualidade do DW têm sido propostos. Wang (WANG et al, 1995) apresenta um framework de análise de dados, baseado no padrão ISO O framework consiste de sete elementos adaptados do padrão ISO 9000: gerência de responsabilidades, custo de operação, pesquisa e desenvolvimento, produção, distribuição, gerência pessoal e função legal. No que diz respeito à qualidade de dados, os itens pesquisa e desenvolvimento são fatores relevantes, pois são considerados a análise e projetos de produtos de dados e projetos de sistemas de dados manufaturados. Na área de projeto de sistemas que visam garantir a qualidade de dados, uma técnica de trajeto de dados (data tracking) é proposta (PAUTKE e REDMAN, 1990). Essa técnica utiliza uma combinação de controle estatístico e identificação manual de erros e suas fontes. Outros trabalhos têm sido propostos na definição de qualidade de dados em dimensões, onde são definidas métricas como: precisão (conformidade do valor armazenado com o atual), periodicidade (valor armazenado está desatualizado) e consistência (uniformidade de representação do dado). A falta de qualidade no Warehousing pode gerar impacto em vários aspectos deste ambiente, como por exemplo: perda de desempenho dos sistemas e conseqüente insatisfação dos usuários, além do aumento dos custos com a manutenção dos sistemas por falta de padronização. Um problema crucial no que tange ao aspecto de qualidade no DW é em relação à qualidade de dados, pois esse problema tem impacto direto na tomada de decisão. Theodoratos e Bouzeghoub (THEODORATOS e BOUZEGHOUB, 1999) propõem como métrica de qualidade de dados no DW a consistência de dados. Um sistema de DW está consistente se satisfaz às seguintes propriedades: 70

72 a) Após um número de atualizações serem aplicadas às relações de origem, o estado das visões materializadas no DW deve eventualmente refletir o estado final das relações de origem; b) O estado de cada visão materializada no DW num dado momento t reflete algum estado anterior das relações de origem; c) Os estados de uma visão materializada, definida usando alguma relação de origem R, em momentos t 1 e t 2, onde t 1 < t 2, reflete o estado da relação R nos momentos t 1 e t 2, onde t 1 < t 2. O processo de carga dos dados no DW é uma tarefa de grande importância no DW. Fatores de qualidade relacionados a esse processo podem ser mapeados:! Suporte à Análise. Esse fator se refere à validação de cada processo e sua interação com o usuário (geração de relatórios ao final de cada operação, especialmente em casos de erro).! Disponibilidade Transacional. Esse fator se refere ao percentual de tempo no qual a informação no DW ou na origem dos dados estava disponível na ausência de processos de carga. As necessidades de qualidade de dados num Warehousing podem ser supridas pela implementação de mecanismos eficientes de linhagem de dados, de modo a garantir o conhecimento global dos processos de geração de informação. 4.2 Linhagem de Dados Os usuários finais do DW (diretores, gerentes, etc..) atuam solicitando visões que geram dados sumarizados, usados como base analítica para a tomada de decisão. Isso exige total confiança na geração do dado, ou seja, o usuário assume como verdade a qualidade do dado em todas as visões geradas, desde a origem dos dados no ambiente operacional, até a sua sumarização pela ferramenta OLAP (Online Analytical Processing). Intuitivamente (CUI et al, 2000), o problema da linhagem de dados pode ser entendido como: dado um item de dado numa visão materializada, determinar a fonte de dado que o produziu e o processo pelo qual este item de dado passou desde a sua origem até a sua composição num dado agregado. De fato, o uso do processo de linhagem de dados através de uma ferramenta específica, em muito pode beneficiar uma variedade de aplicações, a exemplo de: 71

73 # OLAP e OLAM Mineração e análise de dados requerem facilidades de exploração de dados em diferentes níveis. A habilidade de selecionar uma porção relevante de uma visão e navegar até a origem dos dados é muito útil quando se analisam dados gerados por tais ferramentas; # Banco de Dados Científicos Cientistas aplicam algoritmos para a geração de visões derivadas na definição da origem de dados. Como uma ferramenta OLAP, isso pode ser útil para que cientistas foquem numa parte específica do dado e explorem como o dado atual foi gerado a partir do dado bruto; # Sistemas de Diagnósticos e Monitoramento de Rede Online Através de visões de dados computadas pelos sistemas de diagnósticos, um controlador pode identificar, através da linhagem de dados, falhas na transmissão de dados; # Avaliação de Esquema de Visões Materializadas Num DW usuários podem definir visões (como por exemplo, adicionar uma coluna). A linhagem de dados pode ajudar a reconstruir uma nova visão sem precisar recalcular a visão inteira; # Análise de Dados em Sistemas de Apoio a Decisão A linhagem de dados permite que seja feita uma análise mais precisa e automatizada de identificação das origens de um item de dado sem que seja preciso navegar por todos os processos de geração de visões existentes nestes tipos de sistemas. Uma visão provê o mapeamento do dado de origem num dado da visão. Desta forma, através de um dado de origem é possível conhecer o dado que será criado na visão através da definição da visão. Todavia, determinar o mapeamento inverso a partir de um item de dado de uma visão voltar ao item de dado original (back tracing) não é trivial. Para determinar o mapeamento inverso com precisão, é necessário conhecer, além da definição da visão, algumas informações adicionais. O ambiente de Warehousing introduz alguns desafios adicionais ao problema de linhagem de dados, como, por exemplo, identificar e representar o trajeto de geração de um item de dado quando a base de dados está distribuída em múltiplas fontes. O exemplo a seguir ilustra o problema de linhagem de dados. 72

74 S_ID S_NOME CIDADE ESTADO 001 Renner Salvador BA 002 Renner Rio de Janeiro RJ 003 Benetton Ilhéus BA 004 Benetton Niterói RJ TAB 4.1 Tabela LOJAS I_ID I_NOME CATEGORIA 0001 Agenda Escritório 0002 Lapis Escritório 0003 Camisa Vestuário 0004 Calça Vestuário 0005 Panela Cozinha TAB 4.2 Tabela ITENS SID I_ID PRECO NUM TAB 4.3 Tabela VENDAS A TAB 4.1 apresenta uma tabela Lojas, cujos itens de cada loja são mostrados na TAB 4.2, e a TAB 4.3 apresenta a tabela Vendas contendo os fatos do DW, ou seja, os totais de itens vendidos pelas lojas e seus respectivos preços. Suponha que um analista deseje seguir os padrões de vendas das lojas da Bahia (BA). Uma visão materializada vbahia pode ser definida, como apresentado a seguir: CREATE VIEW vbahia AS SELECT S_NOME, I_NOME, NUM FROM LOJAS, ITENS, VENDAS WHERE VENDAS.S_ID = LOJA.S_ID AND VENDAS.I_ID = ITENS.I_ID AND LOJA.ESTADO = BA 73

75 A TAB 4.4 apresenta a visão vbahia. S_NOME I_NOME NUM Renner Agenda 1000 Renner Lapis 3000 Renner Calça 600 Benetton Camisa 1500 Benetton Calça 600 TAB 4.4 Visão vbahia Suponha que observando a visão vbahia, o analista queira saber quais dados de origem produziram a tupla <Renner, Lápis, 3000>. A linhagem da tupla em questão produziu as seguintes relações: S_ID S_NOME CIDADE ESTADO 001 Renner Salvador BA TAB 4.5 Tupla original da tabela Lojas I_ID I_NOME CATEGORIA 0002 Lápis Escritório TAB 4.6 Tupla original da tabela Itens S_ID I_ID PRECO NUM TAB 4.7 Tupla original da tabela Vendas As TABs 4.5, 4.6 e 4.7 apresentam as tuplas originais das tabelas Lojas, Itens e Vendas respectivamente, que geraram a tupla <Renner, Lápis, 3000> na visão vbahia Derivação de Tuplas de Visões A linhagem de dados considera a derivação de tuplas, que corresponde ao conjunto de tuplas de uma relação base que produzem uma tupla de uma visão. Com base no estudo realizado por Cui e Widom (CUI et al, 2000), serão consideradas algumas definições básicas relevantes para a formalização do processo de linhagem. Seja R uma relação, com um esquema S contendo um conjunto de tuplas {t 1,...,t n }, e um banco de Dados D contendo uma lista de tabelas < R 1,..., R m >. Uma visão V é um resultado virtual ou materializado de uma consulta sobre tabelas base de D. A consulta é chamada de definição de visão, denotado como v. Diz-se que R 1,..., R m deriva V se V = v(r 1,...,R m ). 74

76 As visões utilizadas no contexto da linhagem de dados utilizam os operadores da álgebra relacional sobre relações base, os quais são: seleção (σ), join ( X ), agregação (α), união ( ), projeção ( ) e diferença (-). O conceito de derivação pode ser entendido assumindo-se que o conteúdo de uma visão é computado através da avaliação de uma árvore de consulta numa abordagem bottomup, ou seja, do conceito específico para o conceito mais geral. Desta forma, é gerada uma árvore de tabelas resultantes da aplicação dos operadores da álgebra relacional. De acordo com a semântica relacional, cada operador pode gerar seu resultado tupla por tupla sobre os operandos, que neste caso são tabelas. De maneira intuitiva, dada uma tupla t no resultado de um operador Op, algum conjunto das tuplas de entrada produziu t. Diz-se então que tuplas neste subconjunto contribuem para a geração de t, e que um subconjunto inteiro é a derivação de t. A FIG. 4.1 ilustra a derivação de uma tupla. Nesta FIG., o operador Op é aplicado às tabelas R 1 e R 2, que podem servir como tabelas base ou resultados temporários para outros operadores. A tabela R é o resultado da operação. Dada uma tupla t em R, apenas os subconjuntos R * 1 e R * 2 das tabelas R 1 e R 2 contribuem para t. < R * 1, R * 2 > é conhecido como derivação de t. FIG. 4.1 Derivação da Tupla t Formalmente, a derivação de tuplas pode ser definida da seguinte forma: Seja um operador relacional Op, sobre tabelas R 1,..., R m, e seja R = Op(R 1,...,R m ) a tabela resultante da aplicação de Op em R 1,..., R m. Dada uma tupla t R, define-se a derivação de R em R 1,..., R m de acordo com Op como sendo Op -1 < R 1,..., R m > (t) = < R * 1,, R * m >, onde R * 1,, R * m são subconjuntos maximais (CUI et al, 2001) de R 1,, R m tais que : 1. Op(R * 1,, R * m) = {t} 2. R * i : t* R * i : Op(R * 1,, {t*},,r* m ) 75

77 Pode-se dizer que Op R -1 i (t) = R i * é a derivação t de R i e cada tupla t em R i * contribui para t, onde i = 1,...,m. FIG. 4.2 Derivação de Tupla por Agregação A FIG. 4.2 exemplifica uma derivação de tupla utilizando o operador de agregação α. Dada uma tabela R e uma tupla t = <5,7> α X,sum(Y) R, a derivação da tupla t é dada por: α -1 X,sum(Y) R(<5,7>) = {< 5,2>,< 5,4>, < 5,1> } A aplicação de linhagem de dados no ambiente de warehouse garante a qualidade dos dados, pois é possível determinar o conteúdo que originou o dado em qualquer ponto do processo de geração de visões materializadas. A linhagem de dados (GFS01, CW01) possibilita ao usuário do warehouse investigar dados intermediários e capturar exceções, além de fazer o caminho inverso (back tracing) dos processos de higienização de dados através de um grafo de transformações. Usuários do DW podem interagir com o grafo que representa o fluxo de dados do processo de criação de visões e assim aplicar algumas correções como forma de refinamento da informação. O warehousing, sob o ponto de vista de linhagem de dados, tenta resolver o problema da qualidade de dados sob a abordagem de gerência de conteúdo, gerando a tupla de origem para uma dada tupla numa relação destino, considerando os operadores da álgebra relacional. No entanto, dada a complexidade de algumas transformações no ambiente de Warehousing, a exemplo das que geram hipercubos, o problema de linhagem de dados nem sempre é resolvido apenas pelos operadores primários da álgebra relacional. Por exemplo, uma transformação que aplica uma fórmula numa coluna de uma tabela. Para que se faça linhagem para uma transformação desse tipo todas as propriedades da fórmula deveriam estar armazenadas, incluindo a seqüência e semântica de cada operador da fórmula, o que caracteriza um processo não trivial de linhagem de dados. 76

78 No escopo desse trabalho trataremos da linhagem de dados resolvida exclusivamente no âmbito dos operadores da álgebra relacional, isto é, os operadores ASPJ. A garantia de qualidade da informação para um ambiente que almeja tanto a precisão na tomada de decisão quanto a geração de conhecimento corporativo, deve considerar um projeto bem definido e consolidado de metadados. 4.3 Transformações e Linhagem de Dados Nesta seção será apresentada uma formalização (CUI et al, 2001) que generaliza transformações num Warehousing, usadas como base para um processo de linhagem de dados Transformações Seja um conjunto qualquer de itens de dados tuplas, valores, objetos complexos. Uma transformação T é qualquer procedimento que recebe um conjunto de dados de entrada e produz um conjunto de dados de saída. Para qualquer conjunto de dados de entrada I, é possível dizer que a aplicação de T sobre I resulta no conjunto de dados de saída O, denotado por T ( I ) = O, que é uma instância de T. Dada duas transformações T 1 e T 2, sua composição T = T 1 o T 2 é a transformação que aplica T 1 a I obtendo I, e T 2 a I obtendo O. T 1 e T 2 são conhecidas como transformações componentes de T. Uma transformação que não está definida como uma composição de outras transformações é conhecida como transformação atômica. Para a definição acima, considera-se que todas as transformações são estáveis e determinísticas. Uma transformação T é estável se ela nunca produz itens de saída incorretos, ou seja, T( ) =. Uma transformação T é determinística se ela produz a mesma saída dada a mesma entrada. Um exemplo de transformação instável é aquela que agrega um item de dado fixo de saída para cada item de entrada, independente da entrada. Uma transformação não determinística é aquela que transforma randomicamente uma amostra do conjunto de entrada em um conjunto de dados de saída. 77

79 4.3.2 Linhagem de Dados Em geral uma transformação pode inspecionar o conjunto inteiro de dados de entrada e produzir cada item de dado no conjunto de dados de saída, porém na maioria dos casos existe um relacionamento mais tênue entre os itens de dado de entrada e de saída: um item de dado o no conjunto de dados de saída pode ter sido derivado de um pequeno subconjunto de itens de dados de entrada. Dada uma instância de uma transformação T ( I ) = O e um item de dado de saída o O, diz-se que o subconjunto I* I de itens de dados de entrada contribuíram para a linhagem da derivação de o, e denota-se I* = T* (o, I ) Classes de Transformação Nesta seção serão descritas três classes de transformações: despachantes (dispatchers), agregadores (aggregators), e caixas-preta (black-box) (CUI et al, 2001). Para exemplificar as categorias de transformação, considere o exemplo: sejam as tabelas Vendas e Lojas, conforme apresentado nas TABs 4.8 e 4.9 respectivamente. Produto CdLoja CdCliente Data Qtde Preco Total Oleo soja pet soya; Soya; L3 C3 2/1/03 2 R$5,00 10,00 Cereais Cereal 210g nescau; L3 C1 1/2/03 2 R$8,10 16,20 Nestle;Cereais Pao queijo 500g; Minas; L2 C1 2/2/03 4 R$3,62 14,48 Congelados Sabao neutral;neutral;limpeza L1 C1 1/3/03 10 R$2,50 25,00 Refrig 2000ml; Cola- L2 C2 2/3/03 5 R$4,50 22,50 Coca;Bebidas Refrig light; Cola- L4 C2 3/3/03 1 R$6,22 6,22 Coca;Bebidas Papel hig; Suave; Limpeza L5 C2 4/3/03 20 R$6,30 126,00 Chicken L6 C3 4/3/03 3 R$12,00 36,00 queijo;perdigao;congelados Almond frango; L6 C2 12/3/03 2 R$4,35 8,70 Sadia;Congelados Sabao coco 200g c/5; L5 C3 10/3/03 1 R$8,30 8,30 Ruth;Limpeza Fosforo fiat casa; Lux;Limpeza L2 C1 15/3/03 5 R$2,00 10,00 Mate 1500ml diet limao;leao;bebidas L4 C2 15/3/03 8 R$0,80 6,40 TAB 4.8 Tabela Vendas 78

80 Codigo Nome Endereco Cidade Estado Gerente L1 ACME Botafogo Rua XXX, Rio de Janeiro RJ João P. Souza 11 L2 ACME Flamengo Rua YYY Rio de Janeiro RJ Maria Silva 22 L3 ACME Campo Grande Rua ZZZ 33 Salvador BA Paulo Pereira L4 ACME Pituba Rua KKK Salvador BA Carlos José 44 L5 ACME Barra Rua HHH Salvador BA Ana Silva 55 L6 ACME Leblon Rua TTT 66 Rio de Janeiro RJ Bianca Souza TAB 4.9 Tabela de Lojas FIG. 4.3 Grafo de Transformações O campo Produto na tabela de Vendas contém uma lista com informações do produto, marca e categoria a qual o produto pertence. Suponha que um gerente de marketing deseje analisar o resultado da promoção implantada durante o mês de Março para produtos das categorias Limpeza e Bebidas. Para isso deseja um relatório com o total de vendas por loja e por categoria, segundo tais condições. Suponha que para extrair os dados necessários seja preciso executar uma série de transformações, que podem ser representadas como o grafo ilustrado na FIG O grafo é composto das seguintes transformações: T 1 : divide cada produto da tabela Vendas nos campos Produto, Marca e Categoria. Após a aplicação de T1, têm-se uma relação resultante segundo o esquema <Produto, Marca, Categoria, CdLoja, CdCliente, Data, Qtde, Preço, Total> gerando a relação V1; T 2 : Seleciona em V1 as vendas de produtos que pertencem à categoria Limpeza ou Bebidas, gerando assim a relação V2; 79

81 T 3 : Realiza uma junção entre V2 e L, tal que V2.CdLoja = L.Código, e em seguida aplica uma projeção. Essa transformação gera a relação VL1, com o seguinte esquema: <Nome, Cidade, Estado, Produto, Marca, Categoria, Total>; T 4 : Seleciona em VL1 as vendas do mês de Março gerando a relação VL2; T 5 : Sumariza de VL2 as vendas por loja e por categoria gerando a relação final VL3. A aplicação do grafo de transformações da FIG. 4.3 produz a relação resultante final VL3, ilustrada na TAB Nome Categoria Total ACME Flamengo Bebidas R$22,50 ACME Pituba Bebidas R$12,62 ACME Barra Limpeza R$134,30 ACME Botafogo Limpeza R$25,00 ACME Flamengo Limpeza R$10,00 TAB Relação Resultante Imagine que agora um analista quer ver os detalhes da tupla t = < ACME Barra, Limpeza, R$134,30>. De fato, o que usuário deseja visualizar são os subconjuntos das relações de origem responsáveis pela geração da tupla t, mostradas nas TABs 4.11 e Codigo Nome Endereco Cidade Estado Gerente L5 ACME Barra Rua HHH Salvador BA Ana Silva 55 TAB 4.11 Sub-Relação da Tabela Loja que originou a tupla t. Produto CdLoja CdCliente Data Qtde Preco Total Papel hig; Suave; Limpeza L5 C2 4/3/03 20 R$6,30 126,00 Sabao coco 200g c/5; Ruth;Limpeza L5 C3 10/3/03 1 R$8,30 8,30 TAB 4.12 Sub-Relação da Tabela Vendas que originou a tupla t. Através dos algoritmos de linhagem de dados e metadados, é possível acompanhar os itens de dados durante todas as transformações pelas quais os mesmos passaram. 80

82 FIG. 4.4 Classes de Transformação Segundo (CUI et al, 2001), existem três classes genéricas de transformação: Despachante, Agregador e Caixa-Preta, descritas a seguir. Despachante (Dispatcher ) Uma transformação T é um despachante se cada item de dado de entrada produzir zero ou mais itens de dados de saída, de forma independente: I, T (I) = i I T ({i}). A FIG. 4.4(a) ilustra um despachante, no qual o item de entrada 1 produz os itens de saída 1 e 4, o item de entrada 3 produz os itens de saída 3 e 6 e o item de entrada 2 não produz item algum. A linhagem de um item de saída o de acordo com um despachante T é definido como T* ( o, I ) = {i I o T ( { i } ) }. As transformações T 1, T 2, T 3 e T 4 da FIG. 4.3 são da classe Dispatcher. O procedimento TraceDS( T, O*, I ) na FIG. 4.5 pode ser usado para gerar o trajeto de um conjunto de itens de dados de saída O* O de acordo com o despachante T. procedure TraceDS(T,O*,I) I* for each i I do if T({i}) O* then I* I* {i}; return I*; FIG. 4.5 Algoritmo de Linhagem para Transformações Tipo Despachante No procedimento TraceDS da FIG. 4.5, T representa a transformação, O* representa o subconjunto da relação resultante e I representa a relação de entrada. I* é o subconjunto da relação I que originou O*. Neste procedimento, para todas as tuplas i pertencentes à relação de entrada I, se o resultado da aplicação de T sobre i, ou seja, T({i}), isto é, sofreu transformação e essa pertence ao conjunto O*. Logo i participou na geração de O*. Ao final do procedimento, I* contém todas as tuplas que participaram na geração de O*. 81

83 Agregador (Aggregator) Uma transformação T é um agregador se para todo T(I) = O = {o 1,...,o n }, existe uma partição única disjunta de entrada I 1,..., I n de I tal que T(I k ) = {o k } para k = 1... n. No grafo apresentado na FIG. 4.3, a transformação T 5 é uma agregação. A classe Agregagor possui ainda duas outras subclasses: o Agregadores livres de contextos (Context-Free Aggregators) Um agregador T é livre de contexto se para cada item de saída, a partição de itens de dados de entrada é sempre a mesma, ou seja, um agregador livre de contexto determina a partição que um item de dado de entrada pertence, basedo apenas no seu próprio valor, sem considerar os itens de dados das outras partições. O algoritmo TraceCF(T,O*,I) apresentado na FIG. 4.6 gera a linhagem de um item de dado de saída. Procedure TraceCF(T,O*,I) I* pnum 0; for each i I do if pnum = 0 then I 1 {i}; pnum 1;continue; for (k 1;k pnum;k++) do if T(I k {i}) = 1 then I k I k {i}; break; if k > pnum then pnum++; I pnum {i}; for k 1..pnum do if T ( I k ) O* then I* I* I k ; return I*; FIG. 4.6 Algoritmo de Linhagem para Agregadores Livres de Contexto Esse algoritmo recebe como parâmetros a relação de entrada I, a transformação T e o sub-conjunto da relação resultante, retornando o sub-conjunto I* da relação original que gerou O*. Para isso, o procedimento percorre todos as tuplas da relação original e cria partições disjuntas que são livres de contexto em sua natureza e que foram responsáveis pela geração da sub-relação O*. O bloco de código if T(I k {i}) = 1 testa se a cardinalidade do conjunto gerado na aplicação da transformação (agregação) T sobre o conjunto I k {i} é igual a 1. Quando isso ocorre, significa que {i} pertence à partição I k. Os algoritmos propostos em (CUI et al, 2001) são aplicados às classes genéricas de transformação de dados. Em função disso serão apresentados algoritmos de linhagem de dados (criados neste trabalho) específicos para hipercubos gerados sob um esquema estrela e para o grafo de derivação de atributos. Desse modo, o metamodelo do CWM foi estendido 82

84 para suportar tais funcionalidades. O metamodelo estendido e os algoritmos serão apresentados nas próximas seções. TraceTupleCubeStarSchema(o, S){ /* Inicializa variáveis */ for (i = 1;i<=n;i++) I* i P_key_def i P_key_value i I* n+1 /* percorre todos os atributos da dimensão que compõem o cubo */ for (i = 1;i <= n; i ++) for (j = 1;j <k; j++) if d j S.Dim i then P_key_def i P_key_def i d j P_key_value i P_key_value i o j /* Pega nome e valores das dimensões */ for (i = 1 ; i <= n; i++) FtName i key in S.Dim i FtValue i Π σ(s.dim i ) P_key_valuei FtName i /* Gera Linhagem para Dimensões */ for (i = 1;i <= n; i++) I* I σ (S.Dim i ) P_key_value i /* Gera Linhagem para a tabela de fatos */ I* i+1 σ(ft) FtValue return I* } FIG Algoritmo de linhagem de dados para hipercubos A FIG. 4.7 apresenta o algoritmo para a linhagem de dados aplicadas a tuplas pertencentes a cubos implementados sob um esquema estrela. O algoritmo utiliza as seguintes variáveis: n: número de dimensões usadas na geração do cubo; k: o número de colunas na tupla. o: a tupla selecionada; S: esquema; S.Dim i : dimensão i no esquema S; d j : j-ésimo campo na tupla selecionada no cubo; I* i (i < n) : sub-conjunto da dimensão i que gerou a tupla o. I* n+1 : sub-conjunto da tabela de fatos que gerou o; P_key_def i : partição com o conjunto de campos da cláusula Group-By que pretencem à dimensão i; P_key_value i : o valor de cada campo da tupla selecionada; o j : valor da coluna j que aparece em o. FtName i : chave da tabela de fatos que foi usada na junção com a chave da dimensão i. O procedimento obtém as propriedades do cubo gerado e as usa para gerar a linhagem de dados em relação às dimensões e à tabela de fatos. 83

85 o Agregadores com preservação de chave (Key-Preserving Aggregators) Um agregador T é um Key-Preserving-Aggregator se dada uma conjunto de dados de entrada I e suas partições I 1,..., I n para a saída T (I) = {o 1,...,o n }, todos os subconjuntos de I k produz um único item de dado de saída com a mesma chave o k, para k=1,..,n. A transformação T 5 também é um agregador com preservação de chave. De fato, todo agregador com preservação de chave é um agregador livre de contexto. Caixa-Preta (Black-Box) Uma transformação atômica é caixa-preta se não é um dispachante nem um agregador. Esse tipo representa as transformações das quais não se tem muito conhecimento, onde a única informação que se tem são referentes aos dados de entrada e de saída. Uma transformação do tipo caixa-preta poderia ser, por exemplo, um procedimento que lê um nome de um cliente e retorna o nome do mesmo fonetizado. 4.4 Extensão do Metamodelo CWM para Linhagem de Dados O metamodelo de transformações do CWM foi estendido para permitir a implementação das rotinas de linhagem de dados. A FIG. 4.8 apresenta uma extensão do metamodelo de transformações do CWM para suportar as propriedades de cada classe. Nesse diagrama, as classes precedidas por CWM representam as classes dos pacotes do CWM. As demais são classes adicionadas para suportar funcionalidades de linhagem. As classes BlackBox e Dispatcher armazenam as propriedades destes tipos de transformação. Essa última, utiliza-se da classe ColumnProject. As classes CFAggregator e KPAggregator são subclasses da classe Aggregator e representam agregadores livres de contexto e agregadores com preservação de chave, respectivamente. FIG. 4.8 Extensão do CWM para suportar mecanismos de linhagem. 84

86 A classe ColumnProject representa as colunas que serão exibidas nas transformações do tipo Dispatcher. A classe KeyColumnProject contém as colunas usadas numa transformação KPAggregator, sendo esta última uma especialização de uma transformação de agregação cuja característica fundamental é a preservação da chave no resultado da consulta. A classe ColumnJoin é usada na geração do hipercubo, e contém os colunas da junção entre as dimensões e a tabela de fatos no esquema estrela. Em função do metamodelo do CWM ser um framework e portanto genérico e extensível, ele não oferece classes de transformação de dados específicas segundo a abordagem apresentada. Dessa forma foi preciso estender o seu metamodelo. 4.5 Linhagem de Metadados ou Linhagem de Dados Vertical Vários processos são definidos no ambiente de Warehousing com o objetivo de extrair os dados dos sistemas operacionais, transformá-los e carregá-los no DW. Ao final de cada processo um novo nível de visão materializada é gerado. A geração dessa visão materializada envolve transformações de dados que acontecem sob um determinado nível de granularidade (tabela, coluna, registro, arquivo, etc.). A garantia da qualidade de dados gerada está condicionada à implementação de uma política de gerência de metadados que seja capaz de instanciar um metamodelo que integre todos os metadados do ambiente de data warehouse. A linhagem de dados tem por objetivo implementar o operador inverso dentro do conjunto de operadores do espaço canônico ASPJ (Agregação, Seleção, Projeção e Join) para apresentar os subconjuntos das relações originais que formam a derivação de uma determinada tupla dentro de uma relação resultante. Com esta abordagem, é possível, através de uma implementação recursiva, conhecer todos os elementos de dados pertencentes a visões materializadas de um nível anterior que foram responsáveis pela criação de uma tupla numa dada visão. No caso específico de uma solução de linhagem de dados, pressupõe-se confiança na qualidade dos processos de geração de dados, uma vez que não há, por exemplo, validação do processo de geração de um determinado campo presente numa visão materializada. Um problema relevante no contexto de linhagem de dados é o que fazer quando as fontes de dados estão inacessíveis ou não são consistentes com as visões do DW. Como ilustra a FIG. 4.9, a linhagem de dados está num nível de abstração inferior ao de metadados, pois o resultado de um processo de linhagem de dados é única e exclusivamente 85

87 outro dado. Nesta FIG., as relações são representadas por metadados no nível de metamodelo, assim como os processos e transformações responsáveis pela geração de cada elemento de dado. Desta forma, existe uma dependência entre os dois níveis de abstração. FIG. 4.9 Níveis de Abstração: Dados e Metadados. A linhagem de dados é uma abordagem horizontal voltada para o dado, ou seja, apenas seu conteúdo é avaliado. Além disso, ela é aplicada sob um espaço considerado minimal em relação às transformações existentes no ambiente de Warehousing. A heterogeneidade de fontes de dados dos sistemas legados fornece transformações complexas, e que vão além dos operadores existentes no espaço canônico ASPJ, porém não são contempladas no escopo deste trabalho. Tendo em vista a complexidade de transformações e a variedade de processos responsáveis pelos dados presentes nos hipercubos do DW, surge o problema de Linhagem de Metadados ou Linhagem de Dados Vertical. O problema de Linhagem de Metadados intuitivamente é definido como: considerando um item de dado existente numa visão materializada, apresentar todos os processos e transformações aplicadas na geração deste campo através da navegação pelos metadados integrados representados por um metamodelo. Vale lembrar que existe uma abordagem diferenciada de entendimento do termo linhagem de metadados. Esta se refere ao acompanhamento da evolução dos metadados ao longo do tempo. Neste tipo de definição, cada vez que uma determinada transformação evolui, ou seja, sua definição é alterada, esse conhecimento é armazenado. Porém, no contexto deste trabalho, a linhagem de metadados refere-se ao acompanhamento das transformações pelas quais passam os dados. Nesse contexto, o termo linhagem de metadados é justificado pelo fato das instâncias utilizadas no mecanismo de linhagem de metadados fazerem parte dos metadados representados no metamodelo CWM, que armazena 86

88 exclusivamente metadados. Entendemos que para se representar linhagem de metadados através do acompanhamento da evolução dos metadados exige uma representação no nível de meta-metamodelo. O entendimento da diferença entre as duas abordagens é de suma importância para a compreensão da conceituação e algoritmos que serão apresentados a seguir. A linhagem de metadados é uma abordagem ortogonal em relação ao problema de linhagem de dados, pois o trajeto inverso com o uso intensivo de metadados é gerado com o intuito de verificar a qualidade dos processos e extração, transformação e carga dos dados. Logo, pode-se concluir que a linhagem de metadados é complementar em relação à linhagem de dados, sendo que as duas soluções combinadas melhoram os processos de garantia de qualidade de dados no Warehousing Conceituação Suponha que vários processos sejam definidos para extrair, transformar e carregar dados no DW, gerando dessa forma níveis intermediários de visões materializadas, e que tais processos possam ser mapeados e indexados. Considere m processos existentes no Warehousing e sejam W um determinado Warehousing, M um determinado metamodelo implementado em W e P k ; k <= m, ( {k,m,n,i} N) um processo ETL. Considere ϖ i uma coluna pertencente a uma visão materializada V i e Op o operador aplicado à ϖ i gerando a coluna ϖ i+1 pertencente à visão materializada V i+1, de modo que Op(ϖ i ) % ϖ i+1. Se n operadores de transformação forem aplicados na geração de uma coluna numa visão materializada, LM(ϖ i,p k ) é a Linhagem de Metadados relacionada às variáveis ϖ i e P k é definido como sendo a lista Γ de todas as transformações que participaram na geração do campo ϖ i para um dado processo P k, ou seja : LM (ϖ i, P k ) = Γ ( Op(ϖ i ) % ϖ i+1 ) i = 1,, n ; k <= m. Operadores podem ser aplicados à visões materializadas, de modo que a aplicação do operador Op sobre uma determinada visão materializada V i gera a visão V i+1, gerando uma visão em outro nível do processo, ou seja, Op(V i ) % V i+1. Assim a linhagem de metadados pode ser aplicada também no nível de granularidade de visões materializadas, sendo a lista Γ de todas as transformações aplicadas a uma determinada visão num dado processo ETL P k, ou seja: LM (V i, P k ) = Γ ( Op(V i ) % V i+1 ) i = 1,, n ; k <= m. 87

89 Assim, a Linhagem de Metadados Total LMT (W,M) aplicada ao Warehousing W sob a implementação do metamodelo M é a união de todas as linhagens de dados aplicadas a todos os elementos de dados (coluna ou tabela) aplicados pertencentes ao metamodelo M, ou seja : LMT (W,M) = (LM( V i ϖ i, P k )) k = 1,, m Assim, tanto a linhagem de metadados LM quanto a linhagem de metadados total LMT podem servir como base para ferramentas de análise de dados e metadados. A FIG apresenta o algoritmo utilizado para gerar o procedimento de linhagem de metadados. MetaLineage (Destino E t ) for each T T(E s ) % E t /* E s : Origem */ AtualizaGrafo(T,E s,e t ); /* E t : Destino */ MetaLineage(E s ); /* T: Transformação */ FIG Algoritmo para Geração de Linhagem de Metadados O algoritmo MetaLineage apresentado na FIG. 4.10, recebe como parâmetros a origem e o destino de uma transformação de dados num determinado nível de granularidade (tabela ou coluna), e para cada transformação T (T(E s ) % E t ) que gerou o destino corrente, e a matriz de adjacências é atualizada (AtualizaGrafo) matriz que representa a associação entre dois elementos em um grafo. Esta representa o grafo de derivação de atributos e recursivamente é chamada a rotina MetaLineage. O procedimento é executado até que todo o grafo tenha sido gerado. 4.6 Considerações Finais Os algoritmos apresentados e propostos neste capítulo permitem a implementação de funcionalidades de linhagem de dados e metadados aplicados às transformações existentes num ambiente de Warehousing. Tal implementação foi possível devido à captura e representação dos metadados de elementos usados nos processos de transformação. Finalmente, o capítulo propõe a extensão do CWM para representar metadados relativos aos operadores despachante e agregador, necessários para a implementação dos algoritmos de linhagem de dados. Este estudo foi consolidado com o desenvolvimento de uma ferramenta que implementa as funcionalidades formalizadas e apresentadas ao longo deste capítulo, cujo desenvolvimento é apresentado no próximo capítulo. 88

90 A CAPÍTULO 5 A 5. DESENVOLVIMENTO DA FERRAMENTA DE TRANSFORMAÇÃO E LINHAGEM Este capítulo tem por objetivo apresentar a especificação da ferramenta de transformação e linhagem de dados e metadados que será utilizada para definir, visualizar e gerenciar os metadados envolvidos num ambiente de Warehousing. A ferramenta terá como base uma abordagem semi-ativa, na qual apenas as informações estáticas são armazenadas, a exemplo de estruturas, definições, configurações e localizações dos dados. Nesse tipo de abordagem, ao contrário da abordagem ativa de gerência de metadados, os metadados são apenas lidos e visualizados, não executados. A metodologia utilizada para a modelagem do sistema será a linguagem UML, pela sua expressividade na representação de aspectos estáticos e dinâmicos de um sistema computacional. Será apresentada a arquitetura do sistema, com os principais elementos envolvidos no processo de geração de metadados em um ambiente de Warehousing, o metamodelo que integra os pacotes do CWM necessários para a construção da ferramenta conforme apresentado no capítulo 3, e características funcionais da ferramenta. 5.1 Arquitetura do Sistema Num ambiente de Warehousing, as atividades do processo ETL, as atividades de Carga do ODS Operational Data Store (Repositório de Dados Operacionais) e as atividades e tarefas necessárias para o preenchimento do Data Warehouse podem ser vistas como um grafo rotulado, onde cada nó representa um item de dado e cada aresta do grafo representa uma transformação. Cada transformação pode ser expressa através de uma árvore de expressões. Os itens de dados são representados pelo Relational Package e OLAP Package. As transformações são representadas pelo pacote Transformation Package do CWM e são associadas a árvores de expressões através do Expression Metamodel. A integração dos 89

91 pacotes do CWM considerou o fato do CWM ser um Framework, e desse modo o metamodelo integrado é também extensível. A FIG. 5.1 ilustra um ambiente típico de Data Warehouse, onde coexistem nos sistemas operacionais da empresa os Sistemas Legados sistemas que utilizam um modelo de dados relacional e sistemas que utilizam a tecnologia de Flat Files. Os metadados de tais sistemas são representados pelos pacotes Relational Package e Record Package respectivamente, como ilustrado na FIG.. Dados dos sistemas legados precisam ser enviados para o Hipercubo do sistema de Data Warehouse. Transformações são aplicadas aos itens de dados a fim de gerar informações de qualidade para o DW que é o sistema de suporte à tomada de decisão. As transformações que acontecem nesse ambiente podem ser representadas pelo Transformation Package do CWM, onde para cada processo são definidas atividades, tarefas e passos necessários para a implementação das transformações que associam um item de dado de origem a um item de dado de destino. A partir do momento em que os dados transformados já estão no DW, outros metadados precisam ser analisados. Estes correspondem aos metadados que representam cubos, dimensões, hierarquias, ou seja, os metadados do mundo multidimensional. O OLAP Package, através do seu metamodelo multidimensional fornece a funcionalidade necessária para a representação de metadados multidimensionais. A FIG. 5.2 ilustra o mapeamento que ocorre quando aos itens de dados são aplicadas transformações. Neste ponto, um item de dado origem é associado a um item de dado destino por uma transformação. A transformação, por sua vez, é associada a uma árvore de expressões, que é representada pelo metamodelo de expressões do CWM. Assim, expressões, elementos de dados, constantes e funções são associadas formando uma árvore de expressão, necessária à visualização da transformação. 90

92 FIG. 5.1 Relação dos Metadados do DW com os Metamodelos do CWM FIG. 5.2 Relacionamento das Transformações com o Expression Metamodelo 91

93 5.2 Relação entre os Pacotes A FIG. 5.3 ilustra os pacotes integrados utilizados na construção da ferramenta, levandose em consideração o relacionamento de dependência entre eles. Assim, por exemplo, na FIG. pode-se observar que o pacote de transformação depende do pacote relacional, o metamodelo de expressões depende do pacote de transformação, e ainda que o pacote que representa a linhagem depende de todos os demais. FIG. 5.3 Dependências entre os Pacotes do CWM e extensão. O metamodelo detalhado que implementa a integração dos pacotes do CWM é mostrado na FIG A associação ocorre neste caso em função de tais itens de dados participarem das transformações nos processos ETL e de carga do Data Warehouse. O metamodelo de expressões associa-se ao metamodelo relacional pela classe ElementNode, que define nós na árvore de expressões que são usados para a representação de transformações aplicadas aos itens de dados e o pacote OLAP se relaciona com o pacote relacional através da associação implements entre a classe Dimension e a classe Table. 92

94 FIG Metamodelo Integrado 5.3 Diagrama de Use Cases (Casos de Uso) A FIG. 5.5 apresenta o diagrama de Casos de Uso ilustrando conjuntos de ações executadas pelos atores (usuários) do sistema. Esse diagrama mostra a interação do mundo externo com o sistema. A FIG. mostra ainda o módulo da ferramenta ao qual cada caso de uso pertence. Por exemplo, o caso de uso 4.2 (Gera Linhagem de Dados) pertence ao módulo de linhagem, representado na FIG. pela letra L. O ANEXO 1 apresenta a descrição dos principais casos de uso da FIG FIG. 5.5 Diagrama de Casos de Uso 93

95 5.4 Ferramenta A ferramenta foi construída usando a plataforma Windows 2000 e o IDE Delphi 5.0. Considerou-se um ambiente de warehousing implementado sob um framework relacional, onde o tratamento de dados armazenados em Flat Files ou sob a forma de documentos semiestruturados não foram gerenciados nessa primeira versão da ferramenta. A partir do diagrama da FIG. 5.5 foi possível estruturar a ferramenta segundo uma composição de módulos, cuja implementação e funcionalidades são discutidas nas próximas subseções Módulo de Cadastro O módulo de cadastro é responsável pelo primeiro nível de instanciação do metamodelo do CWM. Neste módulo, metadados relativos a dados operacionais representando recursos armazenados num SGBDR são cadastrados através do Relational Package. Esquemas, Tabelas, Colunas e Chaves Primárias são os metadados controlados por este módulo. FIG. 5.6 Tela de Cadastro de Esquema A FIG. 5.6 apresenta a tela de cadastro de esquema, onde o analista seleciona o esquema (ACME) que é implementado no SGBDR SQL Server Nesta tela o usuário cadastra um determinado esquema de banco de dados. A janela 1 indica o campo de descrição do esquema. 94

96 Na janela 2, o usuário cadastra o script de criação do esquema. A janela 3 apresenta todos os esquemas já cadastrados na ferramenta e a janela 4 mostra todas as tabelas criadas para o esquema que está sendo cadastrado. A FIG. 5.7 exemplifica a tela de cadastro de tabelas, na qual seus metadados são armazenados para uso das demais funcionalidades. Nesta tela, a janela 1 representa o campo que contém o script de criação da tabela (Produto). A janela 2 mostra todas as tabelas cadastradas na ferramenta e a janela 3 indica todas as colunas da tabela que está sendo cadastrada. O módulo de cadastro contempla ainda a tela de cadastro de colunas. Tipos de dados, chave primária, tamanho, precisão, semântica e escala são alguns dos metadados cadastrados que aparecem nesta tela. A FIG. 5.8 apresenta um cenário de navegação da ferramenta para a geração de metadados que serão instâncias do pacote relacional do CWM. O primeiro passo é o cadastramento de esquema, seguido pelo cadastro de tabelas e finalmente o cadastro de colunas pertencentes à tabela cadastrada. FIG. 5.7 Tela de Cadastro de Tabelas 95

97 FIG. 5.8 Diagrama de Seqüência para Instanciação do Relational Package Módulo de Processos ETL Este módulo é responsável também pela instanciação do metamodelo de transformações do CWM (Transformation Package). O módulo de gerência de metadados ETL permite definir, visualizar e gerir atividades, passos, tarefas, transformações e expressões. Esse módulo usa a hierarquia atividade-passo-tarefa-transformação implementada no CWM, como ilustra a FIG A ferramenta utiliza o conceito expresso pelo metamodelo de transformações do CWM, onde uma atividade possui um conjunto de passos, e este por sua vez, possui um conjunto de tarefas, e cada tarefa implementa um conjunto de transformações, que são aplicadas a itens de dados. Com esse tipo de abordagem, torna-se viável o acompahamento dos itens de dados ao longo do processo. Esse módulo permite ainda a visualização de árvores de expressões com notação parentisada. Com isso, é possível extrair de uma expressão os elementos que a compõem, e representá-la com os metadados apropriados. A ferramenta é extensível no sentido de que transformações para outros tipos de itens de dados poderão ser implementadas, tais como elementos de um documento XML, ou ainda campos de arquivo texto. 96

98 FIG. 5.9 Atividades, Passos, Tarefas e Transformações, extraído de (OMG, 2000). FIG Tela de criação de tarefas A FIG ilustra a tela de criação de tarefas. O script de criação da tarefa é cadastrado nesta tela (janela 1), assim como a tarefa anterior para indicar a lógica do processo de extração, transformação e carga dos dados. A janela 2 apresenta a descrição da tarefa e janela 3 mostra todas as tarefas cadastradas na ferramenta. A FIG apresenta a tela de transformações, onde através da janela 1 o usuário seleciona o nível de granularidade da transformação, podendo ser no nível de coluna ou de tabela. Na janela 2 é definido o mapeamento entre elementos origem e destino, segundo a granularidade selecionada. A janela 3 mostra a descrição da tarefa, a janela 4 descreve a transformação, a janela 5 apresenta a árvore de expressões correspondente a uma transformação, e, a janela 6 mostra todas as transformações da respectiva tarefa. A FIG apresenta um diagrama de seqüência num cenário de navegação da ferramenta, que possibilita a instanciação dos pacotes de transformações. O usuário define 97

99 processos ETL através da hierarquia definida no CWM em termos de atividades, passos, tarefas e transformações. Além disso, uma transformação, que pode ser representada como uma árvore, serve de base para a instanciação do metamodelo de expressões do CWM. FIG Tela de Transformações de Dados FIG Diagrama de Seqüência para Instanciação do Transformation Package Módulo de Linhagem de Dados e Metadados O módulo de linhagem de dados permite que seja feito o Back Tracing dos processos de transformação de dados quando da aplicação de mecanismos de linhagem de dados utilizando as classes genéricas de transformação de dados discutidas no capítulo 4. A FIG ilustra a tela de cadastro de cubos que são usados para a implementação de mecanismos de linhagem de dados. 98

100 FIG Tela de Cadastro de cubos para a execução de linhagem de dados. Na janela 1 da FIG o usuário seleciona as dimensões e colunas que farão parte do cubo, e na janela 2 essas informações são listadas. A janela 3 mostra as informações das colunas da junção na geração do cubo e a janela 4 lê as informações das janelas anteriores para gerar a cláusula SQL. FIG Tela de Linhagem de Dados para Cubos A FIG ilustra o Back Tracing de uma tupla gerada a partir de um cubo que foi cadastrado na ferramenta. Para fins de implementação, foi considerada linhagem para cubos gerados com até duas dimensões. Inicialmente o usuário seleciona o cubo que foi cadastrado 99

101 na tela da FIG. 5.13, conforme mostra a janela 5. Depois de selecionado, o usuário gera o cubo e seleciona a tupla para a qual deseja realizar a linhagem (janela 1). Após a seleção da tupla, a ferramenta gera a linhagem mostrando os dados que originaram a tupla nas dimensões (janelas 2 e 3) e na tabela de fatos (janela 4). Uma funcionalidade importante neste contexto é a visualização da linhagem de metadados. Na FIG têm-se a linhagem de metadados aplicada na geração da tabela VL3 que contém dados sumarizados. A tabela foi gerada através da atividade Cube_Vendas_Lojas. A ferramenta permite visualizar detalhes da transformação. Neste exemplo, a transformação T5 gerou a tabela VL3 a partir da tabela VL2. FIG Linhagem de Metadados no nível de granularidade de tabela. FIG Detalhamento da Transformação 100

102 A figura 5.16 apresenta o detalhamento da transformação de um grafo de linhagem de metadados no nível de granularidade de tabela Módulo de Interoperabilidade e Visualização de Indicadores Este módulo implementa a interoperabilidade de metadados através da exportação do metamodelo CWM integrado. Para isso, é gerado um documento XML com os metadados representados pelos pacotes do estudo. Este documento XML é validado por um XML Schema (ver ANEXO 3) que define o modelo de metadados do presente trabalho. Além disso, a ferramenta permite visualizar o número de transformações aplicado em cada coluna. Esta funcionalidade viabiliza a definição de métricas de qualidade de dados, pois uma coluna que sofre maior nº de transformações está mais sujeita a causar inconsistências. 5.5 Considerações Finais Os processos de extração, transformação e carga de dados do ambiente operacional para o DW é feito sob diversas formas: inclui mapeamentos campo a campo, cláusulas SQL para carga de tabelas a partir de outras usando os operadores da álgebra relacional, funções de linha dos SGBDRs, ou ainda programas de aplicação que funcionam como uma caixa-preta no processo de transformação de dados. Com a abordagem apresentada neste capítulo, tornou-se possível a implementação de mecanismos de linhagem de dados e metadados dentro de um processo ETL. Tais mecanismos permitiram a realização do Back Tracing dos dados gerados em cubos sob esquema estrela, e a rastreabilidade dos metadados durante todo o processo. Dessa forma, as métricas de qualidade de dados podem ser garantidas e os usuários/analistas podem avaliar melhor a informação que é importante na tomada de decisão. Um aspecto importante, e que vale a pena ressaltar é que os metadados relativos ao pacote relacional (esquemas, tabelas, colunas e chaves) e que servem de base para as funcionalidades mais importantes da ferramenta não são obtidos a partir de um repositório de metadados. Tal fato se deu em função do objetivo inicial da ferramenta de ser acoplada a uma solução comercial de DW, onde tais informações poderiam ser obtidas diretamente do sistema. Os diagramas de modelagem apresentados neste capítulo permitem a representação de dos aspectos mais importantes do sistema. O diagrama de casos de uso criado permitiu a visualização dos cenários sob o ponto de vista do usuário, e o diagrama de seqüência tornou possível a representação interativa entre os objetos do sistema em relação às principais 101

103 funcionalidades. Uma visão mais consolidada da ferramenta será possível através de um estudo de caso, o qual será apresentado no próximo capítulo. 102

104 A 6. ESTUDO DE CASO A CAPÍTULO 6 Este capítulo tem por objetivo apresentar o funcionamento da ferramenta desenvolvida no âmbito de uma aplicação real. O escopo de aplicação se deu através do uso dos metadados existentes em um Warehousing de um comércio varejista, no qual foi possível identificar os elementos de maior importância e visualizá-las através das principais telas da ferramenta desenvolvida. 6.1 Cenário de Aplicação O cenário escolhido é uma rede de supermercados varejistas com filiais em vários estados e cujo nome hipotético é ACME. O objetivo é construir um DW para o cliente permitindo que o mesmo possa utilizar a ferramenta para realizar transformações e linhagem de dados e metadados. A modelagem do DW será definida por um esquema estrela com as tabelas de dimensões desnormalizadas, ilustrando assim um ambiente típico de um DW corporativo, como mostra a FIG O ANEXO 2 apresenta os scripts de criação dessas tabelas. FIG. 6.1 Esquema Estrela do DW do Cliente ACME. 103