Um Componente para Geração e Evolução de Esquemas de Bancos de Dados como Suporte à Construção de Sistemas de Informação

Transcrição

1 UNIVERSIDADE FEDERAL DE GOIÁS INSTITUTO DE INFORMÁTICA ALEXANDRE CLÁUDIO DE ALMEIDA Um Componente para Geração e Evolução de Esquemas de Bancos de Dados como Suporte à Construção de Sistemas de Informação Goiânia 2010

2 UNIVERSIDADE FEDERAL DE GOIÁS INSTITUTO DE INFORMÁTICA AUTORIZAÇÃO PARA PUBLICAÇÃO DE DISSERTAÇÃO EM FORMATO ELETRÔNICO Na qualidade de titular dos direitos de autor, AUTORIZO o Instituto de Informática da Universidade Federal de Goiás UFG a reproduzir, inclusive em outro formato ou mídia e através de armazenamento permanente ou temporário, bem como a publicar na rede mundial de computadores (Internet) e na biblioteca virtual da UFG, entendendo-se os termos reproduzir e publicar conforme definições dos incisos VI e I, respectivamente, do artigo 5 o da Lei n o 9610/98 de 10/02/1998, a obra abaixo especificada, sem que me seja devido pagamento a título de direitos autorais, desde que a reprodução e/ou publicação tenham a finalidade exclusiva de uso por quem a consulta, e a título de divulgação da produção acadêmica gerada pela Universidade, a partir desta data. Título: Um Componente para Geração e Evolução de Esquemas de Bancos de Dados como Suporte à Construção de Sistemas de Informação Autor(a): Alexandre Cláudio de Almeida Goiânia, 22 de Novembro de Alexandre Cláudio de Almeida Autor Dr. Juliano Lopes de Oliveira Orientador

3 ALEXANDRE CLÁUDIO DE ALMEIDA Um Componente para Geração e Evolução de Esquemas de Bancos de Dados como Suporte à Construção de Sistemas de Informação Dissertação apresentada ao Programa de Pós Graduação do Instituto de Informática da Universidade Federal de Goiás, como requisito parcial para obtenção do título de Mestre em Nome do Programa de Pós-Graduação. Área de concentração: Engenharia de Software. Orientador: Prof. Dr. Juliano Lopes de Oliveira Goiânia 2010

4 ALEXANDRE CLÁUDIO DE ALMEIDA Um Componente para Geração e Evolução de Esquemas de Bancos de Dados como Suporte à Construção de Sistemas de Informação Dissertação defendida no Programa de Pós Graduação do Instituto de Informática da Universidade Federal de Goiás como requisito parcial para obtenção do título de Mestre em Nome do Programa de Pós- Graduação, aprovada em 22 de Novembro de 2010, pela Banca Examinadora constituída pelos professores: Prof. Dr. Juliano Lopes de Oliveira Instituto de Informática UFG Presidente da Banca Prof. Dr. Plínio de Sá Leitão Júnior Instituto de Informática - UFG Prof. Dr. Ronaldo dos Santos Mello Departamento de Informática e de Estatística - UFSC

5 Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador(a). Alexandre Cláudio de Almeida Graduou se em Ciência da Computação na UFG - Universidade Federal de Goiás. Durante o Mestrado, na UFG, foi bolsista do CNPq e desenvolveu pesquisa empírica na área de Sistema de Informação com estudo de caso em Sistema de Informação Agropecuário, sob orientação do Prof. Dr. Juliano Lopes de Oliveira.

6 Dedico este trabalho aos meus pais, Antônio Carlos e Madalena, pelo apoio incondicional e por acreditarem no meu potencial.

7 Agradecimentos Agradeço primeiramente a Deus por me dar força e saúde para completar este trabalho. Aos meus pais, Antônio Carlos e Madalena, pelo incentivo e apoio não só no periodo do mestrado mas em toda minha vida. Ao meu orientador, Prof. Juliano Lopes de Oliveira, pelo incentivo, pela ajuda em criar o corpo de conhecimento adquirido até aqui e por ser uma fonte de inspiração como pessoa, não só na computação, mas na vida. Aos meus irmãos, Adriano e André, pela amizade e por estar sempre junto nos momentos bons e principalmente nos difíceis. Aos amigos de mestrado, Glauber Boff, Wilane Carlos, Patrícia Gomes, Fabiana Freitas, Valdemar Neto, Luiz Loja, Sofia Larissa e Victor Ribeiro pela ajuda e companheirismo durante o período do mestrado. Aos professores do Instituto de Informática da UFG pela aprendizado. Aos funcionários do Instituto de Informática da UFG, João Bosco Carmo Moraes e Enio Perez Rodrigues, Edir de Jesus Borges Pinto, Justiniana César da Silva e principalmente para Berenice Vieira Silva pelo carinho e presteza durante todo o periódo de graduação e mestrado. Ao CNPq pelo apoio financeiro.

8 A mente que se abre a uma nova ideia jamais voltará ao seu tamanho original. Albert Einstein,.

9 Resumo Cláudio de Almeida, Alexandre. Um Componente para Geração e Evolução de Esquemas de Bancos de Dados como Suporte à Construção de Sistemas de Informação. Goiânia, p. Dissertação de Mestrado. Instituto de Informática, Universidade Federal de Goiás. Um Sistema de Informação (SI) Corporativo tem três aspectos principais: o banco de dados, que contém dados que são processados para gerar informações do negócio; as funções de aplicação, que transformam dados em informações; e as regras de negócio, que controlam e restringem a manipulação dos dados pelas funções. Um SI precisa evoluir continuamente para acompanhar as mudanças na corporação e, consequentemente, o banco de dados deve ser modificado para atender aos novos requisitos de negócio. Esta dissertação apresenta uma abordagem dirigida por modelos para a automatização do processo de transformação na geração e evolução de bancos de dados de Sistema de Informação. Para isso foi criado um componente de software denominado Especialista em Banco de Dados (EBD). Dois conjuntos de mapeamentos são apresentados para a geração de esquemas, um do modelo conceitual chamado Modelo de Meta Objeto (MMO), utilizado para representação de SI, para o Modelo Relacional; e deste para o dialeto SQL do SGBD PostgreSQL. O componente EBD faz parte de um framework que gera, evolui e gerencia Sistemas de Informação. Este componente fornece também serviços para outros componentes deste framework. Uma experimentação foi feita com engenheiros de software com experiência em desenvolvimento de Sistema de Informação para validar a abordagem proposta. As principais contribuições desta dissertação são: abordagem que apoia ciclo de vida de BD de SI, arquitetura de software que permite a geração e evolução de esquema de SI, especificação de um modelo de representação de dados de SI (MMO), especificação de mapeamentos para geração de esquema e procedimentos de manipulação e definição de um conjunto de operações que automatizam o processo de evolução de esquema de BD de SI. Palavras chave Sistema de Informação, Banco de Dados, Desenvolvimento Dirigido por Modelo

10 Abstract Cláudio de Almeida, Alexandre. A Component to Generate and Evolve Database Schema Supporting Information Systems Constrution. Goiânia, p. MSc. Dissertation. Instituto de Informática, Universidade Federal de Goiás. An Information System (IS) has three main aspects: a database that contains data which is processed to generate business information; an application functions which transforms data in information; and business rules which control and restrict data manipulated by the functions. An IS evolves continuously to follow the corporation changes, and the database should be change to attend the new requirements. This dissertation presents a model driven approach to generate and evolve IS databases. A software component, called Especialista em Banco de Dados (EBD), was developed. There are two mapping sets for database generation: from Modelo de Meta Objeto (MMO) (used to representing IS) to Relational Model (RM), and from this to DBMS PostgreSQL SQL dialect. The component EBD is a part of a framework for modeling, building and maintaining enterprise information systems software. This component provides services to other framework components. To validate the proposed approach, Software Engineers had developed IS using the component EBD. The Dissertation main contributions are an approach to support IS database life cycle, a software architecture to generate and evolve IS database schema, an IS data representation model (MMO), a mapping specification to generate schema and stored procedures and the definition of automated operation sets to evolve IS database schema. Keywords Information System, Database, Model Driven Development (MDD)

11 Sumário Lista de Figuras 12 Lista de Tabelas 13 Lista de Códigos de Programas 15 1 Introdução Ciclo de Vida de Sistemas de Informação Banco de Dados em SI Motivação e Objetivos do Trabalho Metodologia da Pesquisa Desenvolvida Organização do Trabalho 19 2 Desenvolvimento Dirigido por Modelo em Bancos de Dados Desafios e Soluções da Abordagem MDD Desenvolvimento de Bancos de Dados e MDD Comparação de Ferramentas MDD para BD 25 3 Arquitetura do Componente EBD - Especialista em Banco de Dados Arquitetura do Framework Modelo de Representação de Dados de SI - MMO Tipos de Atributo no MMO Arquitetura dos Componentes de Transformação Serviços de Acesso a Dados Serviços de Geração de Esquema Serviços de Evolução de Esquema Serviço de Metadados e Dados de Entidade 39 4 Transformações entre Modelos Mapeamentos do MMO para MR Mapeamento de Entidades e Hierarquia de Especialização Mapeamento de Tipos de Relacionamento (Objeto Interno) Mapeamento de Entidade Fraca Mapeamento de Atributo Multivalorado Geração de DML para Operações CRUD DML para Tipo de Entidade DML para Tipo de Entidade Especializada DML para Objeto Interno DML para Tipo de Entidade Fraca 60

12 4.2.5 DML para Atributo Composto DML para Atributo Simples Multivalorado Mapeamento do MR para PostgreSQL Geração de Tabelas Geração de Stored Procedures (SP) em PL/pgSQL 69 5 Funcionamento do Componente EBD Criação de Sistema de Informação Utilização do Sistema de Informação Operações CRUD 91 Inserção de Instância de uma Entidade 92 Obtenção de Instância de uma Entidade 95 Atualização de Instância de uma Entidade 95 Remoção de Instância de uma Entidade Exemplo: SI para o Agronegócio Exemplos de Geração de Esquema Aplicações de Mapeamentos na Evolução de Esquemas Tipos de mudanças permitidas no esquema MMO Mudanças de Tipo e Domínio de Atributo Mudanças na chave lógica e no tipo de entidade Mudanças em outras meta-informações Mecanismo para Evolução de Esquema de BD Evolução do Sistema de Informação Exemplos de Evolução de Esquema Experimentação do Componente EBD Metodologia Coleta de Dados Análise dos Resultados Conclusões Considerações Finais Contribuições Trabalhos Futuros 133 Referências Bibliográficas 135 A Protocolo para Avaliação da Ferramenta EBD 141 A.1 Objetivos da Avaliação 141 A.2 Procedimentos da Avaliação 141 A.3 Questionário 142 A.4 Modelo Conceitual de uma Empresa 143 B Mapeamentos do Modelo Relacional para SQL (PostgreSQL) 146 B.1 Entidade Fraca 146 B.2 Atributo Composto 151 B.3 Atributo Simples Multivalorado 155

13 C Lista de Abreviaturas e Siglas 159

14 Lista de Figuras 2.1 Transformação entre modelos (Adaptado de [43]) Arquitetura Funcional do Framework (adaptada de [21]) Metamodelo para representação conceitual de SI - Modelo de Meta- Objetos (MMO) [22] Arquitetura do Componente de Geração de Esquema Arquitetura do Componente de Evolução de Esquema Classe Metadados Representação Gráfica de uma Instância de ObjetoApresentacao Classe ObjetoApresentacao Mapeamento de Atributo Enumerado do MMO para o MR Mapeamento de Hierarquia de Especialização do MMO para o MR Mapeamento de Atributo Objeto Interno do MMO para o MR Mapeamento do Atributo Objeto Interno (Agregação) do MMO para o MR Mapeamento de Entidade Fraca do MMO para o MR Mapeamento de Atributo Multivalorado do MMO para o MR Mapeamento de Atributo Composto do MMO para o MR Formulário para Cadastro de Tipo de Entidade do SI Formulário para Cadastro de Atributo de Tipo de Entidade do SI Exemplo de Tela de Manipulação de Pessoa Física gerada pelo framework Modelo Estático das Classes Envolvidas nas Operações CRUD Colaboração para mapeamento Objeto-Relacional na operação de Inserção Colaboração para mapeamento Objeto-Relacional na operação de Consulta Colaboração para mapeamento Objeto-Relacional na operação de Atualização Colaboração para mapeamento Objeto-Relacional na operação de remoção Modelo Conceitual Simplificado - Conceito de "Animal" Modelo Conceitual Simplificado - Conceito de "Cor de Pelo de Animal" Mudanças Possíveis em Tipo/Domínio de um Atributo Mudanças possíveis no tipo de entidade Colaboração no Mecanismo de Verificação e Adaptação para Evolução de Esquema Interface para Modificação das Instâncias da Entidade Ligação das instâncias de Animal com Propriedade Rural Modificação da Chave das Instâncias da Entidade Pessoa Física 125 A.1 Modelo Conceitual de Empresa (adaptado de [55]) 145

15 Lista de Tabelas 2.1 Tabela de Comparação de Ferramentas ORM Mapeamento de Entidades e Hierarquia de Entidades do MMO para o MR Conversão de Tipo/Domínio do MMO para MR Mapeamento de Objeto Interno do MMO para o MR Mapeamento do Atributo Simples Multivalorado do MMO para o MR Mapeamento do Atributo Composto Multivalorado do MMO para o MR Operações CRUD sobre Tipo de Entidade Operações CRUD sobre Tipo de Entidade Especializada Operações CRUD sobre Atributo Objeto Interno Obtenção de Instâncias de Atributo Objeito Interno (Agregação) Operações CRUD sobre Entidade Fraca Operações CRUD sobre Atributo Composto Operações CRUD sobre Atributo Multivalorado Conversão de Tipo/Domínio do MR para SQL Mapeamento de Relação "Entidade" do MR para SQL Mapeamento de Relação "Atributo Objeto Interno" do MR para o SQL Mapeamento de Relação "Atributo Multivalorado" do MR para SQL do PostgreSQL Mapeamento de Relação "Atributo Composto" do MR para o SQL do PostgreSQL Mapeamento de Operações CRUD sobre Tipo de Entidade Mapeamento de Operações CRUD sobre Tipo de Entidade Especializada Mapeamento de Operações CRUD sobre Atributo Objeto Interno Mapeamento de Operações CRUD sobre Atributo Objeito Interno (Agregação) Tempos de Execução da Experimentação Tempo de Desenvolvimento e Quantidade de Erros Tempo de Desenvolvimento e Produtos Gerados Respostas do Questionário de Avaliação da Experimentação da Ferramenta EBD 128 A.1 Dicionário do Esquema de Empresa 144 B.1 Mapeamento de Operações CRUD sobre Tipo de Entidade Fraca 146 B.2 Mapeamento de Operações CRUD sobre Atributo Composto 151 B.3 Mapeamento das Operações CRUD sobre Atributo Multivalorado 156

16 Lista de Códigos de Programas 4.1 Obtenção de Lista de Atributos Simples de uma Hierarquia de Especialização Tabela Modelo em PostgreSQL Tabela Modelo para Criação de Atributo Objeto Interno Modelo de Stored Procedure em PL/pgSQL Stored Procedure Modelo para Obtenção de Instâncias de Tipo de Entidade Stored Procedure Modelo para Inserção de Instância de Tipo de Entidade Stored Procedure Modelo para Remoção de Instância de Tipo de Entidade Stored Procedure Modelo para Atualização de Instância de Tipo de Entidade Stored Procedure Modelo para Obtenção de Instâncias de Tipo de Entidade Especializada Stored Procedure Modelo para Inserção de Instância de Tipo de Entidade Especializada Stored Procedure Modelo para Remoção de Instância de Tipo de Entidade Especializada Stored Procedure Modelo para Atualização de Instância de Tipo de Entidade Especializada Stored Procedure Modelo para Obtenção de Instâncias de Atributo Objeto Interno Stored Procedure Modelo para Inserção de Instância de Atributo Objeto Interno Stored Procedure Modelo para Remoção de Instância de Atributo Objeto Interno Stored Procedure Modelo para Atualização de Instância de Atributo Objeto Interno Stored Procedure Modelo para Obtenção de Instâncias de Atributo Objeto Interno (Agregacao) Stored Procedure Modelo para Inserção de Instância de Atributo Objeto Interno (Agregação) Stored Procedure Modelo para Remoção de Instância de Atributo Objeto Interno (Agregação) Stored Procedure Modelo para Atualização de Instância de Atributo Objeto Interno (Agregação) Tabela da Entidade Animal de Propriedade Stored Procedure para Obtenção de Instâncias da Entidade Animal de Propriedade Stored Procedure para Obtenção de Instância da Entidade Animal de Propriedade 103

17 5.4 Stored Procedure para Inserção de Instância da Entidade Animal de Propriedade Stored Procedure para Remoção de Instância da Entidade Animal de Propriedade Stored Procedure para Atualização de Instância da Entidade Animal de Propriedade Tabela do Atributo Objeto Interno Cor de Pelo Animal Stored Procedure para Obtenção de Instâncias do Atributo Objeto Interno Cor de Pelo Animal Stored Procedure para Inserção de Instância do Atributo Objeto Interno Cor de Pelo Animal Stored Procedure para Remoção de Instância do Atributo Objeto Interno Cor de Pelo Animal 111 B.1 Stored Procedure Modelo para Obtenção de Instâncias de Tipo de Entidade Fraca 149 B.2 Stored Procedure Modelo para Obtenção de Instância de Tipo de Entidade Fraca 149 B.3 Stored Procedure Modelo para Inserção de Instância de Tipo de Entidade Fraca 150 B.4 Stored Procedure Modelo para Remoção de Instância de Tipo de Entidade Fraca 150 B.5 Stored Procedure Modelo para Atualização de Instância de Tipo de Entidade Fraca 151 B.6 Stored Procedure Modelo para Obtenção de Instâncias de Atributo Composto 153 B.7 Stored Procedure Modelo para Inserção de Instância de Atributo Composto154 B.8 Stored Procedure Modelo para Remoção de Instância de Atributo Composto154 B.9 Stored Procedure Modelo para Atualização de Instância de Atributo Composto 155 B.10 Stored Procedure Modelo para Obtenção de Instâncias de Atributo Multivalorado 157 B.11 Stored Procedure Modelo para Inserção de Instância de Atributo Multivalorado 157 B.12 Stored Procedure Modelo para Remoção de Instância de Atributo Multivalorado 158 B.13 Stored Procedure Modelo para Atualização de Instância de Atributo Multivalorado 158

18 Introdução CAPÍTULO 1 Sistemas de Informação apoiam a execução de processos de negócio e estão presentes em todos os tipos de organizações. Eles têm importância tanto no nível operacional, automatizando e controlando as atividades organizacionais, quanto no nível estratégico, possibilitando o gerenciamento de riscos e apoiando a tomada de decisões. Este capítulo apresenta a motivação, os objetivos e a metodologia do trabalho de criação de um componente de persistência de dados para um framework que apoia a geração e evolução de Sistemas de Informação. 1.1 Ciclo de Vida de Sistemas de Informação Um Sistema de Informação (SI) envolve diversos elementos, com destaque para: software, bancos de dados, pessoas, documentação, hardware e procedimentos. O software compreende programas de aplicação e software básico. Pessoas gerenciam e operam o sistema. Bancos de dados (BD) são coleções de dados relacionados ao negócio. A documentação abrange textos informativos e manuais de operação de sistema. Os procedimentos definem o comportamento do SI na organização. O hardware envolve computadores e dispositivos para processamento e transmissão de informações. Normalmente o ciclo de vida de um SI envolve três fases [44]: a concepção contempla atividades de análise do sistema, planejamento do projeto e análise de requisitos; a construção inclui atividades de projeto de software, implementação e testes; e a manutenção envolve atividades de correção, adaptação e evolução do sistema. Na fase de concepção são definidas necessidades, capacidades, características ou fatores de qualidade de um sistema. Nesta fase são identificandos os stakeholders (são todos os interessados no resultado de um projeto de software, por exemplo, gerente de negócio, usuários finais e pessoal de apoio), obtendo destes o entendimento a respeito das necessidades para o sistema planejado e suas expectativas com relação a este sistema. Na fase de construção é elaborada e realizada uma estratégia para atender às necessidades e características definidas para o sistema. Uma das atividades desta fase é a codificação, que envolve a tradução do projeto dos componentes de software e de BD para

19 1.1 Ciclo de Vida de Sistemas de Informação 17 linguagens de implementação. Os testes são feitos para garantir que todas as necessidades descritas na fase de concepção foram implementadas e que o sistema funciona de acordo com o que foi previsto pelos stakeholders. Na fase de manutenção são feitas correções, adaptações e inserções de novos requisitos no sistema desenvolvido. Todas as fases anteriores são repetidas para incorporar estas alterações Banco de Dados em SI O componente de bancos de dados possui ciclo de vida em três fases, análogo aos demais componentes do SI. A fase de Análise de Requisitos do SI provê informações para elaborar o projeto conceitual dos bancos de dados. Essas informações incluem, por exemplo, os grupos de usuários que utilizam certas funcionalidades da aplicação (visões), o fluxo de informação do sistema (determinando os serviços providos pelo sistema de bancos de dados) e as prioridades de usuários em relação a estes serviços. Erros nesta fase levam ao retrabalho e ao aumento do custo de desenvolvimento [69]. O projeto conceitual de banco de dados pode ser dividido em duas etapas: Projeto Conceitual do Esquema do BD e Projeto das Aplicações do BD. De acordo com os requisitos identificados na análise é criado um esquema conceitual do Banco de Dados. Este esquema é constituído de elementos e seus relacionamentos, de acordo com o domínio do conhecimento que está sendo modelado. Assim, o modelo conceitual de BD é uma descrição, em alto nível, de uma porção do domínio de negócio, de forma independente de Sistema Gerenciador de Bancos de Dados (SGBD). Esta descrição utiliza, em geral, linguagens de modelagem conceitual como Entity-Relationship Model (ERM) [16], Unified Modeling Language (UML) [48] e Object-Role Modeling (ORM) [33]. O projeto de aplicações identifica as aplicações necessárias para manipular os dados definidos na modelagem conceitual. Essas aplicações envolvem, em geral, operações básicas para manipulação das entidades do domínio do negócio. Tais operações são conhecidas como operações CRUD (Criar, Ler, Atualizar e Remover - Create, Read, Update e Delete). Operações mais complexas podem ser definidas, tanto para modificação quanto para recuperação de informações armazenadas no banco de dados. Uma atividade necessária para construção de bancos de dados é a escolha do SGBD. Alguns aspectos que precisam ser levados em conta nesta escolha incluem: fatores econômicos, como o custo da aquisição do SGBD, treinamento da equipe de desenvolvimento, suporte técnico e manutenção; e fatores técnicos, como o tipo de SGBD (Semi-Estruturado, Relacional, Orientado a Objeto), ferramentas para desenvolvimento, linguagens de consulta de alto nível, entre outros.

