Universidade Federal do Rio de Janeiro AUMENTANDO O NÍVEL DE ABSTRAÇÃO PARA ETL ATRAVÉS DE MDA. Lúcia Maria Abrunhosa Fernandes

Transcrição

1 Universidade Federal do Rio de Janeiro AUMENTANDO O NÍVEL DE ABSTRAÇÃO PARA ETL ATRAVÉS DE MDA Lúcia Maria Abrunhosa Fernandes 2011

2 AUMENTANDO O NÍVEL DE ABSTRAÇÃO PARA ETL ATRAVÉS DE MDA Lúcia Maria Abrunhosa Fernandes Dissertação de Mestrado apresentada ao Programa de Pós-graduação em Engenharia de Sistemas e Computação, COPPE, da Universidade Federal do Rio de Janeiro, como parte dos requisitos necessários à obtenção do título de Mestre em Engenharia de Sistemas e Computação. Orientadores: Geraldo Zimbrão da Silva Rodrigo Salvador Monteiro Rio de Janeiro Julho de 2011

3 AUMENTANDO O NÍVEL DE ABSTRAÇÃO PARA ETL ATRAVÉS DE MDA Lúcia Maria Abrunhosa Fernandes DISSERTAÇÃO SUBMETIDA AO CORPO DOCENTE DO INSTITUTO ALBERTO LUIZ COIMBRA DE PÓS-GRADUAÇÃO E PESQUISA DE ENGENHARIA (COPPE) DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIAS EM ENGENHARIA DE SISTEMAS E COMPUTAÇÃO. Examinada por: Prof. Geraldo Zimbrão da Silva, D. Sc. Dr. Rodrigo Salvador Monteiro, D. Sc. Prof. Geraldo Bonorino Xexéo, D. Sc. Prof. Leonardo Guerreiro Azevedo, D. Sc. RIO DE JANEIRO, RJ - BRASIL JULHO DE 2011 iii

4 Fernandes, Lúcia Maria Abrunhosa Aumentando o Nível de Abstração para ETL através de MDA / Lúcia Maria Abrunhosa Fernandes. Rio de Janeiro: UFRJ/COPPE, XI, 180 p.: il.; 29,7 cm. Orientadores: Geraldo Zimbrão da Silva Rodrigo Salvador Monteiro Dissertação (mestrado) UFRJ/ COPPE/ Programa de Engenharia de Sistemas e Computação, Referências Bibliográficas: p Model-driven architecture (MDA). 2. Extract, Transform and Load (ETL). 3. Data Warehouse (DW). I. Silva, Geraldo Zimbrão da et al.. II. Universidade Federal do Rio de Janeiro, COPPE, Programa de Engenharia de Sistemas e Computação. III. Título. iii

5 Agradecimentos Ao meu esposo Dilson e filhos Davi, Daniel e Gabriel, que sempre me estimulam nos momentos de desânimo. Aos meus pais que me permitiram esta nova jornada. Ao Professor Geraldo Zimbrão por sua orientação e definição segura do caminho a seguir. Ao Professor Rodrigo Salvador por sua co-orientação, paciência e dedicação durante todo o desenvolvimento deste trabalho. Aos Professores Geraldo Xexéo e Leonardo Azevedo pela honra de tê-los em minha banca examinadora. Aos Professores da Coppe que me deram a oportunidade desta formação, especialmente ao Professor Jano Moreira. À Professora Cláudia Werner por seu exemplo de dedicação e entusiasmo durante o período que pude ser sua aluna. À MI Montreal Informática Ltda., principalmente à Diretora Adjunta Meri Toledano, que me estimulou e apoiou nesta empreitada. A todos que me apoiaram antes e durante o desenvolvimento deste trabalho. iv

6 Resumo da Dissertação apresentada à COPPE/UFRJ como parte dos requisitos necessários para a obtenção do grau de Mestre em Ciências (M.Sc.) AUMENTANDO O NÍVEL DE ABSTRAÇÃO PARA ETL ATRAVÉS DE MDA Lúcia Maria Abrunhosa Fernandes Julho/2011 Orientadores: Geraldo Zimbrão da Silva Rodrigo Salvador Monteiro Programa: Engenharia de Sistemas e Computação A Tecnologia da Informação (TI), desde seu início, sempre teve como objetivo a extensão da capacidade humana, através da melhoria ou automação de suas atividades cotidianas. Durante sua evolução uma meta constante tem sido a elevação do nível de abstração das linguagens de programação. A abordagem MDA (Model Driven Architecture) surgiu como uma tentativa de alcançar estas metas, favorecendo o foco no negócio e permitindo a diminuição da preocupação nos detalhes de implementação. Uma importante área de TI (Tecnologia da Informação) é a gestão organizacional onde sistemas de apoio à decisão se utilizam de dados operacionais e fornecem uma visão geral do negócio. A preparação (captura e transformação) desse ambiente tem um conjunto de características que poderiam ser explorados em uma abordagem MDA no âmbito dos objetivos originais de TI (abstração, refinamento e automação). Este trabalho discute como o processo de construção MDA permitiria a utilização das melhores práticas de implementação ETL mantendo, ao mesmo tempo, foco no negócio e provendo um nível de abstração adequado. v

7 Abstract of Dissertation presented to COPPE/UFRJ as a partial fulfillment of the requirements for the degree of Master of Science (M.Sc.) INCREASING THE ABSTRACTION LEVEL FOR ETL THROUGH MDA Lúcia Maria Abrunhosa Fernandes July/2011 Advisors: Geraldo Zimbrão da Silva Rodrigo Salvador Monteiro Department: Computing and Systems Engineering Information technology (IT), since its beginning, has always had as its aim the extension of human capacity through improvement or automation of daily activities. During its evolution, raising the abstraction level of programming languages has been a constant goal. The MDA (Model Driven Architecture) approach arose as an attempt to achieve these wishes: greater focus on the business and reduce of concern on implementation details. One important area of IT is the organizational management where decision support systems use operational data and provide a business overview. The preparation (capture and transformation) of this environment have a set of characteristics that could be exploited in a MDA approach under the original goals of IT: abstraction, refinement and automation. This work discusses how MDA construction process would allow for using best ETL implementation practices and at the same time keep focus on business providing a suitable abstraction level. vi

8 Índice I. INTRODUÇÃO... 1 II. CONCEITOS FUNDAMENTAIS... 5 II.1. O software e a Engenharia... 5 II.2. Aumentando o nível de abstração com MDA... 7 II.3. Contribuição ao MDArte II.4. Apoiando a Decisão II.5. Criando o ambiente DW II.6. Explorando a Arquitetura Data Warehouse III. TRABALHOS RELACIONADOS III III III III III III III III III III.10. Análise e Posicionamento do Trabalho Atual IV. ESPECIFICAÇÃO IV.1. Objetivos Específicos IV.2. Benefícios IV.3. Processo Característico das Transformações de Modelo IV.4. Personalização do Processo de Transformação IV.5. Fluxo Básico para Personalização de Cartuchos V. PROVA DE CONCEITO V.1. Premissas V.2. Passo 1 (A9): Parâmetros, estereótipos, valores etiquetados e outros V.3. Passo 2 (A10 e A12): Personalização do Metamodelo V.4. Passo 3 (A14): Validação V.5. Passo 4 (A14): A Geração do Código V.6. Passo 5 (A14): Construção do Cartucho V.7. Passo 6 (A15): Criação do Projeto Exemplo V.8. Passo 7 (A15): Configuração ETL V.9. Passo 8 (A16 e A17): Modelos OLTP e DW com marcações vii

9 V.10. Passo 9 (A16 e A17): A Transformação dos Dados V.11. Passo 10 (A18 e A19): Análise dos Resultados VI. CONSIDERAÇÕES FINAIS VI.1 MDA ou Ferramentas ETL? VI.2. Conclusões VI.3. Trabalhos Futuros REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE I: METAFACADES APÊNDICE II: VERIFICAÇÕES E MENSAGENS DE ERRO APÊNDICE III: PROFILE DE PERSISTÊNCIA APÊNDICE IV: MODELOS UML DA POC APÊNDICE V: DESEMPENHO NA CARGA APÊNDICE VI: EXEMPLOS DE MODIFICAÇÕES NO MODELO DE OBJETOS 140 APÊNDICE VII: ARQUIVOS DE ESPECIFICAÇÃO Cartridge.xml Metafacades.xml Namespace.xml Profile.xml viii

10 Índice de Figuras Figura 1: Etapas de transformação CIM PIM PSM... 9 Figura 2: Posicionamento do SBVR no processo MDA (OMG, 2008) Figura 3: Classes da Informação Figura 4: Componentes básicos de um ambiente DW Figura 5: Tipos de tabelas em um Data Warehouse Figura 6: Quadrante Mágico para Ferramentas de Integração de Dados Figura 7: Etapas Básicas do Processo de Transformação Figura 8: Fluxo com macro-atividades para personalização de cartuchos Figura 9: Sub-processo Projetar novos requisitos para cartucho Figura 10: Sub-processo Desenvolver transformações de modelo que atendam aos requisitos Figura 11: Sub-processo Modelar Exemplo e Executar Transformações Figura 12: Processo de Personalização de cartuchos Figura 13: Marcações na entidade Clientes Figura 14: Estereótipos e valores etiquetados para os modelos DW e OLTP Figura 15: Opções de valores para a tag AttributeType Figura 16: Propriedades globais para o projeto DwEtl no arquivo cartridge.xml Figura 17: Valores para propriedades do projeto DwEtl no andromda.xml Figura 18: Trechos dos metamodelos de classes e de atividades do Hibernate Figura 19: Algumas mensagens de erro Figura 20: Join entre duas tabelas OLTP Figura 21: Carga inicial da tabela de Fato Empréstimos Figura 22: Esquema modelo de código para um tipo de carga Figura 23: Trecho de código correspondente ao esquema modelo Figura 24 Valores etiquetados para geração de código Figura 25 Esquema do Processo ETL Figura 26 Dois modelos de classes Figura 27 - Marcações no modelo OLTP Figura 28 - Marcações no modelo DW Figura 29 Parâmetros para o processo de agregação Figura 30 Carga incremental da Dimensão Clientes com Overwrite Figura 31 Carga incremental da Dimensão Clientes com AddRow Figura 32 - Fato com carga incremental na opção CursorSequential Figura 33 Carga incremental do fato Emprestimos usando CommandDirect Figura 34 Atividades de Transformação ix

11 Figura 35 Atividades de Transformação código Figura 36: Exemplo de metamodelo noções básicas Figura 37: Metafacade DwEtlEntityAttribute Figura 38: Estereótipos aplicáveis aos modelos de classes Figura 39: Valor Etiquetado TimeGranularity e código gerado correspondente Figura 40: Trechos de código para CursorSequential e CommandDirect Figura 41: Trechos de código para onextraction e ontransformation Figura 42: Trechos de código para Overwrite e AddRow Figura 43: Listas de valores para tagged values Figura 44: Preenchimento do valor etiquetado AttributeType Figura 45: Seleção de elemento para o valor etiquetado tipocliente Figura 46: Operação de transformação para Saldo_Real Figura 47: Processo de transformação para o fato Empréstimos Figura 48: Estereótipos aplicáveis aos modelos de atividades Figura 49: Atribuição fixa à coluna tipocliente Figura 50: Atribuição condicional a Saldo_Real Figura 51: Atribuição de cálculo a Saldo_Real Figura 52: Diagramas para Transformação de Dados Figura 53: Profile de Persistência Figura 54: Estrutura básica do modelo de persistência do ambiente OLTP Figura 55: Estrutura básica do modelo de persistência do ambiente DW Figura 56: Modelo de ações aplicáveis à entidade Clientes (DW) Figura 57: Código correspondente à transformação da coluna tipocliente Figura 58: Modelo de ações aplicáveis à entidade Emprestimos (DW) Figura 59: Código correspondente à transformação da coluna Saldo_Real Figura 60: Package de Transformação Figura 61: Modelo de Dados OLTP Figura 62: Script para carga de dados da tabela Pessoa Figura 63: Amostragem de dados da tabela Pessoa Figura 64: Amostragem de dados da tabela Cliente Figura 65: Amostragem de dados da tabela Agencia Figura 66: Amostragem de dados da tabela ContaCorrente Figura 67: Amostragem de dados da tabela Emprestimo Figura 68: Modelo de Dados Data Warehouse Figura 69: Script para carga da base DW Figura 70: Amostragem de dados da tabela Clientes Figura 71: Script de carga para Clientes x

12 Figura 72: Script de carga para Emprestimo algoritmo CommandDirect Figura 73: Script de carga para Emprestimo algoritmo CursorSequential Figura 74: Amostragem de dados da tabela Emprestimos Figura 75: Características físicas do equipamento usado nos testes Figura 76: SQL*Plus com versão do Oracle Figura 77: Trecho do modelo OLTP antes e depois da modificação Figura 78: Trecho para carga de Clientes antes e depois da modificação Figura 79: Trecho para carga de Emprestimos antes e depois da modificação Figura 80: Segunda modificação no modelo OLTP e trecho do DW afetado Figura 81: Trecho da operação de carga resultante da modificação Figura 82: Terceira modificação no modelo OLTP e trecho do DW afetado Figura 83: Trecho da operação de carga resultante da modificação xi

13 Capítulo I INTRODUÇÃO O desenvolvimento do raciocínio humano teve início com sua necessidade de contar. Esta capacidade e seu desenvolvimento iniciado com a representação numérica foi um dos fatores que possibilitaram o surgimento da matemática e da lógica. O ábaco foi um dos primeiros instrumentos utilizados para dar suporte a esta operação (FILHO, 2007). O ser humano, os sistemas numéricos, a matemática e conseqüentemente a tecnologia tem se desenvolvido chegando ao que conhecemos hoje como computador, em meados do séc. XX (CONTI, 2010). Desde o surgimento do computador, sua participação no desenvolvimento da humanidade tem crescido, expandindo sua atuação e atingindo diferentes áreas. Esta disseminação da tecnologia tem permanecido razoavelmente constante. Atualmente o computador pode ser encontrado nos mais diversos locais, tais como hospitais, bancos, cartões de crédito, automóveis, eletrodomésticos, telefones e, até, nos primeiros anos escolares. Pode-se concluir, portanto, que a computação (ou informática), ao longo dos anos, tem se tornado o pilar principal de uma estrutura constituída por conhecimento e tecnologia, que estende a capacidade humana em suas diferentes áreas de interesse. Esta expansão, como era de se esperar, chegou aos altos escalões das empresas. Isto ocorreu em virtude da constante busca por vantagem competitiva, que poderia ser traduzida pela busca de conhecimento. Tal necessidade fez com que a informática 1

14 chegasse aos líderes organizacionais, com a finalidade de fornecer informações que viessem a suportar um processo decisório consciente e consistente cuja meta seria, em primeira análise, o retorno do investimento e por fim a sobrevivência da empresa. Apesar de sua constante atividade de apoio a diversas áreas do desenvolvimento humano, até a algum tempo atrás, a informática pouco (ou nada) se preocupava em apoiar seu próprio desenvolvimento. Com o advento da crise do software (PRESSMAN, 2001) esta situação foi drasticamente alterada e diversos produtos (chamados de ferramentas de produtividade) foram criados visando apoiar o desenvolvimento de software, tanto sob o aspecto de velocidade de desenvolvimento quanto de qualidade do produto gerado. Neste universo de produtos, a abordagem MDA (Model Driven Architecture) tem apresentado a possibilidade de orientar o foco do desenvolvimento do software para o negócio e modelos, permitindo a geração automática de código. O seu maior benefício está no aumento do nível de abstração no desenvolvimento do software, de forma que o desenvolvedor deixa de criar um código específico em alguma linguagem para focar no desenvolvimento de modelos que são específicos para o domínio da aplicação, mas são independentes da plataforma (LEWIS.& WRAGE, 2004). Considerando-se ambientes Business Intelligence, observou-se a existência no mercado de diversas ferramentas ETL (Extract, Transform and Load) capazes de construir o banco de dados Data Warehouse, no entanto, acreditamos que a utilização de uma abordagem que traga aumento no nível de abstração e independência de plataforma possa agregar valor ao desenvolvimento e melhorar sua produtividade. Desta forma, este trabalho analisa se os benefícios da abordagem MDA podem se tornar vantajosos para este ambiente (especialmente para sua construção). O objetivo é analisar, passo a passo, o que pode ser feito, como implementar, vantagens e desvantagens, possibilidade de desenvolvimento ou expansão, dificuldade e, finalmente, que resultados podem ser obtidos. Além da contribuição principal que expõe uma alternativa para o desenvolvimento de aplicativos ETL através da utilização de MDA, este trabalho também pretende apresentar algumas outras contribuições paralelas: 2

15 A primeira se refere ao rastreamento das etapas necessárias a novas implementações em cartuchos (MDA), novos ou pré-existentes. O objetivo é estabelecer um processo padrão que oriente futuros desenvolvimentos. A segunda trata da nomenclatura para Data Warehouse (DW) e técnicas correspondentes, estabelecidas por KIMBALL & ROSS (2002), de tal forma que a utilização dos conceitos seja fortemente aplicada durante o desenvolvimento do modelo DW. A terceira refere-se à lista que contém as mensagens de erro utilizadas durante a validação do modelo DW, na qual se poderá observar, mais uma vez, a aderência ao modelo dimensional e demais preceitos estabelecidos por KIMBALL & ROSS (2002). E é neste sentido que esta coleção de mensagens se caracteriza como uma contribuição adicional deste trabalho. Esta dissertação constitui-se de seis capítulos, além desta introdução, e de sete apêndices, descritos, resumidamente a seguir: No Capítulo II, Conceitos Fundamentais, discorre-se sobre os principais conceitos estudados para o desenvolvimento deste trabalho (MDA Model Driven Architecture, DSS Decision Support Systems e ETL Extract Transform and Load), destacando-se suas características e vantagens de uso. No Capítulo III, Trabalhos Relacionados, serão, brevemente, apresentados alguns trabalhos que versem tanto sobre MDA quanto ETL objetivando a contextualização do trabalho atual dentro da comunidade científica. No Capítulo IV, Especificação, serão estudadas as etapas para desenvolvimento de um produto visando à geração de código para ambiente ETL. Serão detalhados, dentre outros, os objetivos principais, requisitos para desenvolvimento e opções de implementação. No Capítulo V, Prova de Conceito, seguindo as etapas definidas previamente no capítulo IV, será apresentada e exemplificada uma prova de conceito, caracterizandose por um desenvolvimento dentro de limites pré-estabelecidos capaz de ratificar os objetivos definidos. 3

16 No Capítulo VI, Resultados e Conclusões, os resultados do desenvolvimento serão analisados e as vantagens e desvantagens da abordagem avaliadas. Um comparativo identificando a aplicabilidade da abordagem proposta versus o uso de ferramentas ETL de mercado encontra-se no início deste capítulo. Além destes itens também serão discutidas as possibilidades de implementação e perspectivas futuras. O Apêndice I (Metafacades) contém os modelos metafacades modificados para adição das classes necessárias ao desenvolvimento. O Apêndice II (Verificações e Mensagens de Erro) apresenta todas as mensagens de erro e suas correspondentes verificações utilizadas na prova de conceito. O Apêndice III (Profile de Persistência) apresenta o profile de persistência, onde diversos itens foram adicionados para atender aos objetivos do projeto. O Apêndice IV (Modelos UML da Poc) contém os modelos de classes utilizados como exemplo para a prova de conceito. O Apêndice V (Desempenho na Carga) contém o modelo de dados utilizado como exemplo para a prova de conceito juntamente com um teste realizado para avaliação de desempenho da carga, de acordo com o algoritmo escolhido. O Apêndice VI (Exemplos de Modificações no Modelo de Objetos) apresenta um conjunto de alterações realizadas nos modelos de classes e o impacto no código gerado a partir destas modificações, considerando-se os modelos originais da Poc. Finalmente, o Apêndice VII (Arquivos de Especificação) apresenta os arquivos de especificação (cartridge.xml, metafacades.xml e profile.xml) do cartucho utilizado como base para a implementação da prova de conceito. OBS: Os fontes desenvolvidos neste trabalho serão disponibilizados no Portal do Software Público Brasileiro, no assunto MDARTE cujo endereço se encontra nas Referências Bibliográficas deste trabalho. 4

17 Capítulo II CONCEITOS FUNDAMENTAIS A utilização da tecnologia como um meio de extensão dos sentidos humanos e aperfeiçoamento de suas capacidades, se materializa através de ferramentas (softwares) e componentes de hardware mais sofisticados a cada dia. Pode-se dizer que a tecnologia seria um fazer, tendo como propulsor o raciocínio e os sentidos (SOUZA, 2008), possuindo vinculação com o desenvolvimento social, econômico e cultural de sua época (FLUSSER, 2002). No entanto, ela mesma não é o objetivo final. Desde os primórdios, seu objetivo tem sido o de apoiar, aperfeiçoar e facilitar atividades executadas pelo ser humano. II.1. O software e a Engenharia A informática, enquanto ciência da computação, vem se estruturando, visando garantir a qualidade e aumentar a produtividade no desenvolvimento do software (FERNANDES & WERNER, 2009). Nos seus primórdios existiam dois níveis de linguagem de programação: nível da máquina (onde o código era desenvolvido) e nível da lógica digital (onde os programas eram executados). Já em 1951 surgiu um terceiro nível (interpretador) com a função de execução dos programas escritos em linguagem de máquina (FILHO, 2007). A partir daí houve um grande desenvolvimento das linguagens de programação e, efetivamente, de softwares utilizando tais linguagens, no entanto, não havia critérios 5

18 que orientassem esse processo de desenvolvimento. Isso acabou sendo fatal, como o revelaram estudos, elaborados na década de 1970, sobre o desenvolvimento de sistemas: ausência de correção e consistência, baixa qualidade, manutenção extremamente custosa em função de problemas não detectados por ausência de uma validação de requisitos mais rigorosa, não reaproveitamento de código, prazos de implementação não cumpridos em conseqüência de erros ao longo própria fase de implementação (FILHO, 2007). Este cenário ficou conhecido como "crise do software" (PRESSMAN, 2001). Em resposta a este cenário foi criada a disciplina Engenharia de Software que tem a intenção de dar um tratamento sistemático e controlado ao desenvolvimento de softwares complexos, além de melhorar a qualidade do software gerado, aumentar a produtividade e atender aos requisitos de eficácia e eficiência (MAFFEO, 1992). Ironicamente, não havia até a crise do software, uma preocupação em se automatizar a própria informática. Foi somente a partir deste momento que a utilização de softwares para automação de processos de desenvolvimento de software passou a ser considerado. Hoje a Engenharia de Software enfrenta desafios ainda maiores que ao tempo de sua criação, tais como: produtividade (sistemas complexos e com grande número de tecnologias envolvidas), portabilidade (softwares fortemente ligados às suas respectivas plataformas), interoperabilidade (a ligação e troca de informações entre sistemas de diferentes tecnologias e plataformas), documentação (modelos são independentes do código, tornando qualquer mudança de requisito em modificação da documentação e do código independentemente) (TRINTA, 2010). Um aspecto que tem crescido constantemente desde o primeiro código é o distanciamento entre o código desenvolvido (mais próximo da linguagem humana) e o gerado (código de máquina). Este distanciamento é chamado de nível de abstração. As linguagens de baixo nível (p.ex: assembly), mais próximas da linguagem de máquina deram lugar a linguagens de alto nível, compostas de símbolos mais complexos, inteligíveis pelo ser humano e não executáveis diretamente pela máquina. Estes saltos tecnológicos trouxeram significativas modificações na forma de se codificar. Em cada um deles ocorreu algum ganho (aumento) no nível de abstração. Seja no afastamento da linguagem da máquina, seja no afastamento da plataforma (QUEIROZ, 2010). 6

19 Até alguns anos atrás, o investimento em nível de abstração (aumento da distância entre o código humano e o código de máquina) era difícil, principalmente por causa do hardware, uma vez que seu custo tornava indispensável a otimização do software desenvolvido. Atualmente, este tipo de pressão é menor, pois o custo do hardware diminuiu consideravelmente em relação ao custo da mão de obra. A preocupação, então, passou a ser a produtividade. O melhor aproveitamento da mão de obra tornouse mais significativo para um projeto que o hardware. Ultimamente têm surgido conceitos que objetivam um novo salto: a elevação do nível da solução através da abstração da codificação e evidenciação das regras e fluxos de negócio. Estes conceitos buscam um melhor aproveitamento do tempo de concepção e desenvolvimento, privilegiando atividades conceituais como especificação, modelagem e prototipagem. Com isso tornam o desenvolvimento (ou mais especificamente, a codificação) mais simples, trazendo como conseqüência a diminuição da necessidade de especialização e quantidade de mão de obra (QUEIROZ, 2010). Os principais conceitos nesta área são: Orientação a Aspectos, Model Driven Architecture (MDA), Ontologias, Wisewig, BPM. É possível que, em um futuro não muito distante, a programação, como a que conhecemos hoje, deixe de existir e a informática se concentre apenas no negócio, deixando as tarefas de desenvolvimento para softwares capazes de gerar o código, a interface e o banco de dados. II.2. Aumentando o nível de abstração com MDA De acordo com KONTIO (2005), MDA (Model Driven Architecture - Arquitetura Orientada por Modelos) é uma abordagem que propõe, através de sua arquitetura, a separação entre a especificação do sistema e os detalhes de sua operação, os quais são inerentes à plataforma usada (de tal forma que as modificações na plataforma não afetem as aplicações existentes e a lógica de negócio evolua independentemente da tecnologia). Isso significa que o foco principal do desenvolvimento com esta abordagem migra do nível de código para o nível de modelo. Esta abordagem (MDA) foi adotada em 2001 pelo OMG (Object Management Group) como um framework que usa modelos no desenvolvimento de software (OMG, 2003). 7

20 A abordagem MDA estabelece uma seqüência de etapas entre a concepção inicial do software e sua construção final na plataforma desejada (OMG, 2003). Estas etapas são: Especificação de um sistema independentemente da plataforma que o suporte; Especificação das plataformas candidatas e determinação da plataforma a ser utilizada pelo sistema; Transformação da especificação do sistema (genérica) para a plataforma escolhida (específica). As três principais metas da abordagem MDA são portabilidade, interoperabilidade e reusabilidade. Para atingir estas metas a arquitetura MDA utiliza três níveis de modelos: CIM, PIM e PSM. O nível CIM (Computation Independent Model) utiliza especificações que não apresentam detalhes da estrutura do sistema. Neste nível o sistema é especificado em termos de negócio: o que deve ser feito e não, como deve ser feito. De acordo com a OMG (2003), o usuário do CIM não precisa estar familiarizado com modelos ou artefatos necessários ao desenvolvimento das funcionalidades para os requisitos definidos neste nível. O CIM representa o nível mais alto, mais abstrato da especificação do sistema. O segundo nível (ou nível intermediário) é o PIM (Platform Independent Model), onde as operações a serem realizadas pelo sistema são especificadas não se levando em consideração onde serão construídas. Uma técnica sugerida por OMG (2003) para a obtenção de independência de plataforma é modelar o sistema para uma technology-neutral virtual machine (isto é, uma máquina virtual de tecnologia neutra, sem plataforma definida, onde os serviços necessários ao projeto podem ser definidos independentemente de qualquer plataforma). Desta forma, o modelo do sistema pode ser definido para esta plataforma genérica, virtual e, posteriormente, derivado para a plataforma desejada (OMG, 2003). O terceiro nível ou PSM (Platform Specific Model) combina as especificações feitas no PIM com os detalhes de como o sistema usa um tipo particular de plataforma. A partir da definição do PSM, o código da aplicação pode ser gerado para execução na plataforma escolhida. 8

21 A passagem de um modelo para o outro (CIM PIM PSM), dentro da arquitetura MDA obedece a critérios diferenciados. Enquanto a transformação do CIM em PIM é manual, através de refinamentos da especificação realizada ao nível de CIM, a transformação do PIM em PSM pode ser feita de forma automática através de mapeamentos, permitindo que ferramentas realizem esta transformação. A partir deste ponto a criação de código para a plataforma específica já pode ser realizada. A figura 1(baseada em MAZÓN et al., 2005), a seguir, representa a seqüência de etapas de transformação desde uma especificação de negócio até seu código final. Pode-se observar que o mapeamento do PIM, que permite a transformação automática para o PSM pode ser reprisado para diferentes plataformas, favorecendo o desenvolvimento de código de acordo com a necessidade. Figura 1: Etapas de transformação CIM PIM PSM Através da figura 1 (baseada em MAZÓN et al., 2005) também se pode inferir que a especificação não é perdida após sua conversão em código. O processo pode ser reprisado a qualquer momento após o desenvolvimento do sistema, seja para conversão de plataforma, seja para inclusão, alteração ou exclusão de funcionalidades. Esta é, verdadeiramente, a promessa MDA, isto é, favorecer a definição de aplicações e modelos de dados que permitam flexibilidade a longo prazo 9

22 no que se refere a: implementação, integração, manutenção, teste e simulação (OMG, 2003). Apesar do processo de passagem do CIM para o PIM ter sido apresentado como Transformação Manual, a OMG (2008) já especificou um conjunto de regras capazes de tornar esta conversão automática. O padrão SBVR (Semantics of Business Vocabulary and Business Rules), estabelecido pelo OMG, tem a finalidade de estabelecer um conjunto de regras para a definição de especificações de negócio de tal forma que as especificações hoje, desenvolvidas em linguagem natural possam ser representadas formalmente visando o processamento mecânico (por computador). Figura 2: Posicionamento do SBVR no processo MDA (OMG, 2008) Este posicionamento tem duas implicações: 1. O SBVR está focado nas regras e vocabulários de negócios, incluindo aqueles relevantes para o uso em conjunto com essas regras. Outros aspectos de modelos de negócios também têm que ser desenvolvidos, incluindo processos de negócios e organização estrutura, mas estes devem ser abordados pela OMG em outras iniciativas. 2. Os modelos de negócios, incluindo os modelos que SBVR suporta, descrevem as empresas e não os sistemas de TI que os suportam. Na arquitetura MDA, os sistemas de TI são especificados usando modelos independentes de plataforma (PIMs) e modelos específicos de plataforma (PSMs). Desta forma, algum direcionamento será necessário para a transformação de modelos de negócios para PIMs. Tal orientação está fora do escopo de SBVR. Está previsto 10

23 que a OMG irá garantir que os metamodelos para diferentes aspectos da modelagem de negócios formem um todo coerente e pretende estabelecer regras visando orientar o desenvolvimento das transformações do modelo de negócios para PIM apropriadamente no futuro. II.3. Contribuição ao MDArte O MDArte tem como propósito a criação de um novo referencial de software público, com o uso de tecnologias modernas, redução do custo total dos serviços de tecnologia da informação e da dependência de soluções proprietárias (MDARTE, 2011). A solução foi lançada no dia 27 de outubro de 2009 em Brasília, durante a abertura do Encontro Nacional do Software Público. O MDArte é baseado na Metodologia MDA, arquitetura dirigida a modelos, e tem como kernel do seu framework a tecnologia aberta AndroMDA (LASKOSKI, 2011). Segundo o site de seus desenvolvedores (ANDROMDA, 2011), o AndroMDA é um framework gerador de código extensível que segue o paradigma MDA. Os modelos em UML (Unified Modeling Language) podem ser transformados em componentes portáveis para a plataforma desejada. O AndroMDA é extensível através de cartuchos possuindo uma série deles já prontos, como Struts, JSF, Spring e Hibernate. Através da MDA os modelos (de classes, atividades, casos de uso) criados em uma ferramenta UML de mercado são exportados em um formato padrão XMI (XML Metadata Interchange) (OMG, 2010), em seguida lidos e analisados pelo cartucho mais apropriado, que gera o código fonte na plataforma desejada (APACHE, 2009). Com a abordagem MDA pretende-se a obtenção de uma infra-estrutura voltada para o desenvolvimento de softwares de governo e disponibilizadas como software público. Este é o principal objetivo da comunidade MDArte (MDARTE, 2011). E é neste sentido que este trabalho se alinha, uma vez que utiliza a abordagem MDA (e o software AndroMDA) para a geração de aplicações ETL (Extract, Transform and Load) a partir de modelos desenvolvidos em UML. A MDArte compreende um conjunto de cartuchos AndroMDA com diversas soluções de projeto e arquitetura incorporadas nos procedimentos de transformação de modelos seguindo a abordagem 11

24 MDA. Ao término do desenvolvimento deste trabalho a comunidade poderá contar com mais instrumento para geração de aplicativos no ambiente Business Intelligence partindo apenas de modelos de alto nível. II.4. Apoiando a Decisão A busca constante por vantagem competitiva faz com que os executivos das empresas estejam, constantemente, analisando suas informações internas (obtidas da própria empresa) e necessitando de novas para a tomada de decisão. Atualmente, a importância da informação para as organizações é universalmente aceita, constituindo senão o mais importante, pelo menos, um dos mais importantes recursos cuja gestão e aproveitamento estão diretamente relacionados ao sucesso desejado (TARAPANOFF, 2001). A utilização da informação no processo decisório, no entanto, não é simples. O volume de informações e dados recebidos pelas organizações diariamente é muito grande. Sabe-se que esta quantidade vem crescendo vertiginosamente a cada ano, chegando mesmo a dobrar a cada cinco anos (OMG, 2003). Para que seja possível a tomada de decisão acertada, o volume de informações e de dados colocados à disposição daqueles que decidem deve ser na medida certa (MORESI, 2000). E é aí que a informática atua como apoio à área executiva da empresa objetivando fornecer a informação certa na hora certa. Segundo MORESI (2000) existem quatro classes diferentes de informação: dados, informação, conhecimento e inteligência. Cada uma destas classes possui diferentes valores para o processo decisório: Dados compreendem a classe mais baixa de informação, é a informação bruta, isto é, são sinais que não foram processados ou interpretados de qualquer forma. Correspondem à matéria-prima a ser utilizada na produção de informações. Não podem ser fornecidos diretamente aos altos escalões da empresa. Informação esta classe já compreende dados que passaram por algum tipo de processamento (formatação, tradução, fusão, impressão e assim por diante). 12

25 Estas informações, geralmente, são usadas nos escalões inferiores da organização, onde a necessidade de informação é quantitativa, possibilitando o desempenho das tarefas do dia a dia. Estão vinculadas à atividade fim da empresa. Conhecimento neste nível as informações foram avaliadas sobre sua confiabilidade, sua relevância e sua importância. É obtido pela interpretação e integração de vários dados e informações. Os insumos provenientes das diversas fontes são analisados e combinados visando à obtenção do conhecimento. Inteligência situa-se no nível mais alto desta hierarquia e é composta não somente por informações. Resulta da síntese do conhecimento, com o uso do julgamento e da intuição daquele que toma decisões. É o conhecimento aplicado ao contexto, transformado em oportunidade e vantagem competitiva. A figura 3, baseada em MORESI (2000), apresenta uma representação esquemática da conversão dos dados inicialmente capturados até atingirem o nível da inteligência. Figura 3: Classes da Informação Esta hierarquia está intimamente associada à própria hierarquia de uma empresa. O nível mais baixo corresponde à entrada de dados nos diversos sistemas de 13

26 informação da empresa (p. ex.: o número da nota fiscal, os itens vendidos na nota fiscal, valor e data da venda etc.). Estes dados são validados, complementados, organizados e armazenados para servir às áreas operacionais da empresa, que trabalham com a informação quantitativa, a informação do dia a dia, que permite gerir o negócio da empresa. A transformação de informação em conhecimento requer mais do que simples agrupamento de dados, requer um processo de análise que estabeleça o tipo de informação a ser fornecida, sua preparação, agregação ou síntese em unidades inteligíveis e a apresentação de forma compreensível e prática para o nível decisório da organização (MORESI, 2000). A necessidade de obtenção de informações qualitativas que permitissem aos altos escalões usarem a informação interna da empresa para obter uma visão global de seu negócio causou o desenvolvimento de sistemas que viessem a dar suporte e ajudar na gestão de decisões estratégicas. Estes sistemas são conhecidos como Sistemas de Apoio à Decisão (DSS Decision Support Systems). Nos anos 80 o GARTNER GROUP (2010) cunhou o termo Business Intelligence (BI), que corresponde a um conjunto de técnicas, métodos e processos que objetivam transformar dados em conhecimento para suportar um processo decisório consciente e consistente cuja meta é a vantagem competitiva, o máximo retorno do investimento e o menor risco. No processo de desenvolvimento de um projeto de BI (Business Intelligence), a primeira etapa é uma técnica chamada Modelagem Dimensional (KIMBALL & ROSS, 2002), isto é, a modelagem de uma base de dados capaz de armazenar e fornecer as informações necessárias à tomada de decisão. Já o local de armazenamento (ou base de dados) onde são concentradas informações históricas e agregadas para permitir consultas e análises é chamado de Data Warehouse (DW). Segundo ELMASRI & NAVATHE (2005), os DWs proporcionam acesso aos dados para análises complexas, descobertas de conhecimento, facilitando a decisão e oferecendo suporte às demandas por dados e informações em uma organização. De acordo com INMON (1992), um Data Warehouse (DW) é uma coleção de dados orientada por assunto, integrada, variante no tempo e não volátil que tem por objetivo dar suporte aos processos de tomada de decisão. É uma forma de, apropriadamente, construir e gerenciar dados oriundos de diversas fontes com o propósito de obter 14

27 desde uma simples visão de partes, até uma visão global de todo um negócio (GARDNER, 1998). A última etapa de um projeto de BI e, talvez a mais difícil, é a tomada de decisão baseada na consulta das informações coletadas. Tais consultas são realizadas, normalmente, através de ferramentas especializadas - OLAP (online analytic processing), mineração de dados (data mining), projeção de cenários e relatórios adhoc. II.5. Criando o ambiente DW O estudo contido neste trabalho trata apenas de uma das etapas da construção de um Data Warehouse chamada ETL (Extract-Transform-Load), cujo objetivo é realizar a obtenção, preparação e armazenamento de dados oriundos das bases diárias em uma base dimensional (DW Data Warehouse). O modelo dimensional possui não apenas características diferentes de um modelo diário (normalmente relacional), mas também nomenclatura e objetivos específicos. De acordo com KIMBALL & ROSS (2002), o modelo dimensional apresenta uma estrutura simplificada onde uma tabela central, chamada Fato, é ligada a várias tabelas responsáveis pela descrição dos fatos, chamadas de Dimensão. A agregação é uma tabela resumo construída a partir de fatos individuais e cujo objetivo é o desempenho de acesso. A transferência de dados entre um ambiente diário (OLTP on-line transaction processing) e um ambiente DW congrega um conjunto de operações. Segundo KIMBALL & ROSS (2002), o primeiro passo é a obtenção dos dados do ambiente original (esta origem pode corresponder a diversas fontes de dados, de acordo com a organização do ambiente OLTP). A extração significa a leitura e entendimento da origem dos dados e a transferência destes dados para uma área de tratamento chamada Staging Area. Uma vez que o dado é extraído, diversas transformações podem ser realizadas, tais como limpeza (tratamento de elementos desaparecidos, padronização de formatos, resolução de conflitos de domínios), combinação de dados oriundos de múltiplas fontes, eliminação de duplicidades e associação a chaves únicas. A última etapa é carga no ambiente definitivo (DW), onde a alta direção poderá realizar pesquisas e obter uma visão global de suas informações. 15

28 Estas etapas são realizadas, basicamente, de duas maneiras: através de programas (freqüentemente escritos na linguagem procedural do banco de dados) ou através de sofisticados softwares de mercado (chamados ferramentas ETL) que requerem o desenvolvimento de modelos específicos para cumprimento desta tarefa. Este trabalho apresenta uma terceira alternativa, iniciada em FERNANDES, NETO, FAGUNDES et al. (2010), na qual a partir dos modelos UML (Unified Modeling Language), principalmente do modelo de classes, são gerados os códigos necessários às operações de extração, transformação e carga. II.6. Explorando a Arquitetura Data Warehouse Neste tópico, utilizando fortemente os preceitos definidos por KIMBALL & ROSS (2002) descreveremos os componentes da arquitetura Data Warehouse e estabeleceremos um vocabulário que será utilizado durante todo o desenvolvimento deste trabalho. Iniciamos este assunto estabelecendo os requisitos básicos para um Data Warehouse (DW): 1. O Data warehouse deve tornar a informação da organização facilmente acessível o conteúdo deve ser intuitivo e óbvio para o usuário de negócio entender (e não apenas o desenvolvedor), o que implica em legibilidade e dados identificados de forma significativa. Os usuários devem ser capazes de realizar operações de combinação e separação de dados, além de obter tais informações com o mínimo tempo de espera. 2. O Data Warehouse deve apresentar consistentemente as informações da organização isto é, ele deve ter credibilidade. O dado, oriundo de diversas fontes, deve ser cuidadosamente trabalhado, criticado, limpo, corrigido, padronizado, consolidado e, só então, apresentado para o usuário. 3. O Data Warehouse de ser adaptável e resistente à mudança isto significa que mudanças no negócio do cliente devem ser refletidas no DW sem trazer impacto para os dados previamente armazenados, isto é, sem invalidá-los e sem modificá-los. 16

29 4. O data warehouse deve servir como base para a tomada de decisão deve conter os dados corretos para apoiar as decisões da organização. Estas decisões trazem impacto nos negócios e valoriza a utilização do DW. Considerando-se os requisitos descritos previamente, passaremos a descrever os componentes de um ambiente warehousing. Na figura 4 (baseada em KIMBALL & ROSS, 2002), encontramos quatro componentes específicos de um ambiente Data Warehouse: Origem de Dados estes dados são oriundos dos sistemas que capturam as transações do negócio do cliente. São os dados do dia a dia. Correspondem à matéria-prima a ser utilizada na produção de informações para o usuário. Área Intermediária (Data Staging Area) corresponde a uma área de trabalho, não acessível pelos usuários, utilizada durante o processo de extração, transformação e carga. Figura 4: Componentes básicos de um ambiente DW Área de Apresentação é onde os dados são organizados, armazenados e disponibilizados para consulta direta pelos usuários, ferramentas de relatórios, e outros aplicativos analíticos. É o Data Warehouse em si. Os dados neste tipo de banco de dados estão organizados de acordo com o modelo dimensional. Um modelo dimensional contém a mesma informação que um modelo E-R normalizado, mas os dados são empacotados em um formato cujo objetivo é a compreensibilidade do usuário, o desempenho da consulta, e a resistência à mudança. Se a área de apresentação é baseada em um banco de dados relacional, então estas tabelas 17

30 modeladas dimensionalmente são organizadas em um formato conhecido como esquema estrela. A outra possibilidade é a utilização de bancos de dados dimensionais (não será tratado neste material). Ferramentas de Acesso a Dados O último componente importante do ambiente de Data Warehouse são as ferramentas de acesso a dados, isto é, o conjunto de recursos que podem ser fornecidos aos usuários de negócios para consultar a área de apresentação visando análises e decisões. Por definição, todas as ferramentas de acesso a dados, o fazem na área de apresentação. A partir deste ponto será apresentada parte do vocabulário dimensional: Fato a tabela de fato é a principal tabela em um modelo dimensional, pois é onde se armazenam as medidas numéricas de desempenho do negócio. Podese observar na figura 5 (baseada em KIMBALL & ROSS, 2002) que a tabela de fato Vendas possui diversas chaves (associadas a cada uma de suas dimensões) e medidas que caracterizam o negócio (quantidade vendida por cliente-loja-vendedor-período, valor total da venda por cliente-loja-vendedorperíodo, percentual de comissão por cliente-loja-vendedor-período). As tabelas de fato representam relações mxn entre dimensões. Uma linha em uma tabela de fato representa uma medida. Uma medida é uma linha em uma tabela de fato. Todas as medidas em uma tabela de fato devem ter a mesma granularidade (por exemplo, todas as medições devem estar associadas a mês: quantidade vendida no mês-cliente-loja-vendedor, percentual de comissão no mês-cliente-loja-vendedor, etc.). Os fatos mais úteis são numéricos e aditivos (por exemplo: quantidade vendida. Um contra-exemplo seria o percentual de comissão, que apesar de ser numérico não é aditivo), isto é, podemos adicionálos em várias linhas e obter informações agregadas (por exemplo: se somarmos a quantidade vendida no mês para uma loja por um vendedor, teremos o total das vendas deste vendedor independentemente do cliente que realizou a compra. O mesmo não pode ser feito com o % de comissão). 18

31 Figura 5: Tipos de tabelas em um Data Warehouse Dimensão as tabelas de dimensão estão sempre vinculadas a alguma tabela de fato. Não possuem vida própria ou independente. Descrevem os fatos. Contém informações textuais sobre os fatos a que se relacionam. A dimensão Cliente, apresentada na figura 5 (baseada em KIMBALL & ROSS, 2002) caracteriza o cliente do fato Vendas, isto é, contém informações relativas ao cliente que realizou a compra registrada no Fato. As dimensões possuem chaves simples, sendo que seus atributos, normalmente, são usados como filtro nas consultas e definem o nível de agregação dos dados. São a chave que torna o DW utilizável e compreensível. Os melhores atributos são textuais e discretos. No Apêndice III apresentamos mais alguns componentes do vocabulário dimensional, sua utilização no trabalho e o impacto na geração de código. 19

32 Capítulo III TRABALHOS RELACIONADOS Neste capítulo serão apresentados, resumidamente, diversos trabalhos relacionados a Data Warehouse, processo ETL (Extract-Transform-Load) e MDA (Model Driven Architecture). Estes trabalhos serão apresentados cronologicamente de acordo com o ano de sua publicação para que seja possível uma noção da evolução da pesquisa científica na área foco deste trabalho. Ao término de toda a exposição será analisada a evolução dos trabalhos nesta área e a contextualização do atual trabalho neste conjunto de estudos desenvolvidos ao longo dos últimos anos. III VASSILIADIS, P., SIMITSIS, A., SKIADOPOULOS, S. no artigo "Conceptual modeling for ETL processes" estabeleceram como foco o problema da definição de atividades de ETL e fornecimento de bases formais para sua representação conceitual. Neste momento, o modelo proposto por eles é conceitual (a) personalizado para o rastreamento de relações inter-atributos e as respectivas atividades ETL nos estágios iniciais de projeto DW; (b) enriquecido com uma "paleta" contendo as mais freqüentes atividades ETL usadas, como, por exemplo, a atribuição de chaves substitutas (surrogate keys), a verificação de valores nulos etc.; (c) construída de uma 20

33 maneira personalizável e extensível, para que o designer possa enriquecê-lo de acordo com seus próprios padrões recorrentes para as atividades ETL. III TRUJILLO, J., LUJÁN-MORA, S. neste artigo, intitulado "A UML Based Approach for Modeling ETL Processes in Data Warehouses", exaltam a complexidade de um ambiente Data Warehouse e enfatizam a necessidade de desenvolvimento de processos ETL capazes de produzir dados de qualidade. Observam que, nesta época, havia pouca pesquisa vinculada à modelagem de processos ETL. Desta forma apresentam uma abordagem utilizando UML (Unified Modeling Language) para a modelagem conceitual de processos ETL. Nesta modelagem são mapeadas as operações mais comuns associadas a ETL, tais como a integração de diferentes fontes de dados, a transformação entre fonte e atributos de destino, a geração de chaves substitutas e assim por diante. Um dos pontos importantes da abordagem, segundo os autores, é a integração do design de processos ETL com o esquema conceitual DW. SIMITSIS, A., VASSILIADIS, P. fizeram uma proposta de metodologia para as primeiras fases do projeto de data warehouse, com o objetivo de traçar uma análise da estrutura e conteúdo das fontes de dados existentes e seu mapeamento para o modelo conceitual de um DW no artigo "A Methodology for the Conceptual Modeling of ETL Processes". Esta metodologia compreende um conjunto de passos que podem ser resumidos como: identificação das bases destino; mapeamento de atributos entre os fornecedores e consumidores e, finalmente, marcação de restrições de execução. III VASSILIADIS, P., SIMITSIS, A., TERROVITIS, M., SKIADOPOULOS, S. neste trabalho ("A generic and customizable framework for the design of ETL scenarios") se aprofundam no projeto lógico de cenários ETL e no fornecimento de uma estrutura genérica e personalizável com o objetivo de apoiar o modelador DW em sua tarefa. Eles apresentam um metamodelo customizado para a definição das atividades de ETL e seguem uma abordagem de fluxo de trabalho, onde a saída de uma determinada atividade pode ser armazenada persistentemente ou passada para uma atividade subseqüente. Além disso, empregam uma linguagem de programação de banco de 21

34 dados declarativa, LDL, para definir a semântica de cada atividade. O metamodelo é genérico o suficiente para capturar qualquer possível atividade ETL. Visando à reusabilidade e flexibilidade, construíram uma paleta com as atividades ETL mais freqüentemente usadas (chamados templates). No artigo também encontramos uma discussão sobre a mecânica de instanciação de modelo para atividades concretas. Os conceitos de design apresentados estão sendo implementados em uma ferramenta, Arktos II, que também é apresentada. MAZON, J.N., TRUJILLO, J., SERRANO, M., PIATTINI, M. no seu artigo "Applying MDA to the development of data warehouses" colocam que diferentes abordagens de modelagem têm sido propostas para superar cada armadilha de projeto no desenvolvimento das diferentes partes de um sistema Data Warehouse (DW). No entanto, segundo eles, todas estas propostas correspondem a soluções parciais que tratam de aspectos isolados do DW e não fornecem designers com um método integrado e padronizado para projetar todo o DW (processos ETL, fontes de dados, o repositório de DW e assim por diante). Como a Model Driven Architecture (MDA) é uma estrutura padrão para desenvolvimento de software que aborda o ciclo de vida completo passando por concepção, implantação, integração e gerenciamento de aplicações através de modelos no desenvolvimento de software, neste artigo eles descrevem como alinhar todo o processo de desenvolvimento DW para toda MDA. Começam com a definição de uma MDA multidimensional (MD2A) e seguem com uma abordagem para a aplicação do framework MDA para uma das etapas do desenvolvimento DW: modelagem multidimensional (MD). Primeiramente apresentam a descrição de como construir os diferentes artefatos MDA (modelos, por exemplo) usando extensões da Unified Modeling Language (UML). Em segundo lugar, as transformações entre os modelos são claramente e formalmente estabelecidas usando a abordagem Query/View/Transformation (QVT). Finalmente, um exemplo é fornecido para melhor mostrar como aplicar MDA e suas transformações para a modelagem multidimensional (MD). SIMITSIS, A. apresenta-nos o artigo "Mapping Conceptual to Logical Models for ETL Processes" que descreve o mapeamento do conceitual para o modelo lógico. Em sua linha de pesquisa anterior ele estava trabalhando em um modelo lógico e conceitual para processos ETL. Ele inicia o artigo identificando como uma entidade conceitual é mapeada para uma entidade lógica. Em seguida determina a ordem de execução dentro do fluxo lógico usando informações adaptadas a partir do modelo 22

35 conceitual. Finalmente ele apresenta uma metodologia para a transição do conceitual para o modelo lógico. III De acordo com CHOWDHARY, MIHAILA & LEI (2006), os data warehouses tradicionais são manualmente desenvolvidos a partir de requisitos específicos e necessidades de análises de dados. Como conseqüência desta abordagem eles percebem um descompasso entre a definição dos modelos de processo dos negócios e os dados armazenados em data warehouses como se eles fossem desenvolvidos manualmente e em isolamento. Desta forma, consideram um desafio a manutenção do DW em sincronismo com as contínuas modificações dos modelos de processo de negócio. Em seu artigo "Model Driven Data Warehousing for Business Performance Management" eles estabelecem uma abordagem MDDW (Model Driven Data Warehouse) na área do BPM (Business Performance Management), de tal forma que o MDDW torne-se uma ponte entre os modelos DW e BPM. Segundo SKOUTAS, D. e SIMITSIS, A., em seu artigo "Designing ETL processes using semantic web technologies", uma das tarefas mais importantes realizadas nos estágios iniciais de um projeto data warehouse é a análise da estrutura e conteúdo das fontes de dados existentes e seu mapeamento para um modelo de dados comum. Eles observam que estabelecer os mapeamentos apropriados entre os atributos das fontes de dados e os atributos das tabelas do Data Warehouse é fundamental para a especificação das transformações necessárias em um fluxo de trabalho ETL. Dizem ainda, que o modelo de dados selecionado deve ser adequado para facilitar os esforços de redefinição e revisão, que geralmente ocorrem durante as fases iniciais de um projeto data warehouse e servir como meio de comunicação entre as partes envolvidas. Neste artigo eles tecem uma argumentação sobre a utilização de ontologias para este fim, pois acreditam que constituem um modelo muito apropriado para este objeto. Em seguida mostram como o uso de ontologias pode permitir que um alto grau de automação sobre a construção de um projeto de ETL. III Os data warehouses (DWs) armazenam informações históricas e agregadas extraídas de fontes de informação heterogêneas, autônomas e distribuídas, desta 23

36 forma, torna-se essencial a especificação de medidas de segurança desde os estágios iniciais do desenvolvimento DW, segundo SOLER, TRUJILLO et al. no artigo "A Framework for the Development of Secure Data Warehouses based on MDA and QVT" eles apresentam um framework baseado em MDA (Model Driven Architecture) para o desenvolvimento seguro de data warehouses, que contempla todas as fases de desenvolvimento (conceitual, lógico e físico), embutindo medidas de segurança em todos os níveis. III No artigo intitulado "A Mixed Approach for Data Warehouse Conceptual Design with MDA", ZEPEDA, CELMA & ZATARIN adotam um conjunto de regras de transformação como mecanismo para a extração de esquemas multidimensionais a partir da descrição conceitual do banco de dados operacional. O método desenvolvido se inicia na descrição conceitual do banco de dados operacional, segue com a captura dos requisitos de DW e termina com um esquema multidimensional conceitual e detalhado. A solução para esta abordagem remete ao uso de MDA. Já GLORIO & TRUJILLO em seu artigo "An MDA Approach for the Development of Spatial Data Warehouses" tratam da implementação da abordagem MDA para o desenvolvimento de "spatial data warehouses" através de uma extensão para o modelo dimensional. Eles definem um conjunto de regras de transformação usando Query / View / Transformation (QVT) que permitem a obtenção de uma representação lógica e automática. MAZÓN & TRUJILLO no artigo "An MDA approach for the development of data warehouses" descrevem como alinhar o processo de desenvolvimento DW com o framework MDA (Model Driven Architecture). Eles focam o desenvolvimento do repositório DW, descrevendo como construir diferentes modelos MDA para este repositório através de uma extensão da UML (Unified Modeling Language) e de CWM (Common Warehouse Metamodel). A transformação entre modelos também é estabelecida com o uso de QVT (Query / View / Transformation language). Em uma tentativa de transformar a gestão de dados de uma empresa rentável, muitas delas estão buscando a integração e centralização de seus dados através de data warehousing segundo MATHEW, A.D., MA, L., HARGREAVES, D.J. no artigo "A 24