20 1.2 Motivação e Objetivos do Trabalho 18 Depois da escolha do SGBD é feito o mapeamento do esquema conceitual, que é independente de tecnologia, para o modelo operacional do SGBD. Esta etapa tem como produto o mapeamento do esquema conceitual do BD para a linguagem de definição de dados (DDL - Data Definition Language) do SGBD alvo. Aspectos de processamento mais específicos, como taxa de processamento, tempo de resposta em transações e espaço de armazenamento, são considerados no projeto operacional do banco de dados. Depois de implementado o esquema do BD no SGBD, o banco de dados é populado e as transações de manipulação de dados são criadas utilizando a linguagem de manipulação de dados (DML - Data Manipulation Language) do SGBD. A medida que o SI é utilizado são identificadas necessidades de manutenção do banco de dados devido a fatores como mudança de requisitos, falta de eficiência das operações do banco de dados ou mudança de SGBD. A geração e a evolução de esquemas de BD consomem uma grande parte do esforço alocado para o desenvolvimento do SI. A manutenção de bancos de dados é particularmente complexa, pois ela tem potencial para impactar um grande número de programas e regras de negócio em um Sistema de Informação. 1.2 Motivação e Objetivos do Trabalho De acordo com [6, 30], o processo de desenvolvimento de software pode ser formalizado em um conjunto de tranformações que levam à produção eficiente de software. Um dos desafios da Engenharia de Software é a especificação de transformações formais de informações obtidas no projeto de software em programas, e a construção de ferramentas que apoiam estas transformações. Estas definições podem ser estendidas para o desenvolvimento de bancos de dados em SI. No processo de criação do esquema do banco de dados de um SI são definidas transformações do modelo conceitual para o modelo operacional do SGBD, e deste para o modelo físico, de acordo com a plataforma computacional. Transformações também são definidas para modificações do esquema conceitual que levam a um conjunto de operações nos esquemas operacionais e físicos. Tais transformações devem ser regidas por regras que preservam a consistência dos dados armazenados no esquema modificado. Este trabalho tem como foco a definição de uma abordagem que apoie o ciclo de vida de bancos de dados em SI. Tendo em vista a complexidade de criação de ferramentas de BD que implementem estas tranformações de forma integrada com os demais componentes de SI, este trabalho especifica necessidades e propõe uma solução para geração e evolução de BD em SI.

21 1.3 Metodologia da Pesquisa Desenvolvida 19 Para isso o trabalho descreve o desenvolvimento de um componente de persistência de dados para um framework que gera, evolui e mantém SI. Este componente é denominado Especialista em Banco de Dados (EBD). A abordagem proposta utiliza o Desenvolvimento Dirigido por Modelo (MDD) [31] para criação e evolução de esquemas de BD, e de operações CRUD que manipulam informações do SI. Além disso, o componente oferece serviços: para acesso a dados e para manipulação de metadados do SI. 1.3 Metodologia da Pesquisa Desenvolvida A primeira fase deste projeto incluiu atividades de pesquisa bibliográfica sobre a abordagem MDD e a análise de ferramentas baseadas nesta abordagem. O objetivo foi identificar requisitos necessários para o desenvolvimento deste projeto. Ferramentas de Bancos de Dados e frameworks para mapeamento objeto relacional (ORM) foram analisadas com intuito de verificar os benefícios e limitações de cada uma delas. Após a definição de requisitos, foi feito o projeto e a implementação dos mecanismos de geração, evolução de esquema e serviços de persistência de conceitos do SI. Em seguida foram feitos testes e integração com os demais componentes do framework de suporte à construção de SI. O esquema de um SI de grande porte foi gerado utilizando a arquitetura desenvolvida neste trabalho, com o propósito de avaliar empiricamente as propostas. Na última fase deste projeto foram feitos experimentos para validação da abordagem proposta. Estes experimentos contaram com a participação de desenvolvedores de SI para criar um esquema de BD com base na ferramenta implementada neste projeto. 1.4 Organização do Trabalho O Capítulo 2 analisa os conceitos de MDD e sua aplicação no desenvolvimento e evolução de esquemas de BD. O capítulo também compara a abordagem proposta neste trabalho com as ferramentas encontradas na primeira fase da pesquisa. O Capítulo 3 apresenta a arquitetura do componente proposto no contexto do framework para geração e evolução de SI, descrevendo o metamodelo utilizado na representação de dados de SI. O Capítulo 4 descreve um conjunto de padrões de mapeamento do metamodelo adotado para o MR, e deste para um dialeto específico de SQL, para geração e evolução de esquemas de BD de SI. O SGBD PostgreSQL [53] e sua linguagem procedural (PL/pgSQL) são utilizados nestes mapeamentos.

22 1.4 Organização do Trabalho 20 O Capítulo 5 discute a criação e utilização de SI com base na proposta deste trabalho. Além disso, o capítulo apresenta exemplos reais de utilização da arquitetura implementada para geração de esquema em um SI para o Agronegócio. O Capítulo 6 discute a aplicação de mapeamentos na evolução de esquema propostos neste trabalho. Também são apresentados exemplos reais de evolução de esquema em um SI para o Agronegócio. O Capítulo 7 discute a validação empírica da proposta deste trabalho. Para isto, o capítulo analisa a metodologia e os dados coletados em um experimento de utilização do componente. O Capítulo 8 apresenta as considerações finais deste trabalho de pesquisa, propondo extensões e direções para trabalhos futuros.

23 Desenvolvimento Dirigido por Modelo em Bancos de Dados CAPÍTULO 2 O Desenvolvimento Dirigido por Modelo (Model-Driven Development - MDD) é uma das propostas recentes que têm obtido resultados significativos para diminuir a dificuldade na manutenção de SI [31]. Esta abordagem especifica conceitos relevantes do domínio da aplicação, incluindo regras de negócio, relacionamentos e semântica de dados, usando linguagens de modelagem de alto nível e independentes de plataforma, para representar o sistema a ser criado. Este capítulo discute os desafios e soluções da abordagem MDD aplicada a BD. Ele também apresenta uma comparação entre ferramentas que utilizam esta abordagem e o componente proposto neste trabalho. 2.1 Desafios e Soluções da Abordagem MDD Tradicionalmente, as equipes de desenvolvimento e manutenção de software compartilham os seguintes desafios [43, 45]: 1. Documentação Inconsistente - O processo de desenvolvimento de software produz grande quantidade de documentação. Esta documentação rapidamente perde seu valor, pois ao invés de ser uma exata especificação do código, os diagramas geralmente tornam-se apenas figuras relacionadas ao código. Isso acontece porque geralmente as modificações são feitas apenas no código fonte, já que atualizar toda a documentação exige tempo que na maioria das vezes não está disponível. 2. Mudanças Frequentes de Tecnologia - Novas tecnologias aparecem de forma muito rápida. Empresas que dependem destas tecnologias devem mudar antes que ela fique obsoleta. 3. Interoperabilidade - Os sistemas não podem ser desenvolvidos de maneira isolada. Eles devem ser desenvolvidos como componentes de software que se comunicam com outros sistemas, de forma que a adaptação ou correção do sistema, ou mesmo a inserção de novos requisitos de negócio, se torne mais fácil.

24 2.1 Desafios e Soluções da Abordagem MDD Falta de Compreensão sobre Documentação - A documentação de sistemas geralmente não é boa porque aqueles que estão envolvidos com o desenvolvimento do sistema, principalmente os programadores, estão apenas preocupados com atividades inerentes a codificação, não tendo ideia de que a documentação auxilia em manutenções futuras dos sistema. O MDD permite especificar conceitos relevantes do domínio da aplicação usando linguagens de modelagem de alto nível de abstração. Com estas linguagens são criados modelos do sistema independentemente da plataforma utilizada para a sua implementação. Modelos em UML, por exemplo, são o padrão de fato utilizado pela indústria de software. Esses modelos de alto nível são chamados de PIM (Platform Independent Model - Modelo Independente de Plataforma). A ideia central do MDD é a transformação de modelos em código executável usando processos de tradução automática. Cada processo de tradução executa a transformação de um modelo (ou aspecto) conceitual do sistema para modelos específicos para uma determinada plataforma de implementação (PSM - Plataform Specific Model). Esses modelos específicos são, por sua vez, automaticamente traduzidos para o código que implementa o sistema de informação. Esta ideia é representada na Figura 2.1. Figura 2.1: Transformação entre modelos (Adaptado de [43]) Os modelos PIM, PSM e o código fonte representam diferentes níveis de abstração na especificação de um sistema. A capacidade de transformar um PIM em um PSM aumenta o nível de abstração no qual o desenvolvedor pode trabalhar, facilitando o desenvolvimento de sistemas. Os desenvolvedores que trabalham com modelos independentes de tecnologia possuem menos trabalho a fazer porque os detalhes específicos de plataformas não precisam ser analisados e projetados; eles já são tratados na definição da transformação do modelo independente para o modelo específico. Na transformação do modelo específico para código fonte há muito menos trabalho a ser feito, pois muito código já foi gerado a partir da transformação do modelo de alto nível. Os desenvolvedores gastam menos tempo realizando codificação e utilizam o tempo para se preocuparem com a modelagem do negócio. Dessa forma, o benefício para os usuários finais é grande. No entanto, o ganho de produtividade é alcançado somente com a utilização de ferramentas que realizam a transformação entre os modelos. A utilização do PIM também aumenta a portabilidade do sistema, visto que esse modelo pode ser transformado para vários modelos específicos voltados para plataformas variadas. Caso apareçam novas tecnologias, devem ser desenvolvidas novas definições

25 2.2 Desenvolvimento de Bancos de Dados e MDD 23 de transformações do modelo independente para essas novas tecnologias. No entanto, o modelo independente já existente não necessita sofrer qualquer modificação. Dessa forma, o PIM representa a documentação em mais alto nível de um sistema. Toda modificação que é feita no sistema deve ser primeiramente feita neste modelo. Depois disso, o modelo específico deve ser gerado novamente, assim como o código da aplicação. Logo, a documentação do sistema sempre será consistente com o código atual. Apesar dos benefícios da utilização da abordagem MDD, algumas dificuldades são enfrentadas. A tradução automática provê padronização do código gerado e produtividade, mas existe o problema relacionado à eficiência. Por exemplo, um código gerado por uma ferramenta de geração de esquema pode não ter a mesma eficiência de um código criado por um DBA (Database Administrator - Administrador de Bancos de Dados) experiente. Outra dificuldade está relacionada à criação da ferramenta de transformação. Uma ferramenta para geração de um SI leva em conta aspectos como representação dos dados, regras de negócio e interface com o usuário. Criar ferramentas para automatizar este tipo de tarefa ainda é um desafio para a comunidade científica de computação. 2.2 Desenvolvimento de Bancos de Dados e MDD Embora a abordagem MDD tenha sido proposta para resolver problemas de desenvolvimento e manutenção de software, os seus princípios também podem ser aplicados no contexto de bancos de dados, já que estes são um componente importante de qualquer software [25]. No processo de desenvolvimento de banco de dados são feitas transformações do modelo conceitual para o modelo operacional do SGBD e, em seguida, para o modelo físico da plataforma computacional. A transformação é uma maneira sistemática de mapeamento entre modelos. No processo de desenvolvimento de banco de dados é frequente a utilização deste recurso em várias atividades, tais como normalização de esquema [56], integração de esquemas [10, 9, 46], interoperabilidade de banco de dados [46], engenharia reversa de banco de dados [47, 27, 32, 39], evolução de esquema [35, 24, 65, 66], otimização de esquema [34], e mapeamento Objeto-Relacional [64, 51]. Ao longo do tempo a comunidade científica e a indústria vêm criando ferramentas que suportam o desenvolvimento de SI. Especificamente para bancos de dados podem ser destacadas as seguintes ferramentas: Mapeamento Objeto-Relacional (ORM - Object-Relational Mapping) - A criação de aplicações de banco de dados, na maioria da vezes, é um trabalho entediante devido à grande quantidade de código semelhante e ao trabalho repetitivo executado.

26 2.2 Desenvolvimento de Bancos de Dados e MDD 24 Em consequência disso, tem-se alto risco de erros na aplicação desenvolvida. Uma das soluções para estes problemas são as ferramentas ORM que têm por objetivo a simplificação da criação do componente de acesso a dados. Ferramentas ORM estabelecem uma ligação bidirecional entre os dados no banco de dados relacional e os objetos no código de aplicações orientadas a objetos. Ambientes de Desenvolvimento Integrado (IDE - Integrated Development Environment) - são ferramentas utilizadas por desenvolvedores e administradores de BD, como por exemplo a ferramenta BrModelo [17]. Elas possuem uma grande variedade de funcionalidades, tais como: geração do esquema de banco de dados a partir do modelo conceitual, modelagem conceitual, criação de instruções de manipulação de dados, engenharia reversa, sincronização entre modelo operacional e esquema físico, tuning de consultas e estatísticas do custo de execução de instrução ou script. Existe uma variedade de frameworks ORM. Eles são mais populares para a linguagem Java [41, 1, 28, 3, 26, 67, 42, 2, 5], mas existem frameworks para outras linguagens, como.net [41, 60, 59, 63]. Recursos mais sofisticados, como importação de modelos, geração de scripts, suporte a vários SGBDs, e criação de modelos com diferentes níveis de abstração (conceitual, lógico e físico), são encontrados em diversas ferramentas [20, 4, 29, 36, 62, 54, 15, 57]. Estas ferramentas utilizam informações de modelos independentes de plataforma para automatizar operações como geração e evolução do esquema e operações de mapeamento de objetos para tabelas no banco de dados. Nos frameworks ORM para Java as meta-informações são armazenadas de diversas formas: em arquivos XML [1, 41, 28, 3, 26, 67, 42, 2, 5]; em annotations [41, 67, 5]; ou em instruções de JavaDoc, chamadas XDoclets [2]. Alguns IDEs utilizam o banco de dados como meio de armazenamento das metainformações, como descrito em [29]. A maioria deles, no entanto, armazena as metainformações em formato proprietário e faz a geração e evolução do esquema de banco de dados indiretamente, usando scripts, ou diretamente, usando conexões do tipo ODBC ou JDBC. O framework proposto nesta dissertação e os IDEs compartilham várias funcionalidades, como geração de esquema e suporte a evolução, mas existe uma diferença básica. O framework participa do fluxo de processamento de informações na execução do SI, diferentemente dos IDEs, que são utilizados na fase de construção ou manutenção do SI.

27 2.3 Comparação de Ferramentas MDD para BD Comparação de Ferramentas MDD para BD Os frameworks ORM utilizam informações de um modelo conceitual independente de plataforma para fazer os mapeamentos necessários para criação, evolução e utilização do esquema de BD de uma aplicação. Os frameworks armazenam estas informações em arquivos externos ou no código da aplicação. Os frameworks Hibernate, Abra, Castor, Cayenne, Databind, OR Broker, OJB e Ebean apresentados respectivamente em [41, 1, 28, 3, 26, 42, 2, 5] utilizam arquivos XML para armazenamento externo das informações utilizadas no mapeamento. O framework DB Visual Architect [67] armazena o modelo conceitual em arquivos criados pela própria ferramenta. Em Java, os frameworks Hibernate e Ebean utilizam annotations [40]. Os frameworks Hibernate e OJB utilizam XDoclet [68] para armazenar as meta informações diretamente no código. No componente EBD, proposto neste trabalho, o modelo conceitual do SI é armazenado no próprio BD. As vantagens desta abordagem estão diretamente relacionadas às vantagens de utilizar SGBD para armazenamento de informações: segurança, suporte a alto volume de uso e acesso restrito às informações armazenadas. Mapeamentos em arquivos externos possuem a desvantagem de manipulação de vários arquivos onde estão as informações das entidades do sistema e problemas em relação ao entendimento da sintaxe utilizada para armazenar tais informações. Estes problemas não são encontrados no mapeamento direto no código da aplicação, mas outros problemas são observados. O código da aplicação pode ficar dependente do mapeamento específico de um certo framework e mudanças no BD levam a mudanças no código da aplicação, ferindo o princípio de independência de dados. Os frameworks Cayenne e DB Visual Architect fornecem editores gráficos para obtenção das informações das entidades do SI. A inferface gráfica facilita o trabalho de criação dos arquivos externos, pois os usuários da ferramenta não se preocupam com a sintaxe da linguagem utilizada para armazenar as meta informações. O EBD fornece formulários de cadastro para facilitar o processo de obtenção das informações de representação das entidades do SI. É comum entre os principais frameworks ORM usar as informações do modelo conceitual para geração do esquema do banco de dados. Em alguns deles o esquema não é gerado automaticamente, como pode ser observado nos frameworks Databind e OR Broker. Mesmo assim é necessária a criação do arquivo de mapeamento, pois este é usado na execução do framework. O EBD utiliza os conceitos MDD para geração automática do esquema do BD do SI. Além do esquema, alguns frameworks geram instruções SQL dinâmicas para manipulação das instâncias das entidades persistentes. Para tornar a manipulação eficiente, os

28 2.3 Comparação de Ferramentas MDD para BD 26 frameworks Hibernate, Castor, DB Visual Architect, OR Broker, OJB e Ebean permitem a manipulação de instâncias via procedimentos armazenados (stored procedures). Dentre estes, somente os frameworks DB Visual Architect e Ebean geram automaticamente estes procedimentos. No EBD a manipulação das instâncias de entidade é feita através de um conjunto de stored procedures geradas a partir do modelo conceitual de SI. Para permitir a modelagem de sistemas complexos, o modelo conceitual dos frameworks deve permitir construções de hierarquias de especialização, tipos de relacionamentos e coleções de tipos de dados (inteiros, string, datas, entre outros). A modelagem de hierarquia de especialização é permitida nos frameworks Hibernate, Abra, Cayenne, DB Visual Architect, OR Broker, OJB e Ebean. Os frameworks Hibernate e OJB permitem a escolha do tipo de mapeamento para hierarquia de especialização. Por exemplo, o usuário pode optar por mapear todos os atributos de super classes e sub classes para uma mesma tabela. Outra opção disponível é mapear cada classe da hierarquia para uma tabela distinta. O EBD permite a modelagem e geração de hierarquia de especialização, mas o mapeamento é restrito: cada classe da hierarquia é mapeada para uma tabela. Este mapeamento é discutido em detalhes no Capítulo 4. Assim como os frameworks Hibernate, Castor, Abra, Cayenne, DB Visual Architect, OR Broker, OJB e Ebean, o EBD permite mapeamentos de tipos de relacionamento com cardinalidade 1:1, 1:N e N:M. No EBD, os tipos de relacionamentos são manipulados através de um conjunto de stored procedures. Já nos frameworkshibernate, Abra e OJB a manipulação é feita através de SQL dinâmico. O EBD permite a manipulação de coleções de strings, inteiros, decimais e datas. Os frameworks Hibernate, Abra, Castor, Cayenne, OR Broker e OJB também permitem a manipulação de coleções destes tipos. Além de gerar automaticamente o esquema do BD da aplicação, os frameworks Hibernate, Cayenne e DB Visual Architect disponibilizam mecanismos para evolução de esquema. Mudanças feitas no modelo conceitual são propagadas para o modelo físico e para os dados do sistema. O EBD também conta com um mecanismo que analisa e propaga as mudanças feitas no esquema conceitual do SI para o modelo físico e para os dados correspondentes. Assim, o componente EBD conta com os recursos típicos dos frameworks ORM encontrados no mercado, mas não oferece algumas funcionalidades específicas. Por exemplo, o framework DB Visual Architect conta com funcionalidades para geração de relatórios, análise de impacto de mudanças no BD e suporte às ferramentas de controle de versão. Os frameworks Hibernate, Ebean, Cayenne e Abra permitem a criação de consultas e gerenciamento de transação. Essas funções fogem do escopo funcional do EBD. A entrada das meta informações da entidade, no EBD, é feita por formulário

29 2.3 Comparação de Ferramentas MDD para BD 27 textual, mas teria melhor usabilidade se a criação do esquema fosse feita a partir de um editor gráfico. Tais funcionalidades são importantes, mas não foram implementadas no componente EBD devido à limitação do tempo para desenvolvimento deste trabalho. Além de possuir funcionalidades semelhantes às dos frameworks discutidos nesta seção, o componente EBD possui um diferencial que é a integração com um framework maior, que gera o SI propriamente dito, e não apenas o esquema do BD [21]. O Capítulo 3 sintetiza as principais características deste framework e discute os detalhes da arquitetura do componente EBD. A Tabela 2.1 apresenta uma comparação entre frameworks ORM para a linguagem Java e o componente EBD, proposto neste trabalho. Os critérios de comparação entre os frameworks são: (a) Suporte a Herança - define se o framework permite a criação de cadeia de especilização, (b) Tipos de Relacionamento - permite relacionamentos entre as entidade definidas no framework, (c) Interface Gráfica para coleta das informações conceituais, (d) Gera Esquema automaticamente, (e) Propaga Mudanças - estabelece se o framework faz a propagação das mudanças realizadas no modelo conceitual, (f) Suporte a Stored Procedure - estabelece se o framework suporta a manipulação do dados de entidade via procedimentos armazenados, (g) Suporte a Coleções - estabelece se o framework permite a manipulação de coleções de strings, inteiros, números de ponto flutuante, datas, etc e (h) Ferramenta Livre - define se a ferramenta é livre ou não. Tais critérios foram obtidos durante a pesquisa das ferramentas ORM que utilizam a abordagem MDD. As características mais importantes de cada ferramenta foram definidas, logo após estas informações foram confrontadas obtendo um conjunto de características comuns e algumas específicas. Dentre estas características, as mais relaventes deram origem aos critérios de comparação. Este capítulo discutiu os desafios e soluções da abordagem MDD aplicada a BD e apresentou uma comparação entre ferramentas que utilizam esta abordagem e o componente proposto neste trabalho.