37 conceptual data modelling methodology for asset management data warehousing". Segundo os autores um Data Warehouse permite às empresas transformar dados em conhecimento, e conhecimento em lucros tangíveis. De acordo com eles um fatorchave de sucesso de um Data Warehouse está em sua capacidade de integrar dados de várias fontes através de um modelo de dados unificado. Dentro da gestão de ativos, vários destes modelos de dados integrados têm sido propostos, porém, individualmente, eles cobrem apenas um número limitado de áreas dentro dos dados de gerenciamento de ativos e não são projetados com data warehousing em mente. No artigo os autores apresentam o processo de desenvolvimento de um novo modelo de dados para data warehousing conceitual que integra, de forma holística, numerosas áreas de dados de gestão de ativos. Uma metodologia de modelagem etnográfica envolve um conjunto diversificado de insumos (incluindo os padrões de modelo de dados, normas, informações de dados de modelos de sistemas e modelos de processos de negócios) que descreve os dados da gestão de ativos. As saídas do processo foram verificadas por mais de 20 especialistas em gestão de ativos e validados contra quatro estudos de caso. Em trabalhos anteriores SIMITSIS, A. e VASSILIADIS, P. apresentaram um framework de modelagem para processos de ETL composto de um modelo conceitual que lida com os estágios iniciais de um projeto de data warehouse, e um modelo lógico que lida com a definição de data-centric workflows. No artigo "A method for the mapping of conceptual designs to logical blueprints for ETL processes", os autores descrevem o mapeamento do modelo conceitual para o modelo lógico. Primeiro, identificam como entidades conceituais são mapeados para entidades lógicas. Em seguida, determinam a ordem de execução do fluxo de trabalho lógico utilizando a informação adaptada a partir do modelo conceitual. Finalmente, fornecem um método para a transição do modelo conceitual para o modelo lógico. Em seu novo trabalho MUÑOZ, L., MAZÓN, J.N., PARDILLO, J. e TRUJILLO, J. chamam a atenção sobre a importância do processo ETL (extract-transform-load). Segundo eles os processos ETL desempenham um papel importante na arquitetura de um data warehouse (DW), pois são responsáveis pela integração de dados de fontes heterogêneas para o Repositório DW. De acordo com os autores a maioria do orçamento de um projeto de DW é gasto em projetar esses processos, uma vez que não são levados em conta nas fases iniciais do projeto, mas, somente, quando o repositório é implantado. Para superar esta situação, no artigo "Modelling ETL Processes of Data Warehouses with UML Activity Diagrams" eles propõem utilizar a 25

38 UML (Unified Modelling language) para modelar conceitualmente a seqüência de atividades envolvidas em processos de ETL, desde o início do projeto, usando a diagramas de atividade (ADs). Essa abordagem oferece aos designers uma modelagem de elementos fácil de usar a fim de captar os aspectos dinâmicos dos processos de ETL. III Data Warehouses (DW) integram diferentes fontes de dados, a fim de fornecer uma visão multidimensional destas fontes para a tomada de decisão. Para este objetivo, os processos ETL (Extract-Transform-Load) são responsáveis por extrair dados de fontes de dados operacionais heterogêneas, realizar sua transformação (conversão, limpeza, padronização, etc.), e, posteriormente, sua carga no DW. Nos últimos anos, várias abordagens de modelagem conceitual foram propostas para a concepção de processos de ETL. Embora essas abordagens sejam muito úteis para documentar processos de ETL e apoiar as tarefas de designer, essas propostas falham no fornecimento de mecanismos para realizar um estágio de geração automática de código. Tal etapa deve ser obrigatória tanto para evitar falhas quanto para economizar tempo de desenvolvimento na implementação do processo de ETL complexos. Desta forma, no artigo "Automatic generation of ETL processes from conceptual models" MUÑOZ, L., MAZÓN, J.N., TRUJILLO, J. definem uma abordagem para a geração automática de código para processos ETL. Eles alinham a modelagem de processos de ETL em DW com MDA (Model Driven Architecture) para, formalmente, definir um conjunto de transformações QVT (Query/View/Transformation). Segundo ESSAIDI, M. e OSMANI, A. vários frameworks para Data Warehouses (DW) e processos de engenharia têm sido propostos nos últimos anos. No entanto não ocorreu um esforço significativo na unificação de ambos em uma abordagem única e integrada. No artigo "Data Warehouse Development Using MDA and 2TUP" os autores apresentam um método unificado que integra o Data Warehousing Framework (DWF) e o Processo de Data Warehousing (DWP). Eles usam MDA (Model Driven Architecture) para a definição do DWF (data warehousing framework) a fim de desenvolver o projeto de cada componente em um DW integrado e padrão. Utilizam ainda o 2 track unified process (2TUP) para definir o DWP (data warehousing process) a fim de permitir o desenvolvimento iterativo de DWlayers, considerando, simultaneamente o negócio e os aspectos técnicos do DW. 26

39 As tecnologias e arquiteturas propostas no contexto de Business Intelligence são destinadas a atender às necessidades de dispor de uma base sólida para a tomada de decisões estratégicas nas organizações de hoje. Este processo envolve assumir riscos e o objetivo fundamental é tentar minimizá-los. No trabalho intitulado "Empleo De Mda En La Generación De Procesos Etl", HEDMAN, F.A. descreve as características que devem possuir os sistemas de apoio à decisão para conduzir os dados pelos caminhos necessários para chegar ao objetivo final, a busca de conhecimento oculto. Este tipo de arquitetura, geralmente tem como centro ou núcleo um Data Warehouse. Os dados integrados neste repositório são a matéria-prima de todo o processo, de modo que sua qualidade é de importância vital. Garantir esta condição é a responsabilidade dos processos de extração, transformação e carga (ETL). Neste trabalho são caracterizados os principais aspectos componentes e fases dos processos ETL considerando-se a necessidade de uso de novos procedimentos para orientação do ciclo de vida de desenvolvimento e manutenção visando o aumento de produtividade. Após da análise do estado da arte, este estudo conclui que o uso da modelagem conceitual baseada em UML em combinação com o paradigma MDA (model-driven architecture) é uma variante de solução factível a considerar. III ESSAIDI, M. e OSMANI, A. em seu artigo intitulado "A Unified Method for Developing Data Warehouses" explicam que a arquitetura de Data Warehousing (DWA) é definida através de várias camadas heterogêneas e inter-relacionados. E ainda, que cada camada contém diferentes componentes, utiliza diferentes modelagem de perfis, e é dependente de várias tecnologias. Outro ponto comentado por eles é que os projetos de Data Warehouse (DW) também estão expostos a vários riscos técnicos e exigem mais conhecimento sobre a base de conhecimento do negócio, onde estes aspectos aumentam os custos e o tempo de desenvolvimento de um DW além de tornar seu projeto e construção muito difícil e desafiador. Eles observam que várias estruturas para projeto de DWs e engenharia de processos têm sido propostas durante os últimos anos, no entanto, as abordagens orientadas a framework deixam de fornecer um sistema integrado e uma estrutura padronizada que aborde todas as camadas do DW. Segundo os autores, a abordagem orientada a processos também falha em definir um processo de engenharia que enderece todo o ciclo de desenvolvimento ddo DW de uma forma iterativa e incremental e, ainda, 27

40 considere tanto os requisitos de negócio quanto os técnicos. Eles também consideraram que muito esforço tem sido dedicado à unificação dos dois em uma abordagem única integrada. No artigo em questão eles se propõe a abordar estas questões propondo um método unificado para o desenvolvimento de DWs que integre o framework de DW (DWF) com o processo de DW (DWP). Eles se utilizam da arquitetura MDA (Model-Driven Architecture) para definir seu framework (DWF) e adaptam o processo 2TUP (2 Track Unified Process) para o desenvolvimento de DWs usando o processo de transformações MDA para definir o DWP. No mesmo ano ESSAIDI, M. e OSMANI, A. apresentaram em uma publicação científica o artigo intitulado "Model driven data warehouse using MDA and 2TUP" que trata do mesmo assunto apresentado no SIIE. A fusão de dados é uma parte essencial do processo de construção ETL (Extract- Transform-Load) durante a construção de um Data Warehouse, de acordo com HYENSOOK, K., OUSSENA, S., ZHANG, Y. e CLARK, T. Em seu artigo "Automatic generation of data merging program codes" eles propõem um Data Merging Metamodel (DMM) e suas transformações em código na forma do modelo orientado a engenharia. Segundo seus autores, DMM permite a definição de relacionamentos de entidades em diferentes modelos e seus tipos de fusão ao nível conceitual. As transformações são formalizadas utilizando-se ATLAS (ATLAS Transformation Language), o que permite a geração automática de pacotes PL/SQL para a execução de operações de fusão (merge) em ferramentas ETL comerciais. Segundo os autores, com esta abordagem, os engenheiros DW são liberados da construção de scripts repetitivos e complexos e da preocupação de manter a consistência de projeto e sua implementação. Segundo PARDILLO, J., MAZÓN, J.N. e TRUJILLO, J. o desenvolvimento de data warehouses deve ser impulsionada por modelos conceituais multidimensionais independente de tecnologia, que são a base para a implementação do esquema do banco de dados de data warehouse de acordo com uma tecnologia específica. De acordo com suas pesquisas, a maioria das pesquisas atuais centra-se na derivação (automática) dos esquemas de base de dados a partir desses modelos conceituais, mas negligenciam a derivação automática de metadados OLAP de forma integrada com o esquema do banco de dados. Consideram que esta integração seja muito importante, uma vez que permite que ferramentas para o usuário final consultem o esquema de banco de dados do data warehouse corretamente com a conseqüente 28

41 redução tanto tempo de desenvolvimento quanto seus custos. No trabalho "Designing OLAP schemata for data warehouses from conceptual models with MDA" eles propõe uma model-transformation architecture com a qual se pode aplicar um conjunto de mapeamentos de dados. Esses mapeamentos permitiriam que os designers facilmente obtivessem vários tipos de metadados OLAP durante a derivação do esquema do banco de dados a partir do modelo conceitual multidimensional. Neste trabalho eles também apresentam uma prova de conceito da abordagem implementada na plataforma Eclipse. Uma vez que Business Intelligence evolui a partir de decisões estratégicas off-line para decisões operacionais online, o projeto de operações ETL (extract-transformload) tem se tornado cada vez mais complexo. Muitos desafios surgem neste novo contexto, como por exemplo, sua otimização e modelagem. No artigo "Leveraging Business Process Models for ETL Design", WILKINSON, K., SIMITSIS, A., CASTELLANOS, M. e DAYAL, U. focam no descompasso entre a visão de TI a respeito da empresa representada por processos ETL e a visão da empresa requerida pelos gestores e analistas. Os autores propõem o uso de um modelo de processo de negócio para uma visão conceitual de DW. Eles apresentam como ligar esta visão conceitual a processos de negócio existentes e como traduzir este ponto de vista conceitual para uma visão lógica de ETL que pode ser otimizada. Desta forma eles pretendem conectar os processos de ETL de volta aos seus processos de negócio subjacentes possibilitando não apenas uma visão de negócio do ETL, mas também uma visão em tempo real de toda a empresa. No artigo "GEM Requirement driven Generation of ETL and Multidimensional Conceptual Designs", MORAL, O.R., SIMITSIS, A. e GAMAZO, A.A. colocam que nas fases iniciais de um projeto de data warehouse, o principal objetivo é coletar os requisitos e necessidades do negócio e traduzi-los em um modelo conceitual e multidimensional apropriado. De um modo geral esta tarefa é realizada manualmente, através de uma série de entrevistas envolvendo dois diferentes grupos: os analistas de negócio e os técnicos modeladores. A concepção de um modelo conceitual apropriado é uma tarefa sujeita a erros, segundo os autores, pois passa por diversas rodadas de conciliação e redesenhar, até que as necessidades do negócio fiquem satisfeitas. Os autores também consideram de grande importância para os negócios de uma empresa que este processo seja facilitado e automatizado. Sendo assim, o objetivo da pesquisa destes foi fornecer aos modeladores um meio semi-automático para a produção de modelos conceituais multidimensionais e, também, uma representação conceitual do 29

42 processo ETL (extract-transform-load) que responde pela orquestração do fluxo de dados a partir de fontes operacionais para as construções DW. Particularmente, eles descrevem um método que combina informações sobre as fontes de dados juntamente com os requisitos de negócio para validação e complementação (se necessário) destes requisitos produzindo um modelo multidimensional e identificando as operações ETL necessárias. O método é apresentado em termos referenciais TPC- DS, mostrando sua aplicabilidade e utilidade. Neste ano, apresentamos (FERNANDES, L. A., NETO, B. H., FAGUNDES, V., ZIMBRÃO, G., SOUZA, J. M., SALVADOR, R.) a primeira parte deste trabalho, intitulado Model-driven Architecture Approach for Data Warehouse no qual são exemplificadas as primeiras transformações de modelo para ETL. Nesta versão a análise principal do trabalho era a verificação da real possibilidade de se gerar código ETL partindo-se apenas dos modelos de dados. Não havia preocupação com a abstração. Os valores etiquetados GroupBy, OrderBy e Filter, dentre outros remetem diretamente à linguagem SQL. No entanto, a partir do resultado bastante promissor das transformações de modelo desenvolvidas, foi possível elevar o nível de abstração e ajustar a proposta a um patamar mais conceitual, objetivo do atual trabalho. III Nos últimos anos, várias abordagens conceituais têm sido propostas para a especificação das principais propriedades multidimensionais (MD) do repositório data warehouse (DW). No entanto, a maioria deles lida com os aspectos isolados da DW e não fornecem aos designers um método integrado e padrão para projetar o ciclo de vida do DW (processos ETL, fontes de dados, o repositório de DW e assim por diante). Algumas abordagens são dependentes de plataformas específicas ou negligenciam questões importantes no desenvolvimento do ciclo de vida do DW. O processo de extração, transformação e carga (ETL) desempenha um papel importante na arquitetura do Data Warehouse porque é o responsável pela integração de dados de fontes heterogêneas para o repositório DW. Estas colocações foram feitas por FARHAN, M.S., MARIE, M.E., EL-FANGARY, L.M. e HELMY, Y.K. no artigo "An Integrated Conceptual Model for Temporal Data Warehouse Security" no qual os autores propõem um modelo conceitual para atualização do data warehouse através de "insert", "update" e "delete", usando processos de ETL e considerando os requisitos 30

43 de segurança DW. Primeiramente o modelo de ETL proposto é baseado em Unified Modeling Language (UML), que permite a realização da modelagem conceitual de processos de ETL. Em seguida é estabelecido foco na integração do modelo ETL com o modelo DW através de MDA (Model Driven Architecture). Resumidamente, o artigo propõe um modelo conceitual integrado para abordar os requisitos temporais de segurança de um data warehouse (CMTDWS). Os dados, em um Data Warehouse (DW), vêm de várias fontes, operacionais ou tradicionais, e contém informações confidenciais de uma organização que são usadas como base para a analise do estado e do desenvolvimento de uma organização visando a tomada de decisão. Estas informações sensíveis precisam de segurança a fim de evitar que sejam acessíveis por usuários não autorizados. As pesquisas atuais em data warehouse têm mostrado vários métodos para a proteção dos dados. Estes métodos são definidos ao nível de negócio, conceitual, lógico e físico. No artigo "A SURVEY ON CURRENT SECURITY STRATEGIES IN DATA WAREHOUSES", os autores SAURABH, A.K. e NAGPAL, B. discutem várias destas estratégias. III.10. Análise e Posicionamento do Trabalho Atual De acordo com os trabalhos apresentados observamos que a maior preocupação está relacionada com a representação conceitual dos componentes de um Data Warehouse (processos ETL e modelo multidimensional - cubo). Esta característica pode ser vista em 2002 (definição de atividades ETL e fornecimento de bases formais para sua representação), 2003 (modelagem conceitual de processos ETL com mapeamento das operações mais comuns e análise da estrutura e conteúdo das fontes de dados existentes), 2005 (projeto lógico de cenários ETL com fornecimento de estrutura genérica e personalizável; uso de mda para a modelagem multidimensional com transformações de modelos através da abordagem qvt e na metodologia para transição do conceitual para o lógico em processos ETL). A partir de 2006 encontramos outras abordagens que se preocupam com segurança e introduzem a utilização de BPM e ontologias, no entanto a modelagem conceitual continua presente como em 2006 (MDDW-model driven data warehouse como uma ponte entre os modelos DW e BPM; uso de ontologias nos esforços iniciais de um projeto dw meio de comunicação entre as partes envolvidas e automação ETL), em 2007 (framework baseado em MDA para o desenvolvimento seguro de dws), em 2008 (mecanismo para extração de esquemas multidimensionais usando MDA; uso de 31

44 MDA para o desenvolvimento de Spatial Data Warehouse; desenvolvimento do repositório DW, usando QVT e MDA; novo modelo de dados para data warehousing conceitual que contemplando gestão de ativos; mapeamento e transição do modelo conceitual para o modelo lógico; modelagem conceitual das atividades envolvidas em processos de ETL usando diagramas de atividades). Todas estas abordagens, apesar de muito interessantes no estabelecimento de padrões e documentação visando auxiliar o modelador na implementação de processos ETL, não dão qualquer solução para a geração automática de código, a qual economizaria tempo de desenvolvimento e diminuiria a probabilidade de erros no desenvolvimento de aplicações ETL (MUÑOZ, MAZÓN, TRUJILLO, 2009). A partir de 2009 surgiram as primeiras tentativas de geração de código, no entanto outras áreas também foram contempladas, tais como processos ETL, merge de dados em diferentes modelos e modelos multidimensionais (utilização MDA e QVT para geração de código a partir do modelo conceitual; MDA para a definição do DWF; caracterização dos principais aspectos componentes e fases dos processos ETL). Em 2010 ocorreu uma nova abordagem contemplando a geração de código, além de outras conceituais (método unificado para DW integrando o framework DWF com o projeto DWP; DMM (data merging metamodel) para definição de relacionamentos entre entidades em diferentes modelos e seus tipos de fusão ao nível conceitual gerando pacotes PL/SQL; geração de metadados OLAP durante a derivação do esquema do banco de dados; uso de processo de negócio para uma visão conceitual de DW; meio semi-automático para a produção de modelos conceituais multidimensionais). Já em 2011 as abordagens retornam ao conceitual (Integração do modelo ETL com o modelo DW através de MDA; métodos para proteção dos dados). Uma observação a cerca deste capítulo é que de acordo com os diferentes objetivos estudados nos diversos trabalhos publicados ao longo destes anos, percebese que o foco destes trabalhos é o ambiente Data Warehouse. O meio de atuação varia, apesar de MDA aparecer em diversos casos como apoio às propostas. No nosso caso, o principal foco do trabalho está localizado na abordagem MDA; o Data Warehouse aparece como coadjuvante no processo. A proposta é que usuários de MDA também tenham facilidade na geração de aplicações no ambiente DW. Esta diferença de foco é importante que seja frisada, pois reflete a importância maior dada a características MDA do que ao Data Warehouse, durante todo o trabalho. 32

45 Em relação à geração de código, este trabalho encontra dois trabalhos mais próximos ( Automatic generation of ETL processes from conceptual models de 2009 e Automatic generation of data merging program codes de 2010). No primeiro trabalho a geração de código ocorre indiretamente através da utilização de uma ferramenta de mercado (no caso, OWB da Oracle). A proposta, utilizando MDA e QVT, gera um modelo de transformação de acordo com a ferramenta de mercado e esta, por sua vez, gera o código correspondente. O segundo trabalho exporta o CWM contendo as transformações desejadas (definidas através de um Data Merging Meta Model) para uma ferramenta de mercado que se encarregará do desenvolvimento das aplicações. Desta forma, ambas as propostas são similares, pois requerem a utilização de uma ferramenta ETL de mercado para a geração do código. Outro ponto observado nas propostas é a preocupação principal com a etapa de transformação de dados. A modelagem enfatiza, explicitamente, operações de merge, grupamento, dentre outras. No trabalho aqui apresentado toda a definição é feita utilizando o modelo de classes, ocorre forte preocupação com abstração (não há qualquer utilização de mecanismos de SQL explicitamente nas especificações), orientação para o enriquecimento do modelo gerado usando componentes típicos do ambiente data warehouse e geração completa de código independente de qualquer software de mercado. Pode-se entender, portanto, que o trabalho atual se encontra consoante com os demais estudos que visam também à geração de código, no entanto, sua forma de atuação é diferenciada dos demais na medida em que se torna independente das atuais ferramentas de mercado gerando o código final a ser aplicado para a realização das operações propostas. 33

46 Capítulo IV ESPECIFICAÇÃO O desenvolvimento de um software para a geração automática de código baseado unicamente em modelos certamente requer o estabelecimento de objetivos bem definidos seguido de uma análise detalhada dos benefícios que se deseja alcançar. Além disso, a opção por MDA, no lugar das atuais ferramentas ETL de mercado, deve conter características que a tornem interessante e agreguem valor ao resultado alcançado. Em relação ao ambiente escolhido (Business Intelligence), observou-se que o mesmo possui algumas características específicas que o tornam diferenciado: nomenclatura exclusiva, grandes volumes de dados, necessidades de desempenhos pontuais, além de contar com uma grande variedade de ferramentas auxiliares. Sendo assim, este trabalho estudará o que poderia ser agregado ou vantajoso na utilização de MDA para este ambiente (Business Intelligence, mais especificamente na fase ETL) e qual a complexidade para este desenvolvimento, tanto do ponto de vista da implementação do projeto quanto de uso da especificação para geração de código. Baseado nas observações acima foi definido um conjunto de metas e uma relação dos principais benefícios desejados. E, para garantir uma concreta avaliação dos resultados, foi decidida a construção de uma prova de conceito, uma avaliação sobre a flexibilidade de expansão inerente à MDA (isto é, possibilidade de desenvolvimento de cartuchos com objetivos específicos) e uma análise da inclusão de novas 34

47 funcionalidades após o produto gerado (facilidade de ajuste na POC criada para a inclusão de novas fontes de dados, novas características de desempenho, etc.). Portanto, neste capítulo serão descritos os requisitos, benefícios e metas, no seguinte será apresentada a prova de conceito (POC proof of concept) e nos apêndices V (Desempenho na Carga) e VI (Exemplo de Modificações no Modelo de Objetos) a utilização do modelo da Poc para análises de impacto de mudanças nos modelos e desempenho do código gerado. IV.1. Objetivos Específicos A primeira etapa deste trabalho foi estabelecer limites, ou fronteiras bem demarcadas, uma clara determinação do que fazer e quais os benefícios desejados. O projeto foi focado, especificamente, na fase ETL (Extract, Transform and Load), considerada uma das mais importantes etapas no desenvolvimento de um ambiente de Business Intelligence (BI). Optou-se por estabelecer metas compatíveis com as características específicas do ambiente, a saber: A. Nomenclatura distinta O ambiente Business Intelligence possui terminologia e conceitos específicos diferenciados do OLTP (Online Transaction Processing) tradicional. Assim, o uso desta terminologia foi considerado importante para a especificação do modelo e das diversas parametrizações. No apêndice III se encontra, em detalhes, toda a terminologia utilizada no trabalho juntamente com o impacto correspondente no código gerado. B. Grandes Volumes de Dados Em virtude do grande volume de dados característico do ambiente, a preocupação com desempenho é uma constante. Entendeu-se que uma solução única de performance que atendesse a todas as situações não seria possível. Além disso, considerou-se que a escolha do melhor algoritmo para cada caso devesse ser uma decisão soberana do modelador, uma vez que as condições não-técnicas (por exemplo, janela de tempo para a operação, uso exclusivo do banco de dados, possibilidade de execução simultânea, disponibilidade de memória, tipo de processador, etc.) poderiam ser mais cruciais do que apenas o volume de dados. Assim, optou-se pela parametrização de algoritmo que possibilitasse a expansão, ou seja, um conjunto que permitisse a criação de algoritmos diferentes para situações específicas, com a possibilidade de adição de novos algoritmos. 35

48 C. Ampla Variedade de Ferramentas A etapa de extração, transformação e carga (ETL) tem à sua disposição, várias ferramentas de mercado que visam à realização das tarefas de extração, transformação e carga. Naturalmente, espera-se que a abordagem MDA acrescente valor ao resultado (ou traga alguma vantagem no uso) e não apenas copie as funcionalidades das ferramentas. Figura 6: Quadrante Mágico para Ferramentas de Integração de Dados A figura 6 (GARTNER, 210) apresenta um quadro com os principais fabricantes de ferramentas para integração de dados do mercado, tais como a Oracle com Oracle Data Integrator, SAP com SAP NetWeaver Business Warehouse, IBM com InfoSphere DataStage, Informática com o Informatica PowerCenter e Microsoft com SQL Server Integration Services. Temos também algumas ferramentas gratuitas tais como o Kettle (do pacote Pentaho Data Integration), Open Studio (Talend), Clover.ETL (OpenSys) e Ketl (Kinetic Networks), dentre outras. Uma vez que MDA está fortemente baseada em modelos e os modelos de ambos os ambientes (origem e destino) podem estar disponíveis, foram acrescentados quatro 36

49 novas características a fim de ilustrar a possibilidade de agregação de valor e extensibilidade: Restrição de transferência verificação ou validação sobre a viabilidade da transferência de dados entre a origem e o destino; Identificação dos relacionamentos disponíveis verificação e análise dos relacionamentos disponíveis entre as tabelas do modelo e determinação das ligações (joins) necessárias à obtenção dos dados; Transformações opcionais utilização opcional da etapa de transformação e possibilidade de determinação do momento da transformação. Carga diferenciada de acordo com o ambiente destino possibilidade de definição de diferentes estruturas (layouts) para a área intermediária (data stage). seria: Resumidamente, a lista de metas a serem alcançadas na POC (proof of concept) 1. Semântica nativa do domínio 2. Flexibilidade nos algoritmos de carga 3. Integridade na transferência 4. Identificação dos relacionamentos disponíveis 5. Definição da etapa de transformação de dados somente quando necessário 6. Flexibilidade no modelo de extração e carga 7. Extensibilidade inerente à abordagem Estas são as metas escolhidas para implementação da POC, uma vez que foram consideradas mais úteis e com mais benefícios, no entanto, esta lista não tem a finalidade e muito menos a pretensão de ser exaustiva. Utilizando-se a abordagem MDA seria possível acrescentar novas metas, à medida que o desenvolvedor adquirisse novos conhecimentos a partir de peculiaridades do ambiente. A facilidade de adição de novos recursos é uma característica intrínseca, que também será analisada neste trabalho. 37

50 IV.2. Benefícios Cada uma das metas estabelecidas possui benefícios específicos associados, descritos a seguir. Na seqüência, será detalhado, um processo MDA característico juntamente com suas etapas de transformação principais, a fim de se identificar os pontos que estão sendo modificados para atender às metas estabelecidas. O benefício principal, garantido pelo uso de MDA, é que o modelador possa se concentrar no negócio, deixando a responsabilidade de implementação para a ferramenta. A primeira meta estabelecida neste trabalho, que trata da terminologia, complementa esse benefício já previsto pela abordagem, uma vez que não são exigidos novos conhecimentos ao modelador para o desenvolvimento do modelo de dados. Seu foco continua a ser associado com o negócio e toda a interface MDA usa seu conhecimento prévio deste negócio para o desenvolvimento da solução. Isso se traduz em aumento de abstração e da separação do raciocínio sobre o negócio do raciocínio sobre a codificação, de acordo com os princípios básicos de TI (Tecnologia da Informação). Uma preocupação constante ao longo do desenvolvimento foi a possibilidade de resistência no uso de uma ferramenta geradora de código, quando a performance fosse importante. Observou-se também que um mesmo algoritmo, dificilmente, atenderia a todas as situações apresentadas. Desta forma, escolheu-se oferecer a opção de criação de diferentes algoritmos. Assim, o desenvolvedor poderia adicionar seu aprendizado em projetos de ETL, criando algoritmos mais adequados a cada ambiente específico e às suas necessidades. No Apêndice V (Desempenho na Carga) o modelo DW utilizado na Poc foi carregado através de dois algoritmos gerados por este trabalho e os tempos de carga foram mensurados como base para futuras análises de desempenho e escolha de novos algoritmos. A capacidade de ler ambos os modelos (OLTP e DW) proporcionou a oportunidade de validação das operações de carga. Quando ocorrem mudanças no ambiente diário (OLTP) ou no ambiente de destino (DW), a modificação em qualquer dos modelos poderia trazer inconsistências no código gerado, desta forma, a validação destas alterações deve ser realizada e uma indicação de possíveis problemas produzida. Isto permitiria uma antecipação de erros nas operações de carga resultantes. No Apêndice II (Verificações e Mensagens de Erro) encontra-se a relação de validações desenvolvidas para a Poc deste trabalho. Muitas outras podem ser adicionadas a fim 38