30 2.3 Comparação de Ferramentas MDD para BD 28 Suporte a Tipos de Tipo de Oferece GUI para Gera Propaga Suporta Suporta Ferramenta Livre? Herança Relacionamento Mapeamento Mapeamento Esquema Mudanças Stored Coleções Procedure Hibernate SIM SIM Annotations NÃO SIM SIM SIM SIM SIM [41] XML e XDoclet Abra SIM SIM XML NÃO SIM NÃO SIM SIM [1] Castor NÃO SIM XML NÃO SIM SIM SIM SIM [28] Cayenne SIM SIM XML SIM SIM SIM NÃO SIM SIM 3.0 [3] Databind NÃO XML NÃO NÃO NÃO NÃO NÃO SIM 0.4 [26] DVA SIM SIM Arquivo SIM SIM SIM SIM NÃO 5.2 [67] próprio OR Broker SIM SIM XML NÃO NÃO SIM SIM SIM [42] OJB SIM SIM XML e NÃO SIM SIM SIM SIM [2] XDoclet Ebean SIM SIM Annotations NÃO SIM NÃO SIM SIM ORM [5] e XML EBD SIM SIM BD SIM SIM SIM SIM SIM SIM 1.0 Legenda: : Informação não encontrada nas referências sobre a ferramenta Tabela 2.1: Tabela de Comparação de Ferramentas ORM

31 CAPÍTULO 3 Arquitetura do Componente EBD - Especialista em Banco de Dados Uma arquitetura de software descreve uma organização de componentes, os seus relacionamentos com o ambiente e as regras que definem o seu projeto e evolução [38]. Este capítulo sintetiza as principais características arquiteturais do framework para geração e evolução de SI (Seção 3.1), detalhando o modelo de representação de dados do SI (Seção 3.2) e analisando a arquitetura do componente de persistência EBD (Seção 3.3). 3.1 Arquitetura do Framework O componente EBD é um componente funcional de uma arquitetura maior que não faz parte das propostas deste trabalho. Esta arquitetura apresenta um framework, inspirado na abordagem MDD, que foi construído para geração e manutenção automática de Sistemas de Informação usando modelos conceituais como entrada. Os componentes de SI gerados pelo framework incluem: a) software de aplicação e interface com o usuário; b) esquemas e restrições de integridade de bancos de dados; e c) regras de negócio que podem ser disparadas a partir de eventos de bancos de dados ou de funções de aplicação. A arquitetura funcional do framework é ilustrada na Figura 3.1. Três módulos - Regras, Interface e Persistência - possuem processos e ferramentas de transformação que mapeiam alguns aspectos dos modelos conceituais para os modelos específicos de plataforma, gerando o código fonte correspondente. O módulo Metadados constitui a base para o mecanismo MDD do framework. Ele provê informações para todos os outros módulos, sendo responsável por gerenciar o modelo conceitual de cada SI. Este modelo conceitual contém os metadados usados pelos demais módulos para construir e gerenciar os códigos fonte do SI (aplicação, regras de negócio e banco de dados). O módulo Interface usa o modelo conceitual do SI (ou seja, os metadados que descrevem conceitualmente o SI) para gerar a interface de usuário para aplicações do

32 3.1 Arquitetura do Framework 30 Figura 3.1: Arquitetura Funcional do Framework (adaptada de [21]) SI. A geração é feita automaticamente, segundo os princípios de MDD, a partir de um esquema de mapeamento dos metadados do SI para metadados de interface (chamados de metadados de apresentação). Este mapeamento descreve, entre outros aspectos, como apresentar cada conceito de negócio em uma interface padrão baseada nos conceitos WIMP (Window, Icon, Menu, Pointer) [18, 19]. O módulo Interface Aplicação serve como adaptador entre os módulos Interface e Aplicação. Seu objetivo principal é repassar mensagens da interface para a aplicação e

33 3.2 Modelo de Representação de Dados de SI - MMO 31 preparar dados vindos da camada de aplicação para serem enviados para a interface. A responsabilidade do módulo Aplicação é realizar as operações das aplicações do SI (incluindo operações CRUD), com o apoio dos módulos Persistência e Negócio. Operações como inserir, alterar, remover, desativar e obter dados relacionados às entidades da aplicação são executadas pelo módulo Aplicação. O módulo Negócio verifica se os dados vindos das camadas superiores estão de acordo com as regras pré-estabelecidas (regras de negócio). Ele executa o controle para que informações inseridas no Banco de Dados sejam válidas para o negócio subjacente ao SI. Através das informações obtidas nos metadados, são tratados aspectos como cardinalidade máxima e mínima dos dados, tipos de dados, valores máximos e mínimos, regras de composição, dentre outras restrições de integridade. O módulo Regras é responsável pelo controle centralizado do repositório de regras de negócio do SI. Essa é uma característica diferencial do framework, pois trata as Regras de Negócio como um aspecto independente dos demais aspectos (dados e funções) [12, 13]. Este módulo traduz as definições de regras do modelo conceitual (definidas na linguagem OCL) para código na linguagem específica da plataforma de implementação e provê, em tempo de execução, facilidades para avaliação e execução destas regras quando disparadas por eventos de BD ou de aplicação. O módulo Persistência gerencia o mapeamento do modelo conceitual do SI para o esquema operacional de banco de dados em um SGBD (e vice-versa). O módulo também gerencia a evolução dos esquemas de bancos de dados de acordo com as mudanças feitas nos metadados conceituais do SI. Este módulo gerencia, ainda, todo o acesso aos dados persistentes do SI, isolando os demais módulos do framework de mudanças na tecnologia de bancos de dados, ou seja, provendo independência de dados para as aplicações construídas com o framework. O presente trabalho descreve o projeto e a implementação do módulo Persistência do framework. Informações detalhadas sobre o framework e seus outros componentes podem ser obtidos em [21, 13, 12, 19, 18]. 3.2 Modelo de Representação de Dados de SI - MMO Para representar os aspectos estruturais do domínio de um SI (tais como conceitos de negócio, instâncias desses conceitos, e relações e restrições sobre essas instâncias), o framework utiliza uma variante orientada a objetos do Modelo Entidade Relacionamento (MER) chamada de Modelo de Meta Objetos (MMO) [22]. Ele é um DSL (Domain Specific Language - Linguagem Específica de Domínio) que específica também aspectos de Interface Homem Computador (IHC) e de Regras de Negócio. A Figura 3.2 apresenta os principais conceitos de representação de dados deste metamodelo. Os con-

34 3.2 Modelo de Representação de Dados de SI - MMO 32 ceitos relacionados aos outros aspectos (IHC e Regras de Negócio) da DSL MMO foram omitidos pois não fazem parte do escopo deste trabalho. Figura 3.2: Metamodelo para representação conceitual de SI - Modelo de Meta-Objetos (MMO) [22] Usando estes elementos de modelagem é possível representar os conceitos de um SI corporativo, independentemente da plataforma de implementação escolhida. Dessa forma, somente detalhes do domínio de negócio aparecem no foco do projetista do SI. Com o MMO é possível representar tipos de entidade, aquelas que possuem indentificação própria (Entidade Forte) e aquelas que possuem dependência de outra entidade para indentificar suas instâncias (Entidade Fraca). Além disso, é possível modelar hierarquias de especialização de entidades, através do auto-relacionamento "especializada em". Para caracterizar um tipo de entidade o MMO disponibiliza os tipos de atributos simples e composto. Estes tipos podem ser especializados em tipos mais específicos,

35 3.2 Modelo de Representação de Dados de SI - MMO 33 conforme discute a Seção Tipos de Atributo no MMO O meta objeto Atributo tem como objetivo reunir informações e funcionalidades comuns a todos os tipos de Atributos especializados do MMO. São características comuns a todos os atributos: Mnemônico: representa o identificador do atributo. O mnemônico é case sensitive e único dentro de todo o SI. Tipo de Atributo: define o tipo de atributo descrito. O valor dessa propriedade de Atributo pode ser: BASICO: indica que é um atributo simples, com um domínio discreto de valores definitos pelo sistema. ENUMERADO: indica que é um atributo simples, com um domínio discreto de valores definidos pelo usuário. OBJETO EXTERNO: indica que o atributo é do tipo multimídia e possui dependência de aplicações externas para ser editado (por exemplo, fotos, vídeos e planilhas). OBJETO INTERNO: representa um relacionamento entre duas entidades do SI. Tipos de relacionamento são representados, no MMO, pelo atributo do tipo objeto interno. Por exemplo, o atributo gerencia da entidade funcionário pode indicar um relacionamento entre as entidades funcionário e departamento. COMPOSTO: indica que o atributo é composto por outros atributos. Por exemplo, o atributo telefone pode ser composto pelos atributos ddd e número. Tipo de Domínio: refere-se ao tipo de valor que o atributo simples básico armazena. São tipos de domínio válidos no MMO: inteiro, decimal, alfanumérico, booleano e data. Cardinalidade Mínima e Máxima: define a cardinalidade do atributo, ou seja, qual o número mínimo e máximo de valores que o atributo pode ter. É Parte de Chave: indica que o atributo faz parte da chave lógica da entidade. É Único: determina que o valor do atributo não pode ser repetido em diferentes instâncias de um tipo de entidade. Desta forma, não poderá haver dois valores iguais no BD. É Atributo de Ligação: é uma informação que ajuda a identificar, no contexto do negócio, a instância da entidade referenciada por um atributo do tipo objeto interno. Dada a entidade B com os atributos atrib1, atrib2 e atrib3, simples monovalorados, e a entidade A com o atribr do tipo objeto interno, se os atributos atrib1 e atrib2 são definidos como atributos de ligação da entidade B, em uma consulta de instâncias

36 3.2 Modelo de Representação de Dados de SI - MMO 34 de atribr os atributos de B que aparecem nesta consulta são os atributos de ligação atrib1 e atrib2. Por exemplo, se a entidade funcionário possui os atributos nome e cpf, e estes são definidos como atributos de ligação desta entidade, e se a entidade departamento possui o atributo gerente, do tipo objeto interno, indicando o relacionamento com a entidade funcionário, uma consulta para obter todos os gerentes do departamento apresentará os atributos nome e cpf. O Atributo Simples Básico representa um dado atômico dentro da entidade da qual ele faz parte. Ou seja, essa informação não pode ser dividida em partes menores com semântica própria. O Atributo Simples contém as seguintes características: Tamanho: é a característica que limita o número máximo de caracteres que o Atributo Simples pode conter. Menor e Maior Valor: caso o Atributo Simples seja do Tipo de Domínio numérico, esta característica determina os valores mínimo e máximo permitidos para este atributo. O Atributo Simples Enumerado descreve dados oriundos de um conjunto de valores definidos pelo usuário, isto é, uma enumeração de valores discretos. Um exemplo de enumeração é o conjunto de valores {masculino, feminino} para o atributo sexo. O Atributo Simples Enumerado possui as seguintes características: Domínio Enumerado: define o nome do conjunto onde estão determinados os valores discretos possíveis para o atributo. Dados Enumerados: esta característica armazena os valores do domínio enumerado. O Atributo Objeto Externo contém informações de entidades externas ao sistema. O Atributo Objeto Externo possui as seguintes características: Extensão: descreve a extensão do objeto externo. Por exemplo,.gif e wma. Aplicativo: indica qual é o aplicativo que executa o objeto externo. Plataforma: indica qual é a plataforma necessária para o objeto externo. O Atributo Composto é formado por um ou mais atributos que podem ser simples ou compostos. Desta forma, é possível representar objetos complexos, que são compostos por outros objetos também complexos. O Atributo Composto possui as seguintes características: Subatributos: referencia o conjunto de atributos que compõem o Atributo Composto.

37 3.3 Arquitetura dos Componentes de Transformação 35 Um tipo notável de Atributo Composto é o Atributo Objeto Interno. Um objeto interno é aquele que referencia alguma entidade do SI. Dessa forma, é possível esbelecer relacionamentos entre entidades do sistema. A denominação objeto interno decorre do fato de a entidade referenciada estar armazenada no próprio BD do SI. Além das características herdadas de Atributo Composto, o Atributo Composto Objeto Interno contém as seguintes: Entidade Referenciada: contém o mnemônico da entidade que o Atributo Composto Objeto Interno referencia. Por exemplo, o relacionamento gerencia entre as entidades funcionário e departamento poderia ser definido por um atributo objeto interno gerente, que pertence à entidade departamento e armazena o mnemônico funcionário no campo Entidade Referenciada. Atributo Referenciado: contém o mnemônico de um Atributo Objeto Interno pertencente à entidade de referência. Desta forma, o modelo permite representar relacionamentos entre relacionamentos. Por exemplo, em uma empresa uma manutenção é requesitada somente por aquele funcionário que é gerente. O atributo objeto interno gerente determina o relacionamento entre as entidades departamento e funcionário. Por sua vez, a entidade manutenção possui o atributo objeto interno requesitada por, que possui no campo Atributo Referenciado o mnemônico do atributo gerente, definindo o relacionamento entre a entidade manutenção e o relacionamento gerente da entidade departamento. No campo entidade referenciada do objeto interno "requisitada por"contém a qual o objeto interno gerente pertence, neste caso, a entidade departamento. 3.3 Arquitetura dos Componentes de Transformação Os mecanismos de transformação para geração e evolução de esquemas e mapeamento objeto-relacional envolvem os módulos Negócio e Persistência, mostrados na arquitetura de alto nível da Figura 3.1. A seguir, são apresentados os serviços do componente EBD para acesso a dados, geração de esquema, evolução de esquema e de metadados e dados de entidade Serviços de Acesso a Dados O pacote Serviços de Acesso a Dados contém os serviços para mapeamento de instâncias de entidades do MMO para o BD e vice versa. O framework disponibiliza as operações de inserção, remoção, atualização e obtenção de instâncias de entidades do SI.

38 3.3 Arquitetura dos Componentes de Transformação 36 Estas operações contam com um conjunto de stored procedures geradas para manipulação de instâncias de entidades. Em Java, a classe CallableStatement do pacote java.sql é utilizada para manipulação de informações do BD através de stored procedures. A preparação de chamada de stored procedure é feita em duas etapas. Primeiramente, a stored procedure que será chamada é registrada no objeto da classe CallableStatement através de uma string que contém o nome da stored procedure e a quantidade de parâmetros que serão passados. Logo após, são registrados os valores dos parâmetros no objeto CallableStatement. A string tem o formato?= call <nome-procedure>(?,?,?,...). O componente EBD nomeia as stored procedures levando em conta o tipo da operação (inserir, desativar, obter e atualizar) e o mnemônico do tipo de entidade ou atributo. Por exemplo, supondo que o mnemônico do tipo de entidade pessoa física seja PesFis, o nome da stored procedure de inserção é inserirpesfis. A quantidade de pontos de interrogação (?) na string definem a quantidade de parâmetros da stored procedure. No EBD, esta string é criada em tempo de execução e a quantidade de parâmetros é obtida a partir da contagem de atributos simples monovalorados do tipo de entidade, do atributo composto ou do objeto interno. O pacote Serviços de Acesso a Dados disponibiliza também serviços de controle de transação (abertura, commit e rollback) e serviços de acesso ao BD utilizados pelo componente Regra do framework Serviços de Geração de Esquema O pacote Serviços de Geração de Esquema (Figura 3.3) contém todos os serviços para geração do esquema SQL e das stored procedures no SGBD utilizado na implementação do SI. O pacote BibliotecaBD é um pacote externo ao Serviços de Geração de Esquema. Ele possui informações e algoritmos de mapeamento para o processo de transformação do modelo conceitual do SI, especificado de acordo com o MMO, para o modelo relacional, e deste para o dialeto SQL alvo. O pacote Gerador DDL oferece os serviços de mapeamento para geração do esquema do banco de dados do SI. A manipulação dos dados do esquema gerado pelo pacote Gerador DDL é feita por um conjunto de stored procedures para operações CRUD geradas pelo pacote Gerador DML. No processo de mapeamento para geração do esquema e de instruções de manipulação de dados do SI são necessários serviços para obtenção de listas de atributos. Por exemplo, para criar uma relação, no mapeamento do MMO para o modelo relacional, é necessário obter uma lista dos mnemônicos dos atributos do tipo de entidade do MMO.

39 3.3 Arquitetura dos Componentes de Transformação 37 Figura 3.3: Arquitetura do Componente de Geração de Esquema O pacote Serviços de Geração de Esquema disponibiliza serviços para: geração de DDL para entidade, atributo composto, atributo objeto interno e atributo simples multivalorado, e geração de stored procedures de consulta, inserção, remoção e obtenção para entidade, atributo composto, atributo objeto interno e atributo simples multivalorado Serviços de Evolução de Esquema O Serviço de Evolução de Esquema trata todo o processo de evolução do esquema e dos dados contidos em um SI quando o modelo conceitual do SI é alterado. A Figura 3.4 mostra este pacote. No componente EBD modificações permitidas no MMO são propagadas para o esquema e, consequentemente, para os dados do SI. O pacote AvaliadorMudança possui os serviços necessários para avaliação das propagações do modelo conceitual (MMO) para o esquema do BD. Por exemplo, uma mudança de tamanho de um atributo

40 3.3 Arquitetura dos Componentes de Transformação 38 Figura 3.4: Arquitetura do Componente de Evolução de Esquema alfanumérico pode ser aplicada se todos os valores daquele atributo no BD forem menores ou iguais ao novo tamanho. As mudanças na chave lógica de uma entidade ou atributo composto, tais como inclusão ou remoção de atributos são executadas no pacote Chave Lógica. Outros tipos de mudanças tratados neste pacote são transformações entre os tipos de entidade e nas hierarquias de especialização. Os serviços para propagação de mudanças de unicidade de um atributo são tratadas no pacote Unicidade. O pacote Domínio possui os serviços para mapeamento da propagação das alterações de domínio de atributos do MMO. As propagações de mudanças em relação a cardinalidades mínima e máxima dos atributos são tratadas no pacote Cardinalidade. A propagação da modificação de tamanho de atributo alfanumérico é tratada pelo pacote Tamanho. O pacote Composição possui os serviços para propagação de mudanças relacionadas aos atributos do domínio composto. Um atributo composto pode ser modificado com adição ou remoção de um atributo, por exemplo.

41 3.3 Arquitetura dos Componentes de Transformação 39 A propagação de mudança de mnemônico de entidade e atributo é tratada pelos serviços do pacote Mnemônico. O pacote Serviços de Evolução de Esquema disponibiliza, em suma, serviços para: criação e remoção de: atributo em entidade, atributo composto, atributo objeto interno, atributo simples multivalorado. mudança de: domínio de atributo e de restrição de unicidade de atributo. transferência de atributo da entidade para um atributo composto ou atributo objeto interno. mudança do mnemônico de entidade ou de atributo. criação e remoção de stored procedures de consulta, inserção, remoção e obtenção para entidade, atributo composto, atributo objeto interno e atributo simples multivalorado Serviço de Metadados e Dados de Entidade Para permitir o tráfego de metadados e dados de um tipo de entidade pelo sistema foram definidas as classes Metadados e ObjetoApresentacao. A classe Metadados (Figura 3.5) do pacote Serviço de Metadados e Dados possui um vetor de atributos que armazena as características de uma instância de tipo de entidade. Metadados disponibiliza serviços para obtenção: do número de atributos dos Metadados. Este serviço retorna a quantidade de atributos que a entidade possui. Por exemplo, se a entidade Pessoa Física possui os atributos nome, cpf e endereço, o retorno deste serviço é o valor inteiro 3. de um atributo a partir de um índice. Este serviço retorna um atributo a partir de seu índice recebido como entrada. No exemplo anterior, o índice 2 retorna o atributo cpf. de um objeto Atributo a partir do mnemônico do Atributo. Dado o mnemônico, este serviço retorna a instância de atributo correspondente. do índice do atributo nos Metadados. Este serviço retorna o índice do atributo dentro dos metadados da entidade. dos valores dos atributos simples a partir de uma instância da entidade. Dada uma instância da entidade, este serviço retorna os valores dos atributos simples monovalorados. dos valores dos atributos que compõem a chave lógica da entidade. Dada uma instância da entidade, este serviço retorna os valores dos atributos que compõem a chave lógica da entidade.

42 3.3 Arquitetura dos Componentes de Transformação 40 dos valores da chave parcial de um atributo composto. Este serviço retorna os valores dos atributos que compõem a chave parcial do atributo composto. A entrada deste serviço é o mnemônico do atributo composto ou objeto interno. dos valores simples do atributo composto. Este serviço retorna os dados dos atributos simples do atributo composto ou objeto interno. A entrada deste serviço é o mnemônico do atributo composto ou objeto interno. A classe Metadados possui os métodos obteratributosimples, obterchavelogica, obterchaveparcialcomposto e obtervaloressimplescomposto que conceitualmente deveria pertencer à classe ObjetoApresentacao, que fornece serviço para os dados de uma instância de entidade. Eles ficaram na classe Metadados pois dependem de metainformações para sua execução. Por exemplo, o método obterchavelogica necessita de um serviço que retorne o índice dos atributos que fazem parte da chave lógica da entidade. Figura 3.5: Classe Metadados A instância de entidade é encapsulada no sistema pela classe ObjetoApresentacao (Figura 3.7). A classe ObjetoApresentacao do pacote Serviços de Metadados e Dados possui o atributo valores que é um vetor de objetos. Neste vetor cada objeto é uma instância do atributo nos Metadados de mesma posição. Os atributos multivalorados são armazenados em vetores de vetores, onde o vetor interno armazena cada uma das instâncias do atributo multivalorado e o vetor externo armazena este conjunto de instâncias. A Figura 3.6 ilustra esta construção. Os serviços de metadados e dados do componente de persistência EBD são utilizados nas operações CRUD para instâncias de entidade, a serem apresentadas na Seção O método adicionarvalorem adiciona um objeto no ObjetoApresentacao no índice passado por parâmetro. Todos os objetos armazenados nos índices maiores que o valor do parâmetro indice são deslocados e o objeto valor é adicionado. Por sua vez, o método adicionarvalor que possui somente um parâmetro adiciona o objeto valor na última posição do ObjetoApresentacao.