51 de tornar a modelagem mais segura e minimizar o risco de erros na implementação de modificações na modelagem dos ambientes OLTP e DW. Esta mesma capacidade também pode fornecer informações sobre os relacionamentos existentes entre as tabelas origem de dados. Assim, quando há mais de um caminho de acesso disponível, seria possível a escolha dos mais interessantes para o tipo de carga desejado. No apêndice VI (Exemplos de Modificações no Modelo de Objetos) é apresentado um passo a passo com modificações na modelagem e conseqüências no código gerado, demonstrando sua capacidade de adaptação resultante. As duas últimas metas abordam o uso da opção de transformação, uma das etapas da operação ETL. A fase de transformação pode ser feita ou não durante a etapa de carga e pode ter um impacto maior ou menor no desempenho global da operação. Assim, seria possível estabelecer regras para a execução das rotinas de transformação (se houver), de acordo com o layout da data stage optando-se: por uma carga mais rápida (sem mudança); ou mais completa (com alterações); Esta flexibilidade daria ao modelador a capacidade de adaptar o código gerado para as características específicas do ambiente. Além dos benefícios provenientes desses objetivos específicos, há outros provenientes da própria abordagem MDA, automaticamente incorporadas, tais como: independência de plataforma; produtividade; interoperabilidade; exatidão da documentação; possibilidade de personalização; Entre esses benefícios intrínsecos a possibilidade de personalização permite o desenvolvimento de um cartucho que lida especificamente com o ambiente ETL, o qual, por sua vez, pode ser melhorado pelos desenvolvedores, permitindo a contínua evolução e utilização real da experiência adquirida em projetos anteriores. 39

52 IV.3. Processo Característico das Transformações de Modelo O procedimento seguido pela abordagem MDA para transformar modelos em código é caracterizada por modelos que definem o sistema e cartuchos que lêem os modelos, identificam suas especificações e geram os códigos apropriados. Esses cartuchos ficam disponíveis aos modeladores para que estes possam incorporar personalizações que venham a agregar algum valor ao seu projeto (por exemplo: produtividade, boas práticas, e assim por diante). Quando um modelador cria um projeto MDA, ele deve responder a várias perguntas, que identificam o tipo de projeto (por exemplo: batch x on-line, web x cliente/servidor x, tipo de banco de dados, e outros). Estas questões determinam os cartuchos a serem executados na fase de transformação do modelo e, indiretamente, o tipo de código gerado. O cartucho, quando lê um modelo, deve encontrar informações suficientes para a geração de código. Em UML (Unified Modeling Language), é possível personalizar os modelos padrões através de extensões UML (FARHAD, 2002), utilizando estereótipos e valores etiquetados (tagged values). De acordo com BOOCH, RUMBAUGH E JACOBSON (1998) um estereótipo estende o vocabulário da UML, permitindo a construção de um novo elemento de modelagem derivado de um elemento já existente, porém, incluindo as novas necessidades. A Figura 7 mostra, esquematicamente, as etapas para se criar e executar um processo de transformação de modelo usando a abordagem MDA. Figura 7: Etapas Básicas do Processo de Transformação As marcas incluídas no modelo permitem seu enriquecimento semântico de acordo com os objetivos previamente estabelecidos. O cartucho a ser desenvolvido deve ser capaz de encontrar e entender estas marcas para realizar as transformações de modelo de acordo com estas especificações. 40

53 Assim, a qualquer momento, novas marcações podem estar disponíveis para uso em modelos, permitindo novas semânticas características dos conceitos introduzidos (DW, por exemplo) e, conseqüentemente, permitindo novas personalizações. Isto significa que um cartucho pode ser modificado para, a partir das novas marcações, gerar os códigos compatíveis com alguma plataforma específica (por exemplo). O modelador, para obter a transformação desejada, tem como tarefa desenvolver o modelo, incluindo as marcações corretamente. Esta, então, torna-se a primeira fase da transformação. Depois disso, o modelador deve executar o processo de transformação MDA que vai ler as especificações do projeto, identificar os cartuchos adequados e dar a estes, os modelos correspondentes. Neste momento, todos os códigos pertinentes são gerados. IV.4. Personalização do Processo de Transformação A abordagem MDA, por sua vez, está baseada em modelos, chamados de metamodelos, que utilizam o padrão MOF (Meta Object Facility) para a definição formal de construtores (por exemplo, entidades, relacionamentos, chave primária, etc.). Estes construtores são usados nos modelos finais dos projetos a serem desenvolvidos. Para a criação de um cartucho ou a personalização de um cartucho existente, deverá ocorrer a extensão do modelo original, incluindo as classes e métodos que respondam às necessidades de transformação proposta. Por exemplo, supondo a existência de uma interface ou classe abstrata denominada "Entity", poderia ser criada uma classe concreta chamada "DWEntity", que tivesse o comportamento característico desejado. Essa nova classe seria composta de métodos capazes de compreender as novas marcas estabelecidas no modelo e realizar as transformações de modelo apropriadas. Assim, quando surgissem novas situações no ambiente ou fosse necessária a incorporação de um novo padrão de desenvolvimento à programação, o modelador poderia decidir: a) Incorporar um novo suporte de transformação de modelo, modificando o cartucho previamente construído, tornando este novo comportamento permanente para futuros projetos; 41

54 b) Ajustar o código gerado pelo cartucho sem a incorporação do novo padrão; c) Utilizar a programação tradicional neste caso; A primeira opção seria uma maneira de estender o cartucho para a geração de código adaptado ao ambiente, trazendo produtividade para projetos futuros similares, na percepção desta ocorrência. No próximo tópico foram definidas, no formato de fluxo, as etapas lógicas seguidas para a construção ou alteração de um cartucho qualquer. Cada atividade foi descrita tomando-se como base o desenvolvimento realizado para a Poc (Proof of Concept). Este esquema pode servir como guia para futuras extensões ao trabalho aqui iniciado. 42

55 IV.5. Fluxo Básico para Personalização de Cartuchos Durante o desenvolvimento deste trabalho percebeu-se a necessidade de se estabelecer um processo padrão que orientasse o desenvolvimento atual e futuro de implementações em cartuchos existentes ou novos cartuchos. Neste tópico estabelece-se uma descrição detalhada deste processo com todas as atividades consideradas relevantes para a personalização de cartuchos no âmbito MDA. A formalização das etapas descritas a seguir corresponde a uma nova contribuição deste trabalho para a comunidade. Nesta versão as etapas correspondem à seqüência de atividades realizadas durante o desenvolvimento, isto é, o passo a passo seguido para a obtenção do resultado alcançado. Estas etapas não foram previamente concebidas, aconteceram de acordo com as necessidades do desenvolvimento. Acreditamos que em trabalhos futuros, uma vez que já possuímos este passo a passo, teremos mais facilidade para o desenvolvimento e poderemos aprimorá-lo e detalhá-lo ainda mais, auxiliando de forma mais efetiva o desenvolvimento da comunidade que utiliza MDA. Observou-se que as atividades necessárias à personalização de cartuchos estão ligadas a três áreas distintas: Projeto, Desenvolvimento e Modelagem. A figura 8 abaixo apresenta um fluxo com macro-atividades características deste desenvolvimento. Figura 8: Fluxo com macro-atividades para personalização de cartuchos 43

56 Na etapa de projeto seriam estudadas todas as necessidades levantadas, elencadas aquelas passíveis de desenvolvimento, determinado o melhor caminho de desenvolvimento, estabelecido o resultado esperado e definido o passo a passo para este desenvolvimento. Figura 9: Sub-processo Projetar novos requisitos para cartucho A figura 9 apresenta o Sub-Processo Projetar novos requisitos para cartucho com o detalhamento de suas atividades, explicitadas a seguir: A1-Levantar Necessidades esta atividade se refere a uma etapa mais conceitual, onde seriam avaliados todos os novos comportamentos desejados para o cartucho quanto à viabilidade de desenvolvimento, benefícios acarretados e esforço de implementação. Em seguida seriam elencados aqueles comportamentos com valor agregado mais significativo dentro das análises efetuadas. A2-Estabelecer Requisitos nesta atividade seriam detalhados os requisitos, já a nível técnico, originados dos comportamentos desejados. Neste momento também seriam discutidas as formas de desenvolvimento (p. ex: o que colocar para resolução pelo Velocity, o que desenvolver em Java, etc.). Ao término desta etapa o ambiente de desenvolvimento (macro) estaria estabelecido. A3-Desenvolver Modelo Exemplo para Teste esta atividade foi considerada de fundamental importância para o sucesso do projeto. A criação de um modelo exemplo contendo a(s) situação(ões) levantada(s) concretiza os anseios estabelecidos anteriormente e facilita o trabalho de desenvolvimento. É nesta etapa que se determina o resultado prático esperado para cada comportamento selecionado para desenvolvimento. 44

57 A4-Criar Código Resultante na Plataforma a partir do modelo exemplo desenvolvido, cria-se o código a ser gerado pelo cartucho. Esta atividade é uma complementação da anterior, objetivando a visualização concreta do que se deseja obter como resultado do desenvolvimento do cartucho. Esta etapa também tem a finalidade de potencializar a criação de templates de código que padronizem e uniformizem o resultado da implementação. A5-É Possível Enriquecer o Modelo Caracterizando os Requisitos? durante as duas atividades anteriores já se pode perceber as vantagens e viabilidade de se enriquecer o modelo com novas marcas que descrevam os novos comportamentos a serem implementados. Nesta etapa, determina-se, então, se estas marcas devem ou não ser desenvolvidas e sua aplicabilidade. A6-Definir Marcas de acordo com a Semântica esta atividade também é conceitual, tendo a finalidade de determinar a criação de marcas compatíveis com a semântica e não apenas visando a parametrização das opções do cartucho. O objetivo das marcas deve ser sempre o enriquecimento do modelo, de tal forma que o modelador possa utilizá-lo para caracterizar mais detalhadamente o ambiente que está representando. O cartucho deverá, conseqüentemente, identificar estas marcas e gerar os comportamentos esperados. A7-O Código criado é Compatível com os Requisitos? esta é uma atividade típica de validação, tanto dos requisitos quanto do comportamento esperado. O objetivo é verificar se o resultado previsto é compatível com os requisitos estabelecidos, isto é, se não foram gerados códigos incoerentes com a previsão inicial. Deve-se, neste momento, analisar o ajuste a ser realizado. No fluxo foi considerado que o ajuste a ser feito no código é mais comum. No entanto, pode acontecer em algumas situações, que os requisitos devam ser ajustados (seja por inviabilidade técnica ou mudanças conceituais). A8-É possível generalizar a solução? esta é a última atividade da área de Projeto e trata, exatamente, da análise de viabilidade da personalização proposta, isto é, a verificação da possibilidade de generalização da proposição para outros modelos diferentes daquele inicialmente desenvolvido. Em caso negativo, o trabalho deve ser reiniciado a partir dos requisitos, uma vez que sua definição influencia todo o planejamento da solução. 45

58 Na figura 10, abaixo se encontra o segundo sub-processo do processo de personalização de cartuchos, o qual se acha associado à área de Desenvolvimento. Figura 10: Sub-processo Desenvolver transformações de modelo que atendam aos requisitos As atividades deste sub-processo, basicamente, se referem a detalhamentos de implementação e que serão mais bem entendidas durante o próximo capítulo deste trabalho com a apresentação da prova de conceito (POC proof of concept). A9 Criar estereótipos e tagged values compatíveis na atividade A6, as marcas a serem criadas (estereótipos e tagged values) já foram estabelecidas. A atividade atual refere-se à implementação da definição prévia. O criador do cartucho, deve obter o modelo associado às marcas (profile no AndroMDA) alterálo de acordo com sua necessidade, compilá-lo e disponibilizá-lo para uso pelo cartucho que deseja modificar ou criar. A10-Existem Metafacades passíveis de Extensão? nesta atividade o criador de cartuchos deverá analisar se existem cartuchos existentes que podem ser utilizados para a construção em andamento ou se é mais viável a criação de um novo cartucho desde o início. Uma vez que a variedade de cartuchos é bastante grande, considerou-se que o desenvolvimento de um cartucho completo é menos freqüente e reuso de códigos anteriores é muito mais constante. Após esta definição, o criador deve verificar se os metafacades previamente construídos neste cartucho já possuem comportamentos que podem ser estendidos e aproveitados na nova implementação. A11-Criar novo metafacade nesta atividade (negação da atividade anterior), o criador deverá criar um novo modelo de classes e criar um metafacade adequado às suas necessidades a partir dos metafacades básicos da ferramenta MDA 46

59 utilizada. O AndroMDA já oferece um conjunto de metafacades com comportamentos úteis ao desenvolvimento de código. A12-Estender Metafacade Existente nesta atividade (aceitação da atividade A10), o criador abrirá o modelo de classes do cartucho escolhido e adicionará sua classe como uma especialização de uma classe pré existente que seja compatível com suas necessidades. A13-Configurar Arquivos de Especificação de Cartucho após a criação das classes o criador deverá estabelecer as configurações necessárias nos arquivos correspondentes da ferramenta MDA escolhida. Para o AndroMDA, os arquivos a serem configurados são: Cartridge.XML (onde são especificados os suportes a metafacades, os modelos (templates), as propriedades (property references), os arquivos para uso do Velocity, etc.), Metafacades.xml (onde são especificados os metafacades para o metamodelo correspondente), Namespace.xml (onde o cartucho é registrado dentro de um descritor de namespaces) e Profile.xml (onde é feito o mapeamento dos estereótipos e tagged values). A14 Construir Transformações esta atividade representa uma típica tarefa de desenvolvimento de software. O criador desenvolverá os códigos em Velocity ou Java capaz de gerar o que foi definido pela área de projeto e realizar os testes correspondentes. Após a construção e teste do cartucho, a etapa de homologação do projeto desenvolvido consiste na criação de um projeto MDA, desenvolvimento de um modelo utilizando a semântica pré estabelecida através das marcas e geração do código desejado. Estas atividades estão contempladas na figura 11, abaixo. Figura 11: Sub-processo Modelar Exemplo e Executar Transformações A15 Configurar Arquivos de Especificação do Projeto esta atividade corresponde à primeira etapa a ser realizada após a criação do projeto pelo 47

60 software MDA. No caso do AndroMDA, a criação do projeto se dá quando o modelador executa o comando mvn correspondente à geração do projeto. Esta criação corresponde a um processo interativo, onde o AndroMDA faz diversas perguntas e, a partir das respostas define o diretório do projeto com os arquivos de especificação (por exemplo: modelo) vazios. Um dos arquivos criados é o AndroMDA.xml, que contém todos os parâmetros a serem preenchidos a fim de se personalizar as características do projeto, sendo esta a atividade a ser desenvolvida neste ponto. A16-Expressar Semântica no Modelo Exemplo a atividade deste item corresponde à criação de um modelo lógico que represente todas as situações previstas no projeto e estabelecimento da semântica no modelo através da utilização dos estereótipos e tagged values previamente criados. A17-Executar as Transformações do Modelo esta é a última atividade de construção do cartucho, pois trata da geração do código a partir do processo MDA. Ao término da execução do processo, os códigos correspondentes à implementação efetuada devem ser gerados de acordo com o esperado. Na figura 12 (abaixo), revisitamos o processo como um todo. Duas atividades finais podem ser observadas, as quais complementam todo o processo dando um fechamento à tarefa proposta. Figura 12: Processo de Personalização de cartuchos 48

61 A18-Transformações bem Sucedidas? esta atividade representa uma validação de todo o processo de construção. O criador retorna agora ao projeto do cartucho e confere cada um dos requisitos propostos contra os resultados obtidos. Se houverem discrepâncias, o retorno às atividades de desenvolvimento se faz necessária para realização das correções dos desvios percebidos. A19-Liberar Cartucho para Comunidade esta atividade encerra todo o processo, com a liberação do cartucho para uso por outros usuários. Evidentemente, ajustes posteriores podem ocorrer, uma vez que melhorias sempre serão úteis na incorporação de novos conceitos. O fluxo apresentado neste capítulo representa logicamente as etapas realizadas neste trabalho para seu desenvolvimento. O desenvolvimento real de uma ferramenta ETL apesar de seguir as mesmas etapas teria uma escala muito maior, onde o processo descrito anteriormente poderia ser repetido diversas vezes ciclicamente até a obtenção do cartucho completo. Para uma clareza maior das etapas deste tipo de desenvolvimento, a prova de conceito, no próximo capítulo, segue os passos de uma personalização de cartucho, exemplificando como os objetivos propostos foram desenvolvidos, como podem ser estendidos e como novos comportamentos podem ser adicionados a um cartucho existente. 49

62 Capítulo V PROVA DE CONCEITO O objetivo da Poc (Proof of Concept) é mostrar, em escala reduzida, que o desenvolvimento de uma ferramenta ETL através de MDA, realmente, poderia assegurar que o esforço do projeto (ou inteligência) esteja centrado na definição dos modelos. Já o desenvolvimento do código estaria sob a responsabilidade das transformações de modelo MDA culminando na geração de código. Isso aproximaria o desenvolvimento ETL ao uso de linguagens declarativas (por exemplo, SQL), onde se especifica o que se deseja obter e não como obter. V.1. Premissas Para o desenvolvimento da Poc, algumas simplificações foram aplicadas a fim de limitar o alcance e acelerar o resultado. A primeira simplificação está associada com a criação do cartucho. Visando um desenvolvimento mais rápido e a limitação do esforço despendido, foi escolhida a modificação de um cartucho pré-existente em vez da criação de um novo. O cartucho do Hibernate provou ser o mais adequado, já que contém muitas especificações relacionadas com a utilização de dados. Desta forma, esta versão da aplicação é uma extensão da básica, usada anteriormente (FERNANDES, NETO, FAGUNDES et al. 50

63 2010), com requisitos mais apurados e objetivos mais específicos, conforme comentado no capítulo III. A segunda simplificação diz respeito à fonte de dados. Foi estabelecido que, apesar da possibilidade do ambiente origem ser composto de diferentes fontes de dados (arquivos de texto, planilhas, bases de dados de diferentes fornecedores, etc.), grande parte das vezes esses dados são obtidos a partir de bases do ambiente OLTP. Assim, o banco de dados OLTP foi escolhida como única fonte origem de dados. Outra questão analisada, visando à simplificação, foi a linguagem escolhida para geração de código. A linguagem do código pode ter influência significativa no desempenho do processo (que no ambiente ETL é bastante importante). Entre as linguagens candidatas, aquelas nativas do banco de dados seriam capazes de utilizar as características de desempenho do banco (tais como funções e procedimentos nativos do próprio SQL, opções de compartilhamento de memória, características de compilação, entre outros) e, portanto, foram consideradas as mais adequadas para o código a ser gerado na Poc. Apesar da grande variedade de linguagens disponíveis para geração de código, visando ainda a simplificação para a Poc, foi decidido usar uma única linguagem - PL / SQL - ligada ao banco de dados utilizado no experimento (Oracle). No Apêndice V encontra-se um exemplo do desempenho obtido com o uso desta linguagem para a carga do modelo definido para a Poc. Finalmente, como última orientação para a simplificação, foi decidido o estabelecimento de um limite para as situações abrangidas pelas transformações da experiência, isto é, neste momento a meta não é o desenvolvimento da ferramenta ETL e sim de uma prova de conceito da viabilidade e benefícios deste desenvolvimento no futuro. Espera-se, contudo, que o código produzido seja suficientemente flexível e que a experiência demonstre a capacidade de expansão e a possibilidade de modificação dos resultados gerados. Como mencionado anteriormente, a ferramenta utilizada em todo o experimento foi o AndroMDA que, além de possuir código aberto e extensível, permitindo modificações e agregações (ANDROMDA, 2011), também é utilizada no projeto MDArte, no qual este trabalho se enquadra. Para a realização dos próximos passos, a ferramenta já deve estar instalada. Para tal, a instalação deve seguir as instruções fornecidas pelo fabricante da ferramenta ou o passo a passo disponível no site do MDARTE (2011). 51

64 O passo a passo a seguir será identificado de acordo com o fluxo estabelecido no item IV.5 do Capítulo IV. Este fluxo estabelece um conjunto de etapas e atividades para a personalização de cartuchos. Algumas destas etapas, considerando-se a POC já foram previamente realizadas, pois tratam-se de etapas conceituais do projeto, não sendo consideradas no detalhamento da POC. A vinculação será feita através da codificação utilizada no fluxo: A1 até A17. Neste passo a passo, em alguns itens, ocorreram aglutinações de etapas do fluxo descrito previamente e em outros maiores detalhamentos. Isto se deu em virtude do objetivo deste passo a passo ser esclarecer o leitor sobre o projeto desenvolvido. Desta forma, houve necessidade de se mudar a ordem de apresentação para que a explicação fosse exibida juntamente com o resultado obtido causando, aparentemente, modificações no fluxo, o que, de fato, não ocorreu. V.2. Passo 1 (A9): Parâmetros, estereótipos, valores etiquetados e outros. O primeiro passo na construção da Poc foi a escolha das informações a serem fornecidas pelo modelador. Essas informações proporcionam opções para geração de código e estabelecem limites para todo o projeto. Foram utilizados três níveis de parametrização: nível da entidade (valores etiquetados), nível de atributo (valores etiquetados) e nível de aplicação (propriedades no arquivo de configuração). O modelador vai contemplar os dois primeiros níveis, durante a construção do modelo, uma vez que o enriquecimento semântico ocorrerá durante a modelagem. O terceiro nível está associado ao projeto como um todo, por isso, o modelador deve definir estas informações diretamente no arquivo de configuração do projeto. Neste trabalho foram definidos alguns estereótipos e diversos valores etiquetados cujo uso será comentado ao longo deste capítulo, de acordo com as transformações desejadas. No Apêndice III se encontra, em detalhes, o conjunto completo dos estereótipos criados juntamente com uma explicação sobre seu uso. Seguindo os objetivos estabelecidos pelo trabalho e, ainda, de acordo com as especificações técnicas estabelecidas por KIMBALL & ROSS (2002) os estereótipos e valores etiquetados foram concebidos visando aproveitar a semântica do ambiente. Em função disso, tais estereótipos e valores etiquetados correspondentes podem ser considerados como mais uma contribuição deste trabalho. 52

65 Na figura 13, a seguir, alguns desses valores etiquetados foram exemplificados na entidade Clientes. O estereótipo <<EntityDW>> foi associado à entidade e o estereótipo <<AttrDW>> aos atributos. Cada um desses estereótipos possui um conjunto de valores etiquetados (tagged values) associados, que precisa ser preenchido para caracterizar corretamente a entidade ou atributo correspondente. Ainda na mesma figura, pode-se observar ao nível de entidade, que os valores etiquetados Type (tipo de entidade), AlgorithmType (tipo de algoritmo a ser usado na carga da entidade) e ChangeType (tipo de mudança de controle para entidades do tipo Dimensão) foram preenchidos. Figura 13: Marcações na entidade Clientes Todos estes estereótipos e valores etiquetados estão disponíveis, para o modelador, durante a construção do modelo. Já o criador do cartucho utiliza os arquivos de configuração do mesmo (p.ex: profiles) para esta especificação. Estes arquivos podem ser personalizados para conter todos os parâmetros que sejam necessários ao enriquecimento do modelo e, em alguns casos, também utilizados para informar ao cartucho características que afetem o código gerado. Na Figura 14 se encontram alguns estereótipos e correspondentes valores etiquetados (tagged values) definidos para a Poc. Pode-se observar que a nomenclatura dos estereótipos e valores etiquetados criados é compatível com o primeiro objetivo definido para a Poc, isto é, nomenclatura orientada ao ambiente. Como exemplo, destacamos o valor etiquetado AlgorithmType (a ser vinculado a uma entidade), que foi criado para atender a um dos objetivos da Poc: flexibilidade na escolha dos algoritmos de carga. Neste caso, o modelador poderá determinar qual o algoritmo de carga mais adequado para cada entidade. 53

66 Figura 14: Estereótipos e valores etiquetados para os modelos DW e OLTP Alguns desses valores etiquetados estão associados a listas de valores prédefinidos. Na figura 15 encontramos uma destas listas. O valor etiquetado (tagged value) AttributeType se acha associado a uma lista chamada AttributeDWType, que é exibida abaixo. Mais uma vez observa-se que os valores apresentados na lista se referem a opções para uso do modelador criadas através do emprego da nomenclatura característica do ambiente DW. Figura 15: Opções de valores para a tag AttributeType O terceiro nível de parametrização (global) é aplicável ao projeto como um todo e, portanto, não está disponível durante a modelagem. O modelador deve preencher os 54

67 valores desejados diretamente no arquivo de configuração do projeto, que no caso da ferramenta AndroMDA se chama AndroMDA.xml. O criador do cartucho realiza a personalização desses parâmetros diretamente no arquivo de configuração do próprio cartucho. Como decidimos simplificar este experimento utilizando um cartucho já existente, somente precisamos modificar o arquivo cartridge.xml do cartucho usado. Os parâmetros escolhidos para Poc podem ser vistos na Figura 16. Os mais relevantes, no contexto deste trabalho, são: loadtype - que indica o tipo de carga, e pode ser preenchido com inicial ou incremental; datastagetype que indica o tipo de layout da área intermediária (Data Stage), podendo ser preenchido com DW similar ou semelhante à OLTP. A vinculação de loadtype e datastagetype ao projeto foi motivada pelo objetivo "flexibilidade no modelo de extração e carga". A combinação destes parâmetros produzirá diferentes códigos para a operação de extração e carga de dados. Cabe observar que para a Poc, o uso de uma área intermediária foi planejado e considerado para todos os códigos ETL gerados, de acordo com KIMBALL & ROSS (2002). Figura 16: Propriedades globais para o projeto DwEtl no arquivo cartridge.xml Os valores para estas propriedades são preenchidos no arquivo andromda.xml e são específicos para cada projeto. Na Figura 17 há um exemplo deste tipo de especificação. Podem ser observadas as mesmas propriedades destacadas anteriormente. Neste caso, no entanto, os valores para as propriedades correspondentes estão preenchidos. 55

68 Figura 17: Valores para propriedades do projeto DwEtl no andromda.xml V.3. Passo 2 (A10 e A12): Personalização do Metamodelo Como já mencionado anteriormente, a fim de acelerar o desenvolvimento, a POC foi construída a partir de um cartucho pré-existente. O cartucho escolhido foi o do Hibernate, pois é associado com a persistência do banco de dados. A modificação no cartucho visa à obtenção de informações de dois tipos de modelos: de classe (para a definição de entidades e seus relacionamentos) e de atividades (para a definição de transformações nos dados origem). No modelo de classes foi incluída a classe DWEtlEntity e DwEtlEntityAttribute utilizando o mecanismo de herança, desta forma, todos os métodos e atributos previamente definidos para as classes existentes no Hibernate podem ser diretamente utilizados (ou modificados), diminuindo o esforço de desenvolvimento. No modelo de atividades (inexistente para o Hibernate) foram criadas as classes DwEtlActivity DwEtlEntityTransform. A herança, desta vez, foi originada das metaclasses básicas do próprio MDA. Na figura 18 se encontram trechos do metamodelo de classes do Hibernate com a derivação das classes DWEtlEntityAttribute (esquerda) e do metamodelo de atividades com a derivação das classes DwEtlActivity e DwEtlEntityTransform. O Hibernate não usava um metamodelo de atividades, desta forma, este modelo foi criado empregando as classes originais desenvolvidas pelo AndroMDA. Observe a diferença entre o metamodelo de classes do Hibernate (esquerda) e o metamodelo de atividades incluído (direita). 56

69 Figura 18: Trechos dos metamodelos de classes e de atividades do Hibernate No modelo de classes (esquerda) pode-se perceber que um método e diversos atributos haviam sido desenvolvidos para o cartucho do Hibernate (por exemplo: HibernateEntityAttribute). As generalizações feitas para a nova classe (por exemplo: DwEtlEntityAttribute) herdam as características da classe anterior, possibilitando o aproveitamento tanto dos métodos quanto dos atributos, permitindo a especificação de diferentes objetivos e encurtando o tempo de desenvolvimento. A personalização de um cartucho pré-existente é um truque de desenvolvimento. Pode-se usar parte de um desenvolvimento anterior e realizar modificações ou acréscimos de acordo com as novas necessidades. V.4. Passo 3 (A14): Validação Uma das metas definidas para a Poc foi a validação da modelagem de transferência, isto é, a verificação da viabilidade de transferência de dados entre a base OLTP e a base DW. Para atingir esse objetivo, decidimos criar algumas restrições a serem observadas durante a elaboração do modelo. Estas restrições não são opcionais, ou seja, não estão vinculadas a qualquer parâmetro. Todos os projetos ETL precisam ser validados. Para a criação de regras de validação, levamos em consideração que, normalmente, a equipe DW é diferente das equipes OLTP. Desta forma consideramos que seria razoável assumir que as mudanças nos modelos ocorrem de forma isolada. Por este motivo, optou-se por estabelecer marcas em ambos os modelos (OLTP e DW). Desta forma, cada equipe é responsável pela manutenção e correção de seu 57

70 modelo de dados. Quando ocorre uma mudança, seja no ambiente DW ou no ambiente OLTP, as rotinas de ETL são reconstruídas e revalidadas. A definição das restrições seguiu a orientação de não interromper o processo de geração, no entanto, eventualmente, isto não é possível. Algumas das situações críticas estão listadas na figura 19. Figura 19: Algumas mensagens de erro Foram estabelecidos dois níveis de erro: W (aviso) e S (erro grave): Para o nível W (aviso), as mensagens são gravadas em um arquivo (dwetlerror.log), no entanto, o processo não fica comprometido. Neste caso, o usuário deve analisar o arquivo e fazer as correções no modelo, se desejar. Para o nível S (grave), as situações de erro são gravadas no mesmo arquivo anterior, porém, há o impedimento da geração de rotinas de extração e carga. Neste caso, há a obrigatoridade da correção. A relação completa de mensagens de erro e verificações realizadas está descrita no Apêndice II. Neste local poderá ser observada que várias das críticas remetem ao modelo dimensional, isto é, se referem à integridade do modelo de acordo com os preceitos estabelecidos por KIMBALL & ROSS (2002). Neste sentido tais verificações se acham em acordo com as metas previamente estabelecidas e podem ser consideradas como mais uma contribuição deste trabalho. A título de exemplificação de uma operação de validação, destacamos o erro E03W. Esta restrição tem a finalidade de verificar a existência de relacionamento entre as entidades origem (OLTP) que serão fonte de dados para as entidades destino (DW). A mensagem correspondente a este tipo de situação é a seguinte: dwetl- 58

71 E03W: A entidade DW &entidade não pode ser carregada pois não há relacionamento entre as entidades OLTP que a carregam. Para a POC foi estabelecido que quando duas ou mais entidades enviam diferentes atributos para uma mesma entidade de destino, estas entidades origem devem estar direta ou indiretamente relacionadas. Para realizar essa validação, o cartucho foi obrigado a identificar todos os relacionamentos existentes entre duas entidades quaisquer; mesmo que este relacionamento fosse realizado de forma indireta, isto é, através de uma terceira entidade (por exemplo: de A para B através de C: A-> C-> B). Esta análise também se tornou útil na criação das rotinas de carga, uma vez que quando existe um relacionamento entre duas entidades, o cartucho gera um SQL de junção (Join) entre estas entidades para as operações de carga, como apresentado na figura 20 abaixo. Figura 20: Join entre duas tabelas OLTP Se ocorrerem mudanças nos relacionamentos entre as tabelas, automaticamente, o novo caminho é encontrado e o SQL é reescrito no programa gerado. No apêndice VI foram ilustrados alguns exemplos relativos às conseqüências para o código gerado de modificações no modelo de classes da Poc, isto é, o que é produzido caso uma tabela seja excluída do modelo ou relacionamentos sejam modificados. V.5. Passo 4 (A14): A Geração do Código Quando o processo de geração MDA para um cartucho identifica uma nova metafacade, ele, normalmente, cria três arquivos de classes: uma interface, uma classe abstrata e uma classe concreta. Para melhor compreensão do significado de um metafacade para um projeto MDA, no apêndice I encontra-se uma explicação mais detalhada sobre este conceito. Dos arquivos gerados pelo processo MDA, somente o terceiro arquivo é modificado pelo desenvolvedor do cartucho (classe concreta) visando à implementação de novas 59

72 funcionalidades. Os outros arquivos podem ser gerados novamente, durante a compilação do cartucho. Esta forma de desenvolvimento garante que novas implementações (de versão, por exemplo) nas metafacades do próprio MDA, sejam atualizadas sem impacto. No caso do experimento da Poc, foi dada seqüência à mesma filosofia, isto é, foram criadas algumas classes especializadas, sem modificação das classes originais do AndroMDA e sem modificação das classes do Hibernate. Por exemplo, para a metafacade DwEtlEntityAttribute foram gerados os seguintes arquivos: 1. DwEtlEntityAttribute interface, que estende a metaclasse HibernateEntityAttribute do Hibernate, 2. DwEtlEntityAttributeLogic classe abstrata, que estende uma classe e implementa uma interface: HibernateEntityAttributeLogicImpl (class) e DwEtlEntityAttribute (interface); 3. DwEtlEntityAttributeLogicImpl classe que estende a DwEtlEntityAttributeLogic. No processo de compilação do cartucho, as classes associadas a cada elemento do modelo são instanciadas e executadas de acordo com as especificações estabelecidas no arquivo Cartridge.xml (para o AndroMDA). Figura 21: Carga inicial da tabela de Fato Empréstimos Embora não seja um objetivo pré-determinado, a legibilidade do código gerado foi considerada um item importante para o usuário do cartucho. Assim, alguns padrões 60

73 foram utilizados no código gerado, tais como: um comando por linha, comandos SQL com cláusulas alinhadas, recuo, etc., como exemplificado na figura 21. Para atender a este requisito e permitir o desenvolvimento de algoritmos específicos para cargas sensíveis, optou-se por estabelecer padrões de desenvolvimento (modelos) dentro do código incrementado nas classes. A idéia é que estes trechos padronizados possam ser facilmente substituídos, melhorados, modificados ou clonados para a geração de uma nova opção de desempenho, visando à reorganização do comando para uma melhor legibilidade ou o desenvolvimento da mesma lógica para fontes de dados diferentes. Figura 22: Esquema modelo de código para um tipo de carga Na figura 22 existe um esquema representando um desses modelos. Pode-se observar que as partes fixas não são afetadas por substituições nas partes variáveis. 61

74 Figura 23: Trecho de código correspondente ao esquema modelo Na figura 23 se encontra um trecho de código produzido a partir do esquema representado na figura 22. Pode-se observar que não só as partes variáveis podem ser substituídas, como também podem ser repetidas quando necessário. Se houver interesse na criação de novo padrão de carga, um novo layout de código pode ser estabelecido. As partes variáveis são modificadas de acordo com o modelo de classes DW do projeto (desenvolvido pelo modelador). V.6. Passo 5 (A14): Construção do Cartucho A última etapa do desenvolvimento de um cartucho é sua compilação, incluindo todas as novas classes e seus códigos. Nesta etapa, se a compilação for bem sucedida, o software MDA (no caso da Poc, o AndroMDA) torna este cartucho, devidamente personalizado, disponível para uso pelos projetos ETL através do armazenamento do código compilado no repositório MDA. A título de exemplo, para um completo entendimento da Poc, nas próximas etapas será apresentado o projeto criado para realização dos testes. V.7. Passo 6 (A15): Criação do Projeto Exemplo Em se tratando da ferramenta AndroMDA, a criação de um novo projeto se inicia com a execução de um procedimento específico (ver o passo a passo no site do fabricante). Este procedimento, para criar um projeto vazio que venha a utilizar os cartuchos corretos, realiza uma série de questionamentos relativos às características do projeto. Uma destas questões trata do framework de persistência a ser adotado. No caso da Poc, deve-se escolher o Hibernate. Após a execução deste procedimento, será criado um diretório contendo pastas específicas para os arquivos de configuração, arquivos de modelos, fontes Java, etc., além do arquivo XML com a configuração definida para o projeto (AndroMDA.xml). Por exemplo, como o nome do projeto para a Poc foi chamado de cetlt, alguns dos diretórios gerados foram: C:\cETLt\mda\src\main\config onde se encontra o arquivo andromda.xml 62

75 C:\cETLt\mda\src\main\uml onde se encontra o arquivo com os modelos UML. C:\cETLt\core\target\src\org\andromda\cETLt onde se encontram fontes Java para a camada de persistência. C:\cETLt\web\target\src\layout onde encontram fontes arquivos.css e.gif para as interfaces web. OBS: A variedade de diretórios está relacionada ao tipo de projeto e aos cartuchos escolhidos durante sua instalação. V.8. Passo 7 (A15): Configuração ETL Com o projeto criado (e vazio), pode-se iniciar sua configuração e modelagem. Não há obrigatoriedade de se iniciar pela configuração, no entanto, para efeito de entendimento consideramos esta ordem mais adequada. O arquivo de configurações do projeto (Andromda.xml) deve ser ajustado de acordo com as necessidades do projeto. Neste arquivo (como já comentamos anteriormente) se encontram todos os parâmetros globais, que afetam o projeto como um todo. Figura 24 Valores etiquetados para geração de código Na figura 24, acima, estão os principais valores etiquetados (tagged values) que afetam a geração de código. Alguns deles afetam o projeto como um todo, são os parâmetros globais (tipo de data stage, tipo de carga). Os demais são especificados ao nível de entidade permitindo que entidades diferentes possuam características diferentes e, portanto, parametrização independente. Os parâmetros vinculados a cada entidade devem ser especificados diretamente no modelo. 63

76 No arquivo de configurações do projeto (AndroMDA.xml) devem ser fornecidos valores para os parâmetros globais (por exemplo: o layout da área intermediária: classic - layout similar ao DW - ou fast - layout similar ao OLTP -, esquematizado na figura 25, abaixo) além de diversos outros parâmetros gerais, de menor importância, tais como: freqüência de commit, nome da origem de dados, prefixo para os arquivos do código gerado, dentre outros. Figura 25 Esquema do Processo ETL Ainda considerando o arquivo de configuração, outro parâmetro global digno de menção é o tipo de carga: inicial ou incremental. Na carga inicial todos os dados são carregados considerando-se que a base de destino está vazia. Na carga incremental, a base de destino já está preenchida. Desta forma, de acordo com a estratégia adotada individualmente por entidade, pode-se simplesmente atualizar os dados existentes ou pode-se incluir uma nova versão daquela informação, como veremos mais adiante. V.9. Passo 8 (A16 e A17): Modelos OLTP e DW com marcações Conforme comentado no Passo 7, a etapa de criação do projeto gera diretórios específicos para armazenamento dos arquivos do projeto. Seguindo esta orientação, o arquivo contendo os modelos do projeto deve estar armazenado no diretório..\mda\src\main\uml. Os modelos criados devem abranger todos os recursos necessários à geração das aplicações responsáveis pelas tarefas de extração, transformação e carga. A modelagem deve utilizar as marcações definidas previamente (parâmetros específicos para entidades e atributos) a fim de caracterizar o tipo de ação a ser 64

77 realizada para cada entidade. Para a Poc foram definidos dois modelos de classe: um para o ambiente OLTP e outro para o ambiente de DW, apresentados na Figura 26. Figura 26 Dois modelos de classes Na figura 27 foi destacada a classe cliente, pertencente ao ambiente OLTP. A marcação no modelo correspondente ao ambiente OLTP é bastante simples: basta a identificação da entidade alvo (EntityTarget) e do atributo alvo (AttrTarget), isto é da entidade e do atributo correspondente no ambiente DW. Embora simples, essas marcas fornecem a relação básica entre os ambientes (OLTP e DW). Na Figura 27, a entidade Cliente (OLTP) é a fonte de dados para a entidade Clientes (DW), onde a coluna Nome do Cliente (OLTP), virá a ser transferida para a coluna Nome de Clientes (DW). 65

78 Figura 27 - Marcações no modelo OLTP Na figura 28 se encontra em destaque a classe Clientes do ambiente DW. No ambiente DW as especificações (marcações) são bem mais detalhadas do que no ambiente OLTP, como pode ser visto pelas figuras acima. Foi levada em consideração que a geração de ETL reúne questões técnicas (p. ex: característica da entidade: fato ou dimensão) e ambientais DW (p. ex: tipo de algoritmo utilizado na carga de uma determinada entidade). Assim, apenas a equipe de desenvolvedores DW poderia definir estas características, com os conhecimentos necessários para o processo. Figura 28 - Marcações no modelo DW Ainda ao nível da entidade (apresentado na figura 26 Empréstimos do modelo DW) é possível determinar o melhor momento para realizar operações de agregação. Esta opção somente é aplicável a Fatos. As opções criadas para a Poc são mostradas na Figura 29. O valor "onextraction" indica que a agregação deve ocorrer durante o processo de extração, enquanto "ontransformation" indica que o processo de agregação será concluído apenas após o término da carga. Esta opção é importante porque afeta o desempenho da operação. As conseqüências (isto é, o código gerado correspondente) de uso de cada uma destas opções estão detalhadas no apêndice III (Profile de Persistência) relativo à utilização de agregação. 66

79 Figura 29 Parâmetros para o processo de agregação De acordo com KIMBALL & ROSS (2002), a carga incremental requer um elaborado processo tanto para a especificação quanto para o desenvolvimento de ambos os tipos de entidades: Fatos e dimensões. Enquanto os atributos da tabela de dimensão são relativamente estáticos, os dados não são. Eles podem mudar, embora lentamente, ao longo do tempo. Esta mudança requer uma estratégia para permitir modificações sem invalidar as relações pré-existentes já registradas na base de dados. Para atender a essa especificação, o modelador pode escolher entre "Overwrite" (onde o novo valor substitui o valor antigo) e "AddRow" (onde uma nova linha é incluída na tabela referente à mesma dimensão) para o parâmetro ChangeType. Uma vez que esta estratégia pode ser diferente para cada entidade, este parâmetro não é global. Na Figura 30, é apresentada uma aplicação para carga incremental (parâmetro global) para a entidade Cliente, onde foi escolhida a opção "Overwrite" para o parâmetro "ChangeType". Neste trecho de código pode ser observado que se for encontrado na base um cliente com o mesmo CPF daquele a ser incluso, os dados são sobrepostos (UPDATE). Caso contrário, uma nova linha será acrescentada à tabela (INSERT). Em ambos os casos, supõe-se que a chave primária é uma chave substituta, obtida no momento da inclusão. No trecho em destaque as colunas Nome, CPF e TipoCliente foram substituídos pelos novos valores recebidos da base original (e transformados, opcionalmente). OBS: Nesta aplicação também pode ser observada a execução da operação de transformação juntamente com a operação de carga (representada pelo trecho dwtransf_clientes). Este assunto será explorado devidamente mais adiante neste capítulo. 67

80 Figura 30 Carga incremental da Dimensão Clientes com Overwrite Na Figura 31 a dimensão Clientes foi gerada com a opção "AddRow". Pode-se observar, no destaque, que, inicialmente, há uma atualização na linha existente, com o preenchimento da data de vencimento. Isso garante que a relação com as linhas préexistentes (tabelas de fatos) é preservada. Em seguida está sendo incluída uma nova linha onde a data final não é preenchida. Esta segunda linha estabelecerá relacionamento com as novas linhas das tabelas de fatos que vierem a ser incluídas a partir deste ponto. 68

81 Figura 31 Carga incremental da Dimensão Clientes com AddRow 69

82 Para a abordagem AddRow, foi considerada a existência de três atributos no destino: a data inicial, a data final e o indicador de versão de linha. Estes três atributos são controlados pela aplicação de carga incremental, mas precisam ser identificados no modelo de classe. O modelador poderá optar por utilizar apenas uma destes mecanismos para controle da versão da linha: as datas de vencimento ou o indicador de versão de linha. A opção "AddRow" sem a identificação de pelo menos um desses atributos causa erro, impedindo a geração de código. O desempenho da aplicação é uma preocupação significativa na geração automática de código. Principalmente no processo de ETL, pois envolve grandes volumes de dados. Para a Poc, a preocupação de atender a esse requisito guiou as opções de projeto. Foi definida que a utilização de modelos de código facilita o desenvolvimento e permitem que o construtor cartucho crie, rapidamente, uma nova opção de desempenho que se adapte à situação específica (p. ex: tipo de banco de dados ou padrões locais). A especificação do algoritmo é realizada ao nível de entidade através da propriedade "AlgorithmType". Nesse experimento foram criadas duas opções associadas a essa propriedade: CursorSequential e CommandDirect. A Figura 32 é um trecho de código (a imagem foi cortada para facilitar a leitura), onde a tabela Empréstimo (Fato) será carregada a partir da tabela correspondente no OLTP, Empréstimo. Nesta opção, foi utilizado um cursor para a obtenção dos dados na tabela origem. Ao ler cada linha da origem as seguintes etapas são realizadas: Geração de chave substituta; Obtenção das chaves das tabelas de dimensão; Transformação de dados (opcional); Inserção na tabela fato destino. Nesta opção a operação de inserção é realizada linha a linha, tornando o processamento mais lento, porém, pode ser interessante para utilização das operações de transformação diretamente durante a leitura das linhas ou quando a quantidade de linhas a ser carregada não for significativa. OBS: No apêndice V (Desempenho na Carga) foi realizada a carga alguns dados e mensurado seu tempo com os dois tipos de algoritmo apresentados na Poc. 70

83 Figura 32 - Fato com carga incremental na opção CursorSequential 71

84 A figura 33 (a imagem foi cortada para facilitar a leitura) realiza a mesma carga feita anteriormente, mas com outro algoritmo. Neste caso, o desempenho foi deixado sob a responsabilidade do próprio banco de dados, uma vez que a operação usa apenas comandos SQL para executar a tarefa. Nesta opção, a etapa de transformação não é feita neste momento. Este algoritmo pode ser utilizado em situações onde se deseja liberar o ambiente OLTP rapidamente e processar dados em uma próxima etapa. Figura 33 Carga incremental do fato Emprestimos usando CommandDirect V.10. Passo 9 (A16 e A17): A Transformação dos Dados Uma das características mais marcantes das ferramentas ETL é a possibilidade de transformação dos dados, ou seja, a mudança entre o que está sendo lido da fonte de dados e o que está sendo gravado no destino. A meta para esta característica foi a opcionalidade, ou seja, o modelador pode estabelecer ou não transformações a serem feitas entre as entidades OLTP e DW. Desta forma, a implementação desse recurso foi realizada utilizando o modelo de atividades, de tal forma que um modelo de atividades possa ser desenvolvido apenas para as entidades onde a transformação é necessária. 72

85 A OMG (Object Management Group) definiu especificações de um metamodelo CWM (Common Warehouse metamodelo), que representa os metadados comuns de um data warehouse (OMG, 2003). Neste metamodelo (CWM) há um sub-modelo (Transformation Package) especificamente associado às operações de transformação exigidas por um processo de ETL. Estes modelos foram usados como base para o desenvolvimento do módulo de transformação. Figura 34 Atividades de Transformação Como o módulo de transformação, nesta versão da ferramenta, foi considerado opcional, o usuário do cartucho não é obrigado a utilizar o conjunto de atividades de transformação disponibilizado, podendo até mesmo optar por não utilizar nenhuma transformação. No exemplo da figura 34, foram escolhidas duas atividades específicas: derivação de valor e conversão de valor. Cada uma destas atividades está associada a colunas específicas da base origem ou da base intermediária, desta forma, pode-se associar mais de uma transformação a um mesmo atributo e podem-se criar diversas transformações de mesmo tipo para atributos diferentes. O momento da transformação poderá variar de acordo com o atributo escolhido, o tipo de transformação e o tipo de base intermediária (Datastage). Por exemplo, quando a transformação é aplicável à coluna origem e possível de ser realizada durante a fase de extração, a aplicação dará preferência por realizar a transformação imediatamente neste momento. No entanto, se o tipo da base intermediária for FastOLTP, a operação será adiada para execução posterior. 73

86 Foram previstas cinco operações de transformação nesta versão: conversão (um valor é substituído por outro), constante (um valor específico associado a um atributo), derivação (um atributo gerado a partir de uma operação envolvendo outros atributos), filtragem (linhas determinadas excluídas do resultado) e cisão (um atributo dividido em partes e associado a outros diferentes atributos). Figura 35 Atividades de Transformação código A figura 35 apresenta a função de transformação para as entidades clientes e empréstimos. Seu acionamento pode ser feito durante o processo de carga ou, posteriormente, enquanto dos dados estão na área intermediária. V.11. Passo 10 (A18 e A19): Análise dos Resultados A última etapa da prova de conceito trata, justamente, de uma comparação entre os objetivos propostos e os resultados alcançados. Para cada um dos objetivos estabelecidos no capítulo IV, verificaremos a forma utilizada na Poc para seu atingimento. 74

87 A principal preocupação e o mais importante objetivo proposto é a utilização do conhecimento do modelador de tal forma que seja possível o enriquecimento do modelo através do uso da linguagem nativa do domínio. Este objetivo foi atingido na Poc (detalhado no apêndice III) através da especificação de estereótipos e valores etiquetados, juntamente com listas de valores, que fazem referência aos conceitos de Data Warehouse, no lugar de referência a técnicas de SQL ou de alguma linguagem de programação. O modelador deve fornecer informações como: tipo de atributo (indica a característica do atributo no ambiente: uma medida, uma descrição, uma surrogatekey, etc.), tipo de medida (indica o tipo de medida do negócio: aditiva, semiaditiva ou não aditiva), tipo de agregação (indicando o momento da operação de agregação: na extração ou na transformação), tipo de mudança para dimensões (indica o comportamento quando ocorrem mudanças na dimensão), granularidade da entidade de tempo, tipo de entidade (dimensão ou fato). Não há referência direta a joins, group by, union etc., tal como previsto no primeiro objetivo. O segundo objetivo se referia à possível resistência por parte dos usuários em relação à performance do código gerado. Segundo Muñoz, Mazón e Trujillo (2010) mesmo a utilização de consolidadas ferramentas de mercado requerem grandes requisitos de hardware para sua execução. Desta forma, na Poc, foi adotada uma estratégia diferenciada, a criação de algoritmos compatíveis com as situações que se apresentassem. Para tal, adotou-se a utilização de templates de código visando à simplificação na criação de novos algoritmos. Inicialmente foram criadas duas opções (CursorSequential e CommandDirect) com uso individual por entidade. Por conseguinte, o modelador faria a opção por um algoritmo específico de acordo com a entidade. Novos algoritmos poderiam ser criados paulatinamente à medida que situações mais complexas ou mais distintas se apresentassem. A título de exemplo, no apêndice V (Desempenho na Carga) foi feita a carga do modelo da POC com os dois algoritmos inicialmente previstos e desenvolvidos. Os tempos obtidos podem ser usados como base para avaliações em ambientes reais e construções de novos algoritmos ainda melhores. O próximo objetivo se refere à integridade na transferência de informações entre a fonte de dados e o destino. Este objetivo está relacionado à mudança de layout de qualquer dos modelos (origem ou destino). Para atingi-lo foram criadas diversas criticas que verificam as regras do ambiente de acordo com KIMBALL & ROSS (2002). Estas críticas (detalhadas no apêndice II) validam o modelo data warehouse e a viabilidade de obtenção e carga dos dados. Estas validações são feitas ao nível de 75

88 modelagem, antes da execução do código. Isso permite a antecipação de possíveis situações de erro durante a execução. Para que a identificação dos relacionamentos disponíveis fosse atingida (quarto objetivo proposto), foram desenvolvidos algoritmos que analisam os modelos (fonte e destino) e extraem os relacionamentos desenhados entre cada uma das entidades, verificando a navegação entre as mesmas. Posteriormente esta identificação é usada na verificação de integridade entre os ambientes e na criação das operações de junção (joins) e grupamentos (group by) durante a etapa de geração de código. Nesta versão da Poc, a detecção de mais de um caminho de navegação entre duas entidades apresenta-se como erro. No entanto, em versões posteriores, já está prevista a utilização de um valor etiquetado associado ao relacionamento de tal forma quer o próprio modelador possa indicar seu caminho preferencial. Um exemplo para melhor entendimento da capacidade de análise e extração dos relacionamentos foi realizada no apêndice VI (Exemplos de Modificações no Modelo de Objetos) onde três mudanças foram implementada no modelo e o código resultante destas mudanças apresentado. O próximo objetivo trata da opcionalidade da transformação de dados. Observou-se que nem sempre existe a necessidade de modificação dos dados originais para o armazenamento na base de dados destino. Foram adotadas duas estratégias para atingimento do objetivo. Primeiramente a criação de rotinas independentes do código principal de carga. Isso permite que, de acordo com o momento escolhido para sua execução (na extração ou na transformação), elas sejam acionadas de dentro da aplicação principal de carga ou posteriormente, a qualquer momento. Em segundo lugar, a modelagem opcional das atividades para uma determinada entidade. Caso o modelador não tenha transformações a adotar para uma entidade, basta que a modelagem das atividades para aquela entidade não seja desenvolvida. Isso não impede que a aplicação de carga seja criada. Ela é criada independentemente de haver ou não transformação e independentemente da transformação ser ou não aplicada. O penúltimo objetivo trata da flexibilidade no modelo de extração e carga, isto significa que a aplicação poderia realizar a carga de dados para uma base intermediária (de acordo com KIMBALL & ROSS, 2002) com características de layout diferentes. Considerou-se que esta base poderia ter um layout similar à base origem, visando uma operação rápida (property datastagetype=fast) de extração de dados 76

89 ou um layout similar à base destino (property datastagetype=classic). Para atender a este objetivo foi criado o parâmetro de projeto, nomeado datastagetype a ser fornecido pelo usuário na configuração do projeto (no arquivo Andromda.xml). Sendo assim, também este objetivo foi atingido pela Poc. O último objetivo listado trata da extensibilidade inerente à abordagem, o qual a Poc, na verdade é um exemplo. Este objetivo diz respeito à possibilidade de desenvolvimento de cartuchos para objetivos específicos. A arquitetura MDA não apenas permite este tipo de abordagem, como é uma de suas características mais interessantes, pois permite que um usuário adapte um cartucho existente às suas necessidades específicas. Com este trabalho e, mais especificamente com a Poc, utilizou-se, justamente, esta característica da abordagem para adicionar funcionalidades específicas de ETL (extract-transform-load) a um cartucho préexistente orientado para persistência de dados (Hibernate). Outra alternativa também oferecida pela abordagem é a construção de um cartucho independente, voltado exclusivamente para um uso particular. Esta poderia ser uma proposta para trabalhos futuros à medida que outros tipos de fontes de dados fossem sendo incluídos no desenvolvimento. A independência permitiria que o modelador optasse por outras formas de persistência de dados e, ainda, utilizasse o cartucho ETL. Após as observações registradas neste tópico conclui-se que todos os objetivos propostos neste trabalho foram alcançados e que a Poc representa a primeira etapa na construção de uma ferramenta para ETL (Data Warehouse) através de MDA com geração de código independente de qualquer ferramenta de mercado e com a possibilidade de adaptação às necessidades de performance do usuário. 77