43 3.3 Arquitetura dos Componentes de Transformação 41 Figura 3.6: Representação Gráfica de uma Instância de ObjetoApresentacao Figura 3.7: Classe ObjetoApresentacao O método obternumvalores retorna a quantidade de objetos armazenados no ObjetoApresentacao. Por exemplo, este método retorna o valor 3 para o ObjetoApresentacao da Figura 3.6. O método obtervalorem retorna o objeto armazenado na posição indice do ObjetoApresentacao. Por exemplo, a chamada deste método com o valor 1, para o ObjetoApresentacao da Figura 3.6, retorna o valor Este capítulo sintetizou as principais características arquiteturais do framework para geração e evolução de SI (Seção 3.1), detalhou o modelo de representação de dados do SI (Seção 3.2) e analisou a arquitetura do componente de persistência EBD (Seção 3.3).

44 Transformações entre Modelos CAPÍTULO 4 O processo de geração automática do esquema de BD é logicamente dividido em duas fases: primeiramente é feito o mapeamento do Modelo de Meta-Objetos (MMO) para o Modelo Relacional (MR), na sequência as informações deste modelo são mapeadas para um dialeto SQL. Este capítulo apresenta, nas Seções 4.1 e 4.2, o mapeamento do MMO para o MR em termos de estruturas e operações. A Seção 4.3 discute o mapeamento do MR para o SQL do SGBD PostgreSQL. 4.1 Mapeamentos do MMO para MR O MMO descreve um SI através de tipos de entidade, objetos internos (tipos de relacionamento), atributos (que podem ser multivalorados e compostos), hierarquias de especialização e restrições estruturais (domínio, chave, unicidade, cardinalidade mínima e máxima de atributo e relacionamento). O componente EBD é capaz de mapear para o Modelo Relacional (MR) todos estes conceitos utilizados para representar um SI Mapeamento de Entidades e Hierarquia de Especialização A Tabela 4.1 apresenta informações do mapeamento de um tipo de entidade no MMO para uma relação no MR. Basicamente, cada tipo de entidade no MMO será mapeado para uma relação no MR. Todas as relações mapeadas pelo componente possuem uma chave artificial (surrogate key) como chave primária. O valor da chave artificial é gerado pelo EBD e não possui significado na perspectiva do negócio. A chave artificial pk pertence ao domínio inteiro e é incrementada automaticamente a cada inserção na relação. O mnemônico do tipo de entidade do MMO é mapeado para o nome da relação no MR. Os atributos do tipo de entidade mapeados para a relação correspondente são os atributos simples monovalorados. No processo de mapeamento, os atributos de um atri-

45 4.1 Mapeamentos do MMO para MR 43 MMO Mnemônico de Tipo de Entidade Conjunto de Atributos Simples Monovalorados Conjunto de Atributos com Restrições "É parte de chave" Restrição "É Único" sobre atributo Restrição "É uma Especialização de" referenciando um Tipo de Entidade Genérico Nome da Relação MR Conjunto de Atributos da Relação Restrição de unicidade sobre o conjunto de atributos Restrição de Unicidade sobre atributo Inclusão de atributo pk com restrição primary key Restrição foreign key sobre o atributo pk referenciando a relação correspondente ao Tipo de Entidade Genérico Tabela 4.1: Mapeamento de Entidades e Hierarquia de Entidades do MMO para o MR MMO MR Tipo do Atributo Tipo de Domínio Domínio Básico Alfanumérico Alfanumérico Básico Inteiro Inteiro Básico Decimal Decimal Básico Data Data Enumerado Booleano Booleano Enumerado Alfanumérico Inteiro Tabela 4.2: Conversão de Tipo/Domínio do MMO para MR buto composto monovalorado são colocados na relação da entidade à qual eles pertencem. Os nome desses atributos no MR são os respectivos mnemônicos no MMO. No MMO é possível definir se um atributo é armazenado ou não. Quando um atributo não é armazenado (derivado) então é associada a ele uma regra de derivação que calcula o valor deste atributo. Por exemplo, o atributo idade de uma pessoa física é um atributo derivado. O mapeamento de tipos/domínios do MMO para o MR é apresentado na Tabela 4.2. O atributo do tipo enumerado é mapeado com uma chave estrangeira para uma relação Valor Enumerado que armazena todos os valores enumerados de todos os domínios enumerados. Esta relação possui uma chave estrangeira para uma relação Domínio Enumerado que contém todos os domínios enumerados definidos para o SI. A relação Domínio Enumerado recebe os nomes dos domínios; como por exemplo, cor primária e sexo. Já a relação Valor Enumerado recebe os valores do domínio; como por exemplo, verde, azul e vermelho, para cores primárias, e masculino e feminino, para sexo. A Figura 4.1 mostra a representação do atributo enumerado no MR. As restrições de integridade de chave e unicidade do MMO são mapeadas para

46 4.1 Mapeamentos do MMO para MR 44 Figura 4.1: Mapeamento de Atributo Enumerado do MMO para o MR restrições de unicidade no MR. A chave primária é uma chave artificial (atributo pk) gerada pelo mecanismo de mapeamento e não possui conceito correspondente no MMO. Os atributos que compõem a chave lógica são definidos com a restrição de unicidade. A abordagem utilizada para mapear hierarquias de especialização considera cada tipo de entidade da hierarquia como uma relação. As vantagens desta abordagem são: (i) facilidade de entendimento, pois o mapeamento feito entre entidade e relação é um para um; (ii) facilidade de manutenção, pois modificações em uma superentidade não afetam suas subentidades; (iii) e a quantidade de espaço armazenado é proporcional ao número de objetos armazenados. Os pontos fracos desta abordagem são o potencial número de relações criadas e, consequentemente o aumento de junções, afetando a eficiência das consultas de informações na hierarquia. Essas limitações não são significativas, pois o próprio componente EBD é responsável pela criação de relações e pela definição de operações de junção, que podem ser otimizadas para cada plataforma alvo do SI. A Figura 4.2 apresenta um exemplo de mapeamento de hierarquia de especialização do MMO para o MR. Para manter a integridade referencial entre instâncias das superentidades e respectivas subentidades é criada uma restrição de chave estrageira da relação da subentidade para a da superentidade. A chave estrangeira é a própria pk da relação especializada. A superentidade é obtida da restrição "é uma especialização de" do MMO Mapeamento de Tipos de Relacionamento (Objeto Interno) O mapeamento de um atributo do tipo objeto interno é feito para uma relação, independente da sua cardinalidade (1:1, 1:n, n:m). Uma potencial desvantagem desta abordagem seria relacionada à possível ineficiência nas consultas, mas a manutenção é beneficiada pois, em casos de mudança de cardinalidade, não é necessário mudar a forma de mapeamento.

47 4.1 Mapeamentos do MMO para MR 45 Figura 4.2: Mapeamento de Hierarquia de Especialização do MMO para o MR A Tabela 4.3 descreve o esquema para o mapeamento de atributo do tipo objeto interno do MMO para o MR. Primeiramente é criada uma relação com o nome definido pelo mnemônico do atributo objeto interno no MMO. Esta relação possui os atributos pk, pkent, pkentref no domínio inteiro, sendo as duas últimas chaves estrangeiras para as entidades a que o atributo objeto interno pertence e para a entidade de referência, respectivamente. Ambas as chaves possuem restrição de não nulidade. Figura 4.3: Mapeamento de Atributo Objeto Interno do MMO para o MR O atributo do tipo objeto interno pode ter subatributos, que correspondem a atributos do relacionamento. O mapeamento é feito da mesma forma descrita para o tipo de entidade, ou seja, são considerados o mesmo mnemônico e a conversão de tipo do MMO para o MR (Tabela 4.2).

48 4.1 Mapeamentos do MMO para MR 46 MMO Mnemônico Objeto Interno Restrição "Entidade Referenciada" indicando a Entidade do Relacionamento Restrição "Atributo Referenciado" indicando o atributo Objeto Interno do Relacionamento. Só ocorre quando é definido relacionamento com agregação MR Nome da Relação Inclusão de atributo pk com restrição primary key Inclusão de atributo pkent com restrição de não nulidade foreign key referenciando a relação correspondente à entidade que contém o atributo objeto interno Inclusão do atributo pkentref com restrição de não nulidade e foreign key referenciando a relação correspondente à Entidade Referenciada pelo atributo objeto interno Inclusão do atributo pkatribref com restrição de não nulidade e foreign key referenciando a relação correspondente ao Atributo Referenciado pelo atributo objeto interno Inclusão da restrição de unicidade para o par (pkent, pkentref ) ou, no caso de relacionamento com agregação, (pkent, pkatribref ) Tabela 4.3: Mapeamento de Objeto Interno do MMO para o MR Para representação de relacionamento com agregação, isto é, relacionamentos entre relacionamentos, a relação do atributo do tipo objeto interno possui algumas variáveis adicionais. A Figura 4.4 apresenta o mapeamento do MMO para o MR de atributo do tipo objeto interno que representa relacionamento com agregação. A relação que representa o atributo objeto interno possui uma chave estrangeira para a relação que representa a entidade contendo o atributo que está sendo mapeado e para a relação que representa o atributo de referência Mapeamento de Entidade Fraca Pela definição de entidade fraca, não há a restrição de unicidade para os atributos que fazem parte da chave parcial. As instâncias de uma entidade fraca são identificadas a partir da chave lógica da entidade da qual ela depende mais a sua chave parcial. No MMO, a chave lógica de um tipo de entidade é definida por um conjunto de atributos simples. Para a entidade fraca, além dos atributos simples que compõem a chave parcial é definido um atributo do tipo objeto interno que faz parte da chave lógica. Para montar a chave lógica da entidade fraca, primeiramente são obtidos os atributos da chave lógica da entidade de referência do atributo objeto interno que faz parte

49 4.1 Mapeamentos do MMO para MR 47 Figura 4.4: Mapeamento do Atributo Objeto Interno (Agregação) do MMO para o MR da chave e, posteriormente, são obtidos os atributos simples da chave parcial da entidade fraca. O mapeamento do atributo objeto interno que faz parte da chave da entidade fraca é feito como descrito na Tabela 4.3. A Figura 4.5 apresenta o mapeamento do MMO para o MR para entidade Fraca. Figura 4.5: Mapeamento de Entidade Fraca do MMO para o MR

50 4.1 Mapeamentos do MMO para MR 48 MMO Mnemônico do Atributo MR Nome da Relação Inclusão de atributo pk com restrição de não nulidade foreign key referenciando a relação correspondente à entidade que contém o atributo multivalorado Inclusão de atributo com o nome valor na relação Inclusão da restrição de primary key sobre o atributo pk e o atributo valor Tabela 4.4: Mapeamento do Atributo Simples Multivalorado do MMO para o MR Mapeamento de Atributo Multivalorado Atributos simples multivalorados no MMO são mapeados para relações no MR. A Figura 4.6 apresenta um atributo multivalorado mapeado para o MR, enquanto a Tabela 4.4 descreve as regras deste mapeamento. Figura 4.6: Mapeamento de Atributo Multivalorado do MMO para o MR No processo de mapeamento primeiramente é criada uma relação com o nome do atributo multivalorado no MMO. A relação possui duas colunas: pk e valor. A coluna pk é uma chave estrangeira para a relação que representa a entidade proprietária do atributo multivalorado. O domínio da coluna valor é obtido através da conversão descrita na Tabela 4.2. A chave primária da relação é composta pelas colunas pk e valor. O atributo composto multivalorado do MMO também é mapeado para uma relação no MR. A Figura 4.7 mostra um exemplo deste mapeamento. Figura 4.7: Mapeamento de Atributo Composto do MMO para o MR O mapeamento inicia com a criação da relação com o mesmo nome do atributo no modelo MMO. As colunas da relação são definidas pela lista de subatributos do

51 4.2 Geração de DML para Operações CRUD 49 MMO Mnemônico do Atributo Conjunto de Atributos Simples Monovalorados Conjunto de SubAtributos com Restrição "É parte de chave" MR Nome da Relação Inclusão de atributo pk com restrição primary key Inclusão de atributo pkent com restrição de não nulidade foreign key referenciando a relação correspondente à entidade que contém o atributo multivalorado Conjunto de Atributos da Relação Inclusão da restrição de unicidade sobre o atributo pkent e o conjunto de atributos Tabela 4.5: Mapeamento do Atributo Composto Multivalorado do MMO para o MR atributo do tipo composto. Além destas colunas, a relação conta com as colunas pk e pkent. A coluna pk é a chave primária da relação, e a coluna pkent é uma chave estrangeira para a relação que representa a entidade proprietária do atributo composto. Para garantir a unicidade dos valores, no MMO um atributo do tipo composto possui chave parcial, como uma entidade fraca. A restrição de unicidade é criada a partir dos atributos que compõem a chave parcial mais a coluna pkent. 4.2 Geração de DML para Operações CRUD Esta seção discute a criação de instruções de manipulação para operações CRUD para Entidade, Hierarquia de Especialização, Atributo Objeto Interno, Entidade Fraca, Atributo Composto e Atributo Multivalorado. A Álgebra Relacional foi utilizada para descrever o conjunto de operações geradas para cada um desses conceitos do MMO DML para Tipo de Entidade Para cada tipo de entidade há dois tipos de consultas implícitas no MMO: uma para obtenção de todas as instâncias e outra para obtenção de uma instância específica. A Tabela 4.6 (a) apresenta a consulta para obtenção de todas as instâncias de um tipo de entidade. A consulta é feita na relação Entidade, lembrando que o nome da relação é igual ao mnemônico do tipo de entidade no MMO. A lista de atributos da operação project (π) é a lista de todos os atributos simples monovalorados da entidade. A consulta para obtenção de uma instância de tipo de entidade é apresentada pela Tabela 4.6 (b). A projeção leva em conta a mesma lista de

52 4.2 Geração de DML para Operações CRUD 50 Relação: Entidade(pk, atributo1, atributo2, atributo3) (a) Obtenção de Instâncias π atributo1,atributo2,atributo3 (Entidade) (b) Obtenção de Instância π atributo1,atributo2,atributo3 ( σ Entidade.atributo1=val1 AND Entidade.atributo2=val2 (Entidade) ) (c) Inserção de Instância pkent max pk (Entidade) + 1 Entidade Entidade {(pkent, val1, val2, val3)} (d) Remoção de Instância pkent π pk (σ Entidade.atributo1=val1 AND Entidade.atributo2=val2(Entidade)) Entidade Entidade - σ Entidade.pk=pkEnt (Entidade) (e) Atualização de Instância pkent π pk (σ Entidade.atributo1=val1NMod AND Entidade.atributo2=val2NMod(Entidade)) Entidade π atributo1 val1, atributo2 val2, atributo3 val3 ( σ Entidade.pk=pkEnt (Entidade)) ) Tabela 4.6: Operações CRUD sobre Tipo de Entidade atributos da consulta para todas as instâncias. A projeção é feita a partir da seleção (σ) da instância da entidade. A condição de seleção da instrução σ é criada a partir do atributos que fazem parte da chave da entidade. A condição é criada a partir do padrão Entidade.atributo = valn, onde Entidade é mnemônico da entidade, atributo é mnemônico do atributo simples monovalorado que faz parte da chave e valn é uma variável, sendo N a sua posição na lista de atributos simples da entidade. A variável vali tem o mesmo domínio do atributo atribi da relação Entidade. As instruções para inserção de instância de entidade são apresentadas na Tabela 4.6 (c). Antes de inserir a instância da entidade, primeiramente é calculado o valor da chave primária, adicionando um ao maior valor na relação Entidade, armazenado na variável pkent. A tupla {(pkent, val1, val2, val3)} é formada com o valor da chave primária artificial mais os valores val1, val2 e val3 para os atributos atrib1, atrib2 e atrib3 respectivamente. Só então a nova tupla é inserida no conjunto de tuplas da relação Entidade. A Tabela 4.6 (d) apresenta o conjunto de instruções para remoção de instâncias de tipo de entidade. A remoção é iniciada obtendo a chave primária através da chave

53 4.2 Geração de DML para Operações CRUD 51 lógica da entidade. A consulta é semelhante à consulta para obtenção de uma instância de entidade. A diferença está na lista de projeção que considera somente o atributo pk. A exclusão é feita a partir da seleção (σ) da tupla que possui o valor da chave primária igual ao valor armazenado na variável pkent. A operação de atualização de instância de entidade é apresentada na Tabela 4.6 (e). Da mesma forma que a remoção de instâncias, a atualização é feita em duas etapas: uma para obter a chave primária da entidade e outra para executar a instrução de atualização. A instrução para obter a chave primária da instância que será atualizada é semelhante à instrução definida no processo de remoção de instância de entidade. A diferença está na condição da consulta onde os valores da chave lógica devem ser os valores antes da modificação da instância da entidade. Caso a chave lógica seja modificada, os valores armazenados em val1 e val2 não podem ser utilizados na consulta para obtenção da chave primária, pois a consulta não retornaria nada. Para isso, são definidas as variáveis va1nmod e val2nmod que recebem os valores antes da modificação da chave lógica. A instrução de atualização possui uma lista de atribuição que é definida pelo formato atributon valn, onde atributon é o atributo N da relação, e valn é a variável que armazena o novo valor do atributo DML para Tipo de Entidade Especializada Não existe limite para níveis de uma hierarquia de especialização no MMO. Logo, os serviços de criação de listas (como lista de atributos na operação project, lista de junções e lista de atribuições na instrução de atualização) devem contemplar todas as entidades da hierarquia. Estas listas podem ser obtidas a partir de mecanismos recursivos. Por exemplo, a lista de atributos da operação project em uma consulta de uma entidade especializada pode ser obtida através do Código 4.1.

54 4.2 Geração de DML para Operações CRUD 52 Código 4.1 Obtenção de Lista de Atributos Simples de uma Hierarquia de Especialização 1 String obterlistaatributos( String mneentidade ) 2 { 3 String listaatributos; 4 String superentidade; 5 Vetor<String> atributos; 6 7 superentidade = obtersuperentidade (mneentidade); 8 9 se superentidade!= nulo faça 10 listaatributos = obterlistaatributos (superentidade ) 11 fim se; atributos = obteratributosentidade (mneentidade); para cada elemento em atributos faça 16 listaatributos = listaatributos +, + atributos[i] +, ; 17 fim retorne listaatributos 20 } O conjunto de operações CRUD sobre tipo de entidades especializadas é apresentado na Tabela 4.7. Nas operações de consulta, a lista de atributos da operação de projeção é composta pelos atributos simples monovalorados da superentidade mais os atributos simples monovalorados da subentidade. Na operação de seleção (σ) são definidas as junções entre todas as tabelas que participam da hierarquia de especialização. A lista de junções pode ser obtida utilizando um algoritmo semelhante ao descrito no Código 4.1. Se a hierarquia de especialização tiver apenas um nível, a lista de junção é definida como SuperEntidade SubEntidade e a condição de junção é SuperEntidade.pk = SubEntidade.pk. A operação de consulta que retorna uma instância da entidade especializada é detalhada na Tabela 4.7 (b). Na operação de seleção (σ) além das condições de junção é criada a lista de comparação entre os atributos da chave lógica da superentidade e os valores da chave lógica. Neste caso são considerados somente os atributos que identificam unicamente uma instância, por isso que esta lista não possui atributos da subentidade. Cada cláusula da condição segue o padrão SuperEntidade.atribN = valn, onde SuperEntidade é mnemônico da entidade raiz da hierarquia, mnemonicoatributo é mnemônico do

55 4.2 Geração de DML para Operações CRUD 53 Relações: SubEntidade(pk, atrib1, atrib2, atrib3) SuperEntidade(pk, atriba, atribb) (a) Obtenção de Instâncias π atriba,atribb,atrib1,atrib2,atrib3 ( σ SuperEntidade.pk=SubEntidade.pk (SuperEntidade SubEntidade) ) (b) Obtenção de Instância π atriba,atribb,atrib1,atrib2,atrib3 ( σ SuperEntidade.pk=SubEntidade.pk AND SuperEntidade.atribA=valA (SuperEntidade SubEntidade) ) (c) Inserção de Instância pkent max pk (SuperEntidade) + 1 SuperEntidade SuperEntidade {(pkent, vala, valb)} SubEntidade SubEntidade {(pkent, val1, val2, val3)} (d) Remoção de Instância pkent π pk (σ SuperEntidade.atribA=valA (SuperEntidade)) SubEntidade SubEntidade - σ SubEntidade.pk=pkEnt (SubEntidade) (e) Atualização de Instância pkent π pk (σ SuperEntidade.atribA=valANMod (SuperEntidade)) SuperEntidade π atriba vala, atribb valb ( σ SuperEntidade.pk=pkEnt (SuperEntidade)) ) SubEntidade π atrib1 val1, atrib2 val2, atrib3 val3 ( σ SubEntidade.pk=pkEnt (SubEntidade) ) Tabela 4.7: Operações CRUD sobre Tipo de Entidade Especializada atributo simples monovalorado que faz parte da chave, e valn é uma variável, sendo N a posição na lista de atributos simples da superentidade raiz da hierarquia. Na operação de inserção, a primeira instrução é a busca pelo maior valor do atributo pk na relação SuperEntidade. O valor encontrado é incrementado de um e armazenado na variável pkent. A nova tupla da relação SuperEntidade {(pkent, vala, valb)} é formada com o valor da chave primária artificial mais os valores vala e valb para os atributos atriba e atribb, respectivamente. Só então a nova tupla é inserida no BD. Os atributos atriba e atribb são os atributos simples monovalorados da entidade com o mnemônico SuperEntidade. A instrução para inserção da tupla da relação SubEntidade é obtida da mesma forma que a instrução da relação SuperEntidade. O atributo pk recebe o mesmo valor da

56 4.2 Geração de DML para Operações CRUD 54 variável pkent garantindo que a chave da superentidade seja propagada por toda a cadeia de especialização. Na operação de remoção, primeiramente é feita a busca pela chave primária da superentidade. Como o valor é o mesmo para as subentidades, na instrução para remover a instância da subentidade SubEntidade a condição de seleção compara os valores pk da relação com o valor da chave primária obtida da superentidade (pkent). A consulta para obtenção da chave primária é criada da mesma forma que a consulta para obtenção de uma instância de uma entidade especializada; a única diferença está na lista de projeção que considera somente o valor pk da superentidade. Na operação de atualização, a operação para obter a chave primária da superentidade é semelhante à utilizada na remoção de instância de entidade especializada; a diferença está na condição da consulta, que segue o mesmo príncípio discutido na atualização de instância de entidade forte, com a busca sendo feita com o valor da chave lógica não modificada. No caso descrito na Tabela 4.7 (e), a consulta é feita considerando o valor da variável valanmod que armazena a chave de SuperEntidade. A atualização é feita da raiz da especialização para as folhas, ou seja, da superentidade para a cadeia de subentidades da hierarquia. Cada entidade na cadeia possui uma instrução para atualização de seus atributos. A geração de instruções para atualização de hierarquia de especialização pode ser obtida com algoritmo semelhante ao apresentado no Código 4.1. A atualização da instância da subentidade é feita depois de obtida a chave primária da superentidade. A operação de projeção (π) possui uma lista de atribuições definida a partir dos atributos simples da subentidade e dos novos valores para estes atributos. A montagem desta lista de atribuições segue o mesmo princípio utilizado na operação de atualização de instância de entidade DML para Objeto Interno As operações CRUD sobre atributo objeto interno são detalhadas na Tabela 4.8. A consulta é feita através da junção entre a relação que representa a entidade à qual o atributo pertence, a relação do atributo objeto interno e a relação da entidade referenciada por este atributo. Na Tabela 4.8 estes são, respectivamente, Entidade, Objeto Interno e Entidade Referenciada. A lista de atributos da operação de projeção (π) é definida pelos atributos de ligação da entidade de referência mais os subatributos do atributo objeto interno. Os atributos atriba e atribb da entidade EntidadeRef são definidos como atributos de ligação. A lista de atributos é definida utilizando o padrão Entidade.atrib, onde

57 4.2 Geração de DML para Operações CRUD 55 Relações: Entidade(pk, atrib1, atrib2, atrib3) ObjetoInterno(pk, pkentidade, pkentidaderef, subatrib1) EntidadeRef(pk, atriba, atribb) (a) Obtenção de Instância π EntidadeRe f.atriba,entidadere f.atribb ( σ Entidade.pk=Ob jetointerno.pkentidade AND Ob jetointerno.pkentidadere f =EntidadeRe f.pk AND Entidade.atrib1=val1 AND EntidadeRe f.atrib1=vala AND EntidadeRe f.atrib2=valb (Entidade ObjetoInterno EntidadeRef) ) (b) Obtenção de Instâncias π EntidadeRe f.atriba,entidadere f.atribb ( σ Entidade.pk=Ob jetointerno.pkentidade AND Ob jetointerno.pkentidadere f =EntidadeRe f.pk AND Entidade.atrib1=val1 (Entidade ObjetoInterno EntidadeRef) ) (c) Inserção de Instância pkent π pk (σ Entidade.atrib1=val1 (Entidade)) pkentref π pk ( σ EntidadeRe f.atriba=vala AND EntidadeRe f.atribb=valb (EntidadeRef) ) pknovo max pk (ObjetoInterno) + 1 ObjetoInterno ObjetoInterno {(pknovo, pkent, pkentref, subatrib1)} (d) Remoção de Instância pkent π pk (σ Entidade.atrib1=val1 (Entidade)) pkentref π pk ( σ EntidadeRe f.atrib1=vala AND EntidadeRe f.atrib2=valb (EntidadeRef) ) ObjetoInterno ObjetoInterno - σ Ob jetointerno.pkentidade=pkent AND Ob jetointerno.pkentidadere f =pkentre f (ObjetoInterno) (e) Atualização de Instância pkent π pk (σ Entidade.atrib1=val1 (Entidade)) pkentref π pk ( σ EntidadeRe f.atrib1=vala AND EntidadeRe f.atrib2=valb (EntidadeRef) ) ObjetoInterno π subatrib1 subval1 ( σ Ob jetointerno.pkentidade=pkent AND Ob jetointerno.pkentidadere f =pkentre f (ObjetoInterno) ) Tabela 4.8: Operações CRUD sobre Atributo Objeto Interno

58 4.2 Geração de DML para Operações CRUD 56 Entidade é o mnemonico da entidade de referência, e atrib é o mnemonico do atributo de ligação. A condição da consulta é definida pelas condições de junção e pela condição para seleção das instâncias. A consulta terá pelo menos duas condições de junção: uma para junção entre Entidade e ObjetoInterno e outra para ObjetoInterno e EntidadeRef. A outra parte da condição é definida pela comparação entre os atributos que formam a chave lógica da entidade à qual o atributo objeto interno pertence e os valores dos parâmetros da condição de seleção. Na Tabela 4.8 a chave da consulta é definida por Entidade.atrib1 = val1, que é a chave lógica da entidade Entidade. Para obtenção de uma instância, a condição de seleção também considera os atributos que fazem parte da chave da entidade referenciada. Na operação de inserção, primeiramente são obtidas as chaves primárias das instâncias das entidades envolvidas no relacionamento. A chave primária da relação Entidade é obtida através da consulta na qual a condição vem da comparação entre os atributos que compõem a chave lógica da entidade e seus valores, neste caso Entidade.atrib1 = val1. A consulta para obtenção de chave primária de entidade referenciada utiliza o mesmo mecanismo. As variáveis pkent e pkentref armazenam a chave primária da entidade e entidade de referência do atributo objeto interno. A nova tupla da relação é definida por valor chave da relação pknovo, pkent, pkentref e a lista de subatributos do atributo objeto interno. No exemplo da Tabela 4.8 o objeto interno possui somente um subatributo, subatrib1. No processamento para remoção de instância do atributo do tipo objeto interno, primeiramente obtém-se as chaves primárias da entidade proprietária do atributo e da entidade de referência do atributo, da mesma forma feita no processamento para inserção. A criação da instrução de remoção é feita a partir da consulta da tupla do atributo onde o valor da chave estrangeira para a entidade é igual ao valor da variável pkent, e o valor da chave estrangeira para a entidade de referência possui o valor igual à variável pkentref. O processamento para atualização de atributo do tipo objeto interno é necessário somente se o atributo possui subatributos. Caso contrário, a troca de instância da entidade de referência é considerada uma atualização, mas pode ser feita a partir de uma remoção e uma inserção. Semelhante ao processo de remoção, primeiramente devem ser obtidas as chaves primárias da entidade proprietária do atributo e da entidade de referência do atributo. A instrução de atualização de instância é semelhante a uma consulta, mas na lista de projeção são definidas as atribuições de valores para os atributos da relação ObjetoInterno. Esta lista é definida pelo formato subatribn subvaln, onde suba-

59 4.2 Geração de DML para Operações CRUD 57 tribn é o subatributo N do atributo e subvaln é a variável que armazena o novo valor. A Tabela 4.9 apresenta as operações CRUD sobre objeto interno para agregação. A operação de consulta é feita de forma semelhante à consulta gerada pela Tabela 4.8 que define o processamento para consulta de instância de atributo objeto interno. Relações: Tabela 4.9: Obtenção de Instâncias de Atributo Objeito Interno (Agregação) Entidade(pk, atrib1, atrib2, atrib3) ObjetoInterno(pk, pkentidade, pkatributoref, subatrib1) AtributoRef(pk, pkentidaderef, pkentidadeatribref) EntidadeRef(pk, atriba, atribb) EntidadeAtribRef(pk, atribx, atriby) (a) Obtenção de Instância π EntidadeRe f.atriba,entidadere f.atribb,entidadeatribre f.atribx ( σ Entidade.pk=Ob jetointerno.pkentidade AND ) Ob jetointerno.pkmnemonicoatribre f =AtributoRe f.pk AND AtributoRe f.pkmnemonicoent=entidade.pk AND AtributoRe f.pkentidadere f =EntidadeRe f.pk AND Entidade.atrib1=val1 AND EntidadeRe f.atriba=vala AND EntidadeAtribRe f.atribx=valx (Entidade ObjetoInterno AtributoRef EntidadeRef EntidadeAtribRef) (b) Obtenção de Instância π EntidadeRe f.atriba,entidadere f.atribb,entidadeatribre f.atribx ( σ Entidade.pk=Ob jetointerno.pkentidade AND ) Ob jetointerno.pkmnemonicoatribre f =AtributoRe f.pk AND AtributoRe f.pkmnemonicoent=entidade.pk AND AtributoRe f.pkentidadere f =EntidadeRe f.pk AND Entidade.atrib1=val1 (Entidade ObjetoInterno AtributoRef EntidadeRef EntidadeAtribRef) Continua na próxima página