90 Capítulo VI CONSIDERAÇÕES FINAIS Na seção anterior foi apresentada uma versão inicial e limitada de um cartucho de MDA para a construção de aplicações que auxiliam o desenvolvimento das operações de extração, transformação e carga em ambiente de DW. Este trabalho, no entanto, não estaria completo sem que alguma análise se fizesse em relação a softwares de mercado. Afinal, existem diversas ferramentas ETL (comentado no item IV.1) já consolidadas que oferecem alternativas aos usuários. VI.1 MDA ou Ferramentas ETL? De acordo com MUÑOZ, MAZÓN e TRUJILLO (2009) a utilização de ferramentas especializadas (muitas delas associadas aos próprios bancos de dados, como é o caso do Oracle Warehouse Builder, SQL Server Integration Services da Microsoft ou do InfoSphere DataStage dentre outros) apesar de bastante difundido possui alguns importantes inconvenientes: (i) notação proprietária, (ii) configuração e estrutura dos processos ETL muito complexas e (iii) exigência de grandes requerimentos de hardware. Estas características tornam difícil a integração com ambientes heterogêneos e a curva de aprendizado aumenta. Desta forma, existem diversas organizações que preferem desenvolver seus próprios processos ETL através de 78

91 desenvolvimento manual de código específico. Eles colocam também que esta forma de proceder também implica em alguns problemas em função do seu alto custo de manutenção. Assim, o ideal seria a modelagem conceitual dos processos ETL, que melhoraria o desenvolvimento uma vez que documentaria o processo, suportando as tarefas de definição. O que faltava nesta abordagem eram processos de geração de código para uma plataforma específica. Além dessas colocações, que reforçam a abordagem deste trabalho, outro aspecto considerado importante é preocupação de manter a consistência de projeto e sua implementação. No caso da abordagem MDA esta preocupação desaparece uma vez que o código está sempre aderente ao modelo (projeto), portanto, a documentação se acha sempre atualizada. Também ponderamos que o uso ou não de ferramentas pode estar associado a fatores ambientais do cliente, tais como a pré-existência de determinada ferramenta, parcerias estabelecidas, ambiente com uso de MDA, documentação ou não dos processos, etc. Com estas situações em mente, para estabelecermos uma comparação inicial, foram imaginados três cenários envolvendo a construção de um Data Warehouse: 1. Ambiente com MDA Neste ambiente, o usuário, já utiliza alguma ferramenta MDA. Neste caso, a inclusão de um cartucho ETL, somente traria vantagens, pois o esforço a mais despendido pelo usuário seria pequeno. Na prática, o código gerado para a carga do ambiente DW poderia ser considerado um plus da abordagem MDA previamente praticada. O modelador, neste caso, já se acha familiarizado no desenvolvimento de modelos e em seu enriquecimento visando à documentação e a geração de código. O uso do cartucho ETL seria mais proveitoso e, naturalmente, mais rápido que o uso de uma ferramenta ETL de mercado, não requerendo conhecimentos adicionais, além, é claro de manter a compatibilidade entre o projeto (representado pelo modelo) e sua implementação, mantendo a documentação atualizada. 2. Ambiente sem MDA, porém com documentação de modelos Neste ambiente, o usuário não utiliza MDA, no entanto, estabelece documentação de modelos e processos. Portanto a utilização de uma ferramenta MDA poderia ser 79

92 vantajosa uma vez que a modelagem seria aproveitada para a geração de código, o qual será gerado antes mesmo da criação do banco de dados, permitindo avaliações de impacto, desempenho etc. Neste caso, o usuário poderá optar por comparar resultados e avaliar vantagens de uma abordagem ou outra de acordo com suas necessidades. O ambiente MDA com seu cartucho ETL traria a este usuário as seguintes vantagens: Permitir foco no negócio, diminuindo a preocupação com o desenvolvimento; Uso de terminologia característica do DW; Aumento do nível de abstração realizando a modelagem ao nível de classe e reduzindo a dependência do conhecimento específico do software de banco de dados; Flexibilidade do modelo de extração e carga; Flexibilidade de algoritmos de carga para alcançar o desempenho desejado (ver apêndice V); Validação de modelos de dados; Identificação de caminhos alternativos para acesso a dados (ver apêndice VI); Independência da plataforma; Extensibilidade; Aprendizado pequeno para entendimento dos estereótipos e valores etiquetados para enriquecimento do modelo. Compatibilidade de documentação entre o código e o projeto. 3. Ambiente sem MDA e sem documentação de modelos Neste caso, certamente, o esforço de uso de uma ferramenta MDA superaria o esforço de utilização de uma ferramenta ETL de mercado, uma vez que tais ferramentas freqüentemente realizam engenharia reversa da base de dados. O usuário (após o aprendizado especializado) passaria a atuar diretamente na ferramenta com a visão direta das tabelas do banco de dados. Para utilização de uma ferramenta ETL baseada em MDA, o usuário, primeiramente, teria necessidade de criar os modelos (parcialmente através de engenharia reversa), posteriormente, enriquecer estes modelo com o uso de estereótipos e valores etiquetados visando à caracterização dos ambientes (OLTP e DW) e a partir daí gerar código para uso no banco de dados. 80

93 Neste caso o mais difícil seria a manutenção dos modelos após a geração dos códigos desejados uma vez que envolveria uma mudança cultural no cliente. Já que o foco da abordagem MDA é a utilização de modelos e abstração do ambiente físico de dados e código, a implantação deste tipo de abordagem em ambientes que não tem o hábito do manuseio de modelos requereria um esforço maior do que o uso de ferramentas que trabalham diretamente no ambiente físico de dados. VI.2. Conclusões No tópico V.11 foram detalhados os objetivos propostos juntamente com a forma utilizada na Poc para cumprimento de tais objetivos. A partir deste detalhamento, entende-se que a Poc não apenas demonstrou a possibilidade de sucesso na criação de uma ferramenta para a geração de código ETL como também a extensibilidade no desenvolvimento, permitindo a inclusão de novas características sempre que se fizerem necessárias ou vantajosas. No tópico VI.1 foram feitas argumentações e análises sobre o uso de MDA e de ferramentas ETL de mercado. A partir do contexto apresentado fica claro que a utilização de uma ferramenta ETL baseada em MDA somente seria competitiva (em relação à utilização de uma ferramenta ETL de mercado) em ambientes que trabalham a partir de modelos. Nestes ambientes, comparando-se apenas o esforço de preparação dos modelos versus o esforço de aprendizado e utilização de uma ferramenta diretamente no ambiente físico de dados, a abordagem MDA pode ser competitiva. O usuário avaliaria as vantagens de cada uma das abordagens considerando fatores como custo, confiabilidade, adequabilidade, performance, dentre outros aderentes às suas necessidades. Já em ambientes onde a utilização de modelos não é uma constante, o uso de uma abordagem MDA teria riscos de insucesso, pois iria de encontro à cultura vigente, além de requerer um esforço de implementação superior ao de uma ferramenta ETL comum. Neste caso o usuário teria como principal fator de análise as vantagens do uso de modelos e documentação conceitual, antes mesmo de chegar à comparação entre MDA e ferramentas ETL. Ao longo deste trabalho pudemos observar que a abordagem MDA tem foco em modelos e abstração de código, o cartucho desenvolvido em consonância com esta abordagem refina-a ainda mais com o aumento do nível de abstração do modelador, 81

94 focando sua especialização em business intelligence, facilitando o desenvolvimento de código além de utilizar a extensibilidade fornecida pela própria MDA. Entendemos que estas características (abstração e extensibilidade) são fundamentais para o aumento da eficiência e rapidez na construção de ambientes Data Warehouse, uma vez que fornecem a possibilidade do desenvolvimento de uma ferramenta ETL baseada em MDA com características similares às linguagens declarativas, onde se determina o objetivo a ser alcançado e não o caminho a ser trilhado, deixando esta responsabilidade para a ferramenta. A partir dos resultados alcançados neste trabalho comprovou-se a viabilidade dos objetivos propostos e que a criação de uma ferramenta para o ambiente ETL baseada em MDA pode trazer valor agregado e tornar o desenvolvimento de código mais eficiente e altamente orientado a modelos. Em virtude das peculiaridades observadas no processo ETL (processo padronizado, características ambientais definidas, conceitos bem estabelecidos) acredita-se mesmo que este nível de automação fique bem perto de 100%. Além dos resultados alcançados durante o desenvolvimento deste trabalho, também se pode registrar o desenvolvimento bem sucedidos das contribuições adicionais previstas na Introdução, quais sejam: 1. O estabelecimento de um processo padrão orientando o desenvolvimento de implementações em cartuchos novos ou pré-existentes, cujo detalhamento se encontra no tópico IV.5 do Capítulo IV. 2. A definição de estereótipos e valores etiquetados aderentes às especificações técnicas estabelecidas por KIMBALL & ROSS (2002), que pode ser encontrada no Apêndice III. 3. A relação mensagens de erro associadas à validação visando à integridade do modelo de acordo com os preceitos estabelecidos por KIMBALL & ROSS (2002), que pode ser visualizada no Apêndice II. O próximo tópico apresenta uma relação de melhorias a serem implementadas na POC a fim de tornarem-na uma ferramenta real. Também são feitas algumas sugestões para futuros trabalhos abrangendo a utilização da ferramenta em um ambiente real. 82

95 VI.3. Trabalhos Futuros A primeira etapa deste item trata de implementações a serem realizadas no código da Poc visando à construção de uma ferramenta ETL. Observamos as seguintes áreas a serem exploradas ou incrementadas no trabalho atual: Estabelecer uma forma do modelador indicar o relacionamento a ser escolhido (entre tabelas) no caso de haver mais de um disponível. Concluir a implementação das transformações de dados propostas na Poc. Identificação da nomenclatura de atributos e entidades x colunas e tabelas. Concluir as operações de carga para a base FAST ou entre a base CLASSIC e o Data Warehouse. Possibilitar a mesclagem (union) entre tabelas e não apenas junção. Concluir as críticas de modelo. Possibilitar a criação de agregações automáticas. Incluir novo algoritmo de carga com novos planos de performance. Testes mais profundos com modelos maiores. Estabelecer commits intermediários para a carga com algoritmo CommandDirect. Após estas etapas a ferramenta estaria apta para utilização em um ambiente real. Poderiam ser feitas análises comparativas com ferramentas de mercado, avaliação de desempenho dos algoritmos, uso de diferentes fontes de dados, etc. Em um projeto real poderiam ser observadas características como a adequabilidade, praticidade, velocidade de desenvolvimento. Isto facilitaria, certamente, o entendimento para novas proposições que viessem a incrementar o produto. Neste momento podem-se propor algumas sugestões para trabalhos futuros que tornem a ferramenta mais competitiva e útil para os usuários MDA e DW: Criação de um cartucho exclusivo ETL, tornando a ferramenta independente do Hibernate. Indicação da fonte de dados para obtenção de informações fora do database, envolvendo manipulação de outros bancos de dados ou outros tipos de arquivos. 83

96 Geração de dados usando outra linguagem (para outro banco de dados, por exemplo). Implementação de novos tipos de transformações. 84

97 REFERÊNCIAS BIBLIOGRÁFICAS ANDROMDA. What is AndroMDA. Disponível em: g&id=19&itemid=42. Acesso em dezembro ANDROMDA. AndroMDA Cartridges. Disponível em: Acesso em abril ANDROMDA. AndroMDA Profiles. Disponível em: Acesso em abril ANDROMDA. AndroMDA UML Common Metafacades Profile. Disponível em: Acesso em maio ANDROMDA. AndroMDA Metafacades. Disponível em: Acesso em maio APACHE. Apache Velocity Engine. Disponível em: Acesso em dezembro BOOCH, G., RUMBAUGH, J. & JACOBSON, I., 1998, The Unified Modelling Language User Guide. 1 ed. Boston,Addison-Wesley Professional. 85

98 CONTI, F., 2010, História do Computador e da Internet. Disponível em: Acesso em julho Cui, Y & Widom J., 2001, Lineage Tracing for General DataWarehouse Transformations. In: Proceedings of the 27th VLDB Conference. Roma, Italy, CHOWDHARY, P., MIHAILA, G., LEI, H., 2006, "Model Driven Data Warehousing for Business Performance Management". In: ICEBE'06 Proceedings of the IEEE International Conference on e-business Engineering, pp Shanghai, China, ELMASRI, R. & Navathe, S.B., 2005, Sistema de Banco de Dados, 4 ed. São Paulo, Pearson-Addison-Wesley. ESSAIDI, M., OSMANI, A., 2009, "Data Warehouse Development Using MDA and 2TUP". In: Proceedings of the 18th International Conference on Software Engineering and Data Engineering (SEDE'2009), pp Junho, 2009, Las Vegas, Nevada, USA. ESSAIDI, M., OSMANI, A., 2010, "A Unified Method for Developing Data Warehouses". In Proceedings of the 3d. International Conference on Information Systems and Economic Intelligence (SIIE'2010), Fevereiro, Sousse, Tunisia. ESSAIDI, M., OSMANI, A., 2010, "Model driven data warehouse using MDA and 2TUP". In: Journal of Computational Methods in Science and Engineering, Volume 10, Supplement 1/2010, pp ISSN: (Print), (Online). DOI /JCM FARHAD, J., 2002, The UML Extension Mechanisms. Dept of Computer Science University College London. Disponível em: Acesso em dezembro FARHAN, M.S., MARIE, M.E., EL-FANGARY, L.M., HELMY, Y.K., "An Integrated Conceptual Model for Temporal Data Warehouse Security". In: Computer and Information Science, Vol. 4, No 4 (2011). ISSN (Print), ISSN (Online). doi: /cis.v4n4p46. FERNANDES, L. & WERNER, C.M.L., 2009, Sobre o uso de Jogos Digitais para o Ensino de Engenharia de Software. In: XXIV Simpósio Brasileiro de Banco de Dados e XXIII Simpósio Brasileiro de Engenharia de Software, pp Fortaleza, Brazil. Outubro

99 FERNANDES, L. A., NETO, B. H., FAGUNDES, V., ZIMBRÃO, G., SOUZA, J. M., SALVADOR, R., 2010, Model-driven Architecture Approach for Data Warehouse. In: The Sixth International Conference on Autonomic and Autonomous Systems. ICAS 2010, pp Cancun, México. Março FILHO, C. F., 2007, História da Computação - O Caminho do Pensamento e da Tecnologia - ISBN ed. Porto Alegre, EDIPUCRS. FLUSSER, V., 2002, Filosofia da Caixa Preta: Ensaios para uma Futura Filosofia da Fotografia. 3 ed. Rio de Janeiro, Sinergia-Relume Dumará. GARDNER, S. R., 1998, Building the Data Warehouse. ACM Communications, v. 41, n. 9, pp GARTNER GROUP, 2010, Business Intelligence. Disponível em: Acesso em Agosto GARTNER GROUP, 2011, Magic Quadrant for Data Integration Tools. Disponível em: ner-november-2011-magic-quadrant-points-to-further-consolidation-in-dataintegration.aspx. Acesso em Julho GLORIO O., TRUJILLO J., 2008, "An MDA Approach for the Development of Spatial Data Warehouses". In: DaWaK'08 Proceedings of the 10th international conference on Data Warehousing and Knowledge Discovery, pp ISBN: doi> / _3. Turin, Itália. Setembro HEDMAN, F.A., 2009, "Empleo De Mda En La Generación De Procesos". Trabalho Final do Instituto Superior Politécnico José Antonio Echeverría Facultad de Ingeniería Informática. Havana, Cuba. HYENSOOK, K., OUSSENA, S., ZHANG, Y., CLARK, T., 2010, "Automatic generation of data merging program codes". In: 5th International Conference on Software and data Technologies (ICSOFT 2010), pp Greece, Julho, INMON, W. H., 1992, Building the Data Warehouse. 1 ed. New York, John Wiley & Sons. KIMBALL, R., & ROSS, M., 2002, The Data Warehouse Toolkit. 2 ed. New York, Wiley Computer Publishing. 87

100 KOCH, C., 2002, Why doesn t you ROI add up?. CIO Magazine. Disponível em: Acesso em dezembro KONTIO, M., 2005, Architectural Manifesto: MDA for the enterprise. Disponível em wireless/library/wi-arch16/. Acesso em Dezembro, LASKOSKI, J., 2011, MDArte disponível no Portal do Software Público. Blog Informação e Conteúdo sobre TI. Disponível em: Acesso em julho de LEWIS, G.A., WRAGE L., 2004, Approaches to Constructive Interoperability (CMU/SEI-2004-TR-020 ESC-TR ). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, [Online]. Disponível em: publications/documents/04.reports/04tr020.html. Acesso em Setembro, MAFFEO, B., 1992, Engenharia de Software e Especificação de Sistemas, 1 ed. Rio de Janeiro, Editora Campus-Elsevier. MATHEW, A.D., MA, L., HARGREAVES, D.J., 2008, "A conceptual data modelling methodology for asset management data warehousing". In: Proceedings World Congress for Engineering Asset Management, pp , Beijing, China, MAZON, J.N., TRUJILLO, J., SERRANO, M., PIATTINI, M., 2005, "Applying MDA to the development of data warehouses". In: DOLAP'05 Proceedings of the 8th ACM international workshop on Data warehousing and OLAP, pp ISBN: doi> / Bremen, Alemanha. Outubro-Novembro MAZÓN, J. N., TRUJILLO, J., 2008, "An MDA approach for the development of data warehouses". Elsevier Science Publishers B. V. - ISSN: Volume 45 Issue 1, April, doi> /j.dss MDARTE. Portal do Software Público Brasileiro:Comunidade MDARTE. Disponível em: Acesso em Maio MORAL, O.R., SIMITSIS, A., GAMAZO, A.A., 2010, "GEM Requirement driven Generation of ETL and Multidimensional Conceptual Designs". Technical Report. Universitat Politècnica de Catalunya. Departament d'enginyeria de Serveis i Sistemes d'informació. 88

101 MORESI, E.A.D., 2000, "Delineando o Valor do Sistema de Informação de uma Organização". Ciência da Informação, v.29, n. 1, pp 14-24, Brasília, jan-abr MUÑOZ, L., MAZÓN, J.N., PARDILLO, J., TRUJILLO, J., 2008, "Modelling ETL Processes of Data Warehouses with UML Activity Diagrams". In: OTM'08 Proceedings of the OTM Confederated International Workshops and Posters on On the Move to Meaningful Internet Systems, pp ISBN: doi> / _21. Monterrey, México, Novembro MUÑOZ, L., MAZÓN, J.N., TRUJILLO, J., 2009, "Automatic generation of ETL processes from conceptual models". In: DOLAP'09 Proceeding of the ACM twelfth international workshop on Data warehousing and OLAP, pp ISBN: doi> / Hong Kong, China. Novembro OMG, OBJECT MANAGEMENT GROUP., 2003, Common Warehouse Metamodel, CWM Specification,V. 1.1, Vol.1. Disponível em: Acesso em dezembro OMG, OBJECT MANAGEMENT GROUP, 2003, MDA Guide, V Disponível em: Acesso em dezembro de OMG, OBJECT MANAGEMENT GROUP, 2008, Semantics of Business Vocabulary and Business Rules (SBVR), v1.0. Disponível em: Acesso em: julho de OMG, OBJECT MANAGEMENT GROUP, 2011, Catalog Of UML Profile Specifications. Disponível em: Acesso em maio OMG, OBJECT MANAGEMENT GROUP, 2011, MetaObject Facility (MOF). Disponível em Acesso em maio PARDILLO, J., MAZÓN, J.N., TRUJILLO, J., 2010, "Designing OLAP schemata for data warehouses from conceptual models with MDA". In: Computer and Information Science, Volume: In Press, pp ISSN: DOI: /j.dss PRESSMAN, R., 2001, Engenharia de Software. 6 ed. Rio de Janeiro, McGrawHill. QUEIROZ, M. A., 2010,. Desenvolvimento de Software Orientado a Negócios, uma nova abordagem sobre o conceito de desenvolvimento de software. Disponível em: softwell.com.br/wp-content/uploads/2009/04/artigo.doc. Acesso em julho

102 SAURABH, A.K., NAGPAL, B., "A SURVEY ON CURRENT SECURITY STRATEGIES IN DATA WAREHOUSES". In: International Journal of Engineering Science and Technology (IJEST), Vol. 3 No. 4, pp ISSN: Abril SIMITSIS, A., 2005, "Mapping Conceptual to Logical Models for ETL Processes". In: DOLAP '05 Proceedings of the 8th ACM international workshop on Data warehousing and OLAP, pp , ISBN: doi> / Bremen, Alemanha, Outubro. Novembro SIMITSIS, A., VASSILIADIS, P., 2003, "A Methodology for the Conceptual Modeling of ETL Processes". In: The 15th Conference on Advanced Information Systems Engineering (CAiSE '03), Klagenfurt/Velden, Áustria. Junho SIMITSIS, A., VASSILIADIS, P., 2008, "A method for the mapping of conceptual designs to logical blueprints for ETL processes". In: Elsevier Science Publishers B. V. - Decision Support Systems, Volume 45 Issue 1, Abril, 2008, pp ISSN: doi> /j.dss SKOUTAS, D., SIMITSIS, A., 2006, "Designing ETL processes using semantic web technologies". In: DOLAP'06 Proceedings of the 9th ACM international workshop on Data warehousing and OLAP, pp ISBN: doi> / Arlington, VA, USA. Novembro SOLER, E., TRUJILLO, J., FERNANDEZ-MEDINA, E., PIATTINI, M., 2007, "A Framework for the Development of Secure Data Warehouses based on MDA and QVT". In: The Second International Conference on Availability, Reliability and Security (ARES'07), 2007, pp Vienna, Austria, SOUZA, M.A., 2008, Informática na Educação Especial Desafio e Possibilidade Tecnológica. Universidade Tecnológica Federal do Paraná. Disponível em: Acesso em julho SPARX SYSTEMS, 2011, UML Profiles. Disponível em: Acesso em maio TARAPANOFF, K., Inteligência Organizacional e Competitiva. 1 ed. Brasília, Universidade de Brasília. 90

103 TRINTA, F., Model Driven Architecture. Disponível em: Acesso em julho TRUJILLO, J., LUJÁN-MORA, S., 2003, "A UML Based Approach for Modeling ETL Processes in Data Warehouses". In: ER 2003, 22nd International Conference on Conceptual Modeling, pp Chicago, IL, USA. Outubro, VASSILIADIS, P., SIMITSIS, A., SKIADOPOULOS, S., 2002, "Conceptual modeling for ETL processes". In: DOLAP'02 Proceedings of the 5th ACM international workshop on Data Warehousing and OLAP, pp ISBN: doi> / VASSILIADIS, P., SIMITSIS, A., TERROVITIS, M., SKIADOPOULOS, S., 2005, "A generic and customizable framework for the design of ETL scenarios". In: Information Systems, v.30 n.7, p Novembro 2005 [doi> /j.is ]. WILKINSON, K., SIMITSIS, A., CASTELLANOS, M., DAYAL, U., 2010, "Leveraging Business Process Models for ETL Design". In: ER'10 Proceedings of the 29th international conference on Conceptual modeling, pp Vancouver, BC, Canada. Novembro ZEPEDA, L., CELMA, M., ZATARAIN, R., 2009, "A Mixed Approach for Data Warehouse Conceptual Design with MDA". In: ICCSA 2008, Part II, LNCS 5073, pp Perugia, Itália

104 Apêndice I METAFACADES De acordo com o ANDROMDA (2011), Metafacades são fachadas (facades) usadas para fornecer acesso a modelos carregados por um repositório. Estes "metafacades" agem como escudos (ou interfaces) para a implementação do meta-modelo implícito. Metafacades são geradas pelo meta-cartucho AndroMDA e utilizam o padrão MOF (OMG s MetaObject Facility). A especificação MOF é a base do ambiente padrão da OMG onde os modelos podem ser exportados a partir de um aplicativo, importados para outro, transportados através de uma rede, armazenados em um repositório e depois recuperados, processados em diferentes formatos (incluindo XMI e OMG XML), transformados e utilizados para gerar o código do aplicativo (OMG, 2011) Metafacades são APIs objeto-orientadas que permitem o acesso a modelos a partir de templates. Usando metafacades, os templates se tornam muito mais simples e diretos, porque a inteligência e responsabilidade para a transformação de código e geração é centralizada em objetos Java, e não na linguagem de script do modelo (ANDROMDA, 2011). 92

105 Figura 36: Exemplo de metamodelo noções básicas O repositório MOF instancia um objeto Java para cada elemento no modelo que é carregado no AndroMDA. A classe daquele objeto faz parte do metamodelo UML. No exemplo da figura 36, quando se modela o atributo de uma classe, uma instância da metaclasse "atributo" é instanciada. O atributo "birth: Date" do elemento de modelo Person" será instanciado como: 1. Um objeto da classe "Attribute" onde o atributo "name" será definido como birth. 2. Um objeto da classe "UMLClass" onde o atributo "name" será definido como "Person" e uma referência para o objeto Attribute que tenha o nome de "birth". O modelo acima representa, exatamente, o detalhamento da explicação que o ANDROMDA METAFACADES (2011) faz em sua documentação. Em função da utilização de metamodelos, o AndroMDA permite a adequação dos cartuchos às necessidades dos desenvolvedores, permitindo customizações sem perda da integridade de seu próprio código. No trabalho realizado para a Prova de Conceito desta dissertação, utilizou-se uma segunda simplificação: a extensão das classes de um cartucho existente. Desta forma, todos os métodos e atributos previamente criados no cartucho original puderam ser utilizados, acrescidos ou modificados sem perda do comportamento original. Permitindo que o foco do trabalho fosse somente a geração ETL. 93

106 Figura 37: Metafacade DwEtlEntityAttribute A figura 37 acima apresenta a estruturação básica realizada. O metafacade básico do AndroMDA chamado EntityAttribute (correspondente a cada atributo das entidades de um modelo) é estendido pelo cartucho do Hibernate através do metafacade HibernateEntityAttribute, com a adição de novos atributos e métodos. Este, por sua vez é estendido durante a adaptação do cartucho do Hibernate através do metafacade DwEtlEntityAttribute a fim de incluir o comportamento característico desejado associado a ETL. Seguindo este comportamento, os seguintes metafacades foram criados no modelo de classes do Hibernate: DwEtlEntity (derivado de HibernateEntity) representa uma entidade do modelo de classes persistentes. DwEtlEntityAttribute (derivado de HibernateEntityAttribute) representa um atributo de uma entidade do modelo de classes persistentes. 94

107 DwEtlAssocEnd (derivado de HibernateAssociationEnd) representa um dos lados de um relacionamento entre classes persistentes. Para a representação da transformação de dados entre uma estrutura OLTP e uma DW foram utilizadas duas classes presentes no modelo de metaclasses do próprio AndroMDA (ActivityGraphFacade e EventFacade). Uma vez que o Hibernate não possuía uma modelo de classes adequado ao projeto, um novo modelo foi incluído para permitir o comportamento desejado. Os seguintes metafacades foram criados: DwEtlEntityTransform (derivado do metafacade original do AndroMDA chamado ActivityGraphFacade) representa a entidade DW que receberá o dado transformado. DwEtlActivity (derivado do metafacade original do AndroMDA chamado EventFacade) representa a transformação em si. Para a Poc, foram previstos cinco comportamentos de transformação de dados: o ActionConstant para a atribuição de valores fixos, constantes a um atributo. Por exemplo, na carga a indicação de tipo do cliente será sempre PF (pessoa física). o ActionConversion para a tradução dos valores originais em valores substitutos, visando a padronização. Por exemplo, o valor 1 passa a ser armazenado como M para a coluna Sexo, enquanto o valor 2 passa a ser armazenado como F. o ActionDerivation visando possibilitar a geração de novos valores calculados. Por exemplo: vendas = qtde vendida * preço_unitário. o ActionFilter permitindo a seleção de apenas determinadas linhas no momento da carga, estabelecendo uma filtragem dos dados originais. Por exemplo: somente transferir linhas com data de venda maior que 01 de janeiro de

108 o ActionSplit com a finalidade de quebra do valor de um atributo em diversos atributos. Por exemplo, partindo-se uma lista separada por vírgulas, seria possível separar os diversos valores em atributos específicos no destino. Apesar de diversas outras possibilidades de transformação existirem na literatura (CUI, Y & WIDOM J, 2001), o estudo desenvolvido para a Poc foi limitado a apenas este pequeno conjunto uma vez que o objetivo era apenas a exemplificação e não a realização do desenvolvimento de um produto completo. 96

109 Apêndice II VERIFICAÇÕES E MENSAGENS DE ERRO As mensagens de erro listadas neste tópico estão vinculadas não apenas a críticas realizadas na programação, mas também a toda uma conceituação do ambiente Data Warehouse estabelecido por KIMBALL & ROSS (2002). Desta forma, a apresentação destas mensagens será acompanhada de uma pequena explicação sobre a verificação realizada e o conceito embutido (quando for o caso). dwetl-e01s: Modelo vazio ou estereótipos não aplicados. Este é um erro severo que impede o prosseguimento da geração de código. Indica que não foram encontrados os estereótipos necessários à transformação de modelo, desta forma, nenhuma classe foi identificada para transformação. dwetl-e02w: EntidadeDW &entidade não está sendo carregada por entidade OLTP. Este é um aviso e não, obrigatoriamente, se constitui um erro. Indica que foi encontrada uma entidade no modelo DW, que não é a entidade de tempo e que não está recebendo dados de uma fonte origem. Neste caso o processo de transformação de modelo não contemplará esta entidade. 97