60 4.2 Geração de DML para Operações CRUD 58 Continuação da Tabela 4.9 (c) Inserção de Instância pkent π pk (σ Entidade.atrib1=val1 (Entidade)) pknovo max pk (ObjetoInterno) + 1 pkatribref π pk ( σ AtributoRe f.pkentidadere f =EntidadeRe f.pk AND AtributoRe f.pkentidadere f =EntidadeAtribRe f.pk AND EntidadeRe f.atriba=vala AND EntidadeAtribRe f.atribx=valx (EntidadeRef AtributoRef EntidadeAtribRef) ObjetoInterno ObjetoInterno {(pknovo, pkent, pkatribref, subatrib1)} (d) Remoção de Instância pkent π pk (σ Entidade.atrib1=val1 (Entidade)) pkatribref π pk ( σ AtributoRe f.pkentidadere f =EntidadeRe f.pk AND AtributoRe f.pkentidadere f =EntidadeAtribRe f.pk AND EntidadeRe f.atriba=vala AND EntidadeAtribRe f.atribx=valx (EntidadeRef AtributoRef EntidadeAtribRef) ObjetoInterno ObjetoInterno - σ Ob jetointerno.pkentidade=pkent AND Ob jetointerno.pkatributore f =pkatribre f (ObjetoInterno) (e) Atualização de Instância pkent π pk (σ Entidade.atrib1=val1 (Entidade)) pkatribref π pk ( σ AtributoRe f.pkentidadere f =EntidadeRe f.pk AND ) AtributoRe f.pkentidadere f =EntidadeAtribRe f.pk AND EntidadeRe f.atriba=vala AND EntidadeAtribRe f.atribx=valx (EntidadeRef AtributoRef EntidadeAtribRef) ObjetoInterno π subatrib1 subval1 ( σ Ob jetointerno.pkentidade=pkent AND Ob jetointerno.pkatributore f =pkatribre f (ObjetoInterno) ) As diferenças estão na operação de projeção e na lista de relações da consulta. A lista de atributos da operação de projeção é definida pelos atributos de ligação da entidade de referência e da entidade de referência do atributo de referência, mais os subatributos do atributo objeto interno, representados, respectivamente, por atriba, atribb, atribx e subatrib1.

61 4.2 Geração de DML para Operações CRUD 59 A consulta é feita através da junção entre a relação da entidade à qual o atributo pertence (relação do atributo) e a relação da entidade de referência, relação do atributo de referência e a relação da entidade de referência do atributo de referência representadas no exemplo por Entidade, ObjetoInterno, EntidadeRef, EntidadeAtribRef e AtributoRef. A Figura 4.4 apresenta o relacionamento entre estas relações. A condição de seleção da operação de obtenção de uma instância leva em conta a chave lógica do tipo de entidade à qual ele pertence (na Tabela 4.9 é o atributo atrib1) e a chave lógica do atributo objeto interno de referência. A chave lógica deste atributo é a chave lógica da entidade à qual ele pertence (atributo atriba) mais a chave da entidade de referência (atributo atribx). O processo de inserção de instâncias do atributo objeto interno para agregação é semelhante ao definido para o atributo objeto interno (Tabela 4.8), sendo necessário obter as chaves primárias da entidade proprietária do atributo e do atributo de referência que representa a agregação. A consulta para obter a chave primária do atributo de referência é semelhante à consulta para obtenção de instâncias de atributo objeto interno. A diferença está na condição da seleção que considera os atributos que fazem parte da chave da entidade de referência. A nova tupla é definida como ({(pknovo, pkent, pkatribref, subatrib1)}) e inserida na relação ObjetoInterno. No processamento para remoção de instância do atributo do tipo objeto interno para relacionamento com agregação, primeiramente são obtidas e armazenadas nas variáveis pkent e pkatribref, respectivamente, as chaves primárias da entidade proprietária do atributo e do atributo de referência. Então é feita uma seleção (σ) para obtenção da tupla que será removida. A chave desta seleção são os valores pkent e pkatribref comparados, respectivamente, com a chave estrangeira para a entidade e com a chave estrangeira para o atributo de referência. Logo, a tupla obtida é removida do conjunto de tuplas da relação ObjetoInterno. Nas instruções para atualização de instâncias do atributo do tipo objeto interno para agregação, primeiramente são obtidas e armazenadas nas variáveis pkent e pkatribref, respectivamente, as chaves primárias da entidade proprietária do atributo e do atributo de referência. Então é feita uma seleção (σ) para obtenção da tupla que será atualizada. A chave desta seleção são os valores pkent e pkatribref comparados, respectivamente, com a chave estrangeira para a entidade e com a chave estrangeira para o atributo de referência. Na operação de projeção (π) é definida a lista de atribuição composta pelos subatributos da relação ObjetoInterno e pelos novos valores, seguindo o formato subatribn subvaln, onde subatribn é o subatributo N do atributo, e subvaln é a variável que armazena o novo valor.

62 4.2 Geração de DML para Operações CRUD DML para Tipo de Entidade Fraca Uma entidade fraca possui, no conjunto de atributos que compõem a chave parcial, um atributo do tipo objeto interno que identifica a entidade da qual a entidade fraca tem dependência de identificação. A chave lógica da entidade fraca é composta pelos atributos da chave lógica da entidade de referência do atributo objeto interno que faz parte da chave (entidade identificadora) mais os atributos simples da chave parcial da entidade fraca. Os detalhes das operações CRUD sobre entidade fraca são apresentados na Tabela Na operação de consulta, a lista de atributos na operação de projeção (π) é composta pela lista de atributos da chave lógica da entidade identificadora mais os atributos simples da entidade fraca. A chave lógica da entidade identificadora é retornada, pois a busca de instâncias de atributos multivalorados, compostos e objetos internos de entidade fraca não seria possível somente com os valores da chave parcial. Na operação de seleção (σ) são feitas as junções entre as relações que representam a entidade identificadora, o atributo objeto interno parte de chave e a entidade fraca. No processamento para obtenção de uma instância da entidade fraca, a consulta é semelhante à consulta definida na Tabela 4.10 (a). A diferença está na condição da seleção que contém os atributos que compõem a chave lógica (chave lógica da entidade identificadora mais chave parcial da entidade fraca). Na operação de inserção de instância de tipo de entidade fraca, primeiramente é obtida e armazenada na variável pkentref a chave primária da entidade identificadora. Depois, são inseridos os valores dos atributos simples da entidade fraca na relação correspondente. Em seguida é obtida e armazenada na variável pkent a chave primária da entidade fraca e, finalmente, as instâncias da entidade identificadora e da entidade fraca são associadas através da inserção na relação que representa o atributo objeto interno que faz parte da chave da entidade fraca. Na operação para remoção de instância de tipo de entidade fraca, o processamento é composto pelas operações de obtenção da chave primária da entidade identificadora e da entidade fraca armazenadas, respectivamente, nas variáveis pkentref e pkent. Antes de remover a tupla da entidade fraca é removida a tupla da relação que representa o atributo objeto interno que associa as instâncias da entidade identificadora e da entidade fraca. Finalmente, a instância da entidade fraca é excluída. Para a atualização de instâncias de tipo de entidade fraca, a primeira operação é a obtenção da chave primária da instância da entidade fraca a partir dos parâmetros da chave lógica antes da modificação. Na operação de projeção (π) é definida a lista de atribuição composta pelos atributos da relação EntidadeFraca e pelos novos valores, seguindo o formato atribn valn, onde atribn é o atributo N da entidade fraca, e valn é a variável que armazena o novo valor para atribn.

63 4.2 Geração de DML para Operações CRUD 61 Relações: EntidadeProp(pk, atriba, atribb, atribc) ObjetoInternoParteChave(pk, pkentidadeprop, pkentidadefraca, subatrib1) EntidadeFraca(pk, atrib1, atrib2) (a) Obtenção de Instâncias π EntidadeProp.atribA,EntidadeProp.atribB,EntidadeFraca.atrib1,EntidadeFraca.atrib2 ( σ Ob jetointernopartechave.pkent=mneentidadefraca.pk AND Ob jetointernopartechave.pkentre f =EntidadeProp.pk (EntidadeFraca ObjetoInternoParteChave EntidadeProp) ) (b) Obtenção de Instância π EntidadeProp.atribA,EntidadeProp.atribB,EntidadeFraca.atrib1,EntidadeFraca.atrib2 ( σ Ob jetointernopartechave.pkent=mneentidadefraca.pk AND Ob jetointernopartechave.pkentre f =EntidadeProp.pk AND EntidadeProp.atribA=valA AND EntidadeFraca.atrib1=val1 (EntidadeFraca ObjetoInternoParteChave EntidadeProp) ) (c) Inserção de Instância pkentref π pk (σ EntidadeProp.atribA=valA (EntidadeProp)) pkent max pk (EntidadeFraca) EntidadeFraca EntidadeFraca {(pk, atrib1, atrib2)} pknovo max pk (mnmonicoobjinternopartechave) mnmonicoobjinternopartechave mnmonicoobjinternopartechave {(pknovo, pkent, pkentref)} (d) Remoção de Instância pkentref π pk (σ EntidadeProp.atribA=valA (EntidadeProp)) pkent π EntidadeFraca.pk ( σ Ob jetointernopartechave.pkent=mneentidadefraca.pk AND Ob jetointernopartechave.pkentre f =EntidadeProp.pk AND EntidadeProp.atribA=valA AND EntidadeFraca.atrib1=val1 (EntidadeFraca ObjetoInternoParteChave EntidadeProp) mnmonicoobjinternopartechave mnmonicoobjinternopartechave - σ Ob jetointernopartechave.pkentidadeprop=pkentre f AND Ob jetointernopartechave.pkentidadefraca=pkent (ObjetoInternoParteChave) EntidadeFraca EntidadeFraca - σ EntidadeFraca.pk=pkEnt (EntidadeFraca) (e) Atualização de Instância pkentref π pk (σ EntidadeProp.atribA=valANMod (EntidadeProp)) pkent π EntidadeFraca.pk ( σ Ob jetointernopartechave.pkent=mneentidadefraca.pk AND Ob jetointernopartechave.pkentre f =EntidadeProp.pk AND EntidadeProp.atribA=valANMod AND EntidadeFraca.atrib1=val1NMod (EntidadeFraca ObjetoInternoParteChave EntidadeProp) EntidadeFraca π atrib1 val1, atrib2 val2 (σ EntidadeFraca.pk=pkEnt (EntidadeFraca)) Tabela 4.10: Operações CRUD sobre Entidade Fraca

64 4.2 Geração de DML para Operações CRUD DML para Atributo Composto As operações CRUD sobre atributo composto são detalhadas na Tabela Na operação de projeção são considerados os subatributos simples monovalorados do atributo composto (subatrib1, subatrib2, subatrib3). Na operação de seleção é estabelecida a junção entre as relações que representam a entidade e o atributo composto (Entidade AtributoComp). A lista de condições da operação de seleção possui a condição de junção (Entidade.pk = AtributoComp.pkEntidade) e a condição de seleção da instância da entidade à qual o atributo pertence. No exemplo, o atributo atrib1 é a chave lógica da entidade. Para obtenção de uma instãncia de atributo composto a condição de seleção considera também os atributos que fazem parte da chave parcial. O processo de inserção de instâncias do atributo composto é iniciado com a obtenção da chave primária da entidade. O valor da chave é armazenado na variável pkent. Depois, é criada a nova tupla da relação AtributoComposto {(pknovo, pkent, subval1, subval2, subval3)}. A variável pknovo é a chave primária da tupla obtida a partir do maior valor do atributo pk mais um; pkent é a chave primária da entidade; e subval1, subval2, subval3 são os valores para os subatributos subatrib1, subatrib2, subatrib3. A nova tupla é inserida no conjunto de tuplas da relação AtributoComposto através da operador de união de conjuntos ( ). Nas instruções para remoção de instâncias do atributo composto, o processamento é iniciado com a instrução para obter a chave primária da entidade. A chave é armazenada na variável pkent. Depois, é obtida a chave primária do atributo composto levando em conta os valores da chave lógica da entidade (pkent) mais a chave parcial do atributo composto (subatrib1 e subatrib2). O valor da chave primária do composto é armazenada na variável pkcomp. Então é removida a tupla que possui chave primária igual ao valor armazenado na variável pkcomp. O processamento para atualização de instâncias do atributo composto é iniciado com a instrução para obter a chave primária da entidade. Depois, uma segunda instrução obtém a chave primária do atributo composto, levando em conta a chave primária da entidade mais a chave parcial do atributo composto não modificada. A tupla na qual a chave primária tem o valor pkcomp é obtida utilizando a operação de seleção. Na operação de projeção são definidas as atribuições, considerando os subatributos do atributo composto e seus novos valores DML para Atributo Simples Multivalorado A Tabela 4.12 apresenta as operações sobre instâncias de atributo simples multivalorado. A operação de projeção é definida com o atributo valor da relação Atributo.

65 4.2 Geração de DML para Operações CRUD 63 Relações: Entidade(pk, atrib1, atrib2, atrib3) AtributoComp(pk, pkentidade, subatrib1, subatrib2, subatrib3) (a) Obtenção de Instâncias π AtributoComp.subAtrib1,AtributoComp.subAtrib2,AtributoComp.subAtrib3 ( σ Entidade.pk=AtributoComp.pkEntidade AND Entidade.atrib1=val1 (Entidade AtributoComp) ) (b) Obtenção de Instância π AtributoComp.subAtrib1,AtributoComp.subAtrib2,AtributoComp.subAtrib3 ( σ Entidade.pk=AtributoComp.pkEntidade AND Entidade.atrib1=val1 AtributoComp.subAtrib1=subval1 AND AtributoComp.subAtrib2=subval2 (Entidade AtributoComp) ) (c) Inserção de Instância pkent π pk (σ Entidade.atrib1=val1 (Entidade)) pknovo max pk (AtributoComposto) + 1 AtributoComp AtributoComp {(pknovo, pkent, subval1, subval2, subval3) (d) Remoção de Instância pkent π pk (σ Entidade.atrib1=val1 (Entidade)) pkcomp π pk (σ AtributoComp.pkEntidade=pkEnt AND AtributoComp.subAtrib1=subval1 AND AtributoComp.subAtrib2=subval2(AtributoComp)) AtributoComp AtributoComp - σ AtributoComp.pk=pkComp (AtributoComp) (e) Atualização de Instância pkent π pk (σ Entidade.atrib1=val1 (Entidade)) pkcomp π pk (σ AtributoComp.pkEntidade=pkEnt AND AtributoComp.subAtrib1=subval1NMod AND AtributoComp.subAtrib2=subval2NMod(AtributoComp)) AtributoComp π subatrib1 subval1, subatrib2 subval2, subatrib3 subval3 ( σ AtributoComp.pk=pkComp (AtributoComp) ) Tabela 4.11: Operações CRUD sobre Atributo Composto

66 4.2 Geração de DML para Operações CRUD 64 Relações: Entidade(pk, atrib1, atrib2, atrib3) Atributo(pk, valor) (a) Obtenção de Instâncias π Atributo.valor ( σ Entidade.pk=Atributo.pkEntidade AND Entidade.atrib1=val1 (Entidade Atributo)) (b) Inserção de Instância pkent π pk (σ Entidade.atrib1=val1 (Entidade)) Atributo Atributo {(pkent, valor)} (c) Remoção de Instância pkent π pk (σ Entidade.atrib1=val1 (Entidade)) Atributo Atributo - {(pkent, valor)} (d) Atualização de Instância pkent π pk (σ Entidade.atrib1=val1 (Entidade)) Atributo π valor val (σ Atributo.pkEnt=pkEnt AND Atributo.valor=valNMod (Atributo)) Tabela 4.12: Operações CRUD sobre Atributo Multivalorado A operação de seleção é definida a partir da junção entre as relações da entidade e do atributo multivalorado. A condição da operação de seleção possui a condição de junção (Entidade.pk = Atributo.pkEntidade) e a condição de seleção de instância da entidade à qual o atributo pertence. No exemplo o atributo atrib1 é a chave lógica da entidade com a condição Entidade.atrib1 = val1. Na operação de inserção de instâncias do atributo simples multivalorado, o processamento é iniciado com a instrução para obter a chave primária da entidade. Depois, é criada a nova tupla da relação Atributo (pkent, val), onde pkent é a chave primária da entidade e val é o valor do atributo multivalorado. A nova tupla é inserida no conjunto de tuplas da relação Atributo através da operador de união de conjuntos ( ). O processamento da operação para remoção de instância do atributo simples multivalorado é iniciado com a instrução para obter a chave primária da entidade. A chave da entidade é armazenada na variável pkent. Depois, é removida a tupla que tem o formato {(pkent, valor)} que é a chave da relação Atributo. Na operação de atualização de instância do atributo simples multivalorado o processamento é iniciado com a instrução para obtenção da chave primária da entidade (valor do atributo pk). A busca da instância do atributo multivalorado é feita a partir da condição de seleção que envolve a chave primária da entidade (armazenada na variável pkent) e o valor do atributo antes da modificação (variável valnmod). O parâmetro val contém o novo valor do atributo.

67 4.3 Mapeamento do MR para PostgreSQL 65 MR SQL (PostgreSQL) Alfanumérico VARCHAR Inteiro INTEGER Decimal DOUBLE PRECISION Data DATE Booleano BOOLEAN Tabela 4.13: Conversão de Tipo/Domínio do MR para SQL 4.3 Mapeamento do MR para PostgreSQL O processo de geração do esquema do BD do SI no componente EBD é dividido em duas etapas: a primeira é o mapeamento do MMO para o MR (MR); na segunda etapa o MR é mapeado para um dialeto SQL. Nesta seção são apresentados os mapeamentos do MR para o SQL do SGBD PostgreSQL 8.4 [53] Geração de Tabelas No mapeamento do MMO para o MR foi determinada como decisão de projeto a criação de uma chave artificial para cada relação. Este atributo é um inteiro que é incrementado automaticamente toda vez que é feita um inserção na relação. O PostgreSQL possui o domínio SERIAL com estas características. Outra restrição em relação ao mapeamento para SQL é a utilização das instruções ON UPDATE RESTRICT e ON DELETE RESTRICT na criação de chave estrangeira, evitando a atualização ou remoção em cadeia de informações do SI. Na geração das tabelas e das stored procedures é necessário mapear os domínios dos atributos do MR para os tipos de dados em SQL. A Tabela 4.13 apresenta este mapeamento. A criação da tabela envolve a criação de duas listas: lista de atributos e lista de restrições. O Código 4.2 apresenta um exemplo de estrutura de tabela modelo do PostgreSQL. Código 4.2 Tabela Modelo em PostgreSQL 1 CREATE TABLE mnemonicoentidade ( 2 pk SERIAL, 3 listaatributos, PRIMARY KEY (pk), 6 listarestrições, 7 ); No mapeamento do MR para SQL as relações são mapeadas para tabelas. A Tabela 4.14 apresenta este mapeamento. O nome da tabela é o mesmo nome da relação,

68 4.3 Mapeamento do MR para PostgreSQL 66 MR Nome da Relação Conjunto de Atributos da Relação Restrição de unicidade sobre o conjunto de atributos Restrição de Unicidade sobre atributo Inclusão do atributo pk com restrição primary key Restrição foreign key sobre o atributo pk referenciando a relação correspondente à Entidade Genérica SQL Nome da Tabela Conjunto de colunas da Tabela Restrição UNIQUE sobre o conjunto de atributos Restrição UNIQUE sobre o atributo Inclusão do atributo pk com tipo SERIAL e restrição PRIMARY KEY Restrição FOREIGN KEY sobre a coluna pk referenciando a tabela que representa a relação genérica da especialização. Tabela 4.14: Mapeamento de Relação "Entidade" do MR para SQL assim como os nomes das colunas da relação são os mesmos dos atributos da tabela. Na definição da tabela, cada atributo é associado a um tipo do SQL, conforme mapeamento definido na Tabela As restrições de integridade, de chave primária e unicidade são mapeadas para as cláusulas PRIMARY KEY e UNIQUE do SQL. A chave primária da tabela é o atributo pk, e os atributos que formam a chave lógica são colocados na cláusula UNIQUE. Aqueles atributos que possuem restrição de unicidade também são colocados em uma cláusula UNIQUE. No mapeamento de relação correspondente a entidade fraca, a única diferença é que na relação da entidade fraca não há a cláusula UNIQUE com os atributos que fazem parte da chave parcial. No mapeamento de hierarquia de especialização o atributo pk da relação especializada é mapeado para um atributo do tipo INTEGER. O mapeamento definido na Tabela 4.14 especifica que a relação da subentidade tem uma chave estrangeira para a superentidade. Na tabela da subentidade é utilizada a cláusula FOREIGN KEY para definir esta restrição de integridade referencial. Os atributos pk, pkent e pkentref que aparecem em relações correspondentes ao mapeamento de objeto interno pertencem ao domínio inteiro no MR. Eles são mapeados para SERIAL, INTEGER e INTEGER, respectivamente em SQL. O atributo pk é definido como PRIMARY KEY da tabela e os atributos pkent e pkentref são definidos como chaves estrangeiras das tabelas Entidade e EntidadeRef, respectivamente, utilizando a cláusula FOREIGN KEY do SQL. Para garantir a integridade do relacionamento, os atributos pkent e pkentref recebem a restrição NOT NULL. A unicidade da ligação é mapeada utilizando a cláusula UNIQUE aplicada aos atributos pkent e pkentref. O Código 4.3 apresenta a tabela resultante do mapeamento da Tabela 4.15.

69 4.3 Mapeamento do MR para PostgreSQL 67 MR Nome da Relação Inclusão de atributo pk com restrição primary key Inclusão de atributo pkent com restrição de não nulidade foreign key referenciando a relação correspondente à entidade que contém o atributo objeto interno Inclusão do atributo pkentref com restrição de não nulidade e foreign key referenciando a relação correspondente à Entidade Referenciada pelo atributo objeto interno Inclusão do atributo pkatribref com restrição de não nulidade e foreign key referenciando a relação correspondente ao Atributo Referenciado pelo atributo objeto interno SQL Nome da Tabela Criação da coluna pk com tipo SERIAL e restrição PRIMARY KEY Criação do Atributo pkent com restrição FOREIGN KEY referenciando a tabela representada pela relação da entidade à qual o atributo objeto interno pertence Criação do Atributo pkentref com restrição FOREIGN KEY referenciando a tabela representada pela relação da entidade referenciada Criação do Atributo pkatribref e com restrição FOREIGN KEY referenciando a tabela representada pela relação do atributo referenciado Inclusão da restrição de unicidade para o par (pkent, pkentref ) ou no caso de relacionamento com agregação (pkent, pkatribref ) Aplicação da restrição UNIQUE sobre o par de colunas pkent, pkentref ou no par pkent, pkatribref Tabela 4.15: Mapeamento de Relação "Atributo Objeto Interno" do MR para o SQL Código 4.3 Tabela Modelo para Criação de Atributo Objeto Interno 1 CREATE TABLE ObjetoInterno ( 2 pk SERIAL, 3 pkent INTEGER NOT NULL, 4 pkentref INTEGER NOT NULL, 5 lista de atributos do relacionamento (opcional), PRIMARY KEY (pk), 8 FOREIGN KEY (pkent) REFERENCES Entidade(pk) 9 ON UPDATE RESTRICT ON DELETE RESTRICT, 11 FOREIGN KEY (pkentref) REFERENCES EntidadeRef(pk) 12 ON UPDATE RESTRICT ON DELETE RESTRICT, 13 FOREIGN KEY (pkatribref) REFERENCES AtributoRef(pk) 14 ON UPDATE RESTRICT ON DELETE RESTRICT, 15 UNIQUE (pkent, pkentref) -- ou restrição UNIQUE (pkent, pkatribref) 16 ); A Tabela 4.16 apresenta os detalhes do mapeamento de uma relação que corre-

70 4.3 Mapeamento do MR para PostgreSQL 68 MR Nome da Relação Inclusão de atributo pk com restrição de não nulidade foreign key referenciando a relação correspondente à entidade que contém o atributo multivalorado Inclusão do atributo com o nome valor na relação Inclusão da restrição de primary key sobre o atributo pk e o atributo valor Nome da Tabela SQL Criação da Coluna pk com a restrição FOREIGN KEY para a tabela que corresponde a tabela da entidade Criação da coluna valor; o domínio é obtido através do mapeamento do MMO para MR e deste para SQL Aplicação da restrição PRIMARY KEY sobre as colunas pk e valor Tabela 4.16: Mapeamento de Relação "Atributo Multivalorado" do MR para SQL do PostgreSQL MR Nome da Relação Inclusão de atributo pk com restrição primary key Inclusão de atributo pkent com restrição de não nulidade foreign key referenciando a relação correspondente à entidade que contém o atributo multivalorado Conjunto de Atributos da Relação Inclusão da restrição de unicidade sobre o atributo pkent e o conjunto de atributos SQL Nome da Tabela Criação da coluna pk com a restrição PRI- MARY KEY Criação da coluna pkent com restrições NOT NULL e FOREIGN KEY referenciando à tabela da entidade Conjunto de colunas da tabela Aplicação da restrição UNIQUE sobre a coluna pkent e o subconjunto de colunas Tabela 4.17: Mapeamento de Relação "Atributo Composto" do MR para o SQL do PostgreSQL sponde a um atributo multivalorado. A tabela recebe o mesmo nome da relação. A relação possui duas colunas, uma pk e valor, as quais possuem, respectivamente, domínio inteiro e um domínio permitido no MR. Este domínio é definido a partir do domínio do atributo que foi mapeado do MMO para MR. As colunas pk e valor são definidas como PRIMARY KEY. A coluna pk é chave estrangeira para a entidade à qual o atributo pertence. Os detalhes do mapeamento para uma relação que corresponde a um atributo composto são apresentados na Tabela A coluna pkent é chave estrangeira para a relação da entidade à qual o atributo pertence. Na Tabela 4.17 a clásula UNIQUE é a chave lógica da tabela que representa o atributo composto. Esta chave é composta pela coluna pkent e as colunas que fazem parte da chave parcial.

71 4.3 Mapeamento do MR para PostgreSQL Geração de Stored Procedures (SP) em PL/pgSQL Esta seção apresenta os mapeamentos de stored procedures (SP) para manipulação de instâncias de entidade, hierarquia de especialização, atributo do tipo objeto interno, atributo composto e atributo simples multivalorado. A linguagem alvo utilizada neste mapeamento é a linguagem procedural do SGBD PostgreSQL, a PL/pgSQL [52]. A maioria dos frameworks ORM para linguagem Java utilizam JPA [49] para gerenciar o mapeamento objeto relacional. Nesta abordagem as operações são geradas em tempo de execução. Um experimento foi feito para decidir entre stored procedures e SQL dinâmico. Neste experimento, foi criada uma tabela com quatro colunas. Em um programa Java foi criado um loop, que armazenava uma tupla na tabela a cada iteração. A eficiência foi medida em relação ao número de tuplas persistidas utilizando stored procedure e SQL dinâmico. No teste com centena de milhares de tuplas o programa travou, utilizando SQL dinâmico. Com o mesmo número de tuplas, a stored procedure persistiu as informações sem travar o programa. O nome das stored procedures é obtido a partir da concatenação da operação (inserir, desativar, atualizar, obter) com o nome da relação. O Código 4.4 apresenta o modelo de stored procedure do PL/pgSQL. As stored procedures para operações de inserção, remoção e atualização sempre retornam um valor booleano true (o tratamento de exceções é feito no componente de persitência EBD no subpacote Serviços de Acesso a Dados), enquanto as stored procedures de obtenção retornam um cursor. Em PL/pgSQL, um cursor é uma estrutura que encapsula uma consulta e permite acessar algumas linhas do resultado por vez. Código 4.4 Modelo de Stored Procedure em PL/pgSQL 1 CREATE FUNCTION operacaomnemonico(listaparametros) RETURNS Retorno AS $$ 2 DECLARE 3 declaracaovariaveis 4 BEGIN 5 instrucoes 6 RETURN ValorRetorno; 7 END; 8 $$ LANGUAGE plpgsql ; O componente EBD faz a geração de dois tipos de stored procedure de consulta, uma para consulta de todas as instâncias de uma entidade e outra para consulta de uma instância específica. A Tabela 4.18 apresenta o mapeamento do MR para SQL para as operações CRUD sobre tipo de entidade. Nas operações de obtenção, a lista de atributos da operação de projeção (π) é mapeada para a lista da cláusula SELECT do SQL. Na cláusula FROM é colocado o nome da relação.

72 4.3 Mapeamento do MR para PostgreSQL 70 Para criar uma SP para obtenção de uma instância da entidade, o mapeamento descrito na Tabela 4.18 é executado. A cláusula WHERE recebe a condição da operação de seleção (σ), que faz a comparação dos atributos chave da relação (atrib1 e atrib2) com os valores de pesquisa (val1 e val2). A SP para obtenção de uma instância de entidade deve receber como parâmetro os valores da chave lógica da entidade. As variáveis val1 e val2 são mapeadas para a lista de parâmetros da stored procedure. A lista de parâmetros de uma stored procedure em PL/pgSQL é definida com o nome da variável mais o tipo em SQL. O tipo é definido a partir do domínio no MR, que é mapaeado para o tipo em SQL de acordo com a Tabela O Código 4.5 apresenta o resultado do mapeamento descrito na Tabela 4.18 para a operação de obtenção de uma instância. Código 4.5 Stored Procedure Modelo para Obtenção de Instâncias de Tipo de Entidade 1 CREATE FUNCTION obterentidadeativo(va1 TipoSQL, val2 TipoSQL) RETURNS 10 2 CURSOR AS $$ 3 DECLARE 4 csr CURSOR; 5 BEGIN 6 OPEN csr FOR 7 SELECT atrib1, atrib2, atrib3 8 FROM Entidade 9 WHERE Entidade.atrib1 = val1 AND Entidade.atrib2 = val2; 11 RETURN csr; 12 END; 13 $$ LANGUAGE plpgsql ; No mapeamento para geração de stored procedure de inserção de instância de entidade, a instrução INSERT possui duas listas, uma com os atributos da tabela que recebem os valores e uma com os valores dos parâmetros. A primeira lista é obtida a partir da lista de atributos da relação menos o atributo pk e a lista de valores (val1, val2, val3) da instrução de inserção no MR. A instrução para calcular a chave primária da nova tupla (pkent max pk (Entidade)) não precisa ser mapeada para o PostgreSQL, pois a variável pk é mapeada com o tipo SERIAL, incrementada automaticamente toda vez que é feita uma inserção na tabela. A lista de parâmetros é formada pela lista de variáveis correspondentes aos atributos da relação que representa a entidade. O Código 4.6 apresenta o modelo da stored procedure gerada a partir do mapeamento da operação de inserção de instância de entidade mapeada na Tabela 4.18.

73 4.3 Mapeamento do MR para PostgreSQL 71 MR π atrib1,atrib2,atrib3 (Entidade) π atrib1,atrib2,atrib3 ( σ Entidade.atrib1=val1 AND Entidade.atrib2=val2 (Entidade)) pkent max pk (Entidade) + 1 mnmonicoentidade Entidade {(pkent, val1, val2, val3)} SQL (a) Obtenção de Instâncias SELECT atrib1, atrib2, atrib3 FROM Entidade (b) Obtenção de Instância SELECT atrib1, atrib2, atrib3 FROM Entidade WHERE Entidade.atrib1 = val1 AND Entidade.atrib2 = val2 (c) Inserção de Instância INSERT INTO Entidade (atrib1, atrib2, atrib3) VALUES (val1, val2, val3) (d) Remoção de Instância pkent π pk (σ Entidade.atrib1=val1 AND SELECT INTO pkent pk Entidade.atrib2=val2(Entidade)) Entidade Entidade - FROM Entidade WHERE Entidade.atrib1 = val1 AND Entidade.atrib2 = val2; DELETE FROM Entidade WHERE pk = pkent; σ Entidade.pk=pkEnt (Entidade) (e) Atualização de Instância pkent π pk (σ Entidade.atrib1=val1NMod AND SELECT INTO pkent pk Entidade.atrib2=val2NMod(Entidade)) Entidade π atrib1 val1, atrib2 val2, atrib3 val3 ( σ Entidade.pk=pkEnt (Entidade)) FROM Entidade WHERE Entidade.atrib1 = val1nmod AND Entidade.atrib2 = val2nmod; UPDATE Entidade SET atrib1 = val1, atrib2 = val2, atrib3 = val3 WHERE pk = pkent; Tabela 4.18: Mapeamento de Operações CRUD sobre Tipo de Entidade

74 4.3 Mapeamento do MR para PostgreSQL 72 Código 4.6 Stored Procedure Modelo para Inserção de Instância de Tipo de Entidade 1 CREATE FUNCTION inserirentidade(val1 TipoSQL,val2 TipoSQL,val3 TipoSQL) 2 RETURNS BOOLEAN AS $$ 3 BEGIN 4 5 INSERT INTO Entidade (atrib1, atrib2, atrib3) VALUES (val1, val2, val3); 6 7 RETURN TRUE; 8 END; 9 $$ LANGUAGE plpgsql ; No mapeamento para remoção de instância de entidade, a instrução para obter a chave primária (pk) é mapeada para SQL utilizando a instrução SELECT INTO. As cláusulas FROM e WHERE da consulta são as mesmas usadas para obtenção de uma instância. A operação de exclusão (Entidade Entidade - σ Entidade.pk=pkEnt (Entidade) é mapeada para a instrução DELETE, e a condição da seleção (σ) é mapeada para a cláusula WHERE. A stored procedure recebe como parâmetro os valores dos atributos que formam a chave lógica da relação. O modelo da stored procedure resultante do mapeamento é apresentada no Código 4.7. Código 4.7 Stored Procedure Modelo para Remoção de Instância de Tipo de Entidade 1 CREATE FUNCTION desativarentidade (va1 TipoSQL, val2 TipoSQL) 2 RETURNS BOOLEAN AS $$ 3 DECLARE 4 pkent INTEGER; 5 6 BEGIN 7 8 SELECT INTO pkent pk 9 FROM Entidade 10 WHERE Entidade.atrib1 = val1 AND Entidade.atrib2 = val2; DELETE FROM Entidade WHERE pk = pkent; RETURN TRUE; 15 END; 16 $$ LANGUAGE plpgsql ; No mapeamento para operação de atualização de instância de entidade, a instrução para obtenção da chave primária é mapeada para a instrução SELECT INTO de SQL. A cláusula WHERE é definida partir de uma lista de comparação da operação de seleção no MR. Neste exemplo é a lista de condição Entidade.atrib1 = val1nmod AND Entidade.atrib2 = val2nmod.

75 4.3 Mapeamento do MR para PostgreSQL 73 Na instrução UPDATE é definida uma lista de atribuição dos atributos, com seus respectivos parâmetros separados por vírgula. Esta lista é obtida através da lista da operação de projeção (π). Antes de atribuir a lista à cláusula SET é feita a conversão do operador de atribuição ( ) de álgebra relacional para o operador de atribuição no SQL (=). A cláusula WHERE recebe a lista de condições da operação de seleção para obtenção da tupla que será atualizada. A lista de parâmetros da stored procedure é definida pelos valores da chave lógica da entidade antes da modificação e pelos valores dos atributos da relação. Na stored procedure do Código 4.8 a chave lógica da relação é composta pelos atributos atrib1 e atrib2 e a lista de parâmetros é definida pelos valores val1nmod, val2nmod, val1, val2 e val3. Código 4.8 Stored Procedure Modelo para Atualização de Instância de Tipo de Entidade 1 CREATE FUNCTION atualizarentidade (va1nmod TipoSQL, 2 val2nmod TipoSQL, val1 TipoSQL, val2 TipoSQL, val3 TipoSQL) 3 RETURNS BOOLEAN AS $$ 4 DECLARE 5 pkent INTEGER; 6 7 BEGIN 8 9 SELECT INTO pkent pk 10 FROM Entidade 11 WHERE Entidade.atrib1 = val1nmod AND 12 Entidade.atrib2 = val2nmod; UPDATE Entidade 15 SET atrib1 = val1, atrib2 = val2, atrib3 = val3 16 WHERE pk = pkent; RETURN TRUE; 19 END; 20 $$ LANGUAGE plpgsql ; A Tabela 4.19 apresenta o mapeamento do MR para SQL para operações CRUD sobre tipo de entidade especializada. Nas operações de consulta, a lista de atributos da operação de projeção (π) é mapeada para a lista da cláusula SELECT. A lista de relações da operação de seleção é mapeada para a cláusula FROM, substituindo o produto cartesiano ( ) pelo operador de junção (JOIN). No PostgreSQL a condição de junção pode ficar na clásula FROM, então a condição da operação de seleção é mapeada para a cláusula FROM da consulta em SQL.

76 4.3 Mapeamento do MR para PostgreSQL 74 Para criar a SP para obtenção de uma instância de entidade especializada, o mapeamento segue a definição da Tabela A cláusula WHERE recebe a condição da operação de seleção (σ), que faz a comparação dos atributos chave da relação que corresponde à superentidade (atriba) com os valores de pesquisa (vala). A stored procedure para obtenção de uma instância de entidade especializada recebe como parâmetro os valores da chave lógica da superentidade. A variável vala é mapeada para a lista de parâmetros da stored procedure. O Código 4.9 apresenta o modelo da SP resultante do mapeamento. Código 4.9 Stored Procedure Modelo para Obtenção de Instâncias de Tipo de Entidade Especializada 1 CREATE FUNCTION obtersubentidadeativo(vala TipoSQL) 2 RETURNS CURSOR AS $$ 3 DECLARE 4 csr CURSOR; 5 BEGIN 6 OPEN csr FOR 7 SELECT atriba, atribb, atrib1, atrib2, atrib3 8 FROM SuperEntidade JOIN SubEntidade 9 ON SuperEntidade.pk = SubEntidade.pk 10 WHERE SuperEntidade.atribA = vala; RETURN csr; 13 END; 14 $$ LANGUAGE plpgsql ; No mapeamento para geração de stored procedure de inserção de instância de entidade especializada, primeiramente é inserida a instância da superentidade. A instrução INSERT possui duas listas, uma com os atributos da tabela que recebem os valores e uma com os parâmetros contendo os valores. A primeira lista é obtida a partir da lista de atributos da relação da superentidade (menos o atributo pk) e a lista de valores (vala, valb) vem da instrução de inserção no MR (menos a variável pkent). A chave primária da superentidade é propagada para toda a cadeia de especialização, e para isso é definida a instrução pkent max pk (SuperEntidade) para obter a chave após a inserção. Esta instrução é mapeada para a instrução SELECT INTO pkent * FROM lastval() que obtém o último valor incrementado, dentro da transação, para colunas do tipo SERIAL. O mapeamento da instrução de inserção para subentidade segue o mesmo princípio da instrução para inserção de instância da superentidade. A stored procedure de inserção para entidade especializada recebe como parâmetros os valores dos atributos da

77 4.3 Mapeamento do MR para PostgreSQL 75 MR SQL (a) Obtenção de Instâncias SELECT atriba, atribb, atrib1, atrib2, π atriba,atribb,atrib1,atrib2,atrib3 ( atrib3 σ SuperEntidade.pk=SubEntidade.pk FROM SuperEntidade JOIN SubEntidade (SuperEntidade SubEntidade) ON SuperEntidade.pk = SubEntidade.pk; ) (b) Obtenção de Instância SELECT atriba, atribb, atrib1, atrib2, π atriba,atribb,atrib1,atrib2,atrib3 ( atrib3 FROM SuperEntidade JOIN SubEntidade σ SuperEntidade.pk=SubEntidade.pk AND SuperEntidade.atribA=valA(SuperEntidade ON SuperEntidade.pk = SubEntidade.pk SubEntidade) ) WHERE SuperEntidade.atribA = vala; (c) Inserção de Instância pkent max pk (SuperEntidade) + 1 SuperEntidade SuperEntidade {(pkent, vala, valb)} INSERT INTO SuperEntidade (atriba, atribb) VALUES (vala, valb); pkent max pk (SuperEntidade) SELECT INTO pkent * FROM lastval(); SubEntidade SubEntidade {(pkent, INSERT INTO SubEntidade (pk, atrib1, val1, val2, val3)} atrib2, atrib3) VALUES (pkent, val1, val2, val3); (d) Remoção de Instância pkent π pk ( SELECT INTO pkent pk σ SuperEntidade.atribA=valA (SuperEntidade)) FROM SuperEntidade WHERE SuperEntidade.atribA = vala; DELETE FROM SubEntidade WHERE SubEntidade SubEntidade - pk = pkent; σ SubEntidade.pk=pkEnt (SubEntidade) (e) Atualização de Instância pkent π pk ( SELECT INTO pkent pk σ SuperEntidade.atribA=valANMod FROM SuperEntidade WHERE SuperEntidade.atribA = valan- (SuperEntidade)) Mod; UPDATE SuperEntidade SET atriba = SuperEntidade vala, atribb = valb π atriba vala, atribb valb ( WHERE pk = pkent; σ SuperEntidade.pk=pkEnt (SuperEntidade)) ) SubEntidade π atrib1 val1, atrib2 val2, atrib3 val3 ( σ SubEntidade.pk=pkEnt (SubEntidade)) UPDATE SubEntidade SET atrib1 = val1, atrib2 = val2, atrib3 = val3 WHERE pk = pkent; Tabela 4.19: Mapeamento de Operações CRUD sobre Tipo de Entidade Especializada

78 4.3 Mapeamento do MR para PostgreSQL 76 superentidade e da subentidade. O Código 4.10 apresenta o modelo da stored procedure resultante deste mapeamento. Código 4.10 Stored Procedure Modelo para Inserção de Instância de Tipo de Entidade Especializada 1 CREATE FUNCTION inserirsubentidade (vala TipoSQL, valb TipoSQL, 2 val1 TipoSQL, val2 TipoSQL, val3 TipoSQL) RETURNS BOOLEAN AS 3 DECLARE 4 pkent INTEGER; 5 BEGIN 6 INSERT INTO SuperEntidade (atriba, atribb) VALUES (vala, valb); 7 SELECT INTO pkent * FROM lastval(); 8 INSERT INTO SubEntidade (pk, atrib1, atrib2, atrib3) 9 VALUES (pkent, val1, val2, val3); 10 RETURN TRUE; 11 END; 12 $$ LANGUAGE plpgsql ; No mapeamento para geração de stored procedure de remoção de instância de entidade especializada, a instrução pkent π pk (σ SuperEntidade.atribA=valA (SuperEntidade)) é mapeada para a instrução SQL: SELECT INTO pkent pk FROM SuperEntidade WHERE SuperEntidade.atribA = vala. A instrução de exclusão em álgebra relacional é mapeada para a instrução DELETE em SQL. A tabela da cláusula DELETE é o nome da relação, e a condição da cláusula WHERE é a condição da operação de seleção (σ). A SP de remoção para entidade especializada recebe como parâmetros os valores dos atributos que compõem a chave lógica da superentidade. O modelo da stored procedure do Código 4.11 é obtido a partir do mapeamento descrito na Tabela Código 4.11 Stored Procedure Modelo para Remoção de Instância de Tipo de Entidade Especializada 1 CREATE FUNCTION desativarsubentidade (vala TipoSQL)RETURNS BOOLEAN AS $$ 2 DECLARE 3 pkent INTEGER; 4 BEGIN 5 SELECT INTO pkent pk FROM SuperEntidade 6 WHERE SuperEntidade.atribA = vala; 7 DELETE FROM SubEntidade WHERE pk = pkent; 8 RETURN TRUE; 9 END; 10 $$ LANGUAGE plpgsql ;

79 4.3 Mapeamento do MR para PostgreSQL 77 No mapeamento para geração de stored procedure de atualização de instância de entidade especializada, cada entidade possui uma instrução UPDATE para atualização de seus atributos. Na instrução UPDATE para superentidade é definida uma lista de atribuição dos atributos com seus respectivos parâmetros separados por vírgula. Esta lista é obtida através da lista da operação de projeção (π). Antes de atribuir a lista à cláusula SET é feita a conversão do operador de atribuição ( ) de álgebra relacional para o operador de atribuição em SQL (=). O mapeamento da instrução de atualização para subentidade é feito da mesma forma. A cláusula WHERE recebe a lista de condições da operação de seleção para obtenção da tupla que será atualizada. A stored procedure de atualização recebe como parâmetros os valores dos atributos da chave lógica da superentidade antes da modificação, os valores de todos os atributos da superentidade e os valores dos atributos simples da subentidade. O modelo da stored procedure resultante do mapeamento é apresentado no Código 4.12 Código 4.12 Stored Procedure Modelo para Atualização de Instância de Tipo de Entidade Especializada 1 CREATE FUNCTION atualizarsubentidade (valanmod TipoSQL, 2 vala TipoSQL, valb TipoSQL, val1 TipoSQL, val2 TipoSQL, 3 val3 TipoSQL) RETURNS BOOLEAN AS $$ 4 BEGIN 5 6 SELECT INTO pkent pk 7 FROM SuperEntidade 8 WHERE SuperEntidade.atribA = valanmod; 9 10 UPDATE SuperEntidade 11 SET atriba = vala, atribb = valb 12 WHERE pk = pkent; UPDATE SubEntidade 15 SET atrib1 = val1, atrib2 = val2, atrib3 = val3 16 WHERE pk = pkent; RETURN TRUE; 19 END; 20 $$ LANGUAGE plpgsql ; Todas as SP de operações CRUD para relações que representam atributo do tipo objeto interno recebem como parâmetro os valores da chave lógica da entidade à qual o atributo pertence. Na operação de consulta, somente a chave lógica da entidade é

80 4.3 Mapeamento do MR para PostgreSQL 78 passada como parâmetro. Nas operações de inserção e atualização, além da chave lógica da entidade à qual o atributo pertence, é passada a chave lógica da entidade de referência e, se for o caso, os subatributos. Na operação de remoção somente os valores das chaves lógicas das entidades envolvidas são passados como parâmetro. As consultas para obtenção da chave primária que fazem parte do processamento para as operações de inserção, remoção e atualização são mapeadas da mesma forma que a consulta para obtenção de instâncias de atributo objeto interno. A Tabela 4.20 apresenta o mapeamento do MR para SQL para as operações CRUD sobre atributo objeto interno. Tabela 4.20: Mapeamento de Operações CRUD sobre Atributo Objeto Interno MR π EntidadeRe f.atrib1,entidadere f.atrib2 ( σ Entidade.pk=Ob jetointerno.pkentidade AND Ob jetointerno.pkentidadere f =EntidadeRe f.pk AND Entidade.atrib1=val1 EntidadeRe f.atriba=vala AND EntidadeRe f.atribb=valb (Entidade ObjetoInterno EntidadeRef)) π EntidadeRe f.atrib1,entidadere f.atrib2 ( σ Entidade.pk=Ob jetointerno.pkentidade AND Ob jetointerno.pkentidadere f =EntidadeRe f.pk AND Entidade.atrib1=val1 (Entidade ObjetoInterno EntidadeRef)) pkent π pk (σ Entidade.atribA=valA SQL (a) Obtenção de Instâncias SELECT INTO pkent pk FROM Entidade WHERE Entidade.atrib1 = val1; SELECT EntidadeRef.atribA, EntidadeRef.atribB FROM Entidade JOIN ObjetoInterno ON Entidade.pk = ObjetoInterno.pkEntidade FROM EntidadeRef JOIN EntidadeRef ON ObjetoInterno.pkEntidadeRef = EntidadeRef.pk WHERE Entidade.pk = pkent AND EntidadeRef.atribA = vala And EntidadeRef.atribB = valb; (b) Obtenção de Instância SELECT INTO pkent pk FROM Entidade WHERE Entidade.atrib1 = val1; SELECT EntidadeRef.atribA, EntidadeRef.atribB FROM Entidade JOIN ObjetoInterno ON Entidade.pk = ObjetoInterno.pkEntidade JOIN EntidadeRef ON ObjetoInterno.pkEntidadeRef = EntidadeRef.pk WHERE Entidade.pk = pkent; (c) Inserção de Instância SELECT INTO pkent pk Continua na próxima página

81 4.3 Mapeamento do MR para PostgreSQL 79 Continuação da Tabela 4.20 MR SQL (Entidade)) FROM Entidade WHERE Entidade.atrib1 = val1; pkentref π pk ( SELECT INTO pkentref pk σ EntidadeRe f.atriba=vala AND FROM EntidadeRef EntidadeRe f.atribb=valb(entidaderef) WHERE EntidadeRef.atribA = vala AND ) EntidadeRef.atribB = valb pknovo max pk (ObjetoInterno) INSERT INTO ObjetoInterno(pkEntidade, ObjetoInterno ObjetoInterno {(pknovo, pkentidaderef) VALUES (pkent, pkentref, pkent, pkentref, subatrib1)} subval1); (d) Remoção de Instância pkent π pk (σ Entidade.atribA=valA SELECT INTO pkent pk FROM Entidade WHERE Entidade.atrib1 = (Entidade)) val1; pkentref π pk ( SELECT INTO pkentref pk σ EntidadeRe f.atriba=vala AND FROM EntidadeRef EntidadeRe f.atribb=valb(entidaderef) WHERE EntidadeRef.atribA = vala AND ) EntidadeRef.atribB = valb; Ob jetointerno.pkentidadere f =pkentre f ObjetoInterno ObjetoInterno - DELETE FROM ObjetoInterno WHERE pkentidade = pkent AND pkentidaderef = σ Ob jetointerno.pkentidade=pkent AND pkentref; (ObjetoInterno) (e) Atualização de Instância pkent π pk (σ Entidade.atribA=valA SELECT INTO pkent pk FROM Entidade WHERE Entidade.atrib1 = (Entidade)) val1; pkentref π pk ( SELECT INTO pkentref pk σ EntidadeRe f.atriba=vala AND EntidadeRe f.atribb=valb(entidaderef)) ObjetoInterno π subatrib1 subval1 ( σ Ob jetointerno.pkentidade=pkent AND Ob jetointerno.pkentidadere f =pkentre f (ObjetoInterno)) FROM EntidadeRef WHERE EntidadeRef.atribA = vala AND EntidadeRef.atribB = valb; UPDATE ObjetoInterno SET subatrib1 = subval1 WHERE pkentidade = pkent AND pkentidaderef = pkentref; Continua na próxima página

82 4.3 Mapeamento do MR para PostgreSQL 80 Continuação da Tabela 4.20 MR SQL A lista de atributos da operação de projeção (π) é mapeada para a lista da cláusula SELECT de SQL. A lista de relações da operação de seleção é mapeada para a cláusula FROM, substituindo o produto cartesiano ( ) pelo operador de junção (JOIN). A condição da operação de seleção é mapeada para a cláusula FROM da consulta em SQL. Na cláusula WHERE é inserida a condição da consulta, que é composta pela comparação entre os valores e os atributos que compõem a chave lógica da entidade à qual o atributo objeto interno pertence. O Mapeamento para consulta de atributo objeto interno para agregação descrito na Tabela 4.21 é feito da mesma forma. Os modelos das SPs resultante dos mapeamentos das Tabelas 4.20 e 4.21 são apresentados nos Códigos 4.13 e 4.17, repectivamente. Código 4.13 Stored Procedure Modelo para Obtenção de Instâncias de Atributo Objeto Interno 1 CREATE FUNCTION obterobjetointernoativo(val1 TipoSQL) 2 RETURNS CURSOR AS $$ 3 DECLARE 4 csr CURSOR; 5 pkent INTEGER; 6 7 BEGIN 8 SELECT INTO pkent pk 9 FROM Entidade 10 WHERE Entidade.atrib1 = val1; OPEN csr FOR 13 SELECT EntidadeRef.atribA, EntidadeRef.atribB 14 FROM Entidade JOIN ObjetoInterno 15 ON Entidade.pk = ObjetoInterno.pkEntidade 16 JOIN EntidadeRef 17 ON ObjetoInterno.pkEntidadeRef = EntidadeRef.pk 18 WHERE Entidade.pk = pkent; RETURN TRUE; 21 END; 22 $$ LANGUAGE plpgsql ; No mapeamento para geração de stored procedure de inserção de instâncias de atributo objeto interno o nome da relação é mapeado para o nome da tabela na instrução INSERT. Esta instrução possui duas listas, uma com os atributos da tabela que recebem os valores, e uma com os parâmetros contendo os valores. A primeira lista é obtida a partir

83 4.3 Mapeamento do MR para PostgreSQL 81 da lista de atributos da relação do atributo menos o atributo pk, e a segunda lista de valores (pknovo, pkent, pkentref, subval1) vem da instrução de inserção no MR menos a variável pknovo. O Mapeamento para inserção de instâncias de atributo objeto interno para agregação, descrito na Tabela 4.20, é feito da mesma forma. Os modelos das stored procedures, de inserção resultantes dos mapeamentos das Tabelas 4.20 e 4.21 são apresentados, respectivamente, nos Códigos 4.14 e Código 4.14 Stored Procedure Modelo para Inserção de Instância de Atributo Objeto Interno 1 CREATE FUNCTION inserirobjetointerno(val1 TipoSQL, 2 vala TipoSQL, valb TipoSQL, subval1) RETURNS BOOLEAN AS $$ 3 DECLARE 4 pkent INTEGER; 5 pkentref INTEGER; 6 BEGIN 7 SELECT INTO pkent pk FROM Entidade 8 WHERE Entidade.atrib1 = val1; 9 SELECT INTO pkentref pk FROM EntidadeRef 10 WHERE EntidadeRef.atribA = vala AND 11 EntidadeRef.atribB = valb; INSERT INTO ObjetoInterno(pkEntidade, 14 pkentidaderef) VALUES (pkent, pkentref, subval1); RETURN TRUE; 17 END; 18 $$ LANGUAGE plpgsql ; No mapeamento para geração de stored procedure de remoção de instâncias de atributo objeto interno a instrução de exclusão em álgebra relacional é mapeada para a instrução DELETE em SQL. A tabela da cláusula DELETE é a relação na instrução em álgebra relacional, e a condição da cláusula WHERE é a condição da operação de seleção (σ). O Mapeamento para remoção de instâncias de atributo objeto interno para agregação, descrito na Tabela 4.21, é feito da mesma forma. Os modelos das stored procedures de remoção de instância resultantes dos mapeamentos das Tabelas 4.20 e 4.21 são apresentados nos Códigos 4.15 e 4.19, respectivamente.

84 4.3 Mapeamento do MR para PostgreSQL 82 Código 4.15 Stored Procedure Modelo para Remoção de Instância de Atributo Objeto Interno 1 CREATE FUNCTION desativarobjetointerno (val1 TipoSQL, 2 vala TipoSQL, valb TipoSQL) RETURNS BOOLEAN AS $$ 3 DECLARE 4 pkent INTEGER; 5 pkentref INTEGER; 6 BEGIN 7 SELECT INTO pkent pk FROM Entidade 8 WHERE Entidade.atrib1 = val1; 9 SELECT INTO pkentref pk FROM EntidadeRef 10 WHERE EntidadeRef.atribA = vala AND 11 EntidadeRef.atribB = valb; DELETE FROM ObjetoInterno 14 WHERE pkentidade = pkent AND 15 pkentidaderef = pkentref; RETURN TRUE; 18 END; 19 $$ LANGUAGE plpgsql ; No mapeamento para geração de stored procedure de atualização de instâncias de atributo objeto interno a instrução de atualização em álgebra relacional é mapeada para a instrução UPDATE, e o nome da relação na instrução em álgebra relacional é o nome da tabela na instrução UPDATE. A lista de atribuições da operação de projeção (π subatrib1 subval1 ) é mapeada para a cláusula SET, convertendo o operador de atribuição ( ) de álgebra relacional para o operador de atribuição em SQL (=). A cláusula WHERE recebe a lista de condições da operação de seleção (ObjetoInterno.pkEntidade = pkent AND ObjetoInterno.pkEntidadeRef = pkentref). O Mapeamento para atualização de instâncias de atributo objeto interno para agregação, descrito na Tabela 4.21, é feito da mesma forma. Os modelos das stored procedures resultantes dos mapeamentos para operação de atualização das Tabelas 4.20 e 4.21 são apresentados nos Códigos 4.16 e 4.20, respectivamente.

85 4.3 Mapeamento do MR para PostgreSQL 83 Código 4.16 Stored Procedure Modelo para Atualização de Instância de Atributo Objeto Interno 1 CREATE FUNCTION atualizarobjetointerno (val1 TipoSQL, 2 vala TipoSQL, valb TipoSQL, subval1) RETURNS BOOLEAN AS $$ 3 DECLARE 4 pkent INTEGER; 5 pkentref INTEGER; 6 BEGIN 7 SELECT INTO pkent pk FROM Entidade 8 WHERE Entidade.atrib1 = val1; 9 SELECT INTO pkentref pk FROM EntidadeRef 10 WHERE EntidadeRef.atribA = vala AND 11 EntidadeRef.atribB = valb; UPDATE ObjetoInterno 14 SET subatrib1 = subval1 15 WHERE pkentidade = pkent AND 16 pkentidaderef = pkentref; RETURN TRUE; 19 END; 20 $$ LANGUAGE plpgsql ; Tabela 4.21: Mapeamento de Operações CRUD sobre Atributo Objeito Interno (Agregação) MR SQL (a) Obtenção de Instâncias SELECT INTO pkent pk FROM Entidade WHERE Entidade.atrib1 = val1; SELECT EntidadeRef.atribA, EntidadeRef.atribB, π EntidadeRe f.atriba,entidadere f.atribb, EntidadeAtribRef.atribX EntidadeAtribRe f.atribx( σ Entidade.pk=Ob jetointerno.pkentidade AND Ob jetointerno.pkatributore f =AtributoRe f.pk AND AtributoRe f.pkent=entidade.pk AND AtributoRe f.pkentre f =EntidadeRe f.pk AND Entidade.atrib1=val1 (Entidade ObjetoInterno AtributoRef FROM Entidade JOIN ObjetoInterno ON Entidade.pk = ObjetoInterno.pkEntidade JOIN AtributoRef ON ObjetoInterno.pkAtributoRef = AtributoRef.pk JOIN EntidadeAtribRef ON AtributoRef.pkEntRef = EntidadeAtribRef.pk Continua na próxima página

86 4.3 Mapeamento do MR para PostgreSQL 84 Continuação da Tabela 4.21 MR EntidadeRef EntidadeAtribRef)) SQL WHERE Entidade.pk = pkent; (b) Obtenção de Instância SELECT INTO pkent pk FROM Entidade WHERE Entidade.atrib1 = val1; SELECT EntidadeRef.atribA, EntidadeRef.atribB, π EntidadeRe f.atriba,entidadere f.atribb, EntidadeAtribRef.atribX EntidadeAtribRe f.atribx( σ Entidade.pk=Ob jetointerno.pkentidade AND Ob jetointerno.pkatributore f =AtributoRe f.pk AND AtributoRe f.pkent=entidade.pk AND AtributoRe f.pkentre f =EntidadeRe f.pk AND Entidade.atrib1=val1 AND EntidadeRe f.atriba=vala EntidadeAtribRe f.atribx=valx) (Entidade ObjetoInterno AtributoRef EntidadeRef EntidadeAtribRef)) pkent π pk ( σ Entidade.atribA=valA (Entidade)) pkatribref π pk ( σ AtributoRe f.pkentidadere f =EntidadeRe f.pk AND AtributoRe f.pkentre f =EntidadeAtribRe f.pk AND FROM Entidade JOIN ObjetoInterno ON Entidade.pk = ObjetoInterno.pkEntidade JOIN AtributoRef ON ObjetoInterno.pkAtributoRef = AtributoRef.pk JOIN EntidadeAtribRef ON AtributoRef.pkEntRef = EntidadeAtribRef.pk WHERE Entidade.pk = pkent; (c) Inserção de Instância SELECT INTO pkent pk FROM Entidade WHERE Entidade.atrib1 = val1; SELECT INTO pkatribref pk FROM EntidadeRef JOIN AtributoRef ON EntidadeRef.pk = AtributoRef.pkEntRef EntidadeRe f.atriba=vala AND JOIN EntidadeAtribRef EntidadeAtribRe f.atribx=valx(entidaderef ON AtributoRef.pkEntidadeAtribRef = EntidadeAtribRef.pk AtributoRef EntidadeAtribRef) WHERE EntidadeRef.atribA = vala AND pknovo max pk (ObjetoInterno) ObjetoInterno ObjetoInterno {(pknovo, pkent, pkatribref, subatrib1)} pkent π pk ( σ Entidade.atribA=valA (Entidade)) EntidadeAtribRef.atribX = valx; INSERT INTO ObjetoInterno(pkEnt, pkatribref) VALUES (pkent, pkatribref, subval1); (d) Remoção de Instância SELECT INTO pkent pk FROM Entidade WHERE Entidade.atrib1 = val1; Continua na próxima página

87 4.3 Mapeamento do MR para PostgreSQL 85 Continuação da Tabela 4.21 MR SQL pkatribref π pk ( SELECT INTO pkatribref pk σ AtributoRe f.pkentidadere f =EntidadeRe f.pk AND AtributoRe f.pkentre f =EntidadeAtribRe f.pk AND EntidadeRe f.atriba=vala AND EntidadeAtribRef.atribX = valx; DELETE FROM ObjetoInterno WHERE ObjetoInterno ObjetoInterno - pkentidade = pkent AND pkatributoref = pkatribref; σ Ob jetointerno.pkentidade=pkent AND Ob jetointerno.pkatributore f =pkatribre f FROM EntidadeRef JOIN AtributoRef ON EntidadeRef.pk = AtributoRef.pkEntRef JOIN EntidadeAtribRef EntidadeAtribRe f.atribx=valx(entidaderef ON AtributoRef.pkEntidadeAtribRef = EntidadeAtribRef.pk AtributoRef EntidadeAtribRef) WHERE EntidadeRef.atribA = vala AND (ObjetoInterno) (e) Atualização de Instância pkent π pk ( SELECT INTO pkent pk FROM Entidade WHERE Entidade.atrib1 = σ Entidade.atribA=valA (Entidade)) val1; pkatribref π pk ( SELECT INTO pkatribref pk σ AtributoRe f.pkentidadere f =EntidadeRe f.pk AND AtributoRe f.pkentre f =EntidadeAtribRe f.pk AND EntidadeRe f.atriba=vala AND EntidadeAtribRef.atribX = valx; ObjetoInterno π subatrib1 subval1 ( UPDATE ObjetoInterno σ Ob jetointerno.pkentidade=pkent AND Ob jetointerno.pkatributore f =pkatribre f (ObjetoInterno) FROM EntidadeRef JOIN AtributoRef ON EntidadeRef.pk = AtributoRef.pkEntRef JOIN EntidadeAtribRef EntidadeAtribRe f.atribx=valx(entidaderef ON AtributoRef.pkEntidadeAtribRef = EntidadeAtribRef.pk AtributoRef EntidadeAtribRef) WHERE EntidadeRef.atribA = vala AND SET subatrib1 = subval1 WHERE pkentidade = pkent AND pkatributoref = pkatribref;

88 4.3 Mapeamento do MR para PostgreSQL 86 Código 4.17 Stored Procedure Modelo para Obtenção de Instâncias de Atributo Objeto Interno (Agregacao) 1 CREATE FUNCTION obterobjetointernoativo(val1 TipoSQL) 2 RETURNS CURSOR AS $$ 3 DECLARE 4 csr REFCURSOR; 5 pkent INTEGER; 6 BEGIN 7 SELECT INTO pkent pk FROM Entidade WHERE Entidade.atrib1 = val1; 8 OPEN csr FOR 9 SELECT EntidadeRef.atribA, EntidadeRef.atribB, EntidadeAtribRef.atribX 10 FROM Entidade JOIN ObjetoInterno ON Entidade.pk = ObjetoInterno.pkEntidade 11 JOIN AtributoRef ON ObjetoInterno.pkAtribRef = AtributoRef.pk 12 JOIN EntidadeRef ON AtributoRef.pkEntRef = EntidadeRef.pk 13 JOIN EntidadeAtribRef ON AtributoRef.pkEntRef = EntidadeAtribRef.pk 14 WHERE Entidade.pk = pkent; 15 RETURN csr; 16 END; 17 $$ LANGUAGE plpgsql ; Código 4.18 Stored Procedure Modelo para Inserção de Instância de Atributo Objeto Interno (Agregação) 1 CREATE inserirobjetointerno(val1 TipoSQL, valatiposql, valx TipoSQL, 2 subatrib1 TipoSQL) RETURNS BOOLEAN AS 3 DECLARE 4 pkent INTEGER; 5 pkatribref INTEGER; 6 BEGIN 7 SELECT INTO pkent pk FROM Entidade WHERE Entidade.atrib1 = val1; 8 9 SELECT INTO pkatribref pk FROM EntidadeRef JOIN AtributoRef 10 ON EntidadeRef.pk = AtributoRef.pkEntidadeRef 11 JOIN EntidadeAtribRef 12 ON AtributoRef.pkEntidadeAtribRef = EntidadeAtribRef.pk 13 WHERE EntidadeRef.atribA = vala AND 14 EntidadeAtribRef.atribX = valx; INSERT INTO ObjetoInterno(pkEntidade, pkatributoref, subatrib1) 17 VALUES (pkent, pkatribref, subval1); 18 RETURN TRUE; 19 END; 20 $$ LANGUAGE plpgsql ;

89 4.3 Mapeamento do MR para PostgreSQL 87 Código 4.19 Stored Procedure Modelo para Remoção de Instância de Atributo Objeto Interno (Agregação) 1 CREATE FUNCTION desativarobjetointerno(val1 TipoSQL, valatiposql, valx TipoSQL) 2 RETURNS BOOLEAN AS 3 DECLARE 4 pkent INTEGER; 5 pkatribref INTEGER; 6 BEGIN 7 SELECT INTO pkent pk FROM Entidade WHERE Entidade.atrib1 = val1; 8 SELECT INTO pkatribref pk FROM EntidadeRef JOIN AtributoRef 9 ON EntidadeRef.pk = AtributoRef.pkEntidadeRef 10 JOIN EntidadeAtribRef 11 ON AtributoRef.pkEntidadeAtribRef = EntidadeAtribRef.pk 12 WHERE EntidadeRef.atribA = vala AND 13 EntidadeAtribRef.atribX = valx; 14 DELETE FROM ObjetoInterno WHERE pkentidade = pkent AND 15 pkatributoref = pkatribref; 16 RETURN TRUE; 17 END; 18 $$ LANGUAGE plpgsql ; Código 4.20 Stored Procedure Modelo para Atualização de Instância de Atributo Objeto Interno (Agregação) 1 CREATE FUNCTION atualizarobjetointerno(val1 TipoSQL, valatiposql, 2 valx TipoSQL, subatrib1 TipoSQL) RETURNS BOOLEAN AS 3 DECLARE 4 pkent INTEGER; 5 pkatribref INTEGER; 6 BEGIN 7 SELECT INTO pkent pk FROM Entidade WHERE Entidade.atrib1 = val1; 8 SELECT INTO pkatribref pk FROM EntidadeRef 9 JOIN AtributoRef ON EntidadeRef.pk = AtributoRef.pkEntidadeRef 10 JOIN EntidadeAtribRef ON AtributoRef.pkEntidadeAtribRef = EntidadeAtribRef.pk 11 WHERE EntidadeRef.atribA = vala AND EntidadeAtribRef.atribX = valx; UPDATE ObjetoInterno SET subatrib1 = subval1 14 WHERE pkentidade = pkent AND pkatributoref = pkatribref; 15 RETURN TRUE; 16 END; 17 $$ LANGUAGE plpgsql ; Os mapeamentos do MR para SQL para Entidade Fraca, Atributo Composto e Atributo Simples Multvalorado são apresentados no Apêndice B, pois a ideia aplicada a estes mapeamentos são análogas às apresentadas nos mapeamentos discutidos nesta

90 4.3 Mapeamento do MR para PostgreSQL 88 seção. O próximo capítulo traz exemplos da utilização desses mapeamentos em aplicações do componente EBD. Este capítulo apresentou os mapeamentos do MMO para o MR em termos de estruturas e operações (Seções 4.1 e 4.2), e deste para o SQL do SGBD PostgreSQL (Seção 4.3).

91 Funcionamento do Componente EBD CAPÍTULO 5 Este capítulo apresenta a criação (Seção 5.1) e utilização (Seção 5.2) de SI a partir do framework do qual o componente EBD faz parte. A Seção 5.3 apresenta exemplos de criação de uma pequena porção do esquema de um SI real do domínio agropecuário. 5.1 Criação de Sistema de Informação Os componentes de SI gerados pelo framework incluem [21]: a) software de aplicação e interface com o usuário; b) esquemas e restrições de integridade de bancos de dados; e c) regras de negócio que podem ser disparadas a partir de eventos de bancos de dados ou de funções de aplicação. Em [12] são encontrados detalhes sobre o mecanismo de geração de regras do framework. O mecanismo de geração de interface do framework é detalhado em [18]. As meta-informações do SI são obtidas a partir de um formulário de cadastro de Tipo de Entidade, mostrado na Figura 5.1. Neste cadastro são registradas informações sobre representação e apresentação de dados utilizadas, respectivamente, na geração do banco de dados e da interface. Cada tipo de entidade possui um conjunto de atributos e as informações de cada um deles são obtidas a partir do formulário de cadastro da Figura 5.2. O MMO não permite a definição de regras dinâmicas, tais como regras de derivação. No entanto, o framework permite a utilização de Object Constraint Language (OCL) [13]. Para cadastrar as regras de um tipo de entidade é utilizado o editor de OCL do framework. As regras dinâmicas de tipo de entidade e regras de atributos são definidas neste editor e são associadas aos respectivos atributos ou tipo de entidade pelo cadastro da Figura 5.1. Utilizando o cadastro de Tipo de Entidade e o editor de Regras é possível definir as informações de um tipo de entidade do SI, que são validadas e armazenadas no BD. Persistidas as informações, o framework gera automaticamente as tabelas e stored procedures para manipulação e validação de informações do tipo de entidade gerado,

92 5.2 Utilização do Sistema de Informação 90 Figura 5.1: Formulário para Cadastro de Tipo de Entidade do SI utilizando os mapeamentos apresentados no Capítulo 4. A partir desta geração, o SI fica disponível para uso. 5.2 Utilização do Sistema de Informação Após a geração das tabelas e stored procedures os formulários para manipulação dos dados das entidades são disponibilizados para uso. Quando o usuário acessa um formulário, o framework manda uma requisição para o módulo de Interface (conforme a Figura 3.1) que obtém os metadados da entidade e gera, em tempo de execução, a interface para manipulação de informações. A Figura 5.3 apresenta um exemplo de formulário para manipulação de instâncias do tipo de entidade pessoa física. A interface gerada pelo framework possui duas áreas principais: uma onde estão todas as instâncias de um tipo de entidade e outra destinada ao formulário para manipulação destas instâncias. Nas operações de inserção, remoção e atualização de instância, o módulo Interface obtém a instância da entidade que está sendo manipulada e repassa para o módulo Interface Aplicação, o qual repassa os dados para o módulo Aplicação.

93 5.2 Utilização do Sistema de Informação 91 Figura 5.2: Formulário para Cadastro de Atributo de Tipo de Entidade do SI Operações CRUD Os serviços de manipulação de metadados e dados disponibilizados pelas classes Metadados e ObjetoApresentação (discutidos na Seção 3.3.4) são utilizados nos mecanismos de mapeamento para as operações de inserção, obtenção, atualização e remoção de instâncias de entidade. A Figura 5.4 apresenta o modelo estático das classes envolvidas nestas operações. A classe AplicacaoCadastro fornece as operações CRUD de manipulação de instâncias de entidades. Ela utiliza os métodos da classe ObjetoNegocio para fazer validações de restrições estáticas (cardinalidades mínima, máxima, unicidade e chave lógica). Além de validar as restrições, a classe ObjetoNegocio extrai as informações da instância de entidade (ObjetoApresentacao) de forma que estas sejam passadas para o mecanismo de persistência. Por exemplo, o método tratarinsercaocomposto de ObjetoNegocio sabe que para persistir uma instância de um atributo composto é necessário passar a chave lógica da entidade mais os valores simples monovalorados da instância deste atributo composto. A classe BDMecanismo é uma fachada para o mecanismo de BD do framework. Ela tem a função de repassar os parâmetros para as stored procedure no BD através do Objeto CallableStatement do pacote externo java.sql. Ela possui alguns serviços, como verificar se o valor da chave lógica de uma entidade existe no BD, obter o valor de atributo

94 5.2 Utilização do Sistema de Informação 92 Figura 5.3: Exemplo de Tela de Manipulação de Pessoa Física gerada pelo framework derivado e obter metadados de entidade. A classe Persistencia tem como função abrir e fechar conexão, abrir transação, fazer commit de transação e executar operações no BD (seleção, inserção, remoção, atualização ou outros serviços disponíveis no framework). A seguir, são apresentados os mecanismos para inserção, obteção, atualização e remoção de instâncias de entidades de SI. Inserção de Instância de uma Entidade O processamento para persistir uma instância de entidade envolve uma série de operações, tais como controle de transação, validação dos dados na instância e mapeamento dos dados para o esquema da entidade no BD. A Figura 5.5 mostra a colaboração das classes das camadas de Aplicação, Negócio e Persistência para executar a inserção de uma instância de entidade. A camada Aplicação é responsável pelo controle de transações nas operações de manipulações de instâncias de entidade. Antes de fazer o desmembramento da instância em partes que são repassadas para o BD, são executadas operações de validação. As restrições estruturais de domínio, chave, unicidade, cardinalidade mínima e máxima de atributos e relacionamentos são verificadas pela classe ObjetoNegocio, enquanto as validações de regras dinâmicas são tratadas pela classe Regras.

95 5.2 Utilização do Sistema de Informação 93 Figura 5.4: Modelo Estático das Classes Envolvidas nas Operações CRUD Feitas as validações, a instância da entidade é passada para a classe ObjetoNegocio. No método inserir o processo de persistência da instância é iniciado com a extração dos dados que serão mapeados para a tabela que armazena as instâncias da entidade. A classe Metadados possui o conhecimento para extrair as informações da instância da entidade. Os dados são repassados para o método inserirmono da classe BDMecanismo que vai criar uma instrução para passar os dados para a stored procedure que faz a inserção dos dados da entidade. Esta instrução é criada a partir do padrão: tipo de operação (neste caso é inserir) concatenado com o mnemônico da entidade. Os atributos multivalorados do tipo Basico, Enumerado, Composto e Objeto Interno possuem tabelas para armazenar suas instâncias. O método tratarinsercaomulti trata o mapeamento das instâncias de atributos do tipo Basico e Enumerados para suas respec-

96 5.2 Utilização do Sistema de Informação 94 Figura 5.5: Colaboração para mapeamento Objeto-Relacional na operação de Inserção tivas tabelas. O mesmo processamento é feito no método tratarinsercaocomposto para atributos do tipo Composto e Objeto Interno. Estes métodos recebem como parâmetro o

97 5.2 Utilização do Sistema de Informação 95 objeto que representa o atributo multivalorado, as instâncias deste atributo e a chave lógica da entidade. Este método repassa para a classe BDMecanismo o mnemônico do atributo, a chave lógica da entidade e uma instância do atributo. Este processo é repetido até que todas as instâncias do atributo sejam passadas. O processo de criação da instrução que passa os parâmetros para a stored procedure é idêntico ao processo descrito anteriormente para instâncias de entidade. Obtenção de Instância de uma Entidade O mecanismo de obtenção de instâncias permite busca de todas as instâncias da entidade ou busca de uma só instância. A Figura 5.6 mostra o diagrama de colaboração para obtenção de instâncias de entidade. O processamento inicia com a consulta no BD de todas as instâncias de uma entidade. A consulta retorna todos os atributos que pertecem à entidade que não são mapeados para tabelas separadas, como atributos multivalorados do tipo Básico, Enumerado, Objeto Externo ou mesmo Composto e Objeto Interno. A consulta dos atributos multivalorados é feita separadamente. A partir do objeto Metadados da entidade estes atributos são localizados e repassados para os métodos que fazem o tratamento da obtenção. O método recebe o mnemônico do atributo e a chave lógica da entidade. Com estas informações é possível obter todas as instâncias do atributo para a instância da entidade identificada pela chave lógica. As instâncias são empacotadas e retornadas. O método obterativos recebe as instâncias manipuladas pelos metodos tratarobtencaocomposto e tratarobtencaomulti e os coloca na instância da entidade representada pelo ObjetoApresentacao. Este processamento é feito até que todas as instâncias da entidade sejam mapeadas para o ObjetoApresentacao. Atualização de Instância de uma Entidade O processo de atualização de uma instância de entidade é feito a partir da comparação de duas instâncias: a instância que sofreu modificações do usuário e a instância que está armazenada no BD. A Figura 5.7 mostra a colaboração no mapeamento Objeto-Relacional na operação de Atualização. O método atualizar da classe AplicacaoCadastro recebe estas duas instâncias. Utilizando o mecanismo de extração de dados da classe Metadados são extraídos os valores que são mapeados para a tabela da entidade de cada um dos ObjetoApresentacao (sem modificação e com modificação). Estes valores são comparados e, se houve modificação, então estes dados são repassados para a stored procedure de atualização dos dados da entidade.

98 5.2 Utilização do Sistema de Informação 96 Figura 5.6: Colaboração para mapeamento Objeto-Relacional na operação de Consulta O próximo passo é a atualização dos dados de atributos multivalorados. Para tratar a atualização destes atributos dois métodos são utilizados: trataratualizacaocomposto, para os atributos do tipo Compostos e ObjetoInterno; e trataratualizacaomulti, para os atributos do tipo Basico, Enumerado, Objeto Externo multivalorados. A atualização de atributos multivalorados pode ser feita através de três operações: inserir uma nova instância no atributo, remover uma instância existente e modificar uma instância existente. Os métodos trataratualizacaocomposto e trataratualizacaomulti recebem

99 5.2 Utilização do Sistema de Informação 97 como parâmetro a instância sem modificação e a instância com modificação. O método deve comparar as instâncias e verificar quais operações devem ser executadas para que as modificações feitas pelo usuário sejam aplicadas nas instâncias que estão armazenadas no BD. Por exemplo, a atualização de um atributo do tipo Basico multivalorado segue os seguintes passos: Para inserir utilize todos os valores que estão na instância modificada e não estão na instância sem modificação. Para remover utilize todos os valores que estão na instância sem modificação, mas não estão na instância modificada. A utilização deste algoritmo para atualização de instâncias de atributos do tipo Composto pode ter implicações negativas na eficiência para atributos com muitas instâncias. Por exemplo, em um atributo composto com três atributos que possui cem instâncias, se o usuário modificar um dos três em todas as instâncias o mecanismo fará cem remoções e cem inserções, ao invés de fazer somente cem atualizações. A solução utilizada no framework é a indexação da operação (inserir, remover e atualizar) em cada uma das instâncias do composto, permitindo que o mecanismo saiba qual operação executar sem necessidade de comparação entre os conjuntos de instâncias. Remoção de Instância de uma Entidade A remoção de uma instância de entidade envolve operações semelhantes a remoção de nós em árvores. Neste caso somente as folhas podem ser removidas. Este processo é feito até que o nó raiz seja também folha. A remoção da instância da entidade é permitida somente se todas as referências provenientes de atributos multivalorados, compostos ou objeto interno forem removidas. A Figura 5.8 mostra a colaboração para o processo de mapeamento objeto relacional na operação de remoção. No ínicio do processamento para remoção é obtida a instância da entidade no BD e comparada com a instância que será removida. Esta verificação é necessária para evitar que uma instância da entidade modificada concorrentemente por um outro usuário seja removida. O processamento da remoção é iniciado na classe ObjetoNegocio com a busca por atributos multivalorados. Os métodos tratardesativacaocomposto e tratardesativacaomulti possuem a finalidade de remover todas as instâncias do atributo que é passado como parâmetro. O método tratardesativacaocomposto recebe como parâmetro o objeto que representa o atributo Composto, a chave lógica da entidade e as instâncias do atributo. Utilizando o serviço de extração de dado de Metadados, a chave parcial do atributo composto é extraída. Esta chave associada com a chave lógica da entidade e a chave parcial do composto permite remover a instância do composto no BD.

100 5.2 Utilização do Sistema de Informação 98 Figura 5.7: Colaboração para mapeamento Objeto-Relacional na operação de Atualização O mesmo processamento é feito no método tratardesativacaomulti, os parâmetros que são passados para stored procedure de remoção considera a chave parcial do atributo, que é o próprio valor. Após remover todos os atributos multivalorados, o mecanismo remove a instância da entidade do BD.