110 dwetl-e03w: EntidadeDW &entidade não pode ser carregada pois não existe relacionamento entre as entidades OLTP que a carregam. Este é um aviso, no entanto, de acordo com as premissas deste trabalho se constitui em um erro que impede o prosseguimento das transformações de modelo para esta entidade. Foi estabelecido que quando duas ou mais fontes de dados transferem informações para a mesma entidade destino, obrigatoriamente, deveria existir um relacionamento entre estas fontes, portanto, o fato deste relacionamento não existir impede a geração de código. dwetl-e04w: Atributo &entidade.&atributo não é carregado por nenhum atributo OLTP. Este é um aviso indicando que um determinado atributo de uma entidade DW não está recebendo nenhuma informação da fonte de dados. Entende-se que se uma entidade DW está qualificada para recepção de dados através do aplicativo gerado pelo processo MDA de transformações de modelo, todos os seus atributos devem estar recebendo alguma informação. O usuário deverá, neste caso, não apenas verificar se a fonte de dados foi corretamente identificada como também se o tipo de atributo (valor está qualificado adequadamente. dwetl-e05w: Existe mais de um relacionamento válido para a carga da Entidade DW &entidade. Para a POC, considerou-se que havendo mais de um relacionamento válido entre as entidades componentes da fonte de dados, o processo, para esta entidade não deveria prosseguir. Outras opções seriam a escolha aleatória do relacionamento ou a identificação por parte do modelador. Estas opções foram consideradas para trabalhos futuros. dwetl-e06w: Não foi possível determinar o relacionamento entre todas as entidades origem para a carga de &entidade. Este erro é um subtipo do E03, indicando que nem todas as fontes de dados estão relacionadas. Existem alguns relacionamentos, porém, não são suficientes para obtenção de todos os dados especificados. Há ausência de algum relacionamento. dwetl-e07w: Atributo &entidade.&atributo possui estereótipo AttrOLTP, porém não implementa Tagged Values. 98

111 Este tipo de erro indica que algum atributo foi marcado com o estereótipo adequado, porém, está incompleto uma vez que o detalhamento que tem a finalidade de caracterizar o tipo de medida (no caso de uma entidade fato) e o tipo de atributo não foi preenchido, impossibilitando a geração de código para esta entidade. dwetl-e08s: Existe mais de uma entidade 'Time' neste modelo. A entidade de tempo representa a dimensão tempo (o quando um fato ocorreu) em um data warehouse, porém, somente uma entidade deste tipo deve existir e todos os fatos devem possuir associação a esta dimensão. A existência de mais de uma entidade deste tipo não tem sentido e se constitui em um erro severo que inviabiliza o prosseguimento do processo de transformação de modelo. dwetl-e09s: Entidade Tempo &entidade não possui granularidade definida. Este também se constitui em um erro severo que impede o prosseguimento de todo o processo de transformação. A dimensão tempo identifica o nível de agregação dos dados da entidade fato, chamado de granularidade. Isto tem conseqüências nas operações de carga. Portanto torna-se indispensável sua identificação. dwetl-e10s: Não encontrada nenhuma entidade 'Time' no modelo DW. A entidade de tempo é uma obrigatoriedade em um data warehouse já que os dados armazenados nas entidades de fato são históricas. Desta forma, a inexistência de uma entidade de tempo inviabiliza o prosseguimento das transformações de modelo. Este é um erro severo que interrompe todo o processo. dwetl-e11w: Entidade fato &entidade não tem ligação com entidade 'Time'. Esta é uma obrigatoriedade de todas as entidades fato. Uma vez que um fato é uma série temporal, deve estar associada a uma entidade de tempo. Este tipo de erro impede o prosseguimento do processo apenas para esta entidade. dwetl-e12w: Entidade &entidade não possui atributos ou relacionamentos. Em um modelo dimensional as tabelas de fato estão obrigatoriamente associadas a dimensões. O erro identificado neste item indica que foi encontrada uma entidade (fato ou dimensão) que não se encontra vinculada a nenhuma outra entidade ou que esta não contém nenhum atributo. Este erro é impeditivo do prosseguimento do processo para esta entidade. dwetl-e13s: Entidade dimensão &entidade não possui Surrogate Key definida. 99

112 KIMBALL (2002) encoraja fortemente o uso de Surrogate Keys (chaves substitutas) para as entidades de dimensão no lugar as chaves originais utilizadas nas fontes de dados. Esta utilização simplifica significativamente o modelo dimensional e foi adotado como regra para este trabalho. Como as dimensões estão ligadas a diversos Fatos, um erro deste porte inviabiliza a geração de código para diversas entidades. Desta forma a interrupção ocorre para todo o modelo e não apenas para esta entidade. dwetl-e14w: Atributo &entidade.&atributo possui identificação de tipo inválida. Este erro indica que um atributo específico se encontra no modelo, no entanto, o tipo identificado está incompatível com sua entidade correspondente. Por exemplo, uma descrição em uma tabela de fato. dwetl-e15s: Entidade dimensão &entidade não possui tipo de controle de mudança definido. Todas as dimensões devem estabelecer o comportamento a ser seguido na carga incremental. Individualmente seria impossível a geração de código da entidade. Adicionalmente, a dimensão afeta as tabelas de fato associadas. Considerou-se, portanto, que este seria um erro importante e todo o processo é interrompido. dwetl-e16w: Não encontrados os atributos necessários ao controle de mudança definido para a entidade dimensão &entidade. Este é um erro vinculado a um controle de mudança do tipo AddRow. Não foi encontrado o atributo identificado como DimRowIndicator nem as datas de início e fim de validade. Desta forma não é possível a geração de código para esta entidade. dwetl-e17w: Atributo &entidade.&atributo não possui identificação de tipo. Este é um erro associado à geração de código. Indica que foi encontrado um atributo em uma entidade DW onde o valor etiquetado AttributeType não está preenchido. Isso impede a identificação do que deve ser atribuído a este elemento no momento da carga. O usuário deve verificar o preenchimento deste valor etiquetado para que a geração de código possa prosseguir para esta entidade. dwetl-e18w: Atributo &entidade.&atributo possui tipo Surrogate Key, mas não possui estereótipo 'Identifier'. Esta é uma necessidade associada ao cartucho do Hibernate. Caso o atributo do tipo SK não seja identificado como Identifier, qualquer tipo de relacionamento fica comprometido e a leitura do modelo incorreta. Desta forma, para a geração de código 100

113 de uma determinada entidade, todas as colunas que participam da Primary Key devem ser identificadas com este estereótipo. dwetl-e19w: Atributo &entidade.&atributo está sendo carregado por atributo OLTP incorretamente. Esta mensagem está associada a diversas situações de atribuição inválida. Por exemplo: transferência de dados para uma coluna identificada como Surrogate Key, para uma coluna de tipo DimRowIndicator ou para uma de tipo Derived, dentre outros. Os erros deste tipo ferem as regras do modelo dimensional e devem ser verificadas pelo usuário. A mensagem identifica o elemento incorreto para a correção necessária. O código para esta entidade não é gerado. dwetl-e20w: EntidadeDW &entidade não possui tipo definido. Este é um erro associado à modelagem dimensional. Significa que a entidade mencionada na mensagem de erro não está associada aos tipos Fato ou Dimensão. Em um modelo dimensional existem entidades do tipo Agregação, no entanto, estas entidades não recebem dados de uma base origem. O erro acima indica que uma entidade caracterizada com o estereótipo EntityDW, portanto, passível de recebimento de dados de uma fonte de dados, não está identificada como Fato ou Dimensão (correspondente ao valor etiquetado Type). Isto impede que as transformações de modelo sejam aplicadas a ela, sendo, então o processo interrompido. dwetl-e21w: Entidade fato &entidade não está relacionada a dimensões. Este é um erro associado à modelagem dimensional. Indica que existe uma entidade caracterizada como Fato que não tem relacionamento com nenhuma das entidades caracterizadas como Dimensão. Este erro fere conceitualmente às regras da modelagem dimensional. Desta forma ocorre a interrupção do processo de transformação de modelo para esta entidade. dwetl-e22w: Entidade dimensão &entidade não possui relacionamentos. Este é um erro associado à modelagem dimensional. Indica que foi encontrada uma entidade caracterizada como Dimensão que não se acha associada a nenhuma das entidades caracterizadas como Fato. Isto significa que existe uma dimensão sem finalidade no modelo. Em um modelo dimensional as dimensões têm a finalidade de decodificar (ou esclarecer) as chaves dos fatos. Uma dimensão isolada não tem finalidade para o modelo, portanto, o processo de transformação de modelo não gera código para esta entidade. 101

114 dwetl-e23w: Agregação inválida para medida não aditiva na Entidade &entidade Em um modelo dimensional, as medidas presentes em um Fato podem ser classificadas como aditivas, semi-aditivas ou não aditivas. Nesta versão da aplicação somente são aceitas medidas aditivas, pois permitem a execução da etapa de agregação de dados de forma simplificada. Desta forma, o processo de transformação de modelo é interrompido para esta entidade. Em trabalhos futuros uma solução para os outros tipos de medida será considerado. O conjunto de erros/validações a seguir está relacionado à etapa de transformação de dados do processo ETL (extract-transform-load). As operações de transformação são importantes para o processo ETL uma vez que visam a padronização dos dados oriundos das diversas bases origem de forma a unificar as informações objetivando a qualidade de dados na base Data Warehouse. Os erros deste tipo não causam a interrupção do processo de transformação de modelo, são considerados avisos, interrompendo apenas a geração do código de transformação. dwetl-e24w: A ação &Action deve possuir exatamente um fluxo de entrada e um fluxo de saída. Este erro tem a finalidade de garantir que o fluxo do modelo de transformação esteja completo e seja possível a identificação de seu início e fim. É exigida a presença de uma e somente uma ação de entrada e uma e somente uma ação de saída. Quando esta situação não é encontrada, o erro é apresentado e a geração de código para a transformação é perdida. dwetl-e25w: A ação &Action possui um fluxo de entrada sem o estereótipo TransitionState. Este é um erro de modelagem associado à leitura correta do modelo. Há necessidade que tanto o fluxo de entrada quanto o de saída estejam associados ao estereótipo TransitionState para que a leitura do modelo de transformações seja feita corretamente. A ausência deste estereótipo interrompe a geração de código de transformação. dwetl-e26w: Encontrada ação sem nome. Verifique a transformação: &Transform. Este é um erro simples, mas que impede a geração de código de transformação. A motivação é muito mais conceitual que técnica. A nomenclatura utilizada no modelo não é levada para o código, no entanto, todas as validações subseqüentes fazem 102

115 referência ao nome do elemento. Desta forma, sua ausência dificulta a identificação do elemento incorreto em caso de erro. dwetl-e27w: A ação &Action possui um fluxo de saída sem o estereótipo TransitionState. Este é um erro de modelagem associado à leitura correta do modelo. Há necessidade que tanto o fluxo de entrada quanto o de saída estejam associados ao estereótipo TransitionState para que a leitura do modelo de transformações seja feita corretamente. A ausência deste estereótipo interrompe a geração de código de transformação. dwetl-e28w: Mais de uma seqüência de atividades encontrada para a mesma entidade (mais de um início/fim). Verifique a transformação: &Transform. Este erro tem a finalidade de garantir que o fluxo do modelo de transformação esteja completo e seja possível a identificação de seu início e fim. É exigida a presença de uma e somente uma ação de entrada e uma e somente uma ação de saída. Quando é encontrada mais de uma ação de entrada ou saída, o processo de geração de código para o fluxo é interrompido. dwetl-e29w: Seqüência de atividades sem fim/início: &Action. Verifique a transformação: &Transform. Este é um erro de modelagem, indicando que no modelo de transformação desenvolvido não foi encontrado o indicador de início, de fim ou ambos. Esta é uma informação importante na medida em que as transformações de dados serão executadas na ordem especificada pelo modelador e a ausência do indicador de início/fim impede a identificação da ordem correta para execução das transformações. Desta forma o processo de transformação de modelo MDA para geração de código da transformação de dados é interrompido para esta entidade. dwetl-e30w: A ação &Action não possui estereótipo válido para transformação. Este erro indica que foi encontrada uma seqüência sem um dos estereótipos previstos para transformação de dados. Isto significa que existe uma etapa de transformação de dados não entendida pelo processo de transformação de modelo. Desta forma, optou-se por interromper a geração de transformação para esta entidade. dwetl-e31w: A ação &Action não possui indicação de nome da coluna constante. 103

116 Este erro está vinculado a uma ação de transformação do tipo ActionConstant, onde uma coluna específica recebe um valor constante. Este erro indica que a coluna não foi especificada. O modelador, neste caso, deve verificar o preenchimento do valor etiquetado ConsColumn. dwetl-e32w: A ação &Action não possui indicação de valor da coluna constante. Este erro está vinculado a uma ação de transformação do tipo ActionConstant, onde uma coluna específica recebe um valor constante. O erro indica que o valor constante não foi preenchido. O modelador, neste caso, deve verificar o preenchimento do valor etiquetado ConsValue. dwetl-e33w: A ação &Action faz referência a um atributo inexistente para a entidade correspondente. Este erro pode estar associado a qualquer das transformações de dados propostas por este trabalho. Indica que foi feita referência a um atributo não encontrado no modelo de dados do trabalho. O modelador deve verificar o preenchimento do valor etiquetado correspondente a nome de coluna na ação &Action mencionada no texto da mensagem. dwetl-e34w: A ação &Action não possui indicação de nome da coluna que sofrerá a conversão. Este erro está vinculado a uma ação de transformação do tipo ActionConversion, onde uma coluna específica recebe um valor constante dependendo de um valor informado ConvOrigValue. O erro indica que o nome da coluna cujo valor será modificado não foi preenchido. O modelador, neste caso, deve verificar o preenchimento do valor etiquetado ConvColumn. dwetl-e35w: A ação &Action não possui indicação de valor original para a conversão. Este erro está vinculado a uma ação de transformação do tipo ActionConversion, onde uma coluna específica recebe um valor constante dependendo de um valor informado ConvOrigValue. O erro indica que o valor usado na comparação não foi preenchido. O modelador, neste caso, deve verificar o preenchimento do valor etiquetado ConvOrigValue. dwetl-e36w: A ação &Action não possui indicação de valor resultante para a conversão. 104

117 Este erro está vinculado a uma ação de transformação do tipo ActionConversion, onde uma coluna específica recebe um valor constante dependendo de um valor informado ConvOrigValue. O erro indica que o valor a ser usado para atribuição à coluna após a comparação não foi informado. O modelador, neste caso, deve verificar o preenchimento do valor etiquetado ConvNewValue. dwetl-e37w: A ação &Action não possui indicação de nome da coluna derivada. Este erro está vinculado a uma ação de transformação do tipo ActionDerivation, onde uma fórmula é calculada para atribuição a uma coluna específica. O erro indica que a coluna receptora do cálculo não foi informada. O modelador, neste caso, deve verificar o preenchimento do valor etiquetado DerivColumn. dwetl-e38w: A ação &Action não possui indicação de fórmula. Este erro está vinculado a uma ação de transformação do tipo ActionDerivation, onde uma fórmula é calculada para atribuição a uma coluna específica. O erro indica que a fórmula não foi informada. O modelador, neste caso, deve verificar o preenchimento do valor etiquetado DerivFormula. 105

118 Apêndice III PROFILE DE PERSISTÊNCIA Um Profile UML tem a finalidade de fornecer um mecanismo de extensão genérica para criação de modelos UML em domínios específicos. São baseados em estereótipos e valores etiquetados (tagged values) que são aplicados aos atributos, métodos e diversos outros elementos de um modelo UML. Um profile é um conjunto de extensões de tal forma que, juntos, descrevem algum problema específico de modelagem e facilitam a modelagem de construções nesse domínio (SPARX SYSTEMS, 2011). Para o OMG (2011), um Profile UML é uma especificação que faz um ou mais dos seguintes itens: Identifica um subconjunto do metamodelo UML; Especifica "regras de boa formação" além daquelas já identificadas pelo subconjunto do metamodelo UML. Especifica "elementos padrões" além daqueles já identificadas pelo subconjunto do metamodelo UML. Especifica semântica, expressa em linguagem natural, além daquelas já identificadas pelo subconjunto do metamodelo UML. 106

119 Especifica os elementos do modelo comum, expressa em termos do profile. Seguindo estas especificações, através do AndroMDA, é possível a criação (ou modificação) de profiles para que os elementos contidos neste tipo de arquivo possam ser aplicados nos modelos usados no processo de transformação MDA (ADROMDA, 2011). Para este trabalho adicionamos alguns estereótipos e valores etiquetados (tagged values) ao profile de persistência padrão utilizado pela ferramenta AndroMDA para permitir que as marcações realizadas no modelo ficassem aderentes à nomenclatura típica de um ambiente Data Warehouse (DW), conforme a figura 38. Na seqüência deste tópico serão apresentados todos os estereótipos juntamente com seus correspondentes valores etiquetados, cada um deles remetendo aos conceitos de modelagem dimensional e conseqüências para o código gerado. Esta contribuição do trabalho estabelece a primeira etapa para a construção de uma ferramenta baseada em MDA que tenha como focos principais a abstração e a utilização dos conceitos de data warehouse. Figura 38: Estereótipos aplicáveis aos modelos de classes Os estereótipos criados para o modelo de classes são de duas categorias distintas: associados a entidades (EntityOLTP e EntityDW) e associados a atributos (AttrOLTP e AttrDW). 107

120 Os estereótipos associados a uma entidade caracterizam o modelo específico e as correspondentes entidades passíveis de uso pelo processo de transformação MDA gerador de código. Quando o estereótipo EntityDW é associado a uma determinada classe indica que aquele classe representa uma entidade do ambiente Data Warehouse subordinado às regras de modelagem dimensional estabelecidas por KIMBALL & ROSS (2002). Para o estereótipo EntityOLTP o objetivo é similar, indicando o ambiente OLTP. Estes estereótipos estão descritos a seguir: EntityDW seu objetivo é a identificação da entidade no ambiente DW que receberá as informações oriundas do ambiente OLTP. Ao nível de entidade, valores etiquetados (tagged values) foram criados para a especificação do tipo da entidade (Type), tipo de algoritmo de carga (AlgorithmType), momento da agregação (AggregationType), granularidade da entidade de tempo (TimeGranularity) e tipo de controle de mudança para dimensões (ChangeType), detalhados mais adiante. EntityOLTP seu objetivo é a identificação da entidade no ambiente OLTP e sua correspondência com a entidade DW. Os estereótipos associados a atributos visam à identificação deste atributo no contexto ao qual se liga. Esta caracterização é muito mais importante para o ambiente DW, como descrito abaixo: AttrDW seu objetivo é caracterizar, para DW, o atributo específico. Possui os seguintes valores etiquetados (tagged values): tipo de atributo (AttributeType), tipo de medida para entidades Fato (MeasureType) e tipo de atributo para entidades Tempo (TimeType). AttrOLTP seu objetivo é identificar o tipo de atributo na entidade OLTP e estabelecer a ligação com o atributo correspondente na entidade DW. O detalhamento dos valores etiquetados correspondentes aos estereótipos acima está descrita abaixo, de acordo com o estereótipo: EntityOLTP 108

121 Este estereótipo possui apenas um valor etiquetado (EntityTarget). É um elemento multivalorado que indica a que entidades do modelo DW os dados desta entidade (OLTP) serão destinados. EntityDW Este estereótipo possui 5 (cinco) valores etiquetados com objetivos diversos, a saber: Type determina o tipo de entidade do ambiente DW: Dimension, Fact ou Time. Um Fato é a principal tabela em um modelo dimensional, onde as medidas numéricas representam o desempenho do negócio. Já uma dimensão tem o objetivo de descrever os fatos e contém informações textuais sobre os fatos a que se relacionam. A entidade de Tempo, sempre presente em um DW, indica o nível de agregação temporal das medidas dos fatos, sendo obrigatória em todo Data Warehouse. A identificação do tipo tem conseqüências tanto para a etapa de verificação quanto para a etapa de geração de código. Desta forma sua identificação correta é primordial para o processo de transformação de modelo. TimeGranularity característica específica de uma entidade de tempo. Indica o nível mais baixo de agregação para os fatos. Os valores válidos são: Year, HalfYear, Quarter, Month, Week, Day, Hour, Minute, Second, SecondFraction. De acordo com o valor escolhido, as operações de agregação de dados geradas no código utilizarão funções específicas da linguagem escolhida para a identificação da informação. Na figura 39 se encontram dois trechos do trabalho desenvolvido. Inicialmente verifica-se que a entidade Tempo possui TimeGranularity igual a Week. Abaixo verifica-se um trecho do código gerado para a carga inicial da entidade Empréstimos (um Fato) onde a coluna data_emprestimo (presente originalmente do ambiente OLTP) é comparada aos atributos da entidade Tempo até atingir o nível Week (previamente especificado) a fim de identificar a chave de Tempo a ser incluída em Empréstimos. 109

122 Figura 39: Valor Etiquetado TimeGranularity e código gerado correspondente AlgorithmType este é um valor etiquetado que pode ser utilizado tanto para entidades de dimensão quanto para entidades de fato. Indica o tipo de algoritmo a ser usado no código a ser gerado. Esta informação tem impacto direto no código gerado. Nesta versão apenas duas opções de algoritmo são válidas: CommandDirect ou CursorSequential. Uma vez que esta característica pode ser diferenciada para cada uma das entidades do modelo, o usuário poderá optar por aquele algoritmo mais adequado de acordo com parâmetros como: tipo de entidade, quantidade de dados e freqüência de carga, dentre outros. Na figura 40 encontram-se dois trechos de código: o primeiro foi gerado para a carga inicial na entidade Clientes utilizando o algoritmo CursorSequential (observase que um cursor foi criado com o comando Select necessário à captura dos dados. Posteriormente este cursor foi usado para leitura linha a linha e conseqüente inclusão na tabela destino). O segundo código foi gerado para a carga inicial da entidade Empréstimos utilizando o algoritmo CommandDirect (observa-se que, neste caso, não há declaração de cursor. O comando para inclusão da linha na tabela destino está diretamente vinculado a um comando Select para captura do dado. Toda a performance fica sob a responsabilidade do banco de dados). 110

123 Figura 40: Trechos de código para CursorSequential e CommandDirect AggregationType opção específica para Fatos. Indica o momento mais adequado para a execução de uma operação de agregação. As opções válidas são: onextraction e ontransformation. Na figura 41 encontram-se dois trechos de código para o valor etiquetado AggregationType. No primeiro trecho pode-se encontrar o comando de atribuição que aciona a rotina de transformação para Empréstimos r1 := DATASTAGEDB.dwTransf.dwTransf_Emprestimos(r1);. Este tipo de comando não existe no segundo trecho de código (criado para a entidade Clientes) uma vez que foi escolhida a transformação após a carga na área de estágio como uma operação isolada. Sendo assim, a operação de carga (inicial ou incremental) não aciona a execução da rotina criada. 111

124 Figura 41: Trechos de código para onextraction e ontransformation ChangeType exclusivo para dimensões. Indica o tipo de mudança controlado para a dimensão correspondente. Uma dimensão, apesar de ter seu layout estável pode sofrer mudanças ao longo do tempo. No entanto, como ela contém a descrição dos fatos aos quais está associada, deve ser capaz de manter a informação correta para os fatos já cadastrados no banco de dados. Por exemplo, suponhamos que a dimensão vendedor possua um atributo região indicativa da região onde o vendedor trabalha. Caso um vendedor mude de região, deve haver uma forma de garantir que os fatos criados quando o vendedor trabalhava na região A permaneçam associados a esta região, enquanto que os novos fatos criados indiquem, corretamente, que o vendedor, agora, trabalha na região B. Desta forma, qualquer operação realizada pelo usuário sobre a base de dados, obterá os dados corretos para cada região. Neste trabalho, foram ofertados para o modelador duas opções de tipo de mudança: Overwrite e AddRow. A opção Overwrite, simplesmente substitui o valor da informação existente na dimensão pela informação nova, desta forma toda informação do fato passado passa a identificar a nova informação nova. A opção AddRow cria uma nova linha e torna a linha anterior inoperante. Assim, os fatos antigos continuam apontando para as linhas anteriores e os novos fatos 112

125 apontam para as novas linhas. A figura 42 a seguir apresenta dois trechos de código de carga incremental para a entidade Clientes. No trecho da esquerda a opção escolhida para controle de mudança foi Overwrite. Pode-se observar que caso a linha da dimensão seja encontrada (trecho if c2%found ), o valor das colunas Nome, CPF e tipocliente é substituído pelo valor novo. Já no trecho da direita, onde a opção de controle de mudança foi AddRow, caso a linha da dimensão seja encontrada (trecho if c2%found ), a linha anterior é expirada e uma nova linha é incluída com data de fim de validade vazia. Para a realização deste tipo de mudança, o modelador deve incluir alguns atributos na dimensão correspondente: uma data de início de validade e uma data de fim de validade e/ou um indicador seqüencial de linha. Estes atributos devem ser caracterizados adequadamente através do valor etiquetado AttributeType. Figura 42: Trechos de código para Overwrite e AddRow 113

126 Nos exemplos apresentados até este momento, freqüentemente, o modelador foi obrigado a informar valores padrões para os valores etiquetados. Durante o desenvolvimento da Poc, optou-se por estabelecer listas de valores que auxiliassem e, simultaneamente, garantissem a acurácia no preenchimento destas informações no modelo. Na figura 43 são apresentadas algumas das listas de valores constantes para os valores etiquetados aos quais estas se encontram vinculadas. Figura 43: Listas de valores para tagged values Quando o modelador seleciona o valor etiquetado na ferramenta de modelagem é apresentada uma lista de valores (figura 44) de tal forma que ele somente possa preencher um dos valores da lista. 114

127 Figura 44: Preenchimento do valor etiquetado AttributeType Uma segunda forma de estabelecer listas de valores limitantes é a associação com um estereótipo específico, como acontece com o item ConsColumn. A este item foi associado o estereótipo AttrDW. Isto significa que o modelador poderá preencher este valor somente com atributos que tenham o estereótipo correspondente, garantindo a validação em relação ao tipo de informação. Na figura 45, quando é selecionado o valor etiquetado ConsColumn, o modelador, pressionando o botão + poderá escolher entre os elementos de modelo que possuam o estereótipo AttrDW. Esta opção também garante uma escolha compatível com o tipo de elemento desejado. Figura 45: Seleção de elemento para o valor etiquetado tipocliente AttrOLTP Este estereótipo possui apenas 2 valores etiquetados AttributeType, que tem a finalidade de indicar o tipo de atributo origem (pode ser preenchido com OLTP ou Work). Nesta versão da aplicação a origem de dados única é OLTP, no entanto, em trabalhos futuros pode-se inferir a criação de novas opções. O segundo valor etiquetado deste estereótipo é o AttrTarget. Trata-se de um elemento multivalorado vinculado a elementos que possuam o valor etiquetado AttrDW. Sua finalidade é indicar o destino do conteúdo do atributo ao qual esteja associado. AttrDW 115

128 Este estereótipo exige um detalhamento maior, pois produz diferenças no código gerado. Os valores etiquetados associados são: AttributeType, MeasureType, TimeType. AttributeType indica o tipo do atributo da entidade DW (fato, dimensão ou tempo). Os valores válidos são: DimExpirationDate, DimRowIndicator, DimValidateDate (associados a dimensões com o objetivo de controle de mudança quando o valor etiquetado ChangeType estive preenchido com AddRow ); FactKey (associado a fatos com o objetivo de identificar os atributos chave da entidade); Measure (associado a fatos com o objetivo de identificar os atributos que correspondem às medições, isto é, valores do negócio. Estes atributos sofrerão agregação caso sejam aditivos); Description (associado a dimensões, indicando uma coluna descritiva, decodificadora de um fato); Derived (associada a fatos, indicando que os dados serão gerados através de fórmulas ou cálculos, possivelmente com o uso de transformações); DimOriginalKey (associada a dimensões, caracterizando a chave original da dimensão. A chave principal de uma dimensão é uma surrogate key, capaz de permitir a utilização do controle de mudança); SurrogateKey (normalmente associada a dimensões, no entanto, também pode ser usada para fatos. Indica uma chave alternativa gerada no momento da carga. Esta chave não possui vínculos lógicos com a linha original, trata-se de um número seqüencial. Seu uso simplifica o modelo dimensional e facilita o controle de mudanças, no caso de dimensões); TimeKey (associada à entidade de tempo, com a finalidade de identificar o atributo chave. Este atributo será utilizado para relacionamento com todos os fatos); DegeneratedDimension (associada a dimensões. Indica os atributos da dimensão quando esta não possui atributos descritivos. Tem a finalidade de impedir críticas na etapa de geração de código); Other (associada a fatos. Tem a finalidade de indicar um atributo a ser ignorado no processo). MeasureType valor etiquetado exclusivo para atributos do tipo Measure (medida do negócio). Os valores válidos são: Additive (indica que esta medida poderá sofrer agregação. Por exemplo: qtd_vendida); SemiAdditive (indica que esta medida não poderá sofrer agregação direta. Por exemplo: saldo, qtd_itens_estoque); NonAdditive (indica que esta medida não poderá sofrer nenhum tipo de agregação. Por exemplo: %ocupação, temperatura diária). Nesta versão da aplicação somente medidas aditivas são consideradas válidas para operações de agregação em fatos. Uma solução de contorno é o uso de 116

129 uma fórmula de cálculo substituindo a agregação. No entanto, o usuário deverá mudar o tipo de dado para Derived. Esta solução de contorno foi utilizada para o atributo Saldo_Real do fato Empréstimos (figura 46). Esta solução, no entanto, foi dada pelo modelador e não pela aplicação. Figura 46: Operação de transformação para Saldo_Real TimeType valor etiquetado exclusivo para a entidade de tempo e tem a finalidade de identificar cada um dos elementos característicos de tempo até o nível especificado para a granularidade da entidade. Os valores válidos são os mesmos utilizados para a granularidade da entidade, isto é, Year, HalfYear, Quarter, Month, Week, Day, Hour, Minute, Second, SecondFraction. A figura 39 (apresentada anteriormente) mostra que quando um atributo de um fato (uma data) é associado à chave da entidade de tipo Time, são extraídos deste atributo os conteúdos necessários às comparações com os atributos da entidade de tempo que identifiquem sua chave primária. Sendo assim, torna-se necessária a identificação de cada uma das colunas desta entidade que sejam responsáveis pela caracterização da referida chave. Os próximos estereótipos estão associados à modelagem das atividades de transformação de dados. Estes estereótipos caracterizam o tipo de transformação de dados a ser aplicada à entidade do diagrama. Cada diagrama está associado a uma única entidade DW. Este diagrama deve indicar o início do fluxo, as operações em ordem seqüencial de execução e fim do fluxo. A figura 47 representa, exatamente, este processo para a entidade Empréstimos. Neste caso ocorrem duas operações de transformação seqüenciais: uma derivação (usa o estereótipo ActionDerivation) e uma conversão de valor (usa o estereótipo ActionConversion). 117

130 Figura 47: Processo de transformação para o fato Empréstimos O grupo de estereótipos descritos a seguir, aplicável ao modelo de transformação de dados poderá ser usado repetidamente para a mesma entidade. A restrição é que em um modelo existam transformações de uma única entidade. A figura 48 apresenta cada um dos estereótipos com seus respectivos valores etiquetados. Figura 48: Estereótipos aplicáveis aos modelos de atividades 118

131 O objetivo desta etapa é permitir que o modelador identifique algumas modificações a serem aplicadas aos dados antes destes serem armazenados na estrutura criada no ambiente DW. De um modo geral as atividades de transformação estão associadas à limpeza dos dados ou equivalência entre dados de fontes diferentes. Por exemplo: em uma determinada fonte de dados, a identificação de homens e mulheres é feito através das letras H e M, já em outra fonte de dados esta informação utiliza as letras F e M e em uma terceira, os valores 1 e 2. Quando estes dados forem enviados para uma mesma coluna no ambiente DW, há necessidade de se estabelecer um padrão. O modelador, neste caso poderá utilizar o método de transformação que considerar mais adequado. Nesta versão da aplicação, os seguintes comportamentos para transformação de dados foram previstos, de acordo com os estereótipos definidos: ActionConstant este estereótipo tem o objetivo de identificar o atributo no ambiente DW que receberá valor constante. Os valores etiquetados são: identificação do atributo (ConsColumn) e valor a ser atribuído (ConsValue). Na figura 49, a coluna tipocliente receberá o valor constante PF em todas as suas linhas. Não há variação, nem dependência de qualquer condição. O valor é fixo. Figura 49: Atribuição fixa à coluna tipocliente ActionConversion identifica o atributo no ambiente DW (ConvColumn) e, condicionalmente, o valor a ser atribuído (ConvNewValue) caso o valor original do dado seja compatível com o valor original informado (ConvOrigValue). Na figura 50 observamos a diferença entre este exemplo e o anterior. Neste caso Saldo_Real somente receberá null se seu valor for 0. Caso contrário, seu conteúdo não será afetado pela operação. A conversão, portanto, é uma operação condicional, nem sempre será realizada. 119

132 Figura 50: Atribuição condicional a Saldo_Real ActionDerivation objetiva a geração de um valor (DerivColumn) no ambiente DW a partir de uma composição de colunas (DerivFormula) do ambiente OLTP. A derivação representa a criação de um valor a partir de outras colunas presentes na mesma linha. A fórmula é aplicada à coluna definida pelo valor etiquetado DerivColumn. A figura 51 apresenta uma exemplificação deste uso: Saldo_Real recebe uma operação de subtração entre Valor_Total e Valor_Pago. Figura 51: Atribuição de cálculo a Saldo_Real ActionFilter estabelece uma condição para filtragem de dados (FilterCondition) a ser aplicada ao ambiente OLTP. Este comportamento foi previsto, porém, não foi desenvolvido para esta versão da aplicação. O objetivo é que seja possível estabelecer uma restrição sobre as linhas a serem obtidas do ambiente OLTP. Caso a condição fosse verdadeira a linha seria transferida para o ambiente DW, caso contrário, não. ActionSplit determina um (ou mais) caractere (SplitCaracter) em relação ao qual a coluna OLTP (SplitOrigColumn) será subdividida e seu conteúdo associado às colunas DW (SplitDestColumn1, SplitDestColumn2, SplitDestColumn3 e SplitDestColumn4) que estiverem preenchidas. Este comportamento foi previsto, porém, não foi desenvolvido para esta versão da aplicação. A intenção é de dividir uma texto qualquer entre diversas colunas na tabela destino. Deve ser informado um caracter a ser usado para a separação do dado. EntityTransform este estereótipo é aplicável à maquina de estado e tem a finalidade única de identificar a entidade destino que receberá a transformação 120

133 (EntityDWTarget). A figura 52 apresenta os elementos UML que devem receber este estereótipo: TrfClientes e TrfEmprestimos. Pode-se observar que cada um dos diagramas se encontra subordinado a este elemento. Diversos diagramas podem ser criados com seqüências de transformação de dados que atendam às necessidades do usuário. A restrição é que não participem do mesmo diagrama entidades diferentes. Figura 52: Diagramas para Transformação de Dados Quando todos os estereótipos, listas e valores etiquetados são devidamente adicionados ao profile de persistência (escolhido em função do tipo de cartucho), o processo de compilação e publicação do AndroMDA, garante que o arquivo resultante seja disponibilizado para os modeladores nas ferramentas UML em uso. Esta característica pode ser visualizada na figura 53 onde é possível a visualização do profile de persistência a partir da ferramenta UML Magic Draw. Nesta imagem podemse perceber a presença de várias listas de valores mencionadas ao longo deste trabalho assim como de alguns estereótipos (ActionConstant, ActionConversion e ActionDerivation). 121

134 Figura 53: Profile de Persistência As características iniciais fornecidas pelo padrão MDA foram estendidas para acomodar os padrões semânticos DW e tornar a modelagem compatível com o negócio do usuário. 122

135 Apêndice IV MODELOS UML DA POC Neste apêndice serão apresentados os quatro modelos utilizados na Poc para realização dos testes do cartucho desenvolvido. Nos modelos de persistência, nem todas as entidades foram criadas com o intuito de transferência entre ambientes. Algumas tiveram a finalidade única de conter erros para verificação das restrições estabelecidas. O modelo de persistência para o ambiente OLTP é composto das seguintes entidades: Agencia entidade auxiliar. Não é enviada ao ambiente DW. ContaCorrente entidade auxiliar. Não é enviada ao ambiente DW. Pessoa entidade utilizada para obtenção do CPF a ser armazenado na entidade Clientes do ambiente DW. Cliente seus dados serão transferidos para o ambiente DW na entidade correspondente Clientes. Empréstimo seus dados serão transferidos para o ambiente DW na entidade correspondente Empréstimos. 123

136 Figura 54: Estrutura básica do modelo de persistência do ambiente OLTP Na figura 54, se encontra a estrutura básica do modelo de persistência do ambiente OLTP. Durante o desenvolvimento do projeto esta estrutura foi alterada diversas vezes para auxiliar na simulação das situações de erro previstas. Figura 55: Estrutura básica do modelo de persistência do ambiente DW Da mesma forma, para o ambiente DW, foi criado um modelo simples (figura 55) que permitisse ajustes e modificações para que fosse possível a simulação de situações variadas previstas no projeto. Para o modelo DW, a estrutura é composta das seguintes entidades: Teste entidade auxiliar. 124

137 Tempo entidade auxiliar. Sua existência é obrigatória em ambiente Data Warehouse. Clientes entidade do tipo Dimensão. Seus dados são oriundos das entidades Cliente e Pessoa, do ambiente OLTP. Empréstimos entidade do tipo Fato. Seus dados são oriundos da entidade Empréstimo, do ambiente OLTP. Para este modelo, diversas simulações foram desenvolvidas, principalmente em virtude dos parâmetros que caracterizam o resultado do código gerado. Sendo assim, o modelo exposto na figura acima corresponde a um dentre muitos dos preenchimentos parametrizáveis tanto para as entidades quanto para os atributos. Para a simulação das tarefas de transformação de dados passíveis de ocorrer durante uma operação de carga, foram criados dois modelos: modelo de ações para a entidade cliente (apresentado na figura 56) e modelo de ações para a entidade empréstimos (apresentado na figura 58). Figura 56: Modelo de ações aplicáveis à entidade Clientes (DW) Para a entidade Cliente utilizou-se apenas a associação de um valor fixo. Esta operação causaria a criação de uma função em um pacote de transformações, exemplificado na figura 57. Esta função poderia ser acionada durante a operação de carga ou posteriormente quando a informação já estivesse na área intermediária (Data Stage). 125

138 Figura 57: Código correspondente à transformação da coluna tipocliente. Neste exemplo (Figura 57), a função receberia uma linha similar à linha da tabela Clientes (DW), transformaria esta linha e retornaria esta linha transformada. Figura 58: Modelo de ações aplicáveis à entidade Emprestimos (DW) Neste exemplo (Figura 58) são desejadas duas operações seqüenciais sobre a linha da tabela Empréstimos. Na primeira ocorre o preenchimento de Saldo_Real através de uma fórmula seguido de uma avaliação do resultado. Caso o resultado da derivação fosse zero, seria atribuído null a Saldo_Real. Na Figura 59 se encontra o código gerado para a realização das duas operações. Pode-se observar que as duas operações são compostas dentro da mesma função. Em ordem seqüencial, como definido pelo diagrama. O objetivo é que o modelador estabeleça todas as operações que deseja realizar em um mesmo diagrama (nesta 126

139 versão da aplicação). Neste caso, o código gerado corresponde a uma única função com todas as operações seqüenciadas, como abaixo. Figura 59: Código correspondente à transformação da coluna Saldo_Real Nesta versão da aplicação o código gerado está vinculado a um único pacote (objeto package do Oracle), como pode ser visto na figura 60 a seguir: Figura 60: Package de Transformação No entanto, considerando-se a possibilidade de grandes quantidades de transformações ou entidades participantes, pode-se pensar na criação de pacotes por entidade, contendo diversas rotinas, de acordo com a quantidade de colunas transformadas ou de acordo com o tipo de transformação, desde que seja mantida a seqüência estabelecida pelo modelador. 127

140 Apêndice V DESEMPENHO NA CARGA Neste apêndice serão apresentados os modelos de dados, o banco de dados correspondente (script de criação das tabelas, índices e restrições de integridade) e amostragens dos dados gerados para a realização do teste de carga inicial da Poc. O modelo relacional do ambiente OLTP é apresentado na figura 61, a seguir. Podese observar que este modelo é bastante similar ao modelo de classes apresentado anteriormente. Isto ocorre porque o trecho do modelo de classes apresentado tratava apenas das classes de persistência (de interesse deste projeto). No entanto, em um modelo de classes real estarão presentes tanto as classes de persistência quanto as demais classes do sistema (por exemplo, classes de interface). O conjunto de classes, em uma abordagem MDA, será utilizado por cada um dos cartuchos a que se referem. No caso deste trabalho as classes de persistência serão lidas e tratadas pelo cartucho do Hibernate, com duas finalidades distintas: construção da camada de acesso ao banco de dados e construção dos aplicativos ETL. 128

141 Figura 61: Modelo de Dados OLTP Para a realização da carga de dados entre ambientes, a base OLTP foi carregada com dados randômicos de acordo com o script exemplo descrito a seguir (para a tabela Pessoa). Pessoa Os dados foram gerados utilizando-se o package DBMS_RANDOM para montagem de valores diversos. O script utilizado para esta carga é apresentado na figura 62. Com ele foram criadas linhas na tabela. Figura 62: Script para carga de dados da tabela Pessoa Na figura 63 encontra-se um exemplo dos dados gerados para preenchimento desta tabela. 129

142 Figura 63: Amostragem de dados da tabela Pessoa Cliente esta tabela já foi gerada levando-se em consideração o conteúdo da tabela Pessoa uma vez que existe um relacionamento entre elas. Na tabela Cliente foram carregadas linhas. O script criado também utilizou o package DBMS_RANDOM para geração dos dados numéricos e listas de valores em memória para a criação dos dados alfanuméricos. Na figura 64 encontra-se uma amostragem dos dados gerados para esta tabela. Figura 64: Amostragem de dados da tabela Cliente Agencia para esta tabela foram criadas apenas 40 linhas. Na figura 65 encontrase uma amostragem dos dados gerados para esta tabela. Figura 65: Amostragem de dados da tabela Agencia ContaCorrente esta tabela estabelece relacionamento com agencia, cliente e indiretamente com Pessoa. Nesta tabela foram criadas linhas. A seguir (figura 66) uma pequena amostragem de dados. 130

143 Figura 66: Amostragem de dados da tabela ContaCorrente Emprestimo - a última tabela do modelo possui um relacionamento com a tabela contacorrente e diversos valores numéricos (gerados randomicamente). Para esta tabela foram geradas linhas. Uma amostragem destes dados se encontra na figura 67. Figura 67: Amostragem de dados da tabela Emprestimo O segundo modelo de dados (apresentado a seguir na figura 68) corresponde à base intermediária (Data Staging) similar, em layout, ao ambiente Data Warehouse criado para a Poc. Figura 68: Modelo de Dados Data Warehouse Antes do início da execução das rotinas de carga, a tabela Tempo foi carregada a partir das datas existentes na tabela Empréstimo do ambiente OLTP. A carga desta tabela pode obedecer a outras regras do ambiente cliente, no entanto, a tempo de carga dos dados na base DW, ela já deve estar preenchida. 131

144 A fim de estabelecermos um controle de tempo sobre a carga de dados foi criada uma tabela auxiliar chamada CARGALOG composta apenas de duas colunas: texto e data. O script apresentado na figura 69 foi executado visando o registro do intervalo de tempo total de cada execução nesta tabela. Figura 69: Script para carga da base DW Clientes para a carga desta tabela utilizou-se o script seqüencial (destacado na figura 71). Foram carregadas linhas em um tempo de 1:37min. (um minuto e trinta e sete segundos). Na figura 70 é apresentada uma amostragem do resultado da carga nesta tabela. Pode-se observar que a coluna TipoCliente já se encontra preenchida. Este preenchimento foi realizado pela etapa de transformação de dados ocorrida concomitantemente com a carga inicial. Figura 70: Amostragem de dados da tabela Clientes Uma vez que a quantidade de dados não era grande e a tabela não possuía muitos relacionamentos, optou-se por realizar a carga com cursor, o que permitiu a execução simultânea das operações de transformação de dados. O script de carga (já apresentado anteriormente) se encontra a seguir (figura 71). 132

145 Figura 71: Script de carga para Clientes Empréstimos (v1) a carga desta tabela ocorreu para duas versões da aplicação. Inicialmente utilizou-se o script apresentado na figura 72. Com esta rotina foram carregadas linhas em um tempo de 4:12 min. (4 minutos e doze segundos). Figura 72: Script de carga para Emprestimo algoritmo CommandDirect 133

146 Empréstimos (v2) para observarmos a diferença de tempo de carga entre os dois algoritmos desenvolvidos, a tabela foi totalmente esvaziadas e uma nova carga ocorreu, porém, desta vez utilizou-se o script apresentado na figura 73. Com esta rotina foram carregadas linhas em um tempo de 07:47min. (7 minutos e quarenta e sete segundos). Apesar do tempo bem superior ao utilizado na primeira versão, ganhou-se com a execução simultânea das transformações de dados previstas para esta tabela, como pode ser observado na figura 74. Figura 73: Script de carga para Emprestimo algoritmo CursorSequential Na amostragem de dados a seguir (figura 74) a coluna SALDO_REAL já aparece preenchida (correspondendo ao resultado de VALOR_TOTAL VALOR_PAGO). Como os valores gerados foram aleatórios, o saldo aparece negativo neste trecho da amostragem. 134

147 Figura 74: Amostragem de dados da tabela Emprestimos O resultado destes testes indica que o usuário nem sempre precisará optar pelo algoritmo mais rápido. Isso dependerá de sua estratégia de carga. De acordo com o tempo previsto para a carga poderá ser mais vantajosa a utilização da carga seqüencial com a execução simultânea das operações de transformação. Como último assunto deste apêndice apresentamos o script para criação dos bancos de dados OLTP e Data Warehouse (área intermediária) e algumas informações sobre o equipamento utilizado para os testes: 1. Script para criação do banco de dados OLTP: CREATE TABLE AGENCIA ( NUMERO NUMBER CONSTRAINT SYS_C NOT NULL, NOME VARCHAR2(100 BYTE) NULL, ENDERECO VARCHAR2(100 BYTE) NULL ); CREATE UNIQUE INDEX PK_AGENCIA ON AGENCIA (NUMERO ASC); ALTER TABLE AGENCIA ADD CONSTRAINT PK_AGENCIA PRIMARY KEY (NUMERO); CREATE TABLE CLIENTE ( ID NUMBER CONSTRAINT SYS_C NOT NULL, ENDERECO VARCHAR2(100 BYTE) NULL, NOME VARCHAR2(100 BYTE) NULL, PK_PESSOA NUMBER NULL ); CREATE UNIQUE INDEX PK_CLIENTE ON CLIENTE (ID ASC); ALTER TABLE CLIENTE ADD CONSTRAINT PK_CLIENTE PRIMARY KEY (ID); CREATE UNIQUE INDEX IX_CLIENTE_01 ON CLIENTE (PK_PESSOA ASC); CREATE TABLE CONTACORRENTE ( ID NUMBER CONSTRAINT SYS_C NOT NULL, 135

148 NUMERO NUMBER NULL, AGENCIA_REF NUMBER NULL, CLIENTE_TITULAR NUMBER NULL, CLIENTE_CONJUNTA NUMBER NULL ); CREATE UNIQUE INDEX PK_CONTACORRENTE ON CONTACORRENTE (ID ASC); ALTER TABLE CONTACORRENTE ADD CONSTRAINT PK_CONTACORRENTE PRIMARY KEY (ID); CREATE INDEX FK_CONTACORRENTE_01 ON CONTACORRENTE (AGENCIA_REF ASC); CREATE INDEX FK_CONTACORRENTE_02 ON CONTACORRENTE (CLIENTE_TITULAR ASC); CREATE INDEX FK_CONTACORRENTE_03 ON CONTACORRENTE (CLIENTE_CONJUNTA ASC); CREATE TABLE EMPRESTIMO ( VALOR NUMBER NULL, TX_JUROS NUMBER NULL, TOTAL_PRESTAÇÕES NUMBER NULL, VALOR_PRESTAÇÃO NUMBER NULL, SALDO NUMBER NULL, NUMERO NUMBER CONSTRAINT SYS_C NOT NULL, DATA_EMPRESTIMO DATE NULL, CCEMPRESTIMO_REF NUMBER NULL ); CREATE UNIQUE INDEX PK_EMPRESTIMO ON EMPRESTIMO (NUMERO ASC); ALTER TABLE EMPRESTIMO ADD CONSTRAINT PK_EMPRESTIMO PRIMARY KEY (NUMERO); CREATE INDEX FK_EMPRESTIMO_01 ON EMPRESTIMO (CCEMPRESTIMO_REF ASC); CREATE TABLE PESSOA ( ID NUMBER CONSTRAINT SYS_C NOT NULL, IDPESSOA NUMBER NULL, CPF NUMBER(11) NULL ); CREATE UNIQUE INDEX PK_PESSOA ON PESSOA (ID ASC); ALTER TABLE PESSOA ADD CONSTRAINT PK_PESSOA PRIMARY KEY (ID); CREATE UNIQUE INDEX IX_PESSOA_01 ON PESSOA (CPF ASC); ALTER TABLE CLIENTE ADD (CONSTRAINT FK_CLIENTE_01 FOREIGN KEY (PK_PESSOA) REFERENCES PESSOA (ID)); 136

149 ALTER TABLE CONTACORRENTE ADD (CONSTRAINT FK_CONTACORRENTE_01 FOREIGN KEY (AGENCIA_REF) REFERENCES AGENCIA (NUMERO)); ALTER TABLE CONTACORRENTE ADD (CONSTRAINT FK_CONTACORRENTE_02 FOREIGN KEY (CLIENTE_TITULAR) REFERENCES CLIENTE (ID)); ALTER TABLE CONTACORRENTE ADD (CONSTRAINT FK_CONTACORRENTE_03 FOREIGN KEY (CLIENTE_CONJUNTA) REFERENCES CLIENTE (ID)); ALTER TABLE EMPRESTIMO ADD (CONSTRAINT FK_EMPRESTIMO_01 FOREIGN KEY (CCEMPRESTIMO_REF) REFERENCES CONTACORRENTE (ID)); 2. Script para criação do banco de dados da área intermediária: CREATE TABLE CLIENTES ( CPF NUMBER NULL, NOME VARCHAR2(100 BYTE) NULL, DTINIVALIDADE DATE NULL, DTFIMVALIDADE DATE NULL, ROWIND NUMBER NULL, IDCLIENTE NUMBER CONSTRAINT SYS_C NOT NULL, TIPOCLIENTE VARCHAR2(2 BYTE) NULL ); CREATE UNIQUE INDEX PK_CLIENTES ON CLIENTES (IDCLIENTE ASC); ALTER TABLE CLIENTES ADD CONSTRAINT PK_CLIENTES PRIMARY KEY (IDCLIENTE); CREATE UNIQUE INDEX IX_CLIENTES_01 ON CLIENTES (CPF ASC); CREATE TABLE EMPRESTIMOS ( VALOR_TOTAL NUMBER NULL, SALDO_ATUAL NUMBER NULL, VALOR_PAGO NUMBER NULL, IDEMPRESTIMO NUMBER CONSTRAINT SYS_C NOT NULL, SALDO_REAL NUMBER NULL, TIPOEMPRESTIMO VARCHAR2(100 BYTE) NULL, CLIENTESPK NUMBER NULL, TEMPOPK NUMBER NULL ); CREATE UNIQUE INDEX PK_EMPRESTIMOS ON EMPRESTIMOS (IDEMPRESTIMO ASC); ALTER TABLE EMPRESTIMOS ADD CONSTRAINT PK_EMPRESTIMOS PRIMARY KEY (IDEMPRESTIMO); CREATE TABLE TEMPO ( 137

150 TIMEID NUMBER CONSTRAINT SYS_C NOT NULL, YEAR NUMBER(4) NULL, MONTH NUMBER(2) NULL, QUARTER NUMBER(1) NULL, WEEK NUMBER(2) NULL ); CREATE UNIQUE INDEX PK_TEMPO ON TEMPO (TIMEID ASC); ALTER TABLE TEMPO ADD CONSTRAINT PK_TEMPO PRIMARY KEY (TIMEID); CREATE INDEX IX_TEMPO_01 ON TEMPO (YEAR ASC,MONTH ASC,QUARTER ASC,WEEK ASC); ALTER TABLE EMPRESTIMOS ADD (CONSTRAINT FK_EMPRESTIMOS_01 FOREIGN KEY (CLIENTESPK) REFERENCES CLIENTES (IDCLIENTE)); ALTER TABLE EMPRESTIMOS ADD (CONSTRAINT FK_EMPRESTIMOS_02 FOREIGN KEY (TEMPOPK) REFERENCES TEMPO (TIMEID)); O equipamento utilizado para realização destes testes foi um Notebook Dell Vostro 1510 com memória e processador apresentados na figura 75. Figura 75: Características físicas do equipamento usado nos testes A versão do banco de dados utilizada se encontra registrada na figura 76 a seguir. 138

151 Figura 76: SQL*Plus com versão do Oracle 139