um componente para geração e evolução de esquemas de

UNIVERSIDADE FEDERAL DE GOIÁS

INSTITUTO DE INFORMÁTICA

ALEXANDRE CLÁUDIO DE ALMEIDA

Um Componente para Geração eEvolução de Esquemas de Bancos deDados como Suporte à Construção de

Sistemas de Informação

Goiânia2010

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 Infor-mática da Universidade Federal de Goiás – UFG a reproduzir, inclusive em outro formatoou mídia e através de armazenamento permanente ou temporário, bem como a publicar narede mundial de computadores (Internet) e na biblioteca virtual da UFG, entendendo-seos termos “reproduzir” e “publicar” conforme definições dos incisos VI e I, respectiva-mente, do artigo 5o da Lei no 9610/98 de 10/02/1998, a obra abaixo especificada, sem queme seja devido pagamento a título de direitos autorais, desde que a reprodução e/ou pub-licação tenham a finalidade exclusiva de uso por quem a consulta, e a título de divulgaçãoda 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 Dadoscomo Suporte à Construção de Sistemas de Informação

Autor(a): Alexandre Cláudio de Almeida

Goiânia, 22 de Novembro de 2010.

Alexandre Cláudio de Almeida – Autor

Dr. Juliano Lopes de Oliveira – Orientador




Dissertação apresentada ao Programa de Pós–Graduação doInstituto de Informática da Universidade Federal de Goiás,como requisito parcial para obtenção do título de Mestre emNome do Programa de Pós-Graduação.

Área de concentração: Engenharia de Software.

Orientador: Prof. Dr. Juliano Lopes de Oliveira

Goiânia2010




Dissertação defendida no Programa de Pós–Graduação do Instituto deInformática da Universidade Federal de Goiás como requisito parcialpara 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 Exami-nadora constituída pelos professores:

Prof. Dr. Juliano Lopes de OliveiraInstituto de Informática – UFG

Presidente da Banca

Prof. Dr. Plínio de Sá Leitão JúniorInstituto de Informática - UFG

Prof. Dr. Ronaldo dos Santos MelloDepartamento de Informática e de Estatística - UFSC

Todos os direitos reservados. É proibida a reprodução total ou parcial dotrabalho 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 deGoiás. Durante o Mestrado, na UFG, foi bolsista do CNPq e desenvolveupesquisa empírica na área de Sistema de Informação com estudo de casoem Sistema de Informação Agropecuário, sob orientação do Prof. Dr. JulianoLopes de Oliveira.

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

Agradecimentos

Agradeço primeiramente a Deus por me dar força e saúde para completar estetrabalho.

Aos meus pais, Antônio Carlos e Madalena, pelo incentivo e apoio não só noperiodo do mestrado mas em toda minha vida.

Ao meu orientador, Prof. Juliano Lopes de Oliveira, pelo incentivo, pela ajudaem criar o corpo de conhecimento adquirido até aqui e por ser uma fonte de inspiraçãocomo pessoa, não só na computação, mas na vida.

Aos meus irmãos, Adriano e André, pela amizade e por estar sempre junto nosmomentos bons e principalmente nos difíceis.

Aos amigos de mestrado, Glauber Boff, Wilane Carlos, Patrícia Gomes, FabianaFreitas, Valdemar Neto, Luiz Loja, Sofia Larissa e Victor Ribeiro pela ajuda e companhei-rismo 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 princi-palmente para Berenice Vieira Silva pelo carinho e presteza durante todo o periódo degraduação e mestrado.

Ao CNPq pelo apoio financeiro.

A mente que se abre a uma nova ideia jamais voltará ao seu tamanhooriginal.

Albert Einstein,.

Resumo

Cláudio de Almeida, Alexandre. Um Componente para Geração e Evoluçãode Esquemas de Bancos de Dados como Suporte à Construção de Sistemasde Informação. Goiânia, 2010. 159p. Dissertação de Mestrado. Instituto deInformática, Universidade Federal de Goiás.

Um Sistema de Informação (SI) Corporativo tem três aspectos principais: o banco dedados, que contém dados que são processados para gerar informações do negócio; asfunçõ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 precisaevoluir 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çãodo processo de transformação na geração e evolução de bancos de dados de Sistema deInformação. Para isso foi criado um componente de software denominado Especialista emBanco de Dados (EBD). Dois conjuntos de mapeamentos são apresentados para a geraçãode 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 dialetoSQL 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 paraoutros componentes deste framework. Uma experimentação foi feita com engenheiros desoftware com experiência em desenvolvimento de Sistema de Informação para validar aabordagem proposta. As principais contribuições desta dissertação são: abordagem queapoia ciclo de vida de BD de SI, arquitetura de software que permite a geração e evoluçãode 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çãoe definição de um conjunto de operações que automatizam o processo de evolução deesquema de BD de SI.

Palavras–chave

Sistema de Informação, Banco de Dados, Desenvolvimento Dirigido por Modelo

Abstract

Cláudio de Almeida, Alexandre. A Component to Generate and EvolveDatabase Schema Supporting Information Systems Constrution. Goiânia,2010. 159p. MSc. Dissertation. Instituto de Informática, Universidade Federalde Goiás.

An Information System (IS) has three main aspects: a database that contains data whichis processed to generate business information; an application functions which transformsdata in information; and business rules which control and restrict data manipulated bythe functions. An IS evolves continuously to follow the corporation changes, and thedatabase should be change to attend the new requirements. This dissertation presentsa model driven approach to generate and evolve IS databases. A software component,called Especialista em Banco de Dados (EBD), was developed. There are two mappingsets for database generation: from Modelo de Meta Objeto (MMO) (used to representingIS) to Relational Model (RM), and from this to DBMS PostgreSQL SQL dialect. Thecomponent EBD is a part of a framework for modeling, building and maintaining enter-prise information systems software. This component provides services to other frameworkcomponents. To validate the proposed approach, Software Engineers had developed IS us-ing the component EBD. The Dissertation main contributions are an approach to supportIS 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 andstored procedures and the definition of automated operation sets to evolve IS databaseschema.

Keywords

Information System, Database, Model Driven Development (MDD)

Sumário

Lista de Figuras 12

Lista de Tabelas 13

Lista de Códigos de Programas 15

1 Introdução 161.1 Ciclo de Vida de Sistemas de Informação 16

1.1.1 Banco de Dados em SI 171.2 Motivação e Objetivos do Trabalho 181.3 Metodologia da Pesquisa Desenvolvida 191.4 Organização do Trabalho 19

2 Desenvolvimento Dirigido por Modelo em Bancos de Dados 212.1 Desafios e Soluções da Abordagem MDD 212.2 Desenvolvimento de Bancos de Dados e MDD 232.3 Comparação de Ferramentas MDD para BD 25

3 Arquitetura do Componente EBD - Especialista em Banco de Dados 293.1 Arquitetura do Framework 293.2 Modelo de Representação de Dados de SI - MMO 31

3.2.1 Tipos de Atributo no MMO 333.3 Arquitetura dos Componentes de Transformação 35

3.3.1 Serviços de Acesso a Dados 353.3.2 Serviços de Geração de Esquema 363.3.3 Serviços de Evolução de Esquema 373.3.4 Serviço de Metadados e Dados de Entidade 39

4 Transformações entre Modelos 424.1 Mapeamentos do MMO para MR 42

4.1.1 Mapeamento de Entidades e Hierarquia de Especialização 424.1.2 Mapeamento de Tipos de Relacionamento (Objeto Interno) 444.1.3 Mapeamento de Entidade Fraca 464.1.4 Mapeamento de Atributo Multivalorado 48

4.2 Geração de DML para Operações CRUD 494.2.1 DML para Tipo de Entidade 494.2.2 DML para Tipo de Entidade Especializada 514.2.3 DML para Objeto Interno 544.2.4 DML para Tipo de Entidade Fraca 60

4.2.5 DML para Atributo Composto 624.2.6 DML para Atributo Simples Multivalorado 62

4.3 Mapeamento do MR para PostgreSQL 654.3.1 Geração de Tabelas 654.3.2 Geração de Stored Procedures (SP) em PL/pgSQL 69

5 Funcionamento do Componente EBD 895.1 Criação de Sistema de Informação 895.2 Utilização do Sistema de Informação 90

5.2.1 Operações CRUD 91Inserção de Instância de uma Entidade 92Obtenção de Instância de uma Entidade 95Atualização de Instância de uma Entidade 95Remoção de Instância de uma Entidade 97

5.3 Exemplo: SI para o Agronegócio 1005.3.1 Exemplos de Geração de Esquema 100

6 Aplicações de Mapeamentos na Evolução de Esquemas 1126.1 Tipos de mudanças permitidas no esquema MMO 112

6.1.1 Mudanças de Tipo e Domínio de Atributo 1126.1.2 Mudanças na chave lógica e no tipo de entidade 1146.1.3 Mudanças em outras meta-informações 116

6.2 Mecanismo para Evolução de Esquema de BD 1206.3 Evolução do Sistema de Informação 1226.4 Exemplos de Evolução de Esquema 123

7 Experimentação do Componente EBD 1267.1 Metodologia 1267.2 Coleta de Dados 1277.3 Análise dos Resultados 128

8 Conclusões 1318.1 Considerações Finais 1318.2 Contribuições 1328.3 Trabalhos Futuros 133

Referências Bibliográficas 135

A Protocolo para Avaliação da Ferramenta EBD 141A.1 Objetivos da Avaliação 141A.2 Procedimentos da Avaliação 141A.3 Questionário 142A.4 Modelo Conceitual de uma Empresa 143

B Mapeamentos do Modelo Relacional para SQL (PostgreSQL) 146B.1 Entidade Fraca 146B.2 Atributo Composto 151B.3 Atributo Simples Multivalorado 155

C Lista de Abreviaturas e Siglas 159

Lista de Figuras

2.1 Transformação entre modelos (Adaptado de [43]) 22

3.1 Arquitetura Funcional do Framework (adaptada de [21]) 303.2 Metamodelo para representação conceitual de SI - Modelo de Meta-

Objetos (MMO) [22] 323.3 Arquitetura do Componente de Geração de Esquema 373.4 Arquitetura do Componente de Evolução de Esquema 383.5 Classe Metadados 403.6 Representação Gráfica de uma Instância de ObjetoApresentacao 413.7 Classe ObjetoApresentacao 41

4.1 Mapeamento de Atributo Enumerado do MMO para o MR 444.2 Mapeamento de Hierarquia de Especialização do MMO para o MR 454.3 Mapeamento de Atributo Objeto Interno do MMO para o MR 454.4 Mapeamento do Atributo Objeto Interno (Agregação) do MMO para o MR 474.5 Mapeamento de Entidade Fraca do MMO para o MR 474.6 Mapeamento de Atributo Multivalorado do MMO para o MR 484.7 Mapeamento de Atributo Composto do MMO para o MR 48

5.1 Formulário para Cadastro de Tipo de Entidade do SI 905.2 Formulário para Cadastro de Atributo de Tipo de Entidade do SI 915.3 Exemplo de Tela de Manipulação de Pessoa Física gerada pelo framework 925.4 Modelo Estático das Classes Envolvidas nas Operações CRUD 935.5 Colaboração para mapeamento Objeto-Relacional na operação de Inserção 945.6 Colaboração para mapeamento Objeto-Relacional na operação de Consulta 965.7 Colaboração para mapeamento Objeto-Relacional na operação de Atual-

ização 985.8 Colaboração para mapeamento Objeto-Relacional na operação de remoção 995.9 Modelo Conceitual Simplificado - Conceito de "Animal" 1005.10 Modelo Conceitual Simplificado - Conceito de "Cor de Pelo de Animal" 107

6.1 Mudanças Possíveis em Tipo/Domínio de um Atributo 1136.2 Mudanças possíveis no tipo de entidade 1156.3 Colaboração no Mecanismo de Verificação e Adaptação para Evolução

de Esquema 1206.4 Interface para Modificação das Instâncias da Entidade 1216.5 Ligação das instâncias de Animal com Propriedade Rural 1246.6 Modificação da Chave das Instâncias da Entidade Pessoa Física 125

A.1 Modelo Conceitual de Empresa (adaptado de [55]) 145

Lista de Tabelas

2.1 Tabela de Comparação de Ferramentas ORM 28

4.1 Mapeamento de Entidades e Hierarquia de Entidades do MMO para o MR 434.2 Conversão de Tipo/Domínio do MMO para MR 434.3 Mapeamento de Objeto Interno do MMO para o MR 464.4 Mapeamento do Atributo Simples Multivalorado do MMO para o MR 484.5 Mapeamento do Atributo Composto Multivalorado do MMO para o MR 494.6 Operações CRUD sobre Tipo de Entidade 504.7 Operações CRUD sobre Tipo de Entidade Especializada 534.8 Operações CRUD sobre Atributo Objeto Interno 554.9 Obtenção de Instâncias de Atributo Objeito Interno (Agregação) 574.10 Operações CRUD sobre Entidade Fraca 614.11 Operações CRUD sobre Atributo Composto 634.12 Operações CRUD sobre Atributo Multivalorado 644.13 Conversão de Tipo/Domínio do MR para SQL 654.14 Mapeamento de Relação "Entidade" do MR para SQL 664.15 Mapeamento de Relação "Atributo Objeto Interno" do MR para o SQL 674.16 Mapeamento de Relação "Atributo Multivalorado" do MR para SQL do

PostgreSQL 684.17 Mapeamento de Relação "Atributo Composto" do MR para o SQL do

PostgreSQL 684.18 Mapeamento de Operações CRUD sobre Tipo de Entidade 714.19 Mapeamento de Operações CRUD sobre Tipo de Entidade Especializada 754.20 Mapeamento de Operações CRUD sobre Atributo Objeto Interno 784.21 Mapeamento de Operações CRUD sobre Atributo Objeito Interno (Agre-

gação) 83

7.1 Tempos de Execução da Experimentação 1287.2 Tempo de Desenvolvimento e Quantidade de Erros 1287.3 Tempo de Desenvolvimento e Produtos Gerados 1287.4 Respostas do Questionário de Avaliação da Experimentação da Ferra-

menta EBD 128

A.1 Dicionário do Esquema de Empresa 144

B.1 Mapeamento de Operações CRUD sobre Tipo de Entidade Fraca 146B.2 Mapeamento de Operações CRUD sobre Atributo Composto 151B.3 Mapeamento das Operações CRUD sobre Atributo Multivalorado 156

Lista de Códigos de Programas

4.1 Obtenção de Lista de Atributos Simples de uma Hierarquia de Especial-ização 52

4.2 Tabela Modelo em PostgreSQL 654.3 Tabela Modelo para Criação de Atributo Objeto Interno 674.4 Modelo de Stored Procedure em PL/pgSQL 694.5 Stored Procedure Modelo para Obtenção de Instâncias de Tipo de Entidade 704.6 Stored Procedure Modelo para Inserção de Instância de Tipo de Entidade 724.7 Stored Procedure Modelo para Remoção de Instância de Tipo de Entidade 724.8 Stored Procedure Modelo para Atualização de Instância de Tipo de Entidade 734.9 Stored Procedure Modelo para Obtenção de Instâncias de Tipo de Enti-

dade Especializada 744.10 Stored Procedure Modelo para Inserção de Instância de Tipo de Entidade

Especializada 764.11 Stored Procedure Modelo para Remoção de Instância de Tipo de Entidade

Especializada 764.12 Stored Procedure Modelo para Atualização de Instância de Tipo de Enti-

dade Especializada 774.13 Stored Procedure Modelo para Obtenção de Instâncias de Atributo Objeto

Interno 804.14 Stored Procedure Modelo para Inserção de Instância de Atributo Objeto

Interno 814.15 Stored Procedure Modelo para Remoção de Instância de Atributo Objeto

Interno 824.16 Stored Procedure Modelo para Atualização de Instância de Atributo

Objeto Interno 834.17 Stored Procedure Modelo para Obtenção de Instâncias de Atributo Objeto

Interno (Agregacao) 864.18 Stored Procedure Modelo para Inserção de Instância de Atributo Objeto

Interno (Agregação) 864.19 Stored Procedure Modelo para Remoção de Instância de Atributo Objeto

Interno (Agregação) 874.20 Stored Procedure Modelo para Atualização de Instância de Atributo

Objeto Interno (Agregação) 875.1 Tabela da Entidade Animal de Propriedade 1015.2 Stored Procedure para Obtenção de Instâncias da Entidade Animal de

Propriedade 1025.3 Stored Procedure para Obtenção de Instância da Entidade Animal de

Propriedade 103

5.4 Stored Procedure para Inserção de Instância da Entidade Animal dePropriedade 104

5.5 Stored Procedure para Remoção de Instância da Entidade Animal dePropriedade 105

5.6 Stored Procedure para Atualização de Instância da Entidade Animal dePropriedade 106

5.7 Tabela do Atributo Objeto Interno Cor de Pelo Animal 1085.8 Stored Procedure para Obtenção de Instâncias do Atributo Objeto Interno

Cor de Pelo Animal 1095.9 Stored Procedure para Inserção de Instância do Atributo Objeto Interno

Cor de Pelo Animal 1105.10 Stored Procedure para Remoção de Instância do Atributo Objeto Interno

Cor de Pelo Animal 111B.1 Stored Procedure Modelo para Obtenção de Instâncias de Tipo de Enti-

dade Fraca 149B.2 Stored Procedure Modelo para Obtenção de Instância de Tipo de Entidade

Fraca 149B.3 Stored Procedure Modelo para Inserção de Instância de Tipo de Entidade

Fraca 150B.4 Stored Procedure Modelo para Remoção de Instância de Tipo de Entidade

Fraca 150B.5 Stored Procedure Modelo para Atualização de Instância de Tipo de Enti-

dade Fraca 151B.6 Stored Procedure Modelo para Obtenção de Instâncias de Atributo Com-

posto 153B.7 Stored Procedure Modelo para Inserção de Instância de Atributo Composto154B.8 Stored Procedure Modelo para Remoção de Instância de Atributo Composto154B.9 Stored Procedure Modelo para Atualização de Instância de Atributo

Composto 155B.10 Stored Procedure Modelo para Obtenção de Instâncias de Atributo Mul-

tivalorado 157B.11 Stored Procedure Modelo para Inserção de Instância de Atributo Multi-

valorado 157B.12 Stored Procedure Modelo para Remoção de Instância de Atributo Multi-

valorado 158B.13 Stored Procedure Modelo para Atualização de Instância de Atributo

Multivalorado 158

CAPÍTULO 1Introdução

Sistemas de Informação apoiam a execução de processos de negócio e estão pre-sentes 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 trabalhode criação de um componente de persistência de dados para um framework que apoia ageraçã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 destaquepara: software, bancos de dados, pessoas, documentação, hardware e procedimentos. Osoftware compreende programas de aplicação e software básico. Pessoas gerenciam eoperam 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. Osprocedimentos definem o comportamento do SI na organização. O hardware envolvecomputadores 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çãocontempla atividades de análise do sistema, planejamento do projeto e análise de requi-sitos; a construção inclui atividades de projeto de software, implementação e testes; e amanutenção envolve atividades de correção, adaptação e evolução do sistema.

Na fase de concepção são definidas necessidades, capacidades, característicasou fatores de qualidade de um sistema. Nesta fase são identificandos os stakeholders (sãotodos os interessados no resultado de um projeto de software, por exemplo, gerente denegócio, usuários finais e pessoal de apoio), obtendo destes o entendimento a respeito dasnecessidades 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 àsnecessidades e características definidas para o sistema. Uma das atividades desta fase é acodificação, que envolve a tradução do projeto dos componentes de software e de BD para

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 necessidadesdescritas na fase de concepção foram implementadas e que o sistema funciona de acordocom o que foi previsto pelos stakeholders.

Na fase de manutenção são feitas correções, adaptações e inserções de novosrequisitos no sistema desenvolvido. Todas as fases anteriores são repetidas para incorporarestas alterações.

1.1.1 Banco de Dados em SI

O componente de bancos de dados possui ciclo de vida em três fases, análogoaos demais componentes do SI. A fase de Análise de Requisitos do SI provê informaçõespara elaborar o projeto conceitual dos bancos de dados. Essas informações incluem, porexemplo, 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 debancos de dados) e as prioridades de usuários em relação a estes serviços. Erros nestafase 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 acordocom os requisitos identificados na análise é criado um esquema conceitual do Banco deDados. Este esquema é constituído de elementos e seus relacionamentos, de acordo como domínio do conhecimento que está sendo modelado.

Assim, o modelo conceitual de BD é uma descrição, em alto nível, de uma porçãodo domínio de negócio, de forma independente de Sistema Gerenciador de Bancos deDados (SGBD). Esta descrição utiliza, em geral, linguagens de modelagem conceitualcomo Entity-Relationship Model (ERM) [16], Unified Modeling Language (UML) [48] eObject-Role Modeling (ORM) [33].

O projeto de aplicações identifica as aplicações necessárias para manipularos 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çõessã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çãoquanto para recuperação de informações armazenadas no banco de dados.

Uma atividade necessária para construção de bancos de dados é a escolha doSGBD. Alguns aspectos que precisam ser levados em conta nesta escolha incluem: fa-tores econômicos, como o custo da aquisição do SGBD, treinamento da equipe de de-senvolvimento, 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.

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 comoproduto o mapeamento do esquema conceitual do BD para a linguagem de definição dedados (DDL - Data Definition Language) do SGBD alvo. Aspectos de processamentomais específicos, como taxa de processamento, tempo de resposta em transações e espaçode 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 linguagemde manipulação de dados (DML - Data Manipulation Language) do SGBD.

A medida que o SI é utilizado são identificadas necessidades de manutençãodo banco de dados devido a fatores como mudança de requisitos, falta de eficiência dasoperaçõ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 doesforç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 deprogramas 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 serformalizado em um conjunto de tranformações que levam à produção eficiente de soft-ware. Um dos desafios da Engenharia de Software é a especificação de transformaçõesformais de informações obtidas no projeto de software em programas, e a construção deferramentas que apoiam estas transformações.

Estas definições podem ser estendidas para o desenvolvimento de bancos dedados em SI. No processo de criação do esquema do banco de dados de um SI sãodefinidas 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 conceitualque levam a um conjunto de operações nos esquemas operacionais e físicos. Tais transfor-mações devem ser regidas por regras que preservam a consistência dos dados armazenadosno esquema modificado.

Este trabalho tem como foco a definição de uma abordagem que apoie o ciclode vida de bancos de dados em SI. Tendo em vista a complexidade de criação deferramentas de BD que implementem estas tranformações de forma integrada com osdemais componentes de SI, este trabalho especifica necessidades e propõe uma soluçãopara geração e evolução de BD em SI.

1.3 Metodologia da Pesquisa Desenvolvida 19

Para isso o trabalho descreve o desenvolvimento de um componente de persistên-cia de dados para um framework que gera, evolui e mantém SI. Este componente é de-nominado Especialista em Banco de Dados (EBD). A abordagem proposta utiliza o De-senvolvimento Dirigido por Modelo (MDD) [31] para criação e evolução de esquemas deBD, e de operações CRUD que manipulam informações do SI. Além disso, o componenteoferece 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 sobrea abordagem MDD e a análise de ferramentas baseadas nesta abordagem. O objetivo foiidentificar requisitos necessários para o desenvolvimento deste projeto.

Ferramentas de Bancos de Dados e frameworks para mapeamento objeto rela-cional (ORM) foram analisadas com intuito de verificar os benefícios e limitações decada uma delas.

Após a definição de requisitos, foi feito o projeto e a implementação dosmecanismos de geração, evolução de esquema e serviços de persistência de conceitosdo SI.

Em seguida foram feitos testes e integração com os demais componentes doframework de suporte à construção de SI. O esquema de um SI de grande porte foigerado utilizando a arquitetura desenvolvida neste trabalho, com o propósito de avaliarempiricamente as propostas.

Na última fase deste projeto foram feitos experimentos para validação da abor-dagem proposta. Estes experimentos contaram com a participação de desenvolvedores deSI 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 desenvolvimentoe evolução de esquemas de BD. O capítulo também compara a abordagem proposta nestetrabalho com as ferramentas encontradas na primeira fase da pesquisa.

O Capítulo 3 apresenta a arquitetura do componente proposto no contextodo framework para geração e evolução de SI, descrevendo o metamodelo utilizado narepresentação de dados de SI.

O Capítulo 4 descreve um conjunto de padrões de mapeamento do metamodeloadotado para o MR, e deste para um dialeto específico de SQL, para geração e evoluçãode esquemas de BD de SI. O SGBD PostgreSQL [53] e sua linguagem procedural(PL/pgSQL) são utilizados nestes mapeamentos.

1.4 Organização do Trabalho 20

O Capítulo 5 discute a criação e utilização de SI com base na proposta destetrabalho. Além disso, o capítulo apresenta exemplos reais de utilização da arquiteturaimplementada 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 esquemapropostos neste trabalho. Também são apresentados exemplos reais de evolução deesquema 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çãodo componente.

O Capítulo 8 apresenta as considerações finais deste trabalho de pesquisa,propondo extensões e direções para trabalhos futuros.

CAPÍTULO 2Desenvolvimento Dirigido por Modelo emBancos de Dados

O Desenvolvimento Dirigido por Modelo (Model-Driven Development - MDD)é uma das propostas recentes que têm obtido resultados significativos para diminuir adificuldade na manutenção de SI [31]. Esta abordagem especifica conceitos relevantesdo domínio da aplicação, incluindo regras de negócio, relacionamentos e semântica dedados, 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 eo componente proposto neste trabalho.

2.1 Desafios e Soluções da Abordagem MDD

Tradicionalmente, as equipes de desenvolvimento e manutenção de softwarecompartilham os seguintes desafios [43, 45]:

1. Documentação Inconsistente - O processo de desenvolvimento de software produzgrande quantidade de documentação. Esta documentação rapidamente perde seuvalor, pois ao invés de ser uma exata especificação do código, os diagramasgeralmente tornam-se apenas figuras relacionadas ao código. Isso acontece porquegeralmente as modificações são feitas apenas no código fonte, já que atualizar todaa documentação exige tempo que na maioria das vezes não está disponível.

2. Mudanças Frequentes de Tecnologia - Novas tecnologias aparecem de formamuito rápida. Empresas que dependem destas tecnologias devem mudar antes queela fique obsoleta.

3. Interoperabilidade - Os sistemas não podem ser desenvolvidos de maneira isolada.Eles devem ser desenvolvidos como componentes de software que se comunicamcom outros sistemas, de forma que a adaptação ou correção do sistema, ou mesmoa inserção de novos requisitos de negócio, se torne mais fácil.

2.1 Desafios e Soluções da Abordagem MDD 22

4. Falta de Compreensão sobre Documentação - A documentação de sistemas geral-mente não é boa porque aqueles que estão envolvidos com o desenvolvimento dosistema, principalmente os programadores, estão apenas preocupados com ativi-dades inerentes a codificação, não tendo ideia de que a documentação auxilia emmanutenções futuras dos sistema.

O MDD permite especificar conceitos relevantes do domínio da aplicação us-ando linguagens de modelagem de alto nível de abstração. Com estas linguagens sãocriados modelos do sistema independentemente da plataforma utilizada para a sua imple-mentação. Modelos em UML, por exemplo, são o padrão de fato utilizado pela indústriade 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 transfor-mação de um modelo (ou aspecto) conceitual do sistema para modelos específicos parauma determinada plataforma de implementação (PSM - Plataform Specific Model). Essesmodelos específicos são, por sua vez, automaticamente traduzidos para o código que im-plementa 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 ab-stração na especificação de um sistema. A capacidade de transformar um PIM em umPSM aumenta o nível de abstração no qual o desenvolvedor pode trabalhar, facilitando odesenvolvimento de sistemas. Os desenvolvedores que trabalham com modelos indepen-dentes de tecnologia possuem menos trabalho a fazer porque os detalhes específicos deplataformas não precisam ser analisados e projetados; eles já são tratados na definição datransformação do modelo independente para o modelo específico.

Na transformação do modelo específico para código fonte há muito menostrabalho a ser feito, pois muito código já foi gerado a partir da transformação do modelo dealto nível. Os desenvolvedores gastam menos tempo realizando codificação e utilizam otempo para se preocuparem com a modelagem do negócio. Dessa forma, o benefício paraos usuários finais é grande. No entanto, o ganho de produtividade é alcançado somentecom 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 essemodelo pode ser transformado para vários modelos específicos voltados para plataformasvariadas. Caso apareçam novas tecnologias, devem ser desenvolvidas novas definições

2.2 Desenvolvimento de Bancos de Dados e MDD 23

de transformações do modelo independente para essas novas tecnologias. No entanto, omodelo independente já existente não necessita sofrer qualquer modificação.

Dessa forma, o PIM representa a documentação em mais alto nível de umsistema. Toda modificação que é feita no sistema deve ser primeiramente feita nestemodelo. Depois disso, o modelo específico deve ser gerado novamente, assim como ocódigo da aplicação. Logo, a documentação do sistema sempre será consistente com ocódigo atual.

Apesar dos benefícios da utilização da abordagem MDD, algumas dificuldadessão enfrentadas. A tradução automática provê padronização do código gerado e produtivi-dade, mas existe o problema relacionado à eficiência. Por exemplo, um código gerado poruma ferramenta de geração de esquema pode não ter a mesma eficiência de um códigocriado por um DBA (Database Administrator - Administrador de Bancos de Dados) ex-periente.

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 dosdados, regras de negócio e interface com o usuário. Criar ferramentas para automatizareste 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 de-senvolvimento e manutenção de software, os seus princípios também podem ser aplicadosno contexto de bancos de dados, já que estes são um componente importante de qualquersoftware [25].

No processo de desenvolvimento de banco de dados são feitas transformaçõesdo modelo conceitual para o modelo operacional do SGBD e, em seguida, para omodelo físico da plataforma computacional. A transformação é uma maneira sistemáticade mapeamento entre modelos. No processo de desenvolvimento de banco de dadosé frequente a utilização deste recurso em várias atividades, tais como normalizaçãode esquema [56], integração de esquemas [10, 9, 46], interoperabilidade de banco dedados [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 ferramen-tas que suportam o desenvolvimento de SI. Especificamente para bancos de dados podemser destacadas as seguintes ferramentas:

• Mapeamento Objeto-Relacional (ORM - Object-Relational Mapping) - A criaçãode aplicações de banco de dados, na maioria da vezes, é um trabalho entediante de-vido à grande quantidade de código semelhante e ao trabalho repetitivo executado.

2.2 Desenvolvimento de Bancos de Dados e MDD 24

Em consequência disso, tem-se alto risco de erros na aplicação desenvolvida. Umadas soluções para estes problemas são as ferramentas ORM que têm por objetivoa simplificação da criação do componente de acesso a dados. Ferramentas ORMestabelecem uma ligação bidirecional entre os dados no banco de dados relacionale os objetos no código de aplicações orientadas a objetos.• Ambientes de Desenvolvimento Integrado (IDE - Integrated Development Environ-

ment) - são ferramentas utilizadas por desenvolvedores e administradores de BD,como por exemplo a ferramenta BrModelo [17]. Elas possuem uma grande var-iedade de funcionalidades, tais como: geração do esquema de banco de dados apartir do modelo conceitual, modelagem conceitual, criação de instruções de ma-nipulação de dados, engenharia reversa, sincronização entre modelo operacional eesquema físico, tuning de consultas e estatísticas do custo de execução de instruçãoou script.

Existe uma variedade de frameworks ORM. Eles são mais populares para alinguagem Java [41, 1, 28, 3, 26, 67, 42, 2, 5], mas existem frameworks para outraslinguagens, como .NET [41, 60, 59, 63]. Recursos mais sofisticados, como importação demodelos, geração de scripts, suporte a vários SGBDs, e criação de modelos com diferentesní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 modelosindependentes de plataforma para automatizar operações como geração e evolução doesquema 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 dediversas 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 meta-

informações, como descrito em [29]. A maioria deles, no entanto, armazena as meta-informações em formato proprietário e faz a geração e evolução do esquema de banco dedados indiretamente, usando scripts, ou diretamente, usando conexões do tipo ODBC ouJDBC.

O framework proposto nesta dissertação e os IDEs compartilham várias fun-cionalidades, como geração de esquema e suporte a evolução, mas existe uma diferençabásica. O framework participa do fluxo de processamento de informações na execução doSI, diferentemente dos IDEs, que são utilizados na fase de construção ou manutenção doSI.

2.3 Comparação de Ferramentas MDD para BD 25

2.3 Comparação de Ferramentas MDD para BD

Os frameworks ORM utilizam informações de um modelo conceitual indepen-dente de plataforma para fazer os mapeamentos necessários para criação, evolução e uti-lização do esquema de BD de uma aplicação. Os frameworks armazenam estas infor-mações em arquivos externos ou no código da aplicação.

Os frameworks Hibernate, Abra, Castor, Cayenne, Databind, OR Broker, OJB eEbean apresentados respectivamente em [41, 1, 28, 3, 26, 42, 2, 5] utilizam arquivos XMLpara armazenamento externo das informações utilizadas no mapeamento. O framework

DB Visual Architect [67] armazena o modelo conceitual em arquivos criados pela própriaferramenta. Em Java, os frameworks Hibernate e Ebean utilizam annotations [40]. Osframeworks Hibernate e OJB utilizam XDoclet [68] para armazenar as meta informaçõesdiretamente no código.

No componente EBD, proposto neste trabalho, o modelo conceitual do SI é ar-mazenado no próprio BD. As vantagens desta abordagem estão diretamente relacionadasàs vantagens de utilizar SGBD para armazenamento de informações: segurança, suportea alto volume de uso e acesso restrito às informações armazenadas.

Mapeamentos em arquivos externos possuem a desvantagem de manipulaçãode vários arquivos onde estão as informações das entidades do sistema e problemasem relação ao entendimento da sintaxe utilizada para armazenar tais informações. Estesproblemas não são encontrados no mapeamento direto no código da aplicação, mas outrosproblemas são observados. O código da aplicação pode ficar dependente do mapeamentoespecífico de um certo framework e mudanças no BD levam a mudanças no código daaplicação, ferindo o princípio de independência de dados.

Os frameworks Cayenne e DB Visual Architect fornecem editores gráficos paraobtenção das informações das entidades do SI. A inferface gráfica facilita o trabalhode criação dos arquivos externos, pois os usuários da ferramenta não se preocupamcom a sintaxe da linguagem utilizada para armazenar as meta informações. O EBDfornece formulários de cadastro para facilitar o processo de obtenção das informaçõesde representação das entidades do SI.

É comum entre os principais frameworks ORM usar as informações do modeloconceitual 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 ORBroker. Mesmo assim é necessária a criação do arquivo de mapeamento, pois este é usadona execução do framework. O EBD utiliza os conceitos MDD para geração automática doesquema do BD do SI.

Além do esquema, alguns frameworks geram instruções SQL dinâmicas para ma-nipulação das instâncias das entidades persistentes. Para tornar a manipulação eficiente, os


frameworks Hibernate, Castor, DB Visual Architect, OR Broker, OJB e Ebean permitema manipulação de instâncias via procedimentos armazenados (stored procedures). Dentreestes, somente os frameworks DB Visual Architect e Ebean geram automaticamente estesprocedimentos. No EBD a manipulação das instâncias de entidade é feita através de umconjunto de stored procedures geradas a partir do modelo conceitual de SI.

Para permitir a modelagem de sistemas complexos, o modelo conceitual dosframeworks deve permitir construções de hierarquias de especialização, tipos de rela-cionamentos e coleções de tipos de dados (inteiros, string, datas, entre outros).

A modelagem de hierarquia de especialização é permitida nos frameworks Hi-bernate, 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 especial-ização. Por exemplo, o usuário pode optar por mapear todos os atributos de super classese sub classes para uma mesma tabela. Outra opção disponível é mapear cada classe dahierarquia para uma tabela distinta. O EBD permite a modelagem e geração de hierarquiade especialização, mas o mapeamento é restrito: cada classe da hierarquia é mapeada parauma tabela. Este mapeamento é discutido em detalhes no Capítulo 4.

Assim como os frameworks Hibernate, Castor, Abra, Cayenne, DB Visual Archi-tect, OR Broker, OJB e Ebean, o EBD permite mapeamentos de tipos de relacionamentocom cardinalidade 1:1, 1:N e N:M. No EBD, os tipos de relacionamentos são manipula-dos através de um conjunto de stored procedures. Já nos frameworksHibernate, Abra eOJB 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 amanipulaçã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 deesquema. Mudanças feitas no modelo conceitual são propagadas para o modelo físicoe para os dados do sistema. O EBD também conta com um mecanismo que analisa epropaga as mudanças feitas no esquema conceitual do SI para o modelo físico e para osdados correspondentes.

Assim, o componente EBD conta com os recursos típicos dos frameworks ORMencontrados no mercado, mas não oferece algumas funcionalidades específicas. Porexemplo, o framework DB Visual Architect conta com funcionalidades para geração derelatórios, análise de impacto de mudanças no BD e suporte às ferramentas de controlede versão. Os frameworks Hibernate, Ebean, Cayenne e Abra permitem a criação deconsultas e gerenciamento de transação. Essas funções fogem do escopo funcional doEBD.

A entrada das meta informações da entidade, no EBD, é feita por formulário


textual, mas teria melhor usabilidade se a criação do esquema fosse feita a partir de umeditor gráfico. Tais funcionalidades são importantes, mas não foram implementadas nocomponente EBD devido à limitação do tempo para desenvolvimento deste trabalho.

Além de possuir funcionalidades semelhantes às dos frameworks discutidosnesta seção, o componente EBD possui um diferencial que é a integração com umframework 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 detalhesda arquitetura do componente EBD.

A Tabela 2.1 apresenta uma comparação entre frameworks ORM para a lin-guagem Java e o componente EBD, proposto neste trabalho. Os critérios de comparaçãoentre os frameworks são: (a) Suporte a Herança - define se o framework permite a cri-ação de cadeia de especilização, (b) Tipos de Relacionamento - permite relacionamentosentre as entidade definidas no framework, (c) Interface Gráfica para coleta das infor-mações conceituais, (d) Gera Esquema automaticamente, (e) Propaga Mudanças - es-tabelece 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 dodados de entidade via procedimentos armazenados, (g) Suporte a Coleções - estabelecese o framework permite a manipulação de coleções de strings, inteiros, números de pontoflutuante, 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 uti-lizam a abordagem MDD. As características mais importantes de cada ferramenta foramdefinidas, logo após estas informações foram confrontadas obtendo um conjunto de carac-terísticas comuns e algumas específicas. Dentre estas características, as mais relaventesderam origem aos critérios de comparação.

Este capítulo discutiu os desafios e soluções da abordagem MDD aplicada aBD e apresentou uma comparação entre ferramentas que utilizam esta abordagem e ocomponente proposto neste trabalho.


Supo

rte

aTi

posd

eTi

pode

Ofe

rece

GU

Ipa

raG

era

Prop

aga

Supo

rta

Supo

rta

Ferr

amen

taL

ivre

?H

eran

çaR

elac

iona

men

toM

apea

men

toM

apea

men

toE

sque

ma

Mud

ança

sSt

ored

Col

eçõe

sPr

oced

ure

Hib

erna

teSI

MSI

MA

nnot

atio

nsN

ÃO

SIM

SIM

SIM

SIM

SIM

3.5.

1[4

1]X

ML

eX

Do-

clet

Abr

aSI

MSI

MX

ML

NÃ

OSI

MN

ÃO

–SI

MSI

M0.

9.9

[1]

Cas

tor

NÃ

OSI

MX

ML

NÃ

OSI

M–

SIM

SIM

SIM

1.3.

1[2

8]C

ayen

neSI

MSI

MX

ML

SIM

SIM

SIM

NÃ

OSI

MSI

M3.

0[3

]D

atab

ind

–N

ÃO

XM

LN

ÃO

NÃ

ON

ÃO

NÃ

ON

ÃO

SIM

0.4

[26]

DVA

SIM

SIM

Arq

uivo

SIM

SIM

SIM

SIM

–N

ÃO

5.2

[67]

próp

rio

OR

Bro

-ke

rSI

MSI

MX

ML

NÃ

ON

ÃO

–SI

MSI

MSI

M

2.0.

3[4

2]O

JBSI

MSI

MX

ML

eN

ÃO

SIM

–SI

MSI

MSI

M1.

0.4

[2]

XD

ocle

tE

bean

OR

MSI

MSI

MA

nnot

atio

nsN

ÃO

SIM

NÃ

OSI

M–

SIM

2.6.

0[5

]e

XM

LE

BD

SIM

SIM

BD

SIM

SIM

SIM

SIM

SIM

SIM

1.0

Leg

enda

:–

:Inf

orm

ação

não

enco

ntra

dana

sre

ferê

ncia

sso

bre

afe

rram

enta

Tabe

la2.

1:Ta

bela

deC

ompa

raçã

ode

Ferr

amen

tas

OR

M

CAPÍTULO 3Arquitetura do Componente EBD - Especialistaem Banco de Dados

Uma arquitetura de software descreve uma organização de componentes, os seusrelacionamentos 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 dedados 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 quenã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áticade Sistemas de Informação usando modelos conceituais como entrada. Os componentesde 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 quepodem 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çãoque mapeiam alguns aspectos dos modelos conceituais para os modelos específicos deplataforma, 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 omodelo conceitual de cada SI. Este modelo conceitual contém os metadados usados pelosdemais módulos para construir e gerenciar os códigos fonte do SI (aplicação, regras denegócio e banco de dados).

O módulo Interface usa o modelo conceitual do SI (ou seja, os metadados quedescrevem conceitualmente o SI) para gerar a interface de usuário para aplicações do

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 umesquema de mapeamento dos metadados do SI para metadados de interface (chamadosde metadados de apresentação). Este mapeamento descreve, entre outros aspectos, comoapresentar cada conceito de negócio em uma interface padrão baseada nos conceitosWIMP (Window, Icon, Menu, Pointer) [18, 19].

O módulo Interface Aplicação serve como adaptador entre os módulos Interfacee Aplicação. Seu objetivo principal é repassar mensagens da interface para a aplicação e

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 enti-dades 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 deacordo com as regras pré-estabelecidas (regras de negócio). Ele executa o controle paraque informações inseridas no Banco de Dados sejam válidas para o negócio subjacenteao SI. Através das informações obtidas nos metadados, são tratados aspectos comocardinalidade 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 deregras de negócio do SI. Essa é uma característica diferencial do framework, pois trata asRegras 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 nalinguagem OCL) para código na linguagem específica da plataforma de implementação eprovê, em tempo de execução, facilidades para avaliação e execução destas regras quandodisparadas por eventos de BD ou de aplicação.

O módulo Persistência gerencia o mapeamento do modelo conceitual do SI parao esquema operacional de banco de dados em um SGBD (e vice-versa). O módulo tambémgerencia a evolução dos esquemas de bancos de dados de acordo com as mudançasfeitas nos metadados conceituais do SI. Este módulo gerencia, ainda, todo o acessoaos dados persistentes do SI, isolando os demais módulos do framework de mudançasna tecnologia de bancos de dados, ou seja, provendo independência de dados para asaplicações construídas com o framework.

O presente trabalho descreve o projeto e a implementação do módulo Persistên-cia do framework. Informações detalhadas sobre o framework e seus outros componentespodem 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 con-ceitos de negócio, instâncias desses conceitos, e relações e restrições sobre essas instân-cias), o framework utiliza uma variante orientada a objetos do Modelo Entidade Rela-cionamento (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émaspectos de Interface Homem Computador (IHC) e de Regras de Negócio. A Figura 3.2apresenta os principais conceitos de representação de dados deste metamodelo. Os con-


ceitos relacionados aos outros aspectos (IHC e Regras de Negócio) da DSL MMO foramomitidos 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 deum SI corporativo, independentemente da plataforma de implementação escolhida. Dessaforma, 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 in-dentificação própria (Entidade Forte) e aquelas que possuem dependência de outra enti-dade para indentificar suas instâncias (Entidade Fraca). Além disso, é possível modelarhierarquias de especialização de entidades, através do auto-relacionamento "especializadaem".

Para caracterizar um tipo de entidade o MMO disponibiliza os tipos de atributossimples e composto. Estes tipos podem ser especializados em tipos mais específicos,


conforme discute a Seção 3.2.1.

3.2.1 Tipos de Atributo no MMO

O meta objeto Atributo tem como objetivo reunir informações e funcionalidadescomuns a todos os tipos de Atributos especializados do MMO. São características comunsa 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 devalores definitos pelo sistema.

– ENUMERADO: indica que é um atributo simples, com um domínio discretode valores definidos pelo usuário.

– OBJETO EXTERNO: indica que o atributo é do tipo multimídia e possuidependência de aplicações externas para ser editado (por exemplo, fotos,vídeos e planilhas).

– OBJETO INTERNO: representa um relacionamento entre duas entidades doSI. Tipos de relacionamento são representados, no MMO, pelo atributo do tipoobjeto interno. Por exemplo, o atributo gerencia da entidade funcionário podeindicar um relacionamento entre as entidades funcionário e departamento.

– COMPOSTO: indica que o atributo é composto por outros atributos. Porexemplo, 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 edata.• 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 iguaisno 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ãodefinidos como atributos de ligação da entidade B, em uma consulta de instâncias


de atribR os atributos de B que aparecem nesta consulta são os atributos de ligaçãoatrib1 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 aentidade departamento possui o atributo gerente, do tipo objeto interno, indicandoo relacionamento com a entidade funcionário, uma consulta para obter todos osgerentes do departamento apresentará os atributos nome e cpf.

O Atributo Simples Básico representa um dado atômico dentro da entidade daqual ele faz parte. Ou seja, essa informação não pode ser dividida em partes menores comsemâ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 oAtributo 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 esteatributo.

O Atributo Simples Enumerado descreve dados oriundos de um conjunto devalores definidos pelo usuário, isto é, uma enumeração de valores discretos. Um exemplode enumeração é o conjunto de valores {masculino, feminino} para o atributo sexo. OAtributo Simples Enumerado possui as seguintes características:

• Domínio Enumerado: define o nome do conjunto onde estão determinados osvalores 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 aosistema. 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 sersimples ou compostos. Desta forma, é possível representar objetos complexos, quesão compostos por outros objetos também complexos. O Atributo Composto possui asseguintes características:

• Subatributos: referencia o conjunto de atributos que compõem o Atributo Com-posto.

3.3 Arquitetura dos Componentes de Transformação 35

Um tipo notável de Atributo Composto é o Atributo Objeto Interno. Umobjeto interno é aquele que referencia alguma entidade do SI. Dessa forma, é possívelesbelecer 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émdas características herdadas de Atributo Composto, o Atributo Composto Objeto Internocontém as seguintes:

• Entidade Referenciada: contém o mnemônico da entidade que o Atributo Com-posto Objeto Interno referencia. Por exemplo, o relacionamento gerencia entre asentidades funcionário e departamento poderia ser definido por um atributo objetointerno gerente, que pertence à entidade departamento e armazena o mnemônicofuncioná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 represen-tar relacionamentos entre relacionamentos. Por exemplo, em uma empresa umamanutenção é requesitada somente por aquele funcionário que é gerente. O atri-buto objeto interno gerente determina o relacionamento entre as entidades departa-

mento e funcionário. Por sua vez, a entidade manutenção possui o atributo objetointerno requesitada por, que possui no campo Atributo Referenciado o mnemônicodo atributo gerente, definindo o relacionamento entre a entidade manutenção e orelacionamento gerente da entidade departamento. No campo entidade referenciadado 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 ma-peamento objeto-relacional envolvem os módulos Negócio e Persistência, mostrados naarquitetura de alto nível da Figura 3.1. A seguir, são apresentados os serviços do compo-nente EBD para acesso a dados, geração de esquema, evolução de esquema e de metada-dos e dados de entidade.

3.3.1 Serviços de Acesso a Dados

O pacote Serviços de Acesso a Dados contém os serviços para mapeamento deinstâncias de entidades do MMO para o BD e vice versa. O framework disponibiliza asoperações de inserção, remoção, atualização e obtenção de instâncias de entidades do SI.


Estas operações contam com um conjunto de stored procedures geradas paramanipulação de instâncias de entidades. Em Java, a classe CallableStatement do pacotejava.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 classeCallableStatement através de uma string que contém o nome da stored procedure e aquantidade de parâmetros que serão passados. Logo após, são registrados os valores dosparâmetros no objeto CallableStatement.

A string tem o formato ?= call <nome-procedure>(?, ?, ?, ...). O com-ponente 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 aquantidade de parâmetros é obtida a partir da contagem de atributos simples monovalo-rados 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 controlede transação (abertura, commit e rollback) e serviços de acesso ao BD utilizados pelocomponente Regra do framework.

3.3.2 Serviços de Geração de Esquema

O pacote Serviços de Geração de Esquema (Figura 3.3) contém todos os serviçospara geração do esquema SQL e das stored procedures no SGBD utilizado na implemen-taçã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 domodelo 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 doesquema do banco de dados do SI. A manipulação dos dados do esquema gerado pelopacote Gerador DDL é feita por um conjunto de stored procedures para operações CRUDgeradas pelo pacote Gerador DML.

No processo de mapeamento para geração do esquema e de instruções demanipulaçã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.


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 atributosimples multivalorado, e• geração de stored procedures de consulta, inserção, remoção e obtenção para enti-

dade, atributo composto, atributo objeto interno e atributo simples multivalorado.

3.3.3 Serviços de Evolução de Esquema

O Serviço de Evolução de Esquema trata todo o processo de evolução doesquema e dos dados contidos em um SI quando o modelo conceitual do SI é alterado. AFigura 3.4 mostra este pacote.

No componente EBD modificações permitidas no MMO são propagadas parao esquema e, consequentemente, para os dados do SI. O pacote AvaliadorMudançapossui 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


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 menoresou iguais ao novo tamanho.

As mudanças na chave lógica de uma entidade ou atributo composto, tais comoinclusão ou remoção de atributos são executadas no pacote Chave Lógica. Outros tiposde mudanças tratados neste pacote são transformações entre os tipos de entidade e nashierarquias de especialização.

Os serviços para propagação de mudanças de unicidade de um atributo sãotratadas no pacote Unicidade.

O pacote Domínio possui os serviços para mapeamento da propagação dasalterações de domínio de atributos do MMO.

As propagações de mudanças em relação a cardinalidades mínima e máxima dosatributos são tratadas no pacote Cardinalidade.

A propagação da modificação de tamanho de atributo alfanumérico é tratada pelopacote Tamanho.

O pacote Composição possui os serviços para propagação de mudanças rela-cionadas aos atributos do domínio composto. Um atributo composto pode ser modificadocom adição ou remoção de um atributo, por exemplo.


A propagação de mudança de mnemônico de entidade e atributo é tratada pelosserviços do pacote Mnemônico.

O pacote Serviços de Evolução de Esquema disponibiliza, em suma, serviçospara:

• criação e remoção de: atributo em entidade, atributo composto, atributo objetointerno, 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 multi-valorado.

3.3.4 Serviço de Metadados e Dados de Entidade

Para permitir o tráfego de metadados e dados de um tipo de entidade pelo sistemaforam definidas as classes Metadados e ObjetoApresentacao. A classe Metadados (Figura3.5) do pacote Serviço de Metadados e Dados possui um vetor de atributos que armazenaas características de uma instância de tipo de entidade. Metadados disponibiliza serviçospara obtenção:

• do número de atributos dos Metadados. Este serviço retorna a quantidade deatributos que a entidade possui. Por exemplo, se a entidade Pessoa Física possuios 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 atributocpf.• 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 simplesmonovalorados.• 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õema chave lógica da entidade.


• dos valores da chave parcial de um atributo composto. Este serviço retorna osvalores dos atributos que compõem a chave parcial do atributo composto. A entradadeste 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, obterChaveLog-

ica, obterChaveParcialComposto e obterValoresSimplesComposto que conceitualmentedeveria pertencer à classe ObjetoApresentacao, que fornece serviço para os dados de umainstância de entidade. Eles ficaram na classe Metadados pois dependem de metainfor-mações para sua execução. Por exemplo, o método obterChaveLogica necessita de umserviç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 ObjetoApresenta-cao (Figura 3.7). A classe ObjetoApresentacao do pacote Serviços de Metadados e Dadospossui o atributo valores que é um vetor de objetos. Neste vetor cada objeto é uma in-stância do atributo nos Metadados de mesma posição. Os atributos multivalorados sãoarmazenados em vetores de vetores, onde o vetor interno armazena cada uma das instân-cias do atributo multivalorado e o vetor externo armazena este conjunto de instâncias. AFigura 3.6 ilustra esta construção.

Os serviços de metadados e dados do componente de persistência EBD sãoutilizados nas operações CRUD para instâncias de entidade, a serem apresentadas naSeção 5.2.1.

O método adicionarValorEm adiciona um objeto no ObjetoApresentacao noíndice passado por parâmetro. Todos os objetos armazenados nos índices maiores queo 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.


Figura 3.6: Representação Gráfica de uma Instância de ObjetoAp-resentacao

Figura 3.7: Classe ObjetoApresentacao

O método obterNumValores retorna a quantidade de objetos armazenados no Ob-jetoApresentacao. Por exemplo, este método retorna o valor 3 para o ObjetoApresentacaoda Figura 3.6.

O método obterValorEm retorna o objeto armazenado na posição indice doObjetoApresentacao. Por exemplo, a chamada deste método com o valor 1, para oObjetoApresentacao da Figura 3.6, retorna o valor 70500333-72.

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 dadosdo SI (Seção 3.2) e analisou a arquitetura do componente de persistência EBD (Seção3.3).

CAPÍTULO 4Transformações entre Modelos

O processo de geração automática do esquema de BD é logicamente divididoem 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 mapeadaspara um dialeto SQL.

Este capítulo apresenta, nas Seções 4.1 e 4.2, o mapeamento do MMO para oMR em termos de estruturas e operações. A Seção 4.3 discute o mapeamento do MR parao 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 derelacionamento), atributos (que podem ser multivalorados e compostos), hierarquias deespecialização e restrições estruturais (domínio, chave, unicidade, cardinalidade mínimae máxima de atributo e relacionamento). O componente EBD é capaz de mapear para oModelo Relacional (MR) todos estes conceitos utilizados para representar um SI.

4.1.1 Mapeamento de Entidades e Hierarquia de Especialização

A Tabela 4.1 apresenta informações do mapeamento de um tipo de entidadeno 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 possuemuma chave artificial (surrogate key) como chave primária.

O valor da chave artificial é gerado pelo EBD e não possui significado naperspectiva do negócio. A chave artificial pk pertence ao domínio inteiro e é incrementadaautomaticamente a cada inserção na relação.

O mnemônico do tipo de entidade do MMO é mapeado para o nome da relaçãono MR. Os atributos do tipo de entidade mapeados para a relação correspondente são osatributos simples monovalorados. No processo de mapeamento, os atributos de um atri-

4.1 Mapeamentos do MMO para MR 43

MMO MRMnemônico de Tipo de Entidade Nome da RelaçãoConjunto de Atributos Simples Monoval-orados

Conjunto de Atributos da Relação

Conjunto de Atributos com Restrições "Éparte de chave"

Restrição de unicidade sobre o conjuntode atributos

Restrição "É Único" sobre atributo Restrição de Unicidade sobre atributoInclusão de atributo pk com restrição pri-mary key

Restrição "É uma Especializaçãode" referenciando um Tipo de EntidadeGenérico

Restrição foreign key sobre o atributo pkreferenciando a relação correspondente aoTipo de Entidade Genérico

Tabela 4.1: Mapeamento de Entidades e Hierarquia de Entidadesdo MMO para o MR

MMO MRTipo do Atributo Tipo de Domínio DomínioBásico Alfanumérico AlfanuméricoBásico Inteiro InteiroBásico Decimal DecimalBásico Data DataEnumerado Booleano BooleanoEnumerado 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 umatributo não é armazenado (derivado) então é associada a ele uma regra de derivação quecalcula o valor deste atributo. Por exemplo, o atributo idade de uma pessoa física é umatributo derivado.

O mapeamento de tipos/domínios do MMO para o MR é apresentado na Tabela4.2.

O atributo do tipo enumerado é mapeado com uma chave estrangeira parauma relação Valor Enumerado que armazena todos os valores enumerados de todosos domínios enumerados. Esta relação possui uma chave estrangeira para uma relaçãoDomí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, corprimária e sexo. Já a relação Valor Enumerado recebe os valores do domínio; como porexemplo, 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


Figura 4.1: Mapeamento de Atributo Enumerado do MMO para oMR

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 consideracada tipo de entidade da hierarquia como uma relação. As vantagens desta abordagemsã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ãoafetam suas subentidades; (iii) e a quantidade de espaço armazenado é proporcional aonúmero de objetos armazenados.

Os pontos fracos desta abordagem são o potencial número de relações criadase, consequentemente o aumento de junções, afetando a eficiência das consultas de infor-mações na hierarquia. Essas limitações não são significativas, pois o próprio componenteEBD é responsável pela criação de relações e pela definição de operações de junção, quepodem ser otimizadas para cada plataforma alvo do SI.

A Figura 4.2 apresenta um exemplo de mapeamento de hierarquia de especial-ização do MMO para o MR. Para manter a integridade referencial entre instâncias dassuperentidades e respectivas subentidades é criada uma restrição de chave estrageira darelação da subentidade para a da superentidade. A chave estrangeira é a própria pk darelação especializada. A superentidade é obtida da restrição "é uma especialização de" doMMO.

4.1.2 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 destaabordagem 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 formade mapeamento.


Figura 4.2: Mapeamento de Hierarquia de Especialização doMMO para o MR

A Tabela 4.3 descreve o esquema para o mapeamento de atributo do tipo objetointerno do MMO para o MR. Primeiramente é criada uma relação com o nome definidopelo mnemônico do atributo objeto interno no MMO. Esta relação possui os atributospk, pkEnt, pkEntRef no domínio inteiro, sendo as duas últimas chaves estrangeiraspara 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 parao MR

O atributo do tipo objeto interno pode ter subatributos, que correspondem aatributos do relacionamento. O mapeamento é feito da mesma forma descrita para o tipode entidade, ou seja, são considerados o mesmo mnemônico e a conversão de tipo doMMO para o MR (Tabela 4.2).


MMO MRMnemônico Objeto Interno Nome da Relação

Inclusão de atributo pk com restrição pri-mary keyInclusão de atributo pkEnt com restriçãode não nulidade foreign key referenciandoa relação correspondente à entidade quecontém o atributo objeto interno

Restrição "Entidade Referenciada" indi-cando a Entidade do Relacionamento

Inclusão do atributo pkEntRef com restri-ção de não nulidade e foreign key refe-renciando a relação correspondente à Enti-dade Referenciada pelo atributo objeto in-terno

Restrição "Atributo Referenciado" indi-cando o atributo Objeto Interno do Rela-cionamento. Só ocorre quando é definidorelacionamento com agregação

Inclusão do atributo pkAtribRef com res-trição de não nulidade e foreign key re-ferenciando a relação correspondente aoAtributo Referenciado pelo atributo objetointernoInclusão da restrição de unicidade para opar (pkEnt, pkEntRef ) ou, no caso de rela-cionamento com agregação, (pkEnt, pkA-tribRef )

Tabela 4.3: Mapeamento de Objeto Interno do MMO para o MR

Para representação de relacionamento com agregação, isto é, relacionamentosentre relacionamentos, a relação do atributo do tipo objeto interno possui algumasvariáveis adicionais. A Figura 4.4 apresenta o mapeamento do MMO para o MR deatributo do tipo objeto interno que representa relacionamento com agregação.

A relação que representa o atributo objeto interno possui uma chave estrangeirapara a relação que representa a entidade contendo o atributo que está sendo mapeado epara a relação que representa o atributo de referência.

4.1.3 Mapeamento de Entidade Fraca

Pela definição de entidade fraca, não há a restrição de unicidade para os atributosque fazem parte da chave parcial. As instâncias de uma entidade fraca são identificadas apartir 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 deatributos simples. Para a entidade fraca, além dos atributos simples que compõem a chaveparcial é 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 osatributos da chave lógica da entidade de referência do atributo objeto interno que faz parte


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 entidadefraca.

O mapeamento do atributo objeto interno que faz parte da chave da entidadefraca é 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


MMO MRMnemônico do Atributo Nome da Relação

Inclusão de atributo pk com restrição denão nulidade foreign key referenciandoa relação correspondente à entidade quecontém o atributo multivaloradoInclusão de atributo com o nome valor narelaçãoInclusão da restrição de primary key sobreo atributo pk e o atributo valor

Tabela 4.4: Mapeamento do Atributo Simples Multivalorado doMMO para o MR

4.1.4 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 Tabela4.4 descreve as regras deste mapeamento.

Figura 4.6: Mapeamento de Atributo Multivalorado do MMO parao MR

No processo de mapeamento primeiramente é criada uma relação com o nome doatributo 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 atributomultivalorado. O domínio da coluna valor é obtido através da conversão descrita naTabela 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 umarelação no MR. A Figura 4.7 mostra um exemplo deste mapeamento.

Figura 4.7: Mapeamento de Atributo Composto do MMO para oMR

O mapeamento inicia com a criação da relação com o mesmo nome do atributono modelo MMO. As colunas da relação são definidas pela lista de subatributos do

4.2 Geração de DML para Operações CRUD 49

MMO MRMnemônico do Atributo Nome da Relação

Inclusão de atributo pk com restrição pri-mary keyInclusão de atributo pkEnt com restriçãode não nulidade foreign key referenciandoa relação correspondente à entidade quecontém o atributo multivalorado

Conjunto de Atributos Simples Monoval-orados

Conjunto de Atributos da Relação

Conjunto de SubAtributos com Restrição"É parte de chave"

Inclusão da restrição de unicidade sobre oatributo pkEnt e o conjunto de atributos

Tabela 4.5: Mapeamento do Atributo Composto Multivalorado doMMO 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 chaveestrangeira 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 compostopossui chave parcial, como uma entidade fraca. A restrição de unicidade é criada a partirdos 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 CRUDpara 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çõesgeradas para cada um desses conceitos do MMO.

4.2.1 DML para Tipo de Entidade

Para cada tipo de entidade há dois tipos de consultas implícitas no MMO: umapara 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 deum tipo de entidade. A consulta é feita na relação Entidade, lembrando que o nome darelação é igual ao mnemônico do tipo de entidade no MMO.

A lista de atributos da operação project (π) é a lista de todos os atributossimples monovalorados da entidade. A consulta para obtenção de uma instância de tipode entidade é apresentada pela Tabela 4.6 (b). A projeção leva em conta a mesma lista de


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ânciapkEnt← maxpk(Entidade) + 1Entidade← Entidade ∪ {(pkEnt, val1, val2, val3)}(d) Remoção de InstânciapkEnt← πpk(σEntidade.atributo1=val1 AND

Entidade.atributo2=val2(Entidade))Entidade← Entidade -

σEntidade.pk=pkEnt (Entidade)(e) Atualização de InstânciapkEnt← π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 (σ) dainstância da entidade.

A condição de seleção da instrução σ é criada a partir do atributos que fazemparte 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 simplesmonovalorado que faz parte da chave e valN é uma variável, sendo N a sua posição nalista de atributos simples da entidade. A variável vali tem o mesmo domínio do atributoatribi da relação Entidade.

As instruções para inserção de instância de entidade são apresentadas naTabela 4.6 (c). Antes de inserir a instância da entidade, primeiramente é calculado o valorda chave primária, adicionando um ao maior valor na relação Entidade, armazenado navariável pkEnt.

A tupla {(pkEnt, val1, val2, val3)} é formada com o valor da chaveprimária artificial mais os valores val1, val2 e val3 para os atributos atrib1, atrib2 eatrib3 respectivamente. Só então a nova tupla é inserida no conjunto de tuplas da relaçãoEntidade.

A Tabela 4.6 (d) apresenta o conjunto de instruções para remoção de instânciasde tipo de entidade. A remoção é iniciada obtendo a chave primária através da chave


lógica da entidade. A consulta é semelhante à consulta para obtenção de uma instânciade entidade. A diferença está na lista de projeção que considera somente o atributo pk. Aexclusão é feita a partir da seleção (σ) da tupla que possui o valor da chave primária igualao valor armazenado na variável pkEnt.

A operação de atualização de instância de entidade é apresentada na Tabela4.6 (e). Da mesma forma que a remoção de instâncias, a atualização é feita em duasetapas: uma para obter a chave primária da entidade e outra para executar a instrução deatualizaçã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. Adiferença está na condição da consulta onde os valores da chave lógica devem ser osvalores antes da modificação da instância da entidade.

Caso a chave lógica seja modificada, os valores armazenados em val1 e val2 nãopodem ser utilizados na consulta para obtenção da chave primária, pois a consulta nãoretornaria nada. Para isso, são definidas as variáveis va1NMod e val2NMod que recebemos valores antes da modificação da chave lógica.

A instrução de atualização possui uma lista de atribuição que é definida peloformato atributoN ← valN, onde atributoN é o atributo N da relação, e valN é avariável que armazena o novo valor do atributo.

4.2.2 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, listade junções e lista de atribuições na instrução de atualização) devem contemplar todas asentidades 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 especializadapode ser obtida através do Código 4.1.


Código 4.1 Obtenção de Lista de Atributos Simples de uma Hierarquia de Especialização1 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;

12

13 atributos = obterAtributosEntidade (mneEntidade);

14

15 para cada elemento em atributos faça

16 listaAtributos = listaAtributos + ’,’ + atributos[i] + ’,’;

17 fim

18

19 retorne listaAtributos

20 }

O conjunto de operações CRUD sobre tipo de entidades especializadas é apre-sentado na Tabela 4.7. Nas operações de consulta, a lista de atributos da operação deprojeção é composta pelos atributos simples monovalorados da superentidade mais osatributos simples monovalorados da subentidade.

Na operação de seleção (σ) são definidas as junções entre todas as tabelasque participam da hierarquia de especialização. A lista de junções pode ser obtidautilizando um algoritmo semelhante ao descrito no Código 4.1. Se a hierarquia deespecializaçã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 é de-

talhada na Tabela 4.7 (b). Na operação de seleção (σ) além das condições de junção é cri-ada a lista de comparação entre os atributos da chave lógica da superentidade e os valoresda chave lógica. Neste caso são considerados somente os atributos que identificam uni-camente uma instância, por isso que esta lista não possui atributos da subentidade. Cadacláusula da condição segue o padrão SuperEntidade.atribN = valN, onde SuperEnti-

dade é mnemônico da entidade raiz da hierarquia, mnemonicoAtributo é mnemônico do


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ânciapkEnt← maxpk(SuperEntidade) + 1SuperEntidade← SuperEntidade ∪ {(pkEnt, valA, valB)}SubEntidade← SubEntidade ∪ {(pkEnt, val1, val2, val3)}(d) Remoção de InstânciapkEnt← πpk(σSuperEntidade.atribA=valA(SuperEntidade))SubEntidade← SubEntidade -

σSubEntidade.pk=pkEnt (SubEntidade)(e) Atualização de InstânciapkEnt← π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 Especiali-zada

atributo simples monovalorado que faz parte da chave, e valN é uma variável, sendo N aposiçã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 doatributo pk na relação SuperEntidade. O valor encontrado é incrementado de um earmazenado na variável pkEnt.

A nova tupla da relação SuperEntidade {(pkEnt, valA, valB)} é formadacom o valor da chave primária artificial mais os valores valA e valB para os atributosatribA e atribB, respectivamente. Só então a nova tupla é inserida no BD. Os atributosatribA e atribB são os atributos simples monovalorados da entidade com o mnemônicoSuperEntidade.

A instrução para inserção da tupla da relação SubEntidade é obtida da mesmaforma que a instrução da relação SuperEntidade. O atributo pk recebe o mesmo valor da


variável pkEnt garantindo que a chave da superentidade seja propagada por toda a cadeiade especialização.

Na operação de remoção, primeiramente é feita a busca pela chave primária dasuperentidade. Como o valor é o mesmo para as subentidades, na instrução para removera instância da subentidade SubEntidade a condição de seleção compara os valores pk darelaçã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 aconsulta para obtenção de uma instância de uma entidade especializada; a única diferençaestá 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 super-entidade é semelhante à utilizada na remoção de instância de entidade especializada; adiferença está na condição da consulta, que segue o mesmo príncípio discutido na atual-ização de instância de entidade forte, com a busca sendo feita com o valor da chave lógicanão modificada. No caso descrito na Tabela 4.7 (e), a consulta é feita considerando o valorda variável valANMod que armazena a chave de SuperEntidade.

A atualização é feita da raiz da especialização para as folhas, ou seja, dasuperentidade para a cadeia de subentidades da hierarquia. Cada entidade na cadeia possuiuma instrução para atualização de seus atributos.

A geração de instruções para atualização de hierarquia de especialização podeser obtida com algoritmo semelhante ao apresentado no Código 4.1.

A atualização da instância da subentidade é feita depois de obtida a chaveprimária da superentidade. A operação de projeção (π) possui uma lista de atribuiçõesdefinida a partir dos atributos simples da subentidade e dos novos valores para estesatributos. A montagem desta lista de atribuições segue o mesmo princípio utilizado naoperação de atualização de instância de entidade.

4.2.3 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 oatributo pertence, a relação do atributo objeto interno e a relação da entidade referenciadapor 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 atributosde ligação. A lista de atributos é definida utilizando o padrão Entidade.atrib, onde


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(


Ob jetoInterno.pkEntidadeRe f=EntidadeRe f .pk AND

Entidade.atrib1=val1(Entidade × ObjetoInterno × EntidadeRef)

)(c) Inserção de InstânciapkEnt← πpk(σEntidade.atrib1=val1(Entidade))pkEntRef← πpk(

σEntidadeRe f .atribA=valA AND EntidadeRe f .atribB=valB(EntidadeRef))pkNovo← maxpk(ObjetoInterno) + 1ObjetoInterno← ObjetoInterno ∪ {(pkNovo, pkEnt, pkEntRef, subAtrib1)}(d) Remoção de InstânciapkEnt← π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ânciapkEnt← πpk(σEntidade.atrib1=val1(Entidade))pkEntRef← πpk(

σEntidadeRe f .atrib1=valA AND EntidadeRe f .atrib2=valB(EntidadeRef))ObjetoInterno← πsubatrib1←subval1(


Ob jetoInterno.pkEntidadeRe f=pkEntRe f (ObjetoInterno))

Tabela 4.8: Operações CRUD sobre Atributo Objeto Interno


Entidade é o mnemonico da entidade de referência, e atrib é o mnemonico do atributode ligação.

A condição da consulta é definida pelas condições de junção e pela condição paraseleção das instâncias. A consulta terá pelo menos duas condições de junção: uma parajunçã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 formama chave lógica da entidade à qual o atributo objeto interno pertence e os valores dosparâmetros da condição de seleção. Na Tabela 4.8 a chave da consulta é definida porEntidade.atrib1 = val1, que é a chave lógica da entidade Entidade. Para obtençãode uma instância, a condição de seleção também considera os atributos que fazem parteda chave da entidade referenciada.

Na operação de inserção, primeiramente são obtidas as chaves primárias dasinstâncias das entidades envolvidas no relacionamento. A chave primária da relaçãoEntidade é obtida através da consulta na qual a condição vem da comparação en-tre os atributos que compõem a chave lógica da entidade e seus valores, neste casoEntidade.atrib1 = val1. A consulta para obtenção de chave primária de entidade ref-erenciada utiliza o mesmo mecanismo. As variáveis pkEnt e pkEntRef armazenam achave 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.8o objeto interno possui somente um subatributo, subAtrib1.

No processamento para remoção de instância do atributo do tipo objetointerno, primeiramente obtém-se as chaves primárias da entidade proprietária do atributoe da entidade de referência do atributo, da mesma forma feita no processamento parainserção.

A criação da instrução de remoção é feita a partir da consulta da tupla do atributoonde o valor da chave estrangeira para a entidade é igual ao valor da variável pkEnt, eo valor da chave estrangeira para a entidade de referência possui o valor igual à variávelpkEntRef.

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ân-cia da entidade de referência é considerada uma atualização, mas pode ser feita a partirde uma remoção e uma inserção.

Semelhante ao processo de remoção, primeiramente devem ser obtidas as chavesprimá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 nalista de projeção são definidas as atribuições de valores para os atributos da relaçãoObjetoInterno. Esta lista é definida pelo formato subatribN ← subvalN, onde suba-


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 agre-

gação. A operação de consulta é feita de forma semelhante à consulta gerada pela Tabela4.8 que define o processamento para consulta de instância de atributo objeto interno.

Tabela 4.9: Obtenção de Instâncias de Atributo Objeito Interno(Agregação)

Relações: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 (


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 (


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


Continuação da Tabela 4.9

(c) Inserção de InstânciapkEnt← πpk(σEntidade.atrib1=val1(Entidade))pkNovo← maxpk(ObjetoInterno) + 1pkAtribRef← πpk(

σ AtributoRe f .pkEntidadeRe f=EntidadeRe f .pk AND

AtributoRe f .pkEntidadeRe f=EntidadeAtribRe f .pk AND


(EntidadeRef × AtributoRef × EntidadeAtribRef)ObjetoInterno← ObjetoInterno ∪ {(pkNovo, pkEnt, pkAtribRef, subAtrib1)}

(d) Remoção de InstânciapkEnt← πpk(σEntidade.atrib1=val1(Entidade))pkAtribRef← πpk(




(EntidadeRef × AtributoRef × EntidadeAtribRef)ObjetoInterno← ObjetoInterno -


Ob jetoInterno.pkAtributoRe f=pkAtribRe f (ObjetoInterno)

(e) Atualização de InstânciapkEnt← πpk(σEntidade.atrib1=val1(Entidade))pkAtribRef← πpk(




(EntidadeRef × AtributoRef × EntidadeAtribRef))ObjetoInterno← πsubatrib1←subval1(


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. Alista de atributos da operação de projeção é definida pelos atributos de ligação da entidadede referência e da entidade de referência do atributo de referência, mais os subatributos doatributo objeto interno, representados, respectivamente, por atribA, atribB, atribX

e subatrib1.


A consulta é feita através da junção entre a relação da entidade à qual o atributopertence (relação do atributo) e a relação da entidade de referência, relação do atributode referência e a relação da entidade de referência do atributo de referência represen-tadas no exemplo por Entidade, ObjetoInterno, EntidadeRef, EntidadeAtribRef eAtributoRef. 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 contaa chave lógica do tipo de entidade à qual ele pertence (na Tabela 4.9 é o atributo atrib1) ea chave lógica do atributo objeto interno de referência. A chave lógica deste atributo é achave lógica da entidade à qual ele pertence (atributo atribA) mais a chave da entidade dereferência (atributo atribX).

O processo de inserção de instâncias do atributo objeto interno para agre-gação é semelhante ao definido para o atributo objeto interno (Tabela 4.8), sendonecessário obter as chaves primárias da entidade proprietária do atributo e do atributode 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á nacondição da seleção que considera os atributos que fazem parte da chave da entidade dereferência. A nova tupla é definida como ({(pkNovo, pkEnt, pkAtribRef, subAtrib1)}) einserida na relação ObjetoInterno.

No processamento para remoção de instância do atributo do tipo objetointerno para relacionamento com agregação, primeiramente são obtidas e armazenadasnas variáveis pkEnt e pkAtribRef, respectivamente, as chaves primárias da entidadeproprietária do atributo e do atributo de referência.

Então é feita uma seleção (σ) para obtenção da tupla que será removida. A chavedesta seleção são os valores pkEnt e pkAtribRef comparados, respectivamente, com achave 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 objetointerno para agregação, primeiramente são obtidas e armazenadas nas variáveis pkEnte pkAtribRef, respectivamente, as chaves primárias da entidade proprietária do atributoe do atributo de referência. Então é feita uma seleção (σ) para obtenção da tupla queserá 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 parao atributo de referência.

Na operação de projeção (π) é definida a lista de atribuição composta pelossubatributos da relação ObjetoInterno e pelos novos valores, seguindo o formatosubatribN ← subvalN, onde subatribN é o subatributo N do atributo, e subvalN é avariável que armazena o novo valor.


4.2.4 DML para Tipo de Entidade Fraca

Uma entidade fraca possui, no conjunto de atributos que compõem a chaveparcial, um atributo do tipo objeto interno que identifica a entidade da qual a entidadefraca tem dependência de identificação. A chave lógica da entidade fraca é compostapelos atributos da chave lógica da entidade de referência do atributo objeto interno quefaz parte da chave (entidade identificadora) mais os atributos simples da chave parcial daentidade fraca.

Os detalhes das operações CRUD sobre entidade fraca são apresentados naTabela 4.10. 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 osatributos 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 deentidade 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 represen-tam 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, aconsulta é semelhante à consulta definida na Tabela 4.10 (a). A diferença está na condiçãoda seleção que contém os atributos que compõem a chave lógica (chave lógica da entidadeidentificadora 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çãocorrespondente. Em seguida é obtida e armazenada na variável pkEnt a chave primária daentidade fraca e, finalmente, as instâncias da entidade identificadora e da entidade fracasão associadas através da inserção na relação que representa o atributo objeto interno quefaz parte da chave da entidade fraca.

Na operação para remoção de instância de tipo de entidade fraca, o proces-samento é composto pelas operações de obtenção da chave primária da entidade iden-tificadora e da entidade fraca armazenadas, respectivamente, nas variáveis pkEntRef epkEnt. Antes de remover a tupla da entidade fraca é removida a tupla da relação que rep-resenta o atributo objeto interno que associa as instâncias da entidade identificadora e daentidade 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 dachave lógica antes da modificação. Na operação de projeção (π) é definida a lista deatribuiçã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, evalN é a variável que armazena o novo valor para atribN.


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.pkEntRe f=EntidadeProp.pk AND

EntidadeProp.atribA=valA AND EntidadeFraca.atrib1=val1(EntidadeFraca × ObjetoInternoParteChave × EntidadeProp)

)(c) Inserção de InstânciapkEntRef← πpk(σEntidadeProp.atribA=valA(EntidadeProp))pkEnt← maxpk(EntidadeFraca)EntidadeFraca← EntidadeFraca ∪ {(pk, atrib1, atrib2)}pkNovo← maxpk(mnmonicoObjInternoParteChave)mnmonicoObjInternoParteChave ← mnmonicoObjInternoParteChave ∪ {(pkNovo,pkEnt, pkEntRef)}(d) Remoção de InstânciapkEntRef← πpk(σEntidadeProp.atribA=valA(EntidadeProp))pkEnt← πEntidadeFraca.pk(



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ânciapkEntRef← πpk(σEntidadeProp.atribA=valANMod(EntidadeProp))pkEnt← πEntidadeFraca.pk(



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


4.2.5 DML para Atributo Composto

As operações CRUD sobre atributo composto são detalhadas na Tabela 4.11. Naoperação de projeção são considerados os subatributos simples monovalorados do atributocomposto (subAtrib1, subAtrib2, subAtrib3). Na operação de seleção é estabelecida ajunçã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 daentidade à qual o atributo pertence. No exemplo, o atributo atrib1 é a chave lógica daentidade. Para obtenção de uma instãncia de atributo composto a condição de seleçãoconsidera também os atributos que fazem parte da chave parcial.

O processo de inserção de instâncias do atributo composto é iniciado coma obtenção da chave primária da entidade. O valor da chave é armazenado na variávelpkEnt. Depois, é criada a nova tupla da relação AtributoComposto {(pkNovo, pkEnt,

subval1, subval2, subval3)}. A variável pkNovo é a chave primária da tupla obtidaa partir do maior valor do atributo pk mais um; pkEnt é a chave primária da enti-dade; e subval1, subval2, subval3 são os valores para os subatributos subatrib1,subatrib2, subatrib3. A nova tupla é inserida no conjunto de tuplas da relaçãoAtributoComposto através da operador de união de conjuntos (∪).

Nas instruções para remoção de instâncias do atributo composto, o proces-samento é 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 compostolevando em conta os valores da chave lógica da entidade (pkEnt) mais a chave parcialdo 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áriaigual 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 segundainstrução obtém a chave primária do atributo composto, levando em conta a chaveprimária da entidade mais a chave parcial do atributo composto não modificada. A tuplana 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 doatributo composto e seus novos valores.

4.2.6 DML para Atributo Simples Multivalorado

A Tabela 4.12 apresenta as operações sobre instâncias de atributo simples multi-valorado. A operação de projeção é definida com o atributo valor da relação Atributo.


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ânciapkEnt← πpk(σEntidade.atrib1=val1(Entidade))pkNovo← maxpk(AtributoComposto) + 1AtributoComp← AtributoComp ∪ {(pkNovo, pkEnt, subval1,

subval2, subval3)(d) Remoção de InstânciapkEnt← π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ânciapkEnt← π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


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ânciapkEnt← πpk(σEntidade.atrib1=val1(Entidade))Atributo← Atributo ∪ {(pkEnt, valor)}(c) Remoção de InstânciapkEnt← πpk(σEntidade.atrib1=val1(Entidade))Atributo← Atributo - {(pkEnt, valor)}(d) Atualização de InstânciapkEnt← π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 doatributo 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 coma condição Entidade.atrib1 = val1.

Na operação de inserção de instâncias do atributo simples multivalorado, oprocessamento é 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áriada entidade e val é o valor do atributo multivalorado. A nova tupla é inserida no conjuntode 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 simplesmultivalorado é iniciado com a instrução para obter a chave primária da entidade. Achave da entidade é armazenada na variável pkEnt. Depois, é removida a tupla que tem oformato {(pkEnt, valor)} que é a chave da relação Atributo.

Na operação de atualização de instância do atributo simples multivaloradoo 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 dacondição de seleção que envolve a chave primária da entidade (armazenada na variávelpkEnt) e o valor do atributo antes da modificação (variável valNMod). O parâmetro val

contém o novo valor do atributo.

4.3 Mapeamento do MR para PostgreSQL 65

MR SQL (PostgreSQL)Alfanumérico VARCHARInteiro INTEGERDecimal DOUBLE PRECISIONData DATEBooleano 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 é divididoem duas etapas: a primeira é o mapeamento do MMO para o MR (MR); na segunda etapao MR é mapeado para um dialeto SQL. Nesta seção são apresentados os mapeamentos doMR para o SQL do SGBD PostgreSQL 8.4 [53].

4.3.1 Geração de Tabelas

No mapeamento do MMO para o MR foi determinada como decisão de projetoa criação de uma chave artificial para cada relação. Este atributo é um inteiro que é in-crementado automaticamente toda vez que é feita um inserção na relação. O PostgreSQLpossui o domínio SERIAL com estas características.

Outra restrição em relação ao mapeamento para SQL é a utilização das instruçõesON 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íniosdos atributos do MR para os tipos de dados em SQL. A Tabela 4.13 apresenta estemapeamento.

A criação da tabela envolve a criação de duas listas: lista de atributos e listade restrições. O Código 4.2 apresenta um exemplo de estrutura de tabela modelo doPostgreSQL.

Código 4.2 Tabela Modelo em PostgreSQL1 CREATE TABLE mnemonicoEntidade (

2 pk SERIAL,

3 listaAtributos,

4 ...

5 PRIMARY KEY (pk),

6 listaRestrições,

7 );

No mapeamento do MR para SQL as relações são mapeadas para tabelas. ATabela 4.14 apresenta este mapeamento. O nome da tabela é o mesmo nome da relação,


MR SQLNome da Relação Nome da TabelaConjunto de Atributos da Relação Conjunto de colunas da TabelaRestrição de unicidade sobre o conjuntode atributos

Restrição UNIQUE sobre o conjunto deatributos

Restrição de Unicidade sobre atributo Restrição UNIQUE sobre o atributoInclusão do atributo pk com restrição pri-mary key

Inclusão do atributo pk com tipo SERIALe restrição PRIMARY KEY

Restrição foreign key sobre o atributo pkreferenciando a relação correspondente àEntidade Genérica

Restrição FOREIGN KEY sobre a colunapk referenciando a tabela que representa arelação genérica da especialização.

Tabela 4.14: Mapeamento de Relação "Entidade" do MR paraSQL

assim como os nomes das colunas da relação são os mesmos dos atributos da tabela. Nadefinição da tabela, cada atributo é associado a um tipo do SQL, conforme mapeamentodefinido na Tabela 4.13.

As restrições de integridade, de chave primária e unicidade são mapeadas para asclá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. Aquelesatributos que possuem restrição de unicidade também são colocados em uma cláusulaUNIQUE.

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 fazemparte da chave parcial.

No mapeamento de hierarquia de especialização o atributo pk da relaçãoespecializada é mapeado para um atributo do tipo INTEGER.

O mapeamento definido na Tabela 4.14 especifica que a relação da subentidadetem uma chave estrangeira para a superentidade. Na tabela da subentidade é utilizada acláusula FOREIGN KEY para definir esta restrição de integridade referencial.

Os atributos pk, pkEnt e pkEntRef que aparecem em relações correspondentesao mapeamento de objeto interno pertencem ao domínio inteiro no MR. Eles são ma-peados 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 definidoscomo chaves estrangeiras das tabelas Entidade e EntidadeRef, respectivamente, uti-lizando 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áusulaUNIQUE aplicada aos atributos pkEnt e pkEntRef. O Código 4.3 apresenta a tabelaresultante do mapeamento da Tabela 4.15.


MR SQLNome da Relação Nome da TabelaInclusão de atributo pk com restrição pri-mary key

Criação da coluna pk com tipo SERIAL erestrição PRIMARY KEY

Inclusão de atributo pkEnt com restriçãode não nulidade foreign key referenciandoa relação correspondente à entidade quecontém o atributo objeto interno

Criação do Atributo pkEnt com restriçãoFOREIGN KEY referenciando a tabelarepresentada pela relação da entidade àqual o atributo objeto interno pertence

Inclusão do atributo pkEntRef com restri-ção de não nulidade e foreign key refe-renciando a relação correspondente à Enti-dade Referenciada pelo atributo objeto in-terno

Criação do Atributo pkEntRef com res-trição FOREIGN KEY referenciando atabela representada pela relação da enti-dade referenciada

Inclusão do atributo pkAtribRef com res-trição de não nulidade e foreign key re-ferenciando a relação correspondente aoAtributo Referenciado pelo atributo objetointerno

Criação do Atributo pkAtribRef e comrestrição FOREIGN KEY referenciando atabela representada pela relação do atri-buto referenciado

Inclusão da restrição de unicidade para opar (pkEnt, pkEntRef ) ou no caso de rela-cionamento com agregação (pkEnt, pkA-tribRef )

Aplicação da restrição UNIQUE sobre opar de colunas pkEnt, pkEntRef ou no parpkEnt, 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 Interno1 CREATE TABLE ObjetoInterno (

2 pk SERIAL,

3 pkEnt INTEGER NOT NULL,

4 pkEntRef INTEGER NOT NULL,

5 lista de atributos do relacionamento (opcional),

6

7 PRIMARY KEY (pk),

8 FOREIGN KEY (pkEnt) REFERENCES Entidade(pk)

9 ON UPDATE RESTRICT ON DELETE RESTRICT,

10

11 FOREIGN KEY (pkEntRef) REFERENCES EntidadeRef(pk)


13 FOREIGN KEY (pkAtribRef) REFERENCES AtributoRef(pk)


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-


MR SQLNome da Relação Nome da TabelaInclusão de atributo pk com restrição denão nulidade foreign key referenciandoa relação correspondente à entidade quecontém o atributo multivalorado

Criação da Coluna pk com a restriçãoFOREIGN KEY para a tabela que corre-sponde a tabela da entidade

Inclusão do atributo com o nome valor narelação

Criação da coluna valor; o domínio éobtido através do mapeamento do MMOpara MR e deste para SQL

Inclusão da restrição de primary key sobreo atributo pk e o atributo valor

Aplicação da restrição PRIMARY KEYsobre as colunas pk e valor

Tabela 4.16: Mapeamento de Relação "Atributo Multivalorado"do MR para SQL do PostgreSQL

MR SQLNome da Relação Nome da TabelaInclusão de atributo pk com restrição pri-mary key

Criação da coluna pk com a restrição PRI-MARY KEY

Inclusão de atributo pkEnt com restriçãode não nulidade foreign key referenciandoa relação correspondente à entidade quecontém o atributo multivalorado

Criação da coluna pkEnt com restriçõesNOT NULL e FOREIGN KEY referenci-ando à tabela da entidade

Conjunto de Atributos da Relação Conjunto de colunas da tabelaInclusão da restrição de unicidade sobre oatributo pkEnt e o conjunto de atributos

Aplicação da restrição UNIQUE sobre acoluna pkEnt e o subconjunto de colunas

Tabela 4.17: Mapeamento de Relação "Atributo Composto" doMR para o SQL do PostgreSQL

sponde a um atributo multivalorado. A tabela recebe o mesmo nome da relação. A re-lação possui duas colunas, uma pk e valor, as quais possuem, respectivamente, domíniointeiro e um domínio permitido no MR. Este domínio é definido a partir do domínio doatributo que foi mapeado do MMO para MR.

As colunas pk e valor são definidas como PRIMARY KEY. A coluna pk é chaveestrangeira para a entidade à qual o atributo pertence.

Os detalhes do mapeamento para uma relação que corresponde a um atributocomposto são apresentados na Tabela 4.17. A coluna pkEnt é chave estrangeira para arelação da entidade à qual o atributo pertence. Na Tabela 4.17 a clásula UNIQUE é a chavelógica da tabela que representa o atributo composto. Esta chave é composta pela colunapkEnt e as colunas que fazem parte da chave parcial.


4.3.2 Geração de Stored Procedures (SP) em PL/pgSQL

Esta seção apresenta os mapeamentos de stored procedures (SP) para manip-ulação de instâncias de entidade, hierarquia de especialização, atributo do tipo objetointerno, atributo composto e atributo simples multivalorado. A linguagem alvo utilizadaneste mapeamento é a linguagem procedural do SGBD PostgreSQL, a PL/pgSQL [52].

A maioria dos frameworks ORM para linguagem Java utilizam JPA [49] paragerenciar o mapeamento objeto relacional. Nesta abordagem as operações são geradas emtempo de execução. Um experimento foi feito para decidir entre stored procedures e SQLdinâmico. Neste experimento, foi criada uma tabela com quatro colunas. Em um programaJava foi criado um loop, que armazenava uma tupla na tabela a cada iteração. A eficiênciafoi medida em relação ao número de tuplas persistidas utilizando stored procedure e SQLdinâmico. No teste com centena de milhares de tuplas o programa travou, utilizando SQLdinâmico. Com o mesmo número de tuplas, a stored procedure persistiu as informaçõessem 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 omodelo de stored procedure do PL/pgSQL. As stored procedures para operações deinserção, remoção e atualização sempre retornam um valor booleano true (o tratamentode exceções é feito no componente de persitência EBD no subpacote Serviços de Acessoa 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 linhasdo resultado por vez.

Código 4.4 Modelo de Stored Procedure em PL/pgSQL1 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 umainstância específica. A Tabela 4.18 apresenta o mapeamento do MR para SQL para asoperaçõ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 onome da relação.


Para criar uma SP para obtenção de uma instância da entidade, o mapeamentodescrito na Tabela 4.18 é executado. A cláusula WHERE recebe a condição da operaçãode 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âmetroos valores da chave lógica da entidade. As variáveis val1 e val2 são mapeadas para alista 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 é definidoa partir do domínio no MR, que é mapaeado para o tipo em SQL de acordo com a Tabela4.13. O Código 4.5 apresenta o resultado do mapeamento descrito na Tabela 4.18 para aoperação de obtenção de uma instância.

Código 4.5 Stored Procedure Modelo para Obtenção de Instâncias de Tipo de Entidade1 CREATE FUNCTION obterEntidadeAtivo(va1 TipoSQL, val2 TipoSQL) RETURNS

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;

10

11 RETURN csr;

12 END;


No mapeamento para geração de stored procedure de inserção de instância deentidade, a instrução INSERT possui duas listas, uma com os atributos da tabela querecebem os valores e uma com os valores dos parâmetros. A primeira lista é obtida apartir 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 ←maxpk(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 umainserção na tabela.

A lista de parâmetros é formada pela lista de variáveis correspondentes aosatributos 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 entidademapeada na Tabela 4.18.


MR SQL(a) Obtenção de Instâncias

πatrib1,atrib2,atrib3(Entidade) SELECT atrib1, atrib2, atrib3FROM Entidade

(b) Obtenção de Instânciaπatrib1,atrib2,atrib3( SELECT atrib1, atrib2, atrib3σEntidade.atrib1=val1 AND Entidade.atrib2=val2 FROM Entidade

(Entidade))WHERE Entidade.atrib1 = val1 AND En-tidade.atrib2 = val2

(c) Inserção de InstânciapkEnt← maxpk(Entidade) + 1mnmonicoEntidade ← Entidade ∪{(pkEnt, val1, val2, val3)}

INSERT INTO Entidade (atrib1, atrib2,atrib3) VALUES (val1, val2, val3)

(d) Remoção de InstânciapkEnt← πpk(σEntidade.atrib1=val1 AND SELECT INTO pkEnt pkEntidade.atrib2=val2(Entidade)) FROM Entidade

WHERE Entidade.atrib1 = val1 ANDEntidade.atrib2 = val2;

Entidade← Entidade -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 pkEntidade.atrib2=val2NMod(Entidade)) FROM Entidade

WHERE Entidade.atrib1 = val1NModANDEntidade.atrib2 = val2NMod;

Entidade← UPDATE Entidade

πatrib1←val1 ,atrib2←val2 ,atrib3←val3(SET atrib1 = val1, atrib2 = val2, atrib3 =val3

σEntidade.pk=pkEnt (Entidade)) WHERE pk = pkEnt;

Tabela 4.18: Mapeamento de Operações CRUD sobre Tipo de En-tidade


Código 4.6 Stored Procedure Modelo para Inserção de Instância de Tipo de Entidade1 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;


No mapeamento para remoção de instância de entidade, a instrução para obtera chave primária (pk) é mapeada para SQL utilizando a instrução SELECT INTO. Asclá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 valoresdos 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 Entidade1 CREATE FUNCTION desativarEntidade (va1 TipoSQL, val2 TipoSQL)


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;

11

12 DELETE FROM Entidade WHERE pk = pkEnt;

13

14 RETURN TRUE;

15 END;


No mapeamento para operação de atualização de instância de entidade, ainstrução para obtenção da chave primária é mapeada para a instrução SELECT INTO deSQL. A cláusula WHERE é definida partir de uma lista de comparação da operação deseleção no MR. Neste exemplo é a lista de condição Entidade.atrib1 = val1NMod

AND Entidade.atrib2 = val2NMod.


Na instrução UPDATE é definida uma lista de atribuição dos atributos, com seusrespectivos parâmetros separados por vírgula. Esta lista é obtida através da lista daoperação de projeção (π). Antes de atribuir a lista à cláusula SET é feita a conversão dooperador 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çãoda tupla que será atualizada.

A lista de parâmetros da stored procedure é definida pelos valores da chaveló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 eatrib2 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 Entidade1 CREATE FUNCTION atualizarEntidade (va1NMod TipoSQL,

2 val2NMod TipoSQL, val1 TipoSQL, val2 TipoSQL, val3 TipoSQL)


4 DECLARE

5 pkEnt INTEGER;

6

7 BEGIN

8


10 FROM Entidade

11 WHERE Entidade.atrib1 = val1NMod AND

12 Entidade.atrib2 = val2NMod;

13

14 UPDATE Entidade

15 SET atrib1 = val1, atrib2 = val2, atrib3 = val3

16 WHERE pk = pkEnt;

17

18 RETURN TRUE;

19 END;


A Tabela 4.19 apresenta o mapeamento do MR para SQL para operações CRUDsobre tipo de entidade especializada. Nas operações de consulta, a lista de atributosda operação de projeção (π) é mapeada para a lista da cláusula SELECT. A lista derelações da operação de seleção é mapeada para a cláusula FROM, substituindo o produtocartesiano (×) pelo operador de junção (JOIN). No PostgreSQL a condição de junçãopode ficar na clásula FROM, então a condição da operação de seleção é mapeada para acláusula FROM da consulta em SQL.


Para criar a SP para obtenção de uma instância de entidade especializada, omapeamento segue a definição da Tabela 4.19. A cláusula WHERE recebe a condiçãoda operação de seleção (σ), que faz a comparação dos atributos chave da relação quecorresponde à superentidade (atribA) com os valores de pesquisa (valA).

A stored procedure para obtenção de uma instância de entidade especializadarecebe 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 modeloda SP resultante do mapeamento.

Código 4.9 Stored Procedure Modelo para Obtenção de Instâncias de Tipo de EntidadeEspecializada

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;

11

12 RETURN csr;

13 END;


No mapeamento para geração de stored procedure de inserção de instânciade entidade especializada, primeiramente é inserida a instância da superentidade. Ainstrução INSERT possui duas listas, uma com os atributos da tabela que recebem osvalores e uma com os parâmetros contendo os valores. A primeira lista é obtida a partirda 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 especial-ização, e para isso é definida a instrução pkEnt ← maxpk(SuperEntidade) para obtera 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, paracolunas 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 in-serção para entidade especializada recebe como parâmetros os valores dos atributos da



πatribA,atribB,atrib1,atrib2,atrib3(SELECT atribA, atribB, atrib1, atrib2,atrib3

σSuperEntidade.pk=SubEntidade.pk FROM SuperEntidade JOIN SubEntidade(SuperEntidade × SubEntidade) ON SuperEntidade.pk = SubEntidade.pk;)

(b) Obtenção de Instância

πatribA,atribB,atrib1,atrib2,atrib3(SELECT atribA, atribB, atrib1, atrib2,atrib3

σSuperEntidade.pk=SubEntidade.pk AND FROM SuperEntidade JOIN SubEntidadeSuperEntidade.atribA=valA(SuperEntidade ×SubEntidade)

ON SuperEntidade.pk = SubEntidade.pk

) WHERE SuperEntidade.atribA = valA;(c) Inserção de Instância

pkEnt← maxpk(SuperEntidade) + 1SuperEntidade ← SuperEntidade ∪{(pkEnt, valA, valB)}

INSERT INTO SuperEntidade (atribA,atribB) VALUES (valA, valB);

pkEnt← maxpk(SuperEntidade) SELECT INTO pkEnt * FROM lastval();SubEntidade ← SubEntidade ∪ {(pkEnt,val1, val2, val3)}

INSERT INTO SubEntidade (pk, atrib1,atrib2, atrib3) VALUES(pkEnt, val1, val2, val3);

(d) Remoção de InstânciapkEnt← πpk( SELECT INTO pkEnt pkσSuperEntidade.atribA=valA(SuperEntidade)) FROM SuperEntidade

WHERE SuperEntidade.atribA = valA;

SubEntidade← SubEntidade -DELETE FROM SubEntidade WHEREpk = pkEnt;

σSubEntidade.pk=pkEnt (SubEntidade)(e) Atualização de Instância

pkEnt← πpk( SELECT INTO pkEnt pkσSuperEntidade.atribA=valANMod FROM SuperEntidade

(SuperEntidade))WHERE SuperEntidade.atribA = valAN-Mod;

SuperEntidade← UPDATE SuperEntidade SET atribA =valA, atribB = valB

πatribA←valA ,atribB←valB( WHERE pk = pkEnt;σSuperEntidade.pk=pkEnt (SuperEntidade)))

SubEntidade← UPDATE SubEntidade SET atrib1 = val1,atrib2 = val2, atrib3 = val3

πatrib1←val1 ,atrib2←val2 ,atrib3←val3( WHERE pk = pkEnt;σSubEntidade.pk=pkEnt (SubEntidade))

Tabela 4.19: Mapeamento de Operações CRUD sobre Tipo de En-tidade Especializada


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 EntidadeEspecializada

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;


No mapeamento para geração de stored procedure de remoção de instância deentidade 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çãoda 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 val-ores 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 4.19.

Código 4.11 Stored Procedure Modelo para Remoção de Instância de Tipo de EntidadeEspecializada

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;



No mapeamento para geração de stored procedure de atualização de instânciade 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 dosatributos com seus respectivos parâmetros separados por vírgula. Esta lista é obtidaatravé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 deatribuiçã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 paraobtenção da tupla que será atualizada. A stored procedure de atualização recebe comoparâmetros os valores dos atributos da chave lógica da superentidade antes da modifi-cação, os valores de todos os atributos da superentidade e os valores dos atributos simplesda subentidade. O modelo da stored procedure resultante do mapeamento é apresentadono Código 4.12

Código 4.12 Stored Procedure Modelo para Atualização de Instância de Tipo de EntidadeEspecializada

1 CREATE FUNCTION atualizarSubEntidade (valANMod TipoSQL,

2 valA TipoSQL, valB TipoSQL, val1 TipoSQL, val2 TipoSQL,

3 val3 TipoSQL) RETURNS BOOLEAN AS $$

4 BEGIN

5


7 FROM SuperEntidade

8 WHERE SuperEntidade.atribA = valANMod;

9

10 UPDATE SuperEntidade

11 SET atribA = valA, atribB = valB


13

14 UPDATE SubEntidade

15 SET atrib1 = val1, atrib2 = val2, atrib3 = val3


17

18 RETURN TRUE;

19 END;


Todas as SP de operações CRUD para relações que representam atributo dotipo 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 é


passada como parâmetro. Nas operações de inserção e atualização, além da chave lógicada entidade à qual o atributo pertence, é passada a chave lógica da entidade de referênciae, se for o caso, os subatributos. Na operação de remoção somente os valores das chaveslógicas das entidades envolvidas são passados como parâmetro.

As consultas para obtenção da chave primária que fazem parte do processamentopara as operações de inserção, remoção e atualização são mapeadas da mesma forma quea consulta para obtenção de instâncias de atributo objeto interno. A Tabela 4.20 apresentao mapeamento do MR para SQL para as operações CRUD sobre atributo objeto interno.

Tabela 4.20: Mapeamento de Operações CRUD sobre AtributoObjeto Interno

MR SQL

(a) Obtenção de InstânciasSELECT INTO pkEnt pk FROM Entidade

WHERE Entidade.atrib1 = val1;

πEntidadeRe f .atrib1,EntidadeRe f .atrib2(SELECT EntidadeRef.atribA, Enti-

dadeRef.atribBσ Entidade.pk=Ob jetoInterno.pkEntidade AND FROM Entidade JOIN ObjetoInterno

Ob jetoInterno.pkEntidadeRe f=EntidadeRe f .pk AND ON Entidade.pk = ObjetoInterno.pkEntidade

Entidade.atrib1=val1 EntidadeRe f .atribA=valA AND FROM EntidadeRef

EntidadeRe f .atribB=valB JOIN EntidadeRef

(Entidade × ObjetoInterno × EntidadeRef))

ON ObjetoInterno.pkEntidadeRef = Enti-

dadeRef.pk WHERE Entidade.pk = pkEnt

AND EntidadeRef.atribA = valA And Enti-

dadeRef.atribB = valB;

(b) Obtenção de InstânciaSELECT INTO pkEnt pk FROM Entidade


πEntidadeRe f .atrib1,EntidadeRe f .atrib2(SELECT EntidadeRef.atribA, Enti-

dadeRef.atribBσ Entidade.pk=Ob jetoInterno.pkEntidade AND FROM Entidade JOIN ObjetoInterno

Ob jetoInterno.pkEntidadeRe f=EntidadeRe f .pk AND ON Entidade.pk = ObjetoInterno.pkEntidade

Entidade.atrib1=val1 JOIN EntidadeRef

(Entidade × ObjetoInterno × EntidadeRef))ON ObjetoInterno.pkEntidadeRef = Enti-

dadeRef.pk WHERE Entidade.pk = pkEnt;

(c) Inserção de InstânciapkEnt← πpk(σEntidade.atribA=valA SELECT INTO pkEnt pk




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← maxpk(ObjetoInterno)

ObjetoInterno ← ObjetoInterno ∪ {(pkNovo,

pkEnt, pkEntRef, subAtrib1)}

INSERT INTO ObjetoInterno(pkEntidade,

pkEntidadeRef) VALUES (pkEnt, pkEntRef,

subval1);

(d) Remoção de InstânciapkEnt← πpk(σEntidade.atribA=valA SELECT INTO pkEnt pk



EntidadeRe f .atribB=valB(EntidadeRef) WHERE EntidadeRef.atribA = valA AND

) EntidadeRef.atribB = valB;

ObjetoInterno← ObjetoInterno - DELETE FROM ObjetoInterno WHERE

σOb jetoInterno.pkEntidade=pkEnt ANDpkEntidade = pkEnt AND pkEntidadeRef =

pkEntRef;Ob jetoInterno.pkEntidadeRe f=pkEntRe f (ObjetoInt-

erno)

(e) Atualização de InstânciapkEnt← πpk(σEntidade.atribA=valA SELECT INTO pkEnt pk



EntidadeRe f .atribB=valB(EntidadeRef))WHERE EntidadeRef.atribA = valA AND En-

tidadeRef.atribB = valB;ObjetoInterno← πsubatrib1←subval1( UPDATE ObjetoInternoσOb jetoInterno.pkEntidade=pkEnt AND SET subatrib1 = subval1Ob jetoInterno.pkEntidadeRe f=pkEntRe f (ObjetoInt-

erno))

WHERE pkEntidade = pkEnt AND pkEnti-

dadeRef = pkEntRef;




MR SQL

A lista de atributos da operação de projeção (π) é mapeada para a lista dacláusula SELECT de SQL. A lista de relações da operação de seleção é mapeada paraa 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çãoentre os valores e os atributos que compõem a chave lógica da entidade à qual o atributoobjeto interno pertence.

O Mapeamento para consulta de atributo objeto interno para agregação descritona Tabela 4.21 é feito da mesma forma. Os modelos das SPs resultante dos mapeamentosdas 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 ObjetoInterno

1 CREATE FUNCTION obterObjetoInternoAtivo(val1 TipoSQL)


3 DECLARE

4 csr CURSOR;

5 pkEnt INTEGER;

6

7 BEGIN


9 FROM Entidade

10 WHERE Entidade.atrib1 = val1;

11

12 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;

19

20 RETURN TRUE;

21 END;


No mapeamento para geração de stored procedure de inserção de instâncias deatributo objeto interno o nome da relação é mapeado para o nome da tabela na instruçãoINSERT. Esta instrução possui duas listas, uma com os atributos da tabela que recebem osvalores, e uma com os parâmetros contendo os valores. A primeira lista é obtida a partir


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 avariável pkNovo.

O Mapeamento para inserção de instâncias de atributo objeto interno paraagregação, descrito na Tabela 4.20, é feito da mesma forma.

Os modelos das stored procedures, de inserção resultantes dos mapeamentos dasTabelas 4.20 e 4.21 são apresentados, respectivamente, nos Códigos 4.14 e 4.18.

Código 4.14 Stored Procedure Modelo para Inserção de Instância de Atributo ObjetoInterno

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


9 SELECT INTO pkEntRef pk FROM EntidadeRef

10 WHERE EntidadeRef.atribA = valA AND

11 EntidadeRef.atribB = valB;

12

13 INSERT INTO ObjetoInterno(pkEntidade,

14 pkEntidadeRef) VALUES (pkEnt, pkEntRef, subval1);

15

16 RETURN TRUE;

17 END;


No mapeamento para geração de stored procedure de remoção de instâncias deatributo objeto interno a instrução de exclusão em álgebra relacional é mapeada para ainstruçã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 paraagregaçã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.21são apresentados nos Códigos 4.15 e 4.19, respectivamente.


Código 4.15 Stored Procedure Modelo para Remoção de Instância de Atributo ObjetoInterno

1 CREATE FUNCTION desativarObjetoInterno (val1 TipoSQL,

2 vala TipoSQL, valB TipoSQL) RETURNS BOOLEAN AS $$

3 DECLARE

4 pkEnt INTEGER;

5 pkEntRef INTEGER;

6 BEGIN






12

13 DELETE FROM ObjetoInterno

14 WHERE pkEntidade = pkEnt AND

15 pkEntidadeRef = pkEntRef;

16

17 RETURN TRUE;

18 END;


No mapeamento para geração de stored procedure de atualização de instânciasde atributo objeto interno a instrução de atualização em álgebra relacional é mapeadapara a instrução UPDATE, e o nome da relação na instrução em álgebra relacional é onome 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.


Código 4.16 Stored Procedure Modelo para Atualização de Instância de Atributo ObjetoInterno

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






12

13 UPDATE ObjetoInterno

14 SET subatrib1 = subval1

15 WHERE pkEntidade = pkEnt AND

16 pkEntidadeRef = pkEntRef;

17

18 RETURN TRUE;

19 END;


Tabela 4.21: Mapeamento de Operações CRUD sobre AtributoObjeito Interno (Agregação)

MR SQL

(a) Obtenção de InstânciasSELECT INTO pkEnt pk FROM Entidade


πEntidadeRe f .atribA,EntidadeRe f .atribB,SELECT EntidadeRef.atribA, Enti-

dadeRef.atribB,

EntidadeAtribRe f .atribX ( EntidadeAtribRef.atribXσ Entidade.pk=Ob jetoInterno.pkEntidade AND FROM Entidade JOIN ObjetoInterno

Ob jetoInterno.pkAtributoRe f=AtributoRe f .pk AND ON Entidade.pk = ObjetoInterno.pkEntidade

AtributoRe f .pkEnt=Entidade.pk AND JOIN AtributoRef

AtributoRe f .pkEntRe f=EntidadeRe f .pk ANDON ObjetoInterno.pkAtributoRef = Atribu-

toRef.pkEntidade.atrib1=val1 JOIN EntidadeAtribRef

(Entidade × ObjetoInterno × AtributoRef ×ON AtributoRef.pkEntRef = EntidadeAtri-

bRef.pk




MR SQLEntidadeRef × EntidadeAtribRef)) WHERE Entidade.pk = pkEnt;

(b) Obtenção de InstânciaSELECT INTO pkEnt pk FROM Entidade


πEntidadeRe f .atribA,EntidadeRe f .atribB,SELECT EntidadeRef.atribA, Enti-

dadeRef.atribB,

EntidadeAtribRe f .atribX ( EntidadeAtribRef.atribXσ Entidade.pk=Ob jetoInterno.pkEntidade AND FROM Entidade JOIN ObjetoInterno

Ob jetoInterno.pkAtributoRe f=AtributoRe f .pk AND ON Entidade.pk = ObjetoInterno.pkEntidade

AtributoRe f .pkEnt=Entidade.pk AND JOIN AtributoRef

AtributoRe f .pkEntRe f=EntidadeRe f .pk ANDON ObjetoInterno.pkAtributoRef = Atribu-

toRef.pkEntidade.atrib1=val1 AND EntidadeRe f .atribA=valA JOIN EntidadeAtribRef

EntidadeAtribRe f .atribX=valX)ON AtributoRef.pkEntRef = EntidadeAtri-

bRef.pk(Entidade × ObjetoInterno × AtributoRef WHERE Entidade.pk = pkEnt;

× EntidadeRef × EntidadeAtribRef))

(c) Inserção de InstânciapkEnt← πpk( SELECT INTO pkEnt pk

σEntidade.atribA=valA(Entidade))FROM Entidade WHERE Entidade.atrib1 =

val1;pkAtribRef← πpk( SELECT INTO pkAtribRef pkσ AtributoRe f .pkEntidadeRe f=EntidadeRe f .pk AND FROM EntidadeRef JOIN AtributoRef

AtributoRe f .pkEntRe f=EntidadeAtribRe f .pk AND ON EntidadeRef.pk = AtributoRef.pkEntRef

EntidadeRe f .atribA=valA AND JOIN EntidadeAtribRefEntidadeAtribRe f .atribX=valX (EntidadeRef ×AtributoRef

ON AtributoRef.pkEntidadeAtribRef = Enti-

dadeAtribRef.pk× EntidadeAtribRef) WHERE EntidadeRef.atribA = valA AND

EntidadeAtribRef.atribX = valX;

pkNovo← maxpk(ObjetoInterno)ObjetoInterno ← ObjetoInterno ∪ {(pkNovo,

pkEnt, pkAtribRef, subAtrib1)}

INSERT INTO ObjetoInterno(pkEnt, pkAtri-

bRef) VALUES (pkEnt, pkAtribRef, subval1);

(d) Remoção de InstânciapkEnt← πpk( SELECT INTO pkEnt pk


val1;




MR SQLpkAtribRef← πpk( SELECT INTO pkAtribRef pkσ AtributoRe f .pkEntidadeRe f=EntidadeRe f .pk AND FROM EntidadeRef JOIN AtributoRef






ObjetoInterno← ObjetoInterno -

DELETE FROM ObjetoInterno WHERE

pkEntidade = pkEnt AND pkAtributoRef =

pkAtribRef;σOb jetoInterno.pkEntidade=pkEnt AND

Ob jetoInterno.pkAtributoRe f=pkAtribRe f (ObjetoInt-

erno)

(e) Atualização de InstânciapkEnt← πpk( SELECT INTO pkEnt pk


val1;pkAtribRef← πpk( SELECT INTO pkAtribRef pkσ AtributoRe f .pkEntidadeRe f=EntidadeRe f .pk AND FROM EntidadeRef JOIN AtributoRef






ObjetoInterno← πsubatrib1←subval1( UPDATE ObjetoInternoσOb jetoInterno.pkEntidade=pkEnt AND SET subatrib1 = subval1

Ob jetoInterno.pkAtributoRe f=pkAtribRe f (ObjetoInt-

erno)

WHERE pkEntidade = pkEnt AND pkAtribu-

toRef = pkAtribRef;


Código 4.17 Stored Procedure Modelo para Obtenção de Instâncias de Atributo ObjetoInterno (Agregacao)

1 CREATE FUNCTION obterObjetoInternoAtivo(val1 TipoSQL)


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;


Código 4.18 Stored Procedure Modelo para Inserção de Instância de Atributo ObjetoInterno (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


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


14 EntidadeAtribRef.atribX = valX;

15

16 INSERT INTO ObjetoInterno(pkEntidade, pkAtributoRef, subAtrib1)

17 VALUES (pkEnt, pkAtribRef, subval1);

18 RETURN TRUE;

19 END;



Código 4.19 Stored Procedure Modelo para Remoção de Instância de Atributo ObjetoInterno (Agregação)

1 CREATE FUNCTION desativarObjetoInterno(val1 TipoSQL, valATipoSQL, valX TipoSQL)

2 RETURNS BOOLEAN AS’

3 DECLARE

4 pkEnt INTEGER;


6 BEGIN


8 SELECT INTO pkAtribRef pk FROM EntidadeRef JOIN AtributoRef

9 ON EntidadeRef.pk = AtributoRef.pkEntidadeRef

10 JOIN EntidadeAtribRef

11 ON AtributoRef.pkEntidadeAtribRef = EntidadeAtribRef.pk


13 EntidadeAtribRef.atribX = valX;

14 DELETE FROM ObjetoInterno WHERE pkEntidade = pkEnt AND

15 pkAtributoRef = pkAtribRef;

16 RETURN TRUE;

17 END;


Código 4.20 Stored Procedure Modelo para Atualização de Instância de Atributo ObjetoInterno (Agregação)

1 CREATE FUNCTION atualizarObjetoInterno(val1 TipoSQL, valATipoSQL,

2 valX TipoSQL, subAtrib1 TipoSQL) RETURNS BOOLEAN AS’

3 DECLARE

4 pkEnt INTEGER;


6 BEGIN


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;

12

13 UPDATE ObjetoInterno SET subatrib1 = subval1

14 WHERE pkEntidade = pkEnt AND pkAtributoRef = pkAtribRef;

15 RETURN TRUE;

16 END;


Os mapeamentos do MR para SQL para Entidade Fraca, Atributo Composto eAtributo Simples Multvalorado são apresentados no Apêndice B, pois a ideia aplicadaa estes mapeamentos são análogas às apresentadas nos mapeamentos discutidos nesta


seção. O próximo capítulo traz exemplos da utilização desses mapeamentos em aplicaçõesdo componente EBD.

Este capítulo apresentou os mapeamentos do MMO para o MR em termos deestruturas e operações (Seções 4.1 e 4.2), e deste para o SQL do SGBD PostgreSQL(Seção 4.3).

CAPÍTULO 5Funcionamento do Componente EBD

Este capítulo apresenta a criação (Seção 5.1) e utilização (Seção 5.2) de SIa partir do framework do qual o componente EBD faz parte. A Seção 5.3 apresentaexemplos de criação de uma pequena porção do esquema de um SI real do domínioagropecuário.

5.1 Criação de Sistema de Informação

Os componentes de SI gerados pelo framework incluem [21]: a) software deaplicação e interface com o usuário; b) esquemas e restrições de integridade de bancos dedados; e c) regras de negócio que podem ser disparadas a partir de eventos de bancos dedados ou de funções de aplicação. Em [12] são encontrados detalhes sobre o mecanismode 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çõessobre representação e apresentação de dados utilizadas, respectivamente, na geração dobanco de dados e da interface.

Cada tipo de entidade possui um conjunto de atributos e as informações de cadaum 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 dederivaçã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 OCLdo framework. As regras dinâmicas de tipo de entidade e regras de atributos são definidasneste editor e são associadas aos respectivos atributos ou tipo de entidade pelo cadastroda Figura 5.1.

Utilizando o cadastro de Tipo de Entidade e o editor de Regras é possível definiras informações de um tipo de entidade do SI, que são validadas e armazenadas noBD. 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,

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 ficadisponí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çãodos dados das entidades são disponibilizados para uso.

Quando o usuário acessa um formulário, o framework manda uma requisiçãopara o módulo de Interface (conforme a Figura 3.1) que obtém os metadados da entidadee gera, em tempo de execução, a interface para manipulação de informações. A Figura 5.3apresenta um exemplo de formulário para manipulação de instâncias do tipo de entidadepessoa física.

A interface gerada pelo framework possui duas áreas principais: uma ondeestão todas as instâncias de um tipo de entidade e outra destinada ao formulário paramanipulação destas instâncias.

Nas operações de inserção, remoção e atualização de instância, o módulo Inter-face obtém a instância da entidade que está sendo manipulada e repassa para o móduloInterface Aplicação, o qual repassa os dados para o módulo Aplicação.


Figura 5.2: Formulário para Cadastro de Atributo de Tipo de En-tidade do SI

5.2.1 Operações CRUD

Os serviços de manipulação de metadados e dados disponibilizados pelas classesMetadados e ObjetoApresentação (discutidos na Seção 3.3.4) são utilizados nos mecanis-mos de mapeamento para as operações de inserção, obtenção, atualização e remoção deinstâncias de entidade. A Figura 5.4 apresenta o modelo estático das classes envolvidasnestas operações.

A classe AplicacaoCadastro fornece as operações CRUD de manipulação deinstâncias de entidades. Ela utiliza os métodos da classe ObjetoNegocio para fazervalidações de restrições estáticas (cardinalidades mínima, máxima, unicidade e chavelógica).

Além de validar as restrições, a classe ObjetoNegocio extrai as informações dainstância de entidade (ObjetoApresentacao) de forma que estas sejam passadas para omecanismo de persistência. Por exemplo, o método tratarInsercaoComposto de Obje-

toNegocio sabe que para persistir uma instância de um atributo composto é necessáriopassar a chave lógica da entidade mais os valores simples monovalorados da instânciadeste 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 doObjeto CallableStatement do pacote externo java.sql. Ela possui alguns serviços, comoverificar se o valor da chave lógica de uma entidade existe no BD, obter o valor de atributo


Figura 5.3: Exemplo de Tela de Manipulação de Pessoa Físicagerada 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 osmecanismos para inserção, obteção, atualização e remoção de instâncias de entidades deSI.

Inserção de Instância de uma Entidade

O processamento para persistir uma instância de entidade envolve uma sériede operações, tais como controle de transação, validação dos dados na instância emapeamento dos dados para o esquema da entidade no BD. A Figura 5.5 mostra acolaboração das classes das camadas de Aplicação, Negócio e Persistência para executara inserção de uma instância de entidade.

A camada Aplicação é responsável pelo controle de transações nas operações demanipulações de instâncias de entidade. Antes de fazer o desmembramento da instânciaem partes que são repassadas para o BD, são executadas operações de validação. Asrestrições estruturais de domínio, chave, unicidade, cardinalidade mínima e máximade atributos e relacionamentos são verificadas pela classe ObjetoNegocio, enquanto asvalidações de regras dinâmicas são tratadas pela classe Regras.


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 ObjetoNego-cio. No método inserir o processo de persistência da instância é iniciado com a extraçãodos dados que serão mapeados para a tabela que armazena as instâncias da entidade. Aclasse Metadados possui o conhecimento para extrair as informações da instância da en-tidade.

Os dados são repassados para o método inserirMono da classe BDMecanismoque vai criar uma instrução para passar os dados para a stored procedure que faz a inserçãodos dados da entidade. Esta instrução é criada a partir do padrão: tipo de operação (nestecaso é inserir) concatenado com o mnemônico da entidade.

Os atributos multivalorados do tipo Basico, Enumerado, Composto e Objeto In-terno possuem tabelas para armazenar suas instâncias. O método tratarInsercaoMulti tratao mapeamento das instâncias de atributos do tipo Basico e Enumerados para suas respec-


Figura 5.5: Colaboração para mapeamento Objeto-Relacional naoperação de Inserção

tivas tabelas. O mesmo processamento é feito no método tratarInsercaoComposto paraatributos do tipo Composto e Objeto Interno. Estes métodos recebem como parâmetro o


objeto que representa o atributo multivalorado, as instâncias deste atributo e a chave lógicada entidade. Este método repassa para a classe BDMecanismo o mnemônico do atributo, achave lógica da entidade e uma instância do atributo. Este processo é repetido até que to-das as instâncias do atributo sejam passadas. O processo de criação da instrução que passaos parâmetros para a stored procedure é idêntico ao processo descrito anteriormente parainstâ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 daentidade ou busca de uma só instância. A Figura 5.6 mostra o diagrama de colaboraçãopara obtenção de instâncias de entidade.

O processamento inicia com a consulta no BD de todas as instâncias de umaentidade. A consulta retorna todos os atributos que pertecem à entidade que não são ma-peados 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 objetoMetadados da entidade estes atributos são localizados e repassados para os métodos quefazem o tratamento da obtenção. O método recebe o mnemônico do atributo e a chavelógica da entidade. Com estas informações é possível obter todas as instâncias do atributopara a instância da entidade identificada pela chave lógica. As instâncias são empacotadase retornadas.

O método obterAtivos recebe as instâncias manipuladas pelos metodos tratarOb-

tencaoComposto e tratarObtencaoMulti e os coloca na instância da entidade representadapelo ObjetoApresentacao. Este processamento é feito até que todas as instâncias da enti-dade 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 dacomparação de duas instâncias: a instância que sofreu modificações do usuário e ainstância que está armazenada no BD. A Figura 5.7 mostra a colaboração no mapeamentoObjeto-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 val-ores 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 modifi-cação, então estes dados são repassados para a stored procedure de atualização dos dadosda entidade.


Figura 5.6: Colaboração para mapeamento Objeto-Relacional naoperação de Consulta

O próximo passo é a atualização dos dados de atributos multivalorados. Paratratar a atualização destes atributos dois métodos são utilizados: tratarAtualizacaoCom-

posto, 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 modificaruma instância existente.

Os métodos tratarAtualizacaoComposto e tratarAtualizacaoMulti recebem


como parâmetro a instância sem modificação e a instância com modificação. O métododeve comparar as instâncias e verificar quais operações devem ser executadas para queas modificações feitas pelo usuário sejam aplicadas nas instâncias que estão armazenadasno BD. Por exemplo, a atualização de um atributo do tipo Basico multivalorado segue osseguintes passos:

• Para inserir utilize todos os valores que estão na instância modificada e não estãona 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 dotipo Composto pode ter implicações negativas na eficiência para atributos com muitasinstâncias. Por exemplo, em um atributo composto com três atributos que possui ceminstâ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 eatualizar) em cada uma das instâncias do composto, permitindo que o mecanismo saibaqual 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 aremoção de nós em árvores. Neste caso somente as folhas podem ser removidas. Esteprocesso é 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 oprocesso de mapeamento objeto relacional na operação de remoção.

No ínicio do processamento para remoção é obtida a instância da entidade noBD e comparada com a instância que será removida. Esta verificação é necessária paraevitar que uma instância da entidade modificada concorrentemente por um outro usuárioseja removida.

O processamento da remoção é iniciado na classe ObjetoNegocio com a buscapor atributos multivalorados. Os métodos tratarDesativacaoComposto e tratarDesativa-

caoMulti possuem a finalidade de remover todas as instâncias do atributo que é passadocomo parâmetro. O método tratarDesativacaoComposto recebe como parâmetro o objetoque 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 com-posto é extraída. Esta chave associada com a chave lógica da entidade e a chave parcialdo composto permite remover a instância do composto no BD.


Figura 5.7: Colaboração para mapeamento Objeto-Relacional naoperação de Atualização

O mesmo processamento é feito no método tratarDesativacaoMulti, os parâmet-ros que são passados para stored procedure de remoção considera a chave parcial do atri-buto, que é o próprio valor. Após remover todos os atributos multivalorados, o mecanismoremove a instância da entidade do BD.


Figura 5.8: Colaboração para mapeamento Objeto-Relacional naoperação de remoção

5.3 Exemplo: SI para o Agronegócio 100

5.3 Exemplo: SI para o Agronegócio

O sistema SIA (Sistemas Integrados de Agronegócio) foi desenvolvido dentrode um projeto de pesquisa no Instituto de Informática da UFG e provê infra-estruturade Tecnologia da Informação para otimizar a produção de gado de corte. O objetivoprincipal do SIA é o suporte às atividade inerentes a produção de gado de corte [22].Existem projetos futuros para suporte à cadeia de produção de gado de leite e controle depastagem.

O SIA é um sistema de informação bastante complexo e trabalha com grandequantidade e variedade de informações inerentes ao processo de negócio agropecuário.O modelo conceitual do SIA, descrito com o MMO, contém cerca de 200 entidadesde negócio e um repositório de regras que contém mais de 150 regras de negócioespecificadas e implementadas no SI.

O esquema de banco de dados operacional gerado a partir do framework descritona Seção 3.1, contém cerca de 590 tabelas e mais de 3200 stored procedures, incluindoaquelas usadas para manipulação de regras de negócio.

5.3.1 Exemplos de Geração de Esquema

Esta seção apresenta exemplos reais da utilização do componente EBD parageração de partes do esquema do BD do SIA.

A entidade Animal de Propriedade é uma especialização da entidade Animal que,por sua vez, é uma entidade fraca da entidade Propriedade Rural. A Figura 5.9 apresentaestes conceitos do modelo conceitual do BD do SIA.

Figura 5.9: Modelo Conceitual Simplificado - Conceito de "Ani-mal"


No SIA, existe também o conceito de "Animal de Catálogo" que é um animal deelite, não pertencente à propriedade rural, mas utilizado para definir a árvore genealógicade animais da propriedade.

Como Animal de Propriedade faz parte de uma hierarquia de especializaçãoentão, as Tabelas 4.1 e 4.14 são utilizadas para gerar a tabela de Animal de Propriedade

mostrada no Código 5.1.

Código 5.1 Tabela da Entidade Animal de Propriedade1 CREATE TABLE animalProd

2 (

3 pk integer NOT NULL,

4 datanascanimal date,

5 pkcondicaoreprodanimal integer NOT NULL,

6 pktipoidfisicomanejo integer,

7 pksituacaoanimal integer NOT NULL,

8 PRIMARY KEY (pk),

9 FOREIGN KEY (pk) REFERENCES animal (pk)


11 FOREIGN KEY (pkcondicaoreprodanimal) REFERENCES valorenumerado (pk)


13 FOREIGN KEY (pksituacaoanimal) REFERENCES valorenumerado (pk)


15 FOREIGN KEY (pktipoidfisicomanejo) REFERENCES valorenumerado (pk)

16 ON UPDATE RESTRICT ON DELETE RESTRICT

17 )

As stored procedures para obtenção, inserção, remoção e atualização de instân-cias de Animal de Propriedade são geradas a partir dos mapeamentos para hierarquia deespecialização e entidade fraca, descritos nas Tabelas 4.7, 4.10, 4.19 e B.1.

Os Códigos 5.2, 5.3, 5.4, 5.5 e 5.6 apresentam as stored procedures geradas paraas operações de obtenção de instâncias, obtenção de uma instância, inserção, remoção eatualização da entidade Animal de Propriedade.

No Código 5.1, a linha 1 indica a entidade que está sendo mapeada. A linha 3traz o campo gerado para a chave primária (surrogate key), que não tem correspondente noesquema conceitual, já que é gerada pelo componente EBD. Nas linhas 4 a 7 descrevemos atributos específicos da entidade mapeada. As linhas 5, 6 e 7 descrevem os atributosenumerados com suas respectivas restrições de chave estrangeira, nas linhas 11, 13 e 15.


Código 5.2 Stored Procedure para Obtenção de Instâncias da Entidade Animal de Pro-priedade1 CREATE OR REPLACE FUNCTION obterAnimalProdativo() RETURNS refcursor AS $$

2 DECLARE

3 csr REFCURSOR;

4 BEGIN

5 OPEN csr FOR

6 SELECT PropRur.codigoPropRur , PropRur.nomePropRur , Animal.idAnimal ,

7 Animal.nomeAnimal , enumsexoAnimal.mnemonico , AnimalProd.dataNascAnimal ,

8 enumsituacaoAnimal.mnemonico , enumcondicaoReprodAnimal.mnemonico ,

9 enumtipoMatrizAnimal.mnemonico , AnimalProd.criadorAnimal

10 FROM PropRur JOIN propRurAnimal ON PropRur.pk = propRurAnimal.pkPropRur

11 JOIN Animal ON Animal.pk = propRurAnimal.pkAnimal

12 JOIN ValorEnumerado AS enumsexoAnimal ON Animal.pksexoAnimal = enumsexoAnimal.pk

13 JOIN AnimalProd ON Animal.pk = AnimalProd.pk

14 JOIN ValorEnumerado AS enumtipoIdFisicoManejo ON AnimalProd.pktipoIdFisicoManejo =

15 enumtipoIdFisicoManejo.pk

16 JOIN ValorEnumerado AS enumsituacaoAnimal ON AnimalProd.pksituacaoAnimal =

17 enumsituacaoAnimal.pk

18 JOIN ValorEnumerado AS enumcondicaoReprodAnimal ON

19 AnimalProd.pkcondicaoReprodAnimal = enumcondicaoReprodAnimal.pk ;

20 RETURN csr;

21 END;



Código 5.3 Stored Procedure para Obtenção de Instância da Entidade Animal de Pro-priedade1 CREATE OR REPLACE FUNCTION obteranimalprodativo(codigoproprurger VARCHAR,

2 idanimalger VARCHAR) RETURNS refcursor AS $$

3 DECLARE

4 csr REFCURSOR;

5 BEGIN

6 SELECT PropRur.codigoPropRur , PropRur.nomePropRur , Animal.idAnimal ,

7 Animal.nomeAnimal , enumsexoAnimal.mnemonico , AnimalProd.dataNascAnimal ,

8 enumsituacaoAnimal.mnemonico , enumcondicaoReprodAnimal.mnemonico ,

9 enumtipoMatrizAnimal.mnemonico , AnimalProd.criadorAnimal



12 JOIN ValorEnumerado AS enumsexoAnimal ON Animal.pksexoAnimal = enumsexoAnimal.pk


14 JOIN ValorEnumerado AS enumtipoIdFisicoManejo ON AnimalProd.pktipoIdFisicoManejo =

15 enumtipoIdFisicoManejo.pk

16 JOIN ValorEnumerado AS enumsituacaoAnimal ON AnimalProd.pksituacaoAnimal =

17 enumsituacaoAnimal.pk

18 JOIN ValorEnumerado AS enumcondicaoReprodAnimal ON

19 AnimalProd.pkcondicaoReprodAnimal = enumcondicaoReprodAnimal.pk

20 WHERE PropRur.codigoPropRur = codigoPropRurGER AND Animal.idAnimal = idAnimalGER;

21 RETURN csr;

22 END;


Nos Códigos 5.2 e 5.3 as listas das cláusulas SELECT, na linha 6, estão todos osatributos da entidade AnimalProd, Animal e PropRur.

Na cláusula FROM, para cada atributo enumerado é feita uma junção comValorEnumerado, que é a tabela que contém todos os valores dos domínios enumeradosdo SI.


Código 5.4 Stored Procedure para Inserção de Instância da Entidade Animal de Pro-priedade1 CREATE OR REPLACE FUNCTION inseriranimalprod(codigoproprurger VARCHAR, idanimalger

2 VARCHAR, nomeanimalger VARCHAR, sexoanimalger VARCHAR, tipoidfisicomanejoger VARCHAR,

3 datanascanimalger date, situacaoanimalger VARCHAR, condicaoreprodanimalger VARCHAR)

4 RETURNS boolean AS $$

5 DECLARE

6 pkEnumtipoIdFisicoManejo INTEGER;

7 pkEnumsituacaoAnimal INTEGER;

8 pkEnumcondicaoReprodAnimal INTEGER;

9 pkEnumsexoAnimal INTEGER;

10 pkEnt INTEGER;

11 BEGIN

12 SELECT INTO pkEnumtipoIdFisicoManejo ValorEnumerado.pk

13 FROM DominioEnum JOIN ValorEnumerado ON DominioEnum.pk = ValorEnumerado.pkDominioEnum

14 WHERE DominioEnum.DominioEnumNome = ’EnumTipoIdFisicoAnimal’

15 AND ValorEnumerado.mnemonico = tipoIdFisicoManejoGER;

16 SELECT INTO pkEnumsituacaoAnimal ValorEnumerado.pk


18 WHERE DominioEnum.DominioEnumNome = ’EnumSituacaoAnimal’

19 AND ValorEnumerado.mnemonico = situacaoAnimalGER;

20 SELECT INTO pkEnumcondicaoReprodAnimal ValorEnumerado.pk


22 WHERE DominioEnum.DominioEnumNome = ’EnumCondicaoReprodutiva’

23 AND ValorEnumerado.mnemonico = condicaoReprodAnimalGER;

24 SELECT INTO pkEnumsexoAnimal ValorEnumerado.pk


26 WHERE DominioEnum.DominioEnumNome = ’EnumSexo’ AND

27 ValorEnumerado.mnemonico = sexoAnimalGER;

28

29 SELECT INTO pkEntRef PropRur.pk FROM PropRur WHERE

30 PropRur.codigoPropRur = codigoPropRurGER;

31

32 INSERT INTO Animal (idAnimal, nomeAnimal, pksexoAnimal) VALUES

33 (idAnimalGER , nomeAnimalGER , pkEnumsexoAnimal);


35 INSERT INTO propRurAnimal (pkAnimal , pkPropRur) VALUES (pkEnt , pkEntRef);

36

37 INSERT INTO AnimalProd (pk, dataNascAnimal, pksituacaoAnimal, pkcondicaoReprodAnimal)

38 VALUES (pkEnt , dataNascAnimalGER , pkEnumsituacaoAnimal , pkEnumcondicaoReprodAnimal);

39 RETURN TRUE;

40 END; $$ LANGUAGE ’plpgsql’;

No Código 5.4, as linhas 12, 16, 20 e 24 são instruções que obtém o valor dachave estrangeira dos atributos enumerados. A linha 29 obtém o valor da chave primária


da entidade identificadora (PropRur). A linha 32 apresenta a instrução que insere daentidade Animal, e na sequência, na linha 36, a instrução faz a ligação entre as entidadePropRur e Animal. Finalmente, os dados da entidade AnimalProd são inseridos, de acordocom a instrução da linha 37. A instância da entidade AnimalProd possui o mesmo valorde chave primária que a entidade Animal, garantida pela instrução da linha 34.

Código 5.5 Stored Procedure para Remoção de Instância da Entidade Animal de Pro-priedade1 CREATE OR REPLACE FUNCTION desativaranimalprod(codigoproprurger VARCHAR,

2 idanimalger VARCHAR) RETURNS boolean AS $$

3 DECLARE

4 pkEnt INTEGER;

5 pkEntRef INTEGER;

6 BEGIN

7 SELECT INTO pkEnt Animal.pk

8 FROM PropRur

9 JOIN propRurAnimal ON PropRur.pk = propRurAnimal.pkPropRur


11 WHERE PropRur.codigoPropRur = codigoPropRurGER AND

12 Animal.idAnimal = idAnimalGER;

13

14 SELECT INTO pkEntRef PropRur.pk

15 FROM PropRur

16 WHERE PropRur.codigoPropRur = codigoPropRurGER;

17

18 DELETE FROM AnimalProd WHERE pk = pkEnt;

19 DELETE FROM propRurAnimal WHERE pkAnimal = pkEnt AND

20 pkPropRur = pkEntRef ;

21 DELETE FROM Animal WHERE pk = pkEnt;

22

23 RETURN TRUE;

24 END;

25 $$ LANGUAGE ’plpgsql’

No Código 5.5, primeiramente obtém-se o valor das chaves das entidades fracae identificadora, respectivamente, nas linhas 7 e 14. Em seguida, a instância da entidadeAnimalProd é removida, seguindo com a instância do atributo objeto interno parte dechave propRurAnimal, e finalmente a instância da entidade Animal é removida (instruçãoda linha 21).


Código 5.6 Stored Procedure para Atualização de Instância da Entidade Animal dePropriedade1 CREATE OR REPLACE FUNCTION atualizaranimalprod(codigoproprurger1 VARCHAR, idanimalger1

2 VARCHAR, idanimalger VARCHAR, nomeanimalger VARCHAR, sexoanimalger VARCHAR,

3 tipoidfisicomanejoger VARCHAR, datanascanimalger date, situacaoanimalger VARCHAR,

4 condicaoreprodanimalger VARCHAR) RETURNS boolean AS $$

5 DECLARE

6 pkEnumtipoIdFisicoManejo INTEGER;

7 pkEnumsituacaoAnimal INTEGER;

8 pkEnumcondicaoReprodAnimal INTEGER;

9 pkEnumsexoAnimal INTEGER;

10 pkEnt INTEGER;

11 BEGIN

12 SELECT INTO pkEnumtipoIdFisicoManejo ValorEnumerado.pk


14 WHERE DominioEnum.DominioEnumNome = ’EnumTipoIdFisicoAnimal’

15 AND ValorEnumerado.mnemonico = tipoIdFisicoManejoGER;

16

17 SELECT INTO pkEnumsituacaoAnimal ValorEnumerado.pk


19 WHERE DominioEnum.DominioEnumNome = ’EnumSituacaoAnimal’

20 AND ValorEnumerado.mnemonico = situacaoAnimalGER;

21

22 SELECT INTO pkEnumcondicaoReprodAnimal ValorEnumerado.pk


24 WHERE DominioEnum.DominioEnumNome = ’EnumCondicaoReprodutiva’

25 AND ValorEnumerado.mnemonico = condicaoReprodAnimalGER;

26

27 SELECT INTO pkEnumsexoAnimal ValorEnumerado.pk


29 WHERE DominioEnum.DominioEnumNome = ’EnumSexo’ AND

30 ValorEnumerado.mnemonico = sexoAnimalGER;

31

32 SELECT INTO pkEnt Animal.pk



35 WHERE PropRur.codigoPropRur = codigoPropRurGER1 AND Animal.idAnimal = idAnimalGER1;

36

37 UPDATE Animal SET idAnimal = idAnimalGER , nomeAnimal = nomeAnimalGER ,

38 pksexoAnimal = pkEnumsexoAnimal WHERE pk = pkEnt;

39 UPDATE AnimalProd SET pktipoIdFisicoManejo = pkEnumtipoIdFisicoManejo ,

40 dataNascAnimal = dataNascAnimalGER , pksituacaoAnimal = pkEnumsituacaoAnimal ,

41 pkcondicaoReprodAnimal = pkEnumcondicaoReprodAnimal WHERE pk = pkEnt;

42

43 RETURN TRUE;

44 END;



No Código 5.6, da mesma forma que no Código 5.4, o processamento inicia comas instruções, nas linhas 12, 17, 22 e 27, de obtenção de chave estrangeira dos atributosenumerados das entidades que fazem parte da hierarquia de especialização. Em seguida,a chave primária da entidade AnimalProd é obtida, na instrução apresentada na linha 32.

Finalmente, os valores dos atributos das respectivas entidade da hierarquia sãoatualizados pelas instruções das linhas 37 e 39.

A Figura 5.10 apresenta um exemplo de relacionamento entre uma entidade(Animal de Propriedade) e uma agregação (Cor de Pelo de Raça). No esquema definidocom o MMO, o atributo objeto interno Cor de Pelo Animal pertence à entidade Animal de

Propriedade.Para geração da tabela de um atributo objeto interno são utilizados os mapea-

mentos das Tabelas 4.3 e 4.15. A tabela resultante destes mapeamentos é apresentada noCódigo 5.7.

As stored procedures para obtenção inserção, remoção e atualização de instân-cias de Cor de Pelo de Animal são geradas a partir dos mapeamentos das Tabelas 4.9 e4.21. Os Códigos 5.8, 5.9 e 5.10, apresentam as stored procedures para as operações deobtenção, inserção e remoção de instâncias de Cor de Pelo de Animal.

No Código 5.1, a linha 1 indica o relacionamento que está sendo mapeado.A linha 3 e 4 traz os campos que são chaves estrangeiras para a entidade a qual orelacionamento pertence (AnimalProd) e para o atributo de referência (corPeloRaca). Aslinhas 7 e 9 apresentam as restrições de chave estrangeiras para os campos das linhas 3 e4, respectivamente.

Figura 5.10: Modelo Conceitual Simplificado - Conceito de "Corde Pelo de Animal"


Código 5.7 Tabela do Atributo Objeto Interno Cor de Pelo Animal1 CREATE TABLE corDePeloAnimal(

2 pk serial NOT NULL,

3 pkanimalProd INTEGER NOT NULL,

4 pkcorPeloRaca INTEGER NOT NULL,

5

6 PRIMARY KEY (pk),

7 FOREIGN KEY (pkanimalprod) REFERENCES animalprod (pk)


9 FOREIGN KEY (pkcorPeloRaca ) REFERENCES corPeloRaca (pk)


11 UNIQUE (pkanimalprod, pkcorPeloRaca)

12 )

No Código 5.8, a linha 7 apresenta a instrução para obtenção da chave primáriada entidade AnimalProd a partir da chave lógica. Na linha 14, a operação de seleçãoretorna todos valores do relacionamento corPeloDeAnimal.


Código 5.8 Stored Procedure para Obtenção de Instâncias do Atributo Objeto Interno Corde Pelo Animal1 CREATE OR REPLACE FUNCTION obtercordepeloanimalativo(codigoproprurger VARCHAR,

2 idanimalger VARCHAR) RETURNS refcursor AS $$

3 DECLARE

4 csr REFCURSOR;

5 pkEnt INTEGER;

6 BEGIN

7 SELECT INTO pkEnt AnimalProd.pk

8 FROM PropRur





13

14 OPEN csr FOR

15 SELECT enumnomeRaca.mnemonico , enumnomeCorPelo.mnemonico

16 FROM Raca

17 JOIN ValorEnumerado AS enumnomeRaca ON Raca.pknomeRaca = enumnomeRaca.pk

18 JOIN corDePeloAnimal ON Raca.pk = corDePeloAnimal.pkRaca

19 JOIN AnimalProd ON AnimalProd.pk = corDePeloAnimal.pkAnimalProd

20 JOIN (CorPeloAnimal JOIN ValorEnumerado AS enumnomeCorPelo

21 ON CorPeloAnimal.pknomeCorPelo = enumnomeCorPelo.pk )

22 ON CorPeloAnimal.pk = corDePeloAnimal.pkCorPeloAnimal

23 WHERE corDePeloAnimal.pkAnimalProd = pkEnt;

24

25 RETURN csr;

26 END;


No Código 5.9, a instruções das linhas 8 e 13 obtém o valor das chaves es-trangeiras para entidade AnimalProd e para o atributo objeto interno corPeloRaca. NoCódigo 5.10, as instruções para obtenção de chave estrangeira são as mesmas instruçõesencontradas no Código da stored procedure de inserção.


Código 5.9 Stored Procedure para Inserção de Instância do Atributo Objeto Interno Corde Pelo Animal1 CREATE OR REPLACE FUNCTION inserircordepeloanimal(codigoproprurger VARCHAR,

2 idanimalger VARCHAR, nomeracager VARCHAR, nomecorpeloger VARCHAR)


4 DECLARE

5 pkEnt INTEGER;


7 BEGIN

8 SELECT INTO pkEnt AnimalProd.pk FROM PropRur





13 SELECT INTO pkAtribRef corPeloRaca.pk FROM CorPeloAnimal

14 JOIN ValorEnumerado AS enumnomeCorPelo ON

15 CorPeloAnimal.pknomeCorPelo = enumnomeCorPelo.pk

16 JOIN corPeloRaca ON CorPeloAnimal.pk = corPeloRaca.pkCorPeloAnimal

17 JOIN Raca ON Raca.pk = corPeloRaca.pkRaca

18 WHERE enumnomeRaca.mnemonico = nomeRacaGER AND

19 enumnomeCorPelo.mnemonico = nomeCorPeloGER;

20 INSERT INTO corDePeloAnimal (pkAnimalProd, pkcorPeloRaca) VALUES

21 (pkEnt , pkAtribRef);

22 RETURN TRUE;

23 END;



Código 5.10 Stored Procedure para Remoção de Instância do Atributo Objeto Interno Corde Pelo Animal1 CREATE OR REPLACE FUNCTION desativarcordepeloanimal(codigoproprurger VARCHAR,

2 idanimalger VARCHAR, nomeracager VARCHAR, nomecorpeloger VARCHAR)


4 DECLARE

5 pkEnt INTEGER;

6 pkComp INTEGER;

7 BEGIN

8 SELECT INTO pkEnt AnimalProd.pk FROM PropRur





13 SELECT INTO pkAtribRef corPeloRaca.pk FROM CorPeloAnimal

14 JOIN ValorEnumerado AS enumnomeCorPelo ON

15 CorPeloAnimal.pknomeCorPelo = enumnomeCorPelo.pk

16 JOIN corPeloRaca ON CorPeloAnimal.pk = corPeloRaca.pkCorPeloAnimal

17 JOIN Raca ON Raca.pk = corPeloRaca.pkRaca

18 WHERE enumnomeRaca.mnemonico = nomeRacaGER AND

19 enumnomeCorPelo.mnemonico = nomeCorPeloGER;

20 DELETE FROM corDePeloAnimal WHERE pkAnimalProd = pkEnt And

21 pkcorPeloRaca = pkAtribRef;

22 RETURN TRUE;

23 END;

24 $$ LANGUAGE ’plpgsql’

Este capítulo apresentou a criação (Seção 5.1) e utilização (Seção 5.2) de SIa partir do framework do qual o componente EBD faz parte. A Seção 5.3 apresentouexemplos de criação de uma pequena porção do esquema de um SI real do domínioagropecuário.

CAPÍTULO 6Aplicações de Mapeamentos na Evolução deEsquemas

Este capítulo discute as operações permitidas na evolução de esquemas de BDde SI (Seção 6.1). A Seção 6.2 introduz o mecanismo de evolução de esquemas de BDno contexto do framework de construção e gerência de SI. A Seção 6.3 apresenta como éfeita a evolução de um SI utilizando o framework. A Seção 6.4 discute exemplos reais deevolução de um SI agropecuário.

6.1 Tipos de mudanças permitidas no esquema MMO

A evolução de SI é feita com o apoio do componente EBD em quatro passos.Primeiro, a mudança é feita no esquema conceitual (MMO), depois a mudança é mapeadado MMO para o MR, e deste para o SQL. Antes de efetuar a mudança, a consistência dosdados é garantida para o novo esquema [23, 24]. Os mapeamentos envolvidos na evoluçãode esquemas são os mesmos discutidos no Capítulo 4.

Esta seção analisa os tipos de mudanças aceitas no MMO e a sua propagação paraos dados do SI. A Seção 6.1.1 analisa as mudanças de tipo e domínio de atributo. A Seção6.1.2 avalia as mudanças permitidas na chave lógica de entidade. A Seção 6.1.3 abordamudanças em mnemônico da entidade, atributo armazenado, composição de atributo,restrições de cardinalidade mínima e máxima, unicidade e tamanho.

6.1.1 Mudanças de Tipo e Domínio de Atributo

A Figura 6.1 mostra uma máquina de estados onde cada estado é umtipo/domínio de atributo no MMO e as transições definem as operações permitidas parapassar de um estado para outro.

O SGBD PostgreSQL oferece suporte às transformações 1, 3, 4, 6 e 8, mas nãopermite as transformações 2, 5 e 7. Por exemplo, um atributo de uma tabela pode ser

6.1 Tipos de mudanças permitidas no esquema MMO 113

convertido de Integer para Varchar, mas o contrário não é permitido, pois podem existirvalores deste atributo que não são passíveis de serem convertidos para Integer.

No entanto, um procedimento pode ser criado para verificar as instâncias do atri-buto que está sendo modificado e, se todas as instâncias forem passíveis de modificação,então a operação pode ser efetuada [14, 23, 24]. No exemplo dado, basta usar o conversorde Varchar para Integer. O mesmo algoritmo pode ser usado para permitir as transições 5e 7.

Figura 6.1: Mudanças Possíveis em Tipo/Domínio de um Atributo

Um atributo com o tipo/domínio Enumerado Alfanumérico pode ser mapeadopara um atributo do tipo Básico Alfanumérico. As seguintes operações são necessáriaspara propagar a mudança 9:

1. Criar um atributo do domínio alfanumérico na relação.2. Para cada valor do atributo que representa o atributo enumerado, obter o valor na

relação ValorEnumerado e atribuir este valor ao atributo que foi criado no passoanterior.

3. Remover o atributo que representa o atributo enumerado da relação.

Na operação inversa (mudança 10) a propagação da modificação segue asseguintes operações:

1. Todos os valores do atributo alfanumérico são testados, contra os valores da relaçãoValorEnumerado, para verificar se pertencem ao domínio escolhido. O teste ficarestrito aos valores deste domínio.

2. Caso seja verdadeiro, um atributo com o domínio inteiro é criado. Este atributoé uma chave estrangeira para a relação ValorEnumerado, da mesma forma que oatributo pkDom na Figura 4.1.

3. Para cada valor do atributo alfanumérico é obtido o valor do atributo pk na relaçãoValorEnumerado e atribuído ao atributo criado no passo anterior.

4. O atributo alfanumérico é removido da relação.


6.1.2 Mudanças na chave lógica e no tipo de entidade

A chave lógica de um Tipo de Entidade pode sofrer as seguintes modificações:adição de um novo atributo (que não existe na entidade), adição de um atributo que jáexiste na entidade e remoção de um atributo.

A adição de um atributo que não existe na entidade à chave lógica pode ser feitacom os seguintes passos: (i) criar o novo atributo na entidade; (ii) mapear a entidade parao BD; (iii) popular o novo atributo; e adicioná-lo à chave lógica da entidade.

No caso da modificação da chave na qual é adicionado um atributo que jápertence à entidade, somente a adição do atributo na chave é executada, seguida domapeamento para o BD. Tais modificações de ampliação do conjunto de atributos chavesão necessárias apenas nos casos em que a entidade do mundo real modifica a sua formade identificação. Por exemplo, a entidade funcionário poderia ter o campo matrícula comochave. Com a criação de filiais para empresa em que o funcionário trabalha, a matrículapoderia não mais ser única na empresa, e sim em cada filial. Neste caso a nova chave daentidade funcionário deveria ser composta de matrícula e filial.

Para remover um atributo da chave são definidas as seguintes operações: verificarse a chave lógica possui mais de um atributo; verificar se o conjunto de atributos quecompõem a chave, menos o atributo que será retirado, satifaz a restrição de unicidadeentre as instâncias da entidade no BD. Se sim, o atributo é retirado da chave da entidadee é feito o mapeamento para o BD; caso contrário a operação não é executada.

As operações definidas anteriormente para adição e remoção de atributo emchave lógica de entidade podem ser aplicadas da mesma forma para o tipo de entidadefraca, só que neste caso são considerados os atributos que formam a chave parcial daentidade.

No caso de entidades que estão envolvidas em uma especialização, os procedi-mentos descritos anteriormente são aplicados somente às superentidades, pois são estasque contêm as chaves lógicas, que são herdadas pelas subentidades.

Outras modificações que podem ocorrer em uma instância de Tipo de Entidadeestá relacionada ao seu tipo ("Forte", Fraca e Especializada). A Figura 6.2 mostra aspossíveis transformações entre esses tipos.

No MMO uma entidade fraca está associada a uma entidade identificadora,representada pelo atributo objeto interno que faz parte da chave da entidade fraca. Paraexecutar a transformação 1 são exigidos os seguintes passos:

1. Criar um atributo do tipo objeto interno e defini-lo como parte da chave da entidade.A entidade de referência do atributo objeto interno é a entidade identificadora.


Figura 6.2: Mudanças possíveis no tipo de entidade

2. Criar, através do mecanismo de geração do componente EBD, a relação do atributoobjeto interno definido no passo anterior. A criação da relação é feita utilizando omapeamento descrito na Seção 4.1.2.

3. Ligar as instâncias da entidade identificadora com as instâncias da entidade que estásendo modificada.

A transformação 2 (conversão de entidade fraca em entidade forte) é processadacomo segue: verificar se as instâncias dos atributos que formam a chave parcial daentidade fraca são únicas entre si; caso positivo, remover do objeto interno a restrição"é parte da chave". Caso contrário, é necessário modificar os valores da chave parcialde modo que eles sejam únicos entre si. O framework disponibiliza uma aplicação paramodificação dos dados da entidade, conforme discute a Seção 6.2.

O conjunto de operações para executar a operação 3 (conversão de entidade forteem entidade especializada) segue os seguintes passos:

1. Escolher a instância de tipo de entidade que será modificada, e a superentidade paraesta instância.

2. Criar um atributo inteiro, na relação da subentidade, com a restrição de chaveestrangeira para a relação da superentidade (conforme a Figura 4.2); e ligar asinstâncias da superentidade com as instâncias já existentes da subentidade que estásendo modificada.

A operação 4 (conversão de entidade especializada em entidade forte) da Figura6.2 pode ser executada da seguinte forma:

1. replicar na subentidade todos os atributos da superentidade;2. copiar todos os valores correspondentes para os atributos criados no primeiro passo;3. criar as restrições de integridade (chave primária, chave estrangeira e unicidade);4. remover a chave estrangeira que liga a subentidade com a superentidade;5. remover todas as instâncias da superentidade correspondente as instâncias da antiga

subentidade.


Por exemplo, a aplicação da operação 4 nas entidades pessoa física(nome, cpf,

endereço) e funcionário(salário), sendo que funcionário é uma especialização de pessoa

física, é executada da seguinte forma: primeiramente, são criados na entidade funcionário

os atributos nome, cpf e endereço. Em seguida, são copiados todos os respectivos valoresdos atributos da entidade pessoa física (nome, cpf e endereço) para os novos atributos,criados anteriormente. São definidas na entidade funcionário as restrições de chaveprimária para o atributo pk e a restrição de unicidade para o atributo cpf. Finalmentesão removidas a restrição de chave estrangeira da entidade funcionário para a entidadepessoa física e todas as instâncias de pessoa física que são instâncias de funcionários.

6.1.3 Mudanças em outras meta-informações

A mudança de mnemônico, tanto de entidade quanto de atributo, é mapeadadiretamente para mudança do nome da relação ou atributo. Primeiramente, verifica-seo novo mnemônico satisfaz a restrição de unicidade (mnemônico de tipo de entidade eatributo deve ser único no SI).

Um atributo pode pertencer a uma entidade ou a outro atributo. No processo deevolução do BD pode ser necessária mudança na qual um atributo que pertença a umaentidade passe a pertencer a um atributo composto ou vice-versa. Neste tipo de mudançadeve ser considerada a cardinalidade máxima do atributo composto.

A mudança que envolve composto monovalorado não tem impacto no nível deinstância no BD pois os atributos de um atributo composto monovalorado são colocadosna relação da entidade à qual eles pertencem.

Por exemplo, a entidade pessoa física possui o atributo composto monovalorado,dados pessoais com os atributos nome, sobrenome, e o atributo alfanumérico apelido.Neste caso, a relação que representa a entidade possui os atributos: nome, sobrenome eapelido. Tornando o atributo apelido componente do composto dados pessoais o mapea-mento para o SQL continua o mesmo, pois todos os atributos do composto monovaloradosão mapeados para a relação da entidade.

Já a mudança de um atributo pertencente a uma entidade para um atributocomposto multivalorado envolve as seguintes operações:

1. Cada atributo conhece o atributo ao qual ele pertence: se o valor do atributocompositor for vazio então o atributo pertence a entidade. Então, o atributo emquestão é modificado para pertencer ao atributo composto.

2. Verificar se o atributo não pertence a chave da entidade.3. No mapeamento para SQL, criar com ALTER TABLE um atributo com mesmo

mnemônico e mesmo tipo do atributo da entidade na tabela do atributo composto.


4. Copiar todos os valores do atributo da entidade para o novo atributo no composto.Neste caso deve se respeitar a ligação das instâncias da entidade e do composto.

Por exemplo, uma entidade Empresa possui os atributos: ddd de origem da

empresa e telefone, que é composto pelos atributos tipo e número. Não é possívelarmazenar telefone de empresas que possuem filiais em outros estados onde o ddd édiferente. Neste caso o atributo ddd deve ser componente do atributo telefone.

A operação de mudança no sentido de um atributo composto multivalorado parauma entidade não foi definida, pois o resultado desta operação seria uma tabela comapenas um atributo e valores que fazem sentido somente no composto em questão. Porexemplo, o atributo multivalorado telefone é composto pelos atributos ddd e número, osvalores do atributo ddd não faz sentido fora do composto telefone.

No MMO é possível definir se um atributo é armazenado ou não. Quando umatributo não é armazenado (derivado) então é associada a ele uma regra de derivação quecalcula o valor deste atributo. Por exemplo, o atributo idade de uma pessoa física é umatributo derivado. Um atributo pode ser modificado de armazenado para derivado e vice-versa. Para passar um atributo armazenado para derivado são necessárias as seguintesoperações:

1. É Armazenado é um atributo booleano do metadado Atributo. Nesta transformaçãoo atributo É Armazenado recebe o valor false.

2. Verificar se o atributo não faz parte de chave:

(a) No SQL é feito um ALTER TABLE para remover o atributo da tabela.(b) Criar uma regra de derivação para o atributo utilizando o mecanismo do

Componente Regra [12].

Na operação para conversão de atributo derivado para atributo armazenado osseguintes passos devem ser seguidos:

1. O atributo É Armazenado do Atributo que está sendo modificado recebe o valortrue.

2. No mapeamento para SQL é feito um ALTER TABLE para criar o atributo na tabelaque representa a entidade (ou atributo composto ou objeto interno)

3. Se cardinalidade mínima maior que 1 (se a cardinalidade mínima for 0 o atributopode receber valores nulos então não é necessário fazer nada)

(a) Popular atributo(b) Definir restrição de não nulidade

O novo atributo é populado utilizando a Aplicação de Evolução de Esquemaapresentada na Seção 6.2.


Em relação à cardinalidade mínima de um atributo, duas operações demanutenção podem ser aplicadas: Uma quando há mudança da cardinalidade mínima dezero para maior ou igual a um, e outra quando se tem a cardinalidade mínima maior queum e é necessária a mudança para cardinalidade mínima zero.

A mudança da cardinalidade mínima de um atributo de zero para maior ou iguala um poder ser feita como segue:

1. A cardinalidade do atributo é atualizada de zero para um valor maior igual a 1.2. Se o atributo for do tipo BASICO ou ENUMERADO então verificar se existe valor

no atributo.

(a) Sim. Com ALTER TABLE criar restrição não nula na coluna.(b) Não. Preencher todos os valores nulos do atributo e, através da instrução

ALTER TABLE, criar a restrição de não nulidade.

3. Se o atributo for do tipo COMPOSTO ou OBJETO INTERNO verificar se cadainstância da entidade possui um valor para o atributo em questão.

(a) Sim. Não faz nada.(b) Não. Criar uma instância para o atributo em questão para cada instância da

entidade que não possui valor deste atributo.

A mudança da cardinalidade mínima de maior que zero para zero pode serexecutada como segue:

1. A cardinalidade mínima do atributo é atualizada para zero.2. Se atributo for do tipo BASICO ou ENUMERADO, então remover com ALTER

TABLE a restrição não nula do atributo na tabela que o contém.

A partir da cardinalidade máxima é possível transformar um atributo monoval-orado em multivalorado ou vice-versa. Basta mudar a cardinalidade máxima de um paraum valor maior que um, no primeiro caso, ou mudar o valor maior que um para um, nosegundo caso. A mudança de cardinalidade máxima de um atributo de um para maior queum pode ser feita usando as seguintes operações:

1. A cardinalidade máxima do atributo é atualizada para um valor maior que 1.2. Se o atributo for do tipo BASICO ou ENUMERADO:

(a) Criar uma relação para o atributo, de acordo com o mapeamento descrito naSeção 4.1.4.

(b) Copiar os valores do atributo para a nova tabela e associar a instância doatributo com a instância da entidade.

(c) Com ALTER TABLE remover o atributo da tabela que o contém.


O processo inverso em relação a cardinalidade máxima pode ser feito da seguintemaneira:

1. A cardinalidade máxima do atributo é atualizada para 1.2. Se o atributo for do tipo BASICO ou ENUMERADO:3. Com ALTER TABLE criar um atributo na tabela da entidade à qual ele pertence

(a) Escolher um dos valores que será repassado para o atributo recém criado ecopiar este valor;

(b) Com DROP TABLE remover a tabela que contém os valores do atributomodificado.

No MMO, o atributo "Único"do metadado Atributo tem a mesma semânticada claúsula UNIQUE de SQL, que é definir como uma restrição de integridade queas instâncias do atributo devem ser únicas na relação. Ele é definido com um valorbooleano, onde true indica que o atributo é único, e false o contrário. Para um atributo sercontemplado com esta restrição são necessárias as seguintes operações:

1. O atributo É Único é definido com o valor true.2. Se o atributo for do tipo BASICO ou ENUMERADO

(a) Verificar se todas as instâncias do atributo na tabela à qual ele pertence sãoúnicas entre si:

i. Sim. Com ALTER TABLE, criar a restrição única para o atributo;ii. Não. Não executa a operação.

O processo inverso é feito removendo a restrição de unicidade.Para um atributo com o tipo BASICO e domínio ALFANUMERICO pode ser

necessária a restrição do tamanho do texto que será armazenado. A manutenção dotamanho pode ser feita como segue:

1. Na instância do metadado Atributo (que será modificado), o atributo Tamanho éatualizado

2. Se o atributo for do tipo BASICO e tipo de domínio ALFANUMERICO:

(a) Verificar se o tamanho atual é menor que o novo tamanho;

i. Com ALTER TABLE, atualizar o valor do tamanho na coluna que repre-senta o atributo na tabela.

(b) Se o tamanho atual for maior que o novo tamanho:

i. Verificar se todos os valores do atributo possuem tamanho menor ou igualao novo tamanho:

A. Sim. Com ALTER TABLE, atualizar o valor do tamanho na colunaque representa o atributo;

B. Não. Não faz nada.

6.2 Mecanismo para Evolução de Esquema de BD 120

6.2 Mecanismo para Evolução de Esquema de BD

A evolução do esquema conceitual de entidades do MMO é feita através docadastro de tipo de entidade. Primeiramente a instância da entidade é modificada atravésdo formulário de cadastro (Figura 5.1), depois é feita uma avaliação das mudanças,comparando as duas versões do esquema da entidade (antes e depois da modificação)e, em seguida, a estrutura do BD é adaptada (se necessário).

As modificações na instância de tipo de entidade são feitas através do mecanismodescrito na Seção 5.2.1, mas a atualização é feita através de uma classe específica paraevolução de tipo de entidade (classe AplicacaoEvolucao), apresentada na Figura 6.3. Aclasse AplicacaoEvolucao é uma subclasse da classe AplicacaoCadastro.

Figura 6.3: Colaboração no Mecanismo de Verificação e Adap-tação para Evolução de Esquema

A classe AplicacaoEvolucao compara as duas instâncias do tipo de entidade,a modificada e a instância antes da modificação, verificando quais características dainstância de tipo de entidade foram modificadas.

Para cada característica modificada é feita uma avaliação se a mudança pode ounão ser aplicada no esquema operacional sem impacto. Por exemplo, é preciso verificar

6.2 Mecanismo para Evolução de Esquema de BD 121

se o novo tamanho de um atributo básico alfanumérico se aplica a todas as instânciasarmazenadas. Para algumas modificações são necessárias adaptações no esquema opera-cional do BD. Por exemplo, a inclusão de um atributo na chave lógica de uma entidadeexige a criação do atributo na tabela que representa a entidade no BD.

Para aqueles características da entidade que foram modificadas e que não podemser aplicadas no BD devido aos dados da entidade não serem compatíveis com a modifi-cação, uma aplicação em forma de planilha para modificação das instâncias da entidadeé oferecida, em tempo de modificação. A Figura 6.4 apresenta a interface gráfica destaaplicação.

Cada linha da planilha contém uma instância da entidade modificada. A área dasinstâncias é divida em outras duas: área dos atributos de ligação da entidade (atributosque identificam cada instância) e área dos atributos modificados. Os atributos da primeiraárea são obtidos dos metadados antes da modificação. Já os atributos da segunda área sãotodos aqueles que foram modificados e necessitam de ajuste das instâncias para permitira propagação.

A interface possui também uma área para atualização múltipla dos valores dosatributos. Esta possui os campos linha inicial, linha final, coluna e valor. A modificaçãoé feita escolhendo o intervalo das instâncias que serão modificadas, coluna (atributo) e ovalor que será aplicado às instâncias.

Figura 6.4: Interface para Modificação das Instâncias da Entidade

Após a modificação de todas as instâncias é feita uma nova avaliação, se aavaliação for positiva, a modificação no esquema operacional é aplicada.

6.3 Evolução do Sistema de Informação 122

6.3 Evolução do Sistema de Informação

Quando o contexto do negócio muda, é necessário evoluir o modelo conceitualdo SI para que este se adapte aos novos conceitos do negócio.

No framework, a evolução do SI é feita no formulário de cadastro de Tipo deEntidade (Figura 5.1), também utilizado para geração do SI. O processo de manipulaçãode metadados é o mesmo processo utilizado para os dados, como foi definido na Seção5.2.

O processo de evolução das Regras de Negócio do SI do framework é feito nomódulo Regra. Ele recebe a regra modificada (em OCL) e faz todas as validações emrelação a sintaxe. Depois é feita a validação em relação ao impacto da nova regra no BD,ou seja, se os dados armazenados não violam a regra modificada, e finalmente a regra éimplantada [13].

Como já foi dito, o módulo de Persistência possui um componente específicopara tratar essa evolução: Serviço de Evolução de Esquema.

A seguinte sequência de atividades deve ser executada no processo de evoluçãode BD no framework:

1. O módulo de Persistência recebe uma versão modificada dos metadados de um tipode entidade e faz uma cópia da versão não modificada. Esta cópia é armazenadacomo metadados, no próprio banco de dados do SI, semelhante ao mecanismo deshadow page utilizados em Sistemas de BD [55].

2. O Serviço de Evolução de BD analisa a consistência da nova versão. Este processoverifica todas as modificações, comparando as duas versões do esquema: a versãooriginal e a versão modificada.

3. Modificações no modelo conceitual levam a um conjunto de operações de evoluçãoque devem ser propagadas para o modelo operacional (incluindo tanto o código emSQL-DDL quanto o código das stored procedures).

4. Depois de verificar a consistência da nova versão, o processador gera o conjuntode operações de evolução de esquema pertinente. Estas operações são aplicadasno esquema operacional, modificando as instruções SQL-DDL e os procedimentosarmazenados, além de todas as instâncias do tipo de entidade armazenadas no bancode dados.

Após estas modificações no tipo de entidade, todo o esquema de BD estápronto para ser usado para manipular as instâncias do tipo de entidade. Desta forma,componentes que dependem dos serviços do módulo de Persistência (neste caso omódulo de Negócio) não sofrem impacto quando modificações no modelo conceitual sãoaplicadas.

6.4 Exemplos de Evolução de Esquema 123

6.4 Exemplos de Evolução de Esquema

Esta seção apresenta dois exemplos de evolução do esquema obtidos do projetoSIA [22]. O primeiro apresenta a transformação da entidade Animal para entidade Fraca;o outro exemplo apresenta a mudança da chave lógica da entidade Pessoa Física.

O SIA inicialmente gerenciava uma única propriedade rural, contemplandoinformações sobre animais, manejos e estoques de produtos, por exemplo.

Este fato limitava a aplicação do SIA em relação à necessidade de proprietáriosque possuem duas ou mais propriedades. Para adaptar o SIA a esta necessidade foinecessário modificar algumas entidades, tornando-as dependentes da propriedade rural.Por exemplo, a entidade Animal foi transformada em entidade fraca da entidade Pro-

priedade Rural. No EBD, esta tranformação foi feita de acordo com as seguintes opera-ções:

1. Através do cadastro de Tipo de Entidade, na instância de metadado Animal foicriado um atributo objeto interno que faz parte da chave da entidade (atributopropRurAnimal)

2. A propagação desta mudança foi executada através das atividades:

(a) Avaliação da mudança: neste caso a mudança não tem impacto pois nãomodifica as instâncias armazenadas.

(b) Adaptação do Esquema: através do mecanismo de mapeamento (Tabelas 4.3 e4.15) a tabela que liga as instâncias de Animal e Propriedade Rural foi criada.

(c) Populando o novo atributo: a ligação das instâncias de Animal e Propriedade

Rural foi feita através da aplicação da Figura 6.5

Na Figura 6.5, cada linha representa uma instância da entidade Animal. Asduas primeiras colunas são os valores dos atributos de ligação, Identificador e Nome,respectivamente. A terceira coluna é o atributo objeto interno Propriedade Rural que faza ligação entre as instâncias de Animal e Propriedade Rural.

Outra evolução feita no esquema do SIA envolveu a definição de Pessoa Física.Inicialmente a identificação da pessoa física, no SIA, era feita a partir do número doCPF. Porém, existiam casos de pessoas que não possuiam este documento. Para permitir aflexibilidade da identificação, o esquema da entidade Pessoa Física foi modificado usandoas seguintes operações:

1. Através do cadastro de Tipo de Entidade, na instância de metadado Pessoa Física,foram criados dois atributos: um enumerado para o domínio tipo de documento(CPF, Carteira de Indentidade, CREA, CRMV) e outro básico alfanumérico para ovalor do documento.

2. A propagação desta mudança foi executada através das atividades:


Figura 6.5: Ligação das instâncias de Animal com PropriedadeRural

(a) Avaliação da mudança: neste caso a mudança não tem impacto pois nãomodifica as instâncias armazenadas.

(b) Adaptação do Esquema: os dois atributos foram mapeados para a tabela daentidade Pessoa Física.

(c) Adaptação das Instâncias: as instâncias de Pessoa Física foram atualizadas apartir da inteface da Figura 6.6

(d) Para finalizar a coluna CPF foi removida da tabela e foi aplicada às duascolunas criadas a restrição UNIQUE.

Na Figura, as duas primeiras colunas são os atributos de ligação da entidadePessoa Física (Nome e CPF). As outras duas colunas são referentes aos dois novosatributos (Tipo Identificador e Valor Identificador)

Este capítulo discutiu as operações permitidas na evolução de esquemas de BDde SI (Seção 6.1). A Seção 6.2 introduziu o mecanismo de evolução de esquemas de BDno contexto do framework de construção e gerência de SI. A Seção 6.3 apresentou comoé feita a evolução de um SI utilizando o framework. A Seção 6.4 discutiu exemplos reaisde evolução de um SI agropecuário.


Figura 6.6: Modificação da Chave das Instâncias da Entidade Pes-soa Física

CAPÍTULO 7Experimentação do Componente EBD

Este capítulo apresenta o procedimento utilizado para avaliar aspectos de fun-cionalidade e usabilidade da ferramenta EBD. De acordo com a Norma ISO 9126 [37],estas são duas características de qualidade que devem estar presentes em um produto desoftware. O protocolo completo utilizado na condução do experimento aqui descrito estácontido no Apêndice A.

7.1 Metodologia

A Funcionalidade é a capacidade do produto de software de prover funções queatendam às necessidades explícitas e implícitas, quando o software estiver sendo utilizadosob condições especificadas. A norma ISO 9126 indica as subcaracterísticas que deveriamser avaliadas para assegurar que a funcionalidade é apropriada, dentre as quais o protocolode experimentação definido contempla:

• Adequação: Capacidade do produto de software de prover um conjunto apropriadode funções para tarefas e objetivos do usuário especificados;• Acurácia: Capacidade do produto de software de prover, com grau de precisão

necessário, resultados ou efeitos corretos ou conforme acordado;• Conformidade: Capacidade do produto de software de estar de acordo com nor-

mas, convenções ou regulamentações previstas em leis e prescrições similares rela-cionadas à funcionalidade.

Já a Usabilidade é definida como a capacidade do produto de software de sercompreendido, aprendido, operado e atraente ao usuário, quando usado sob condições es-pecificadas [37]. No procedimento de experimentação definido são avaliadas as seguintessubcaracterísticas de usabilidade do componente EBD:

• Inteligibilidade: Capacidade do produto de software de possibilitar ao usuáriocompreender se o software é apropriado e como ele pode ser usado para tarefase condições de uso específico;

7.2 Coleta de Dados 127

• Apreensibilidade: Capacidade do produto de software de possibilitar ao usuárioaprender sua aplicação;• Operacionalidade: Capacidade do produto de software de minimizar o esforço do

usuário para sua operação.

A avaliação dessas características e subcaracterísticas de qualidade foi feita noprotocolo proposto de forma quantitativa, com base em duas fontes de informação:

• o número de respostas às respectivas questões pelos participantes da avaliação; e• as estatísticas de desempenho de cada participante nas atividades de Modelagem e

Avaliação previstas no Método do protocolo proposto. Essas estatísticas envolvemo tempo utilizado para a realização das atividades e o número de erros presentesnos resultados das atividades.

As subcaracterísticas Interoperabilidade e Segurança de Acesso de Funcionali-dade, Atratividade e Conformidade de Usabilidade assim como as características Confia-bilidade, Eficiência, Manutenibilidade e Portabilidade não foram abordadas neste experi-mento. Tais características são secundárias em relação ao foco do presente trabalho.

7.2 Coleta de Dados

O procedimento de avaliação da ferramenta EBD foi executado por cinco desen-volvedores (D1, D2, D3, D4 e D5) que satisfazem o seguinte perfil:

• experiência de pelo menos um ano em desenvolvimento de software para Sistemasde Informação;• conhecimento sobre Modelagem Conceitual de Bancos de Dados para Sistemas de

Informação.

O protocolo, apresentado no Apêndice A, foi criado para padronizar a execuçãoda experimentação e conta com um procedimento que possui cinco atividades, nive-lamento, entendimento, modelagem, validação e avaliação da ferramenta. O esquema(Figura A.1) e o dicionário de dados (Tabela A.1) do SI desenvolvido foram fornecidosaos desenvolvedores.

A Tabela 7.1 apresenta o tempo gasto pelos cinco desenvolvedores para execuçãodas atividades de treinamento e desenvolvimento.

A Tabela 7.2 apresenta a quantidade de erros de cada desenvolvedor na ativi-dade de desenvolvimento. Os erros foram coletados pelo pesquisador que coordenou oexperimento, a medida em que aconteciam.

A Tabela 7.3 apresenta a quantidade de tabela e stored procedures geradas peloscinco desenvolvedores em relação ao tempo de desenvolvimento.

7.3 Análise dos Resultados 128

D1 D2 D3 D4 D5Treinamento 90min 90min 50min 45min 50minDesenvolvimento 101min 136min 79min 101min 110minTotal 171min 226min 129min 146min 160min

Tabela 7.1: Tempos de Execução da Experimentação

D1 D2 D3 D4 D5Desenvolvimento 101 min 136 min 79 min 101 min 110 minNúmero de Erros 19 13 09 17 22Média (erros/10min) 1,9 0,9 1,1 1,7 2

Tabela 7.2: Tempo de Desenvolvimento e Quantidade de Erros

D1 D2 D3 D4 D5Desenvolvimento 101 min 136 min 79 min 101 min 110 minNúmero de Tabelas 15 15 15 15 15Número de Procedures 42 42 42 42 42Elementos do Esquema 57 57 57 57 57Média (elemento/min) 0,56 0,41 0,72 0,56 0,51

Tabela 7.3: Tempo de Desenvolvimento e Produtos Gerados

Questão/Subcaracterística SIM PARCIALMENTE NÃO1. Adequação 5 0 02. Acurácia 5 0 03. Conformidade 5 0 04. Inteligibilidade (Percepção) 3 2 05. Inteligibilidade (Facilidade de Uso) 3 2 06. Apreensibilidade 2 2 17. Operacionalidade 5 0 0

Tabela 7.4: Respostas do Questionário de Avaliação da Experi-mentação da Ferramenta EBD

Na atividade de avaliação da ferramenta os desenvolvedores responderam oquestionário descrito na Seção A.3 do Apêndice A. A Tabela 7.4 apresenta a quantificaçãodas respostas deste questionário.

7.3 Análise dos Resultados

Pelas respostas obtidas dos desenvolvedores, a ferramenta EBD possui umconjuntos de funções que permitem criar um modelo conceitual e, a partir deste modelo,gerar o BD. Além disso, o modelo conceitual registrado no componente EBD não sofreperda de informação em relação ao modelo conceitual original e, da mesma forma, omodelo em SQL gerado é consistente com o modelo conceitual original.


Com as respostas da Questão 8 do formulário os participantes apontaram algu-mas melhorias para o componente como: a necessidade de visualização do esquema antesou mesmo depois de ser gerado; geração do atributo sequencial (este atributo define aordem dos atributos de uma entidade no MMO); teclas de atalho e modificação da apli-cação, permitindo editar os atributos em uma planilha, onde cada linha seria um atributoda entidade.

Em relação à percepção das funcionalidades oferecidas pela ferramenta, dois doscinco desenvolvedores tiveram certa dificuldade de assimilar alguns conceitos do MMO.Como por exemplo, o mapeamento para relacionamento feito pelo atributo do tipo objetointerno e o momento em que o esquema operacional do BD deveria ser gerado. Os errosdetectados no experimento são categorizados como:

• tamanho de atributo alfanumérico não fornecido• atributo do tipo objeto interno não foi definido como parte da chave, na criação de

entidade fraca• chave parcial do atributo composto não foi definida• entidade de referência do atributo objeto interno não forncecida• atributo de referência do atributo objeto interno não fornecido• chave parcial da entidade fraca não fornecida• atributos de ligação das entidades envolvidas em relacionamentos não definidos

Apesar da dificuldade de alguns em relação aos conceitos, a quantidade de errosfoi pequena para todos os desenvolvedores, como mostra a Tabela 7.2. A menor taxa deerro foi de 0,9 em 10 minutos e a maior foi 2 erros a cada 10 minutos de desenvolvimento.Com isso tem-se indícios que é de fácil operação.

O tempo estimado de trinta minutos para o treinameto não foi suficiente para ne-nhum dos cinco desenvolvedores, devido à grande quantidade de conceitos apresentados.Um dos participantes marcou como negativa a apreensiblidade, apesar de justificar que notempo do treinamento todos os conceitos foram passados, permitindo assim a utilizaçãodo componente.

Foi consenso entre os participantes que a ferramenta diminui o esforço emrelação à modelagem e geração de esquema em relação ao processo manual. A Tabela7.3 traz a média de produção de cada um dos desenvolvedores. O melhor caso criou umelemento do esquema (tabela ou stored procedure) em pouco mais de um minuto, temposignificamente mais curto do que necessário para criar um destes elementos manualmente.

Neste experimento o tamanho do esquema utilizado foi pequeno (6 entidadese 7 relacionamentos), mas a partir dele foram exercitados grande parte dos conceitospara definição de esquemas no MMO. Também foi consenso entre os participantes quea utilização do componente ajuda na produtividade em relação à criação de BD de SI.


Este capítulo apresentou o procedimento utilizado para avaliar aspectos defuncionalidade e usabilidade da ferramenta EBD. Foram apresentados também os dadoscoletados e a análise destes dados.

CAPÍTULO 8Conclusões

Este capítulo apresenta as considerações finais sobre este trabalho (Seção 8.1).A Seção 8.2 discute as principais contribuições do presente trabalho e a Seção 8.3 indicatrabalhos futuros e possíveis extensões.

8.1 Considerações Finais

No ciclo de vida de BD são utilizados mecanismos de transformação parageração e evolução do esquema e das aplicações do BD. Esses processos (geração eevolução de esquema) quando executados de forma manual, estão sujeitos a erros nomomento das tranformações entre os modelos conceitual, lógico e físico do BD.

Geralmente as modificações necessárias para evolução do esquema são aplicadasdiretamente no modelo físico (ou operacional) do BD; tornando o modelo conceitualdesatualizado. Outro problema que dificulta os processos de geração e evolução deesquema de BD é a baixa produtividade do desenvolvimento manual desses processos.

Este trabalho apresenta uma abordagem dirigida por modelos (MDD - Model

Driven Development) para a automatização do processo de transformação na geração eevolução de bancos de dados de Sistemas de Informação (SI). Para isso foi projetado eimplementado um componente nomeado de Especialista em Banco de Dados (EBD).

O EBD é um componente de um framework de software que constroi, evolui egerencia SI com base na abordagem dirigida por modelos [58]. O processo de criação eevolução de esquemas de BD de SI proposto neste trabalho envolve dois tipos de transfor-mação: do Modelo de Meta Objetos (MMO) para o Modelo Relacional; e deste para umdialeto do SQL. Além do esquema do BD, são gerados procedimentos armazenados paraoperações do tipo Criação, Recuperação, Atualização e Remoção (CRUD) para manipu-lação dos dados das entidades modeladas, o que facilita o desenvolvimento de aplicaçõesde BD.

As informações do modelo conceitual (metadados) são armazenadas no próprioBD da aplicação, ao contrário de outras ferramentas que armazenam em arquivos (XML)ou diretamente no código fonte. As vantagens do armazenamento no BD estão rela-

8.2 Contribuições 132

cionadas à segurança das informações do modelo que descreve o SI e à alta disponi-bilidade fornecida pelo SGBD.

Uma possível limitação desta prática é a mudança do SGBD onde estão ar-mazenadas as informações que representam o SI. No entanto, na abordagem propostaneste trabalho, o uso de técnicas de engenharia de software baseada em modelos garantea independência de SGBD, bastando que o mecanismo de transformação de modelos sejaajustado para o SGBD alvo.

Além da geração e evolução do esquema, o componente EBD fornece serviçospara outros componentes do framework. Por exemplo, obtenção de metadados de tipo deentidade, verificação de existência de chave lógica de uma entidade e serviços utilizadospara validação de regras dinâmicas que são executados no BD.

Esta integração do componente EBD com um framework de mais alto nível,que gera e gerencia aplicações de SI, é um diferencial em relação a outras ferramentasencontradas que atendem necessidades gerais de evolução e geração de BD, mas nãoatendem as necessidades específicas das aplicações de SI.

A automatização do processo de transformação dos modelos, segundo a abor-dagem MDD, trata problemas relacionados ao desenvolvimento de sistema de software etambém de BD. Há uma diminuição de erros relacionados a transformação, que é feita porferramentas e de forma automática. O esquema conceitual permanece sempre atualizado,pois as modificações são executadas no esquema conceitual e propagadas automatica-mente para os esquemas lógico e físico.

Além disso, há um ganho de produtividade, pois ao término da modelagem oesquema é gerado automaticamente. Outra vantagem está relacionada à portabilidade daaplicação, pois a lógica de negócio é separada da linguagem utilizada para implemen-tação.

A principal dificuldade desta abordagem MDD é o custo de desenvolvimentode ferramentas de transformação automática de esquemas, como a que é proposta nestetrabalho.

8.2 Contribuições

A principal contribuição deste trabalho é a definição de uma abordagem queapóia todo o ciclo de vida de BD de SI. Esta abordagem contempla uma arquiteturade sofware que permite a geração e evolução do esquema em SI. Foi criado tambémum mecanismo que oferece as operações básicas para manipulação das instâncias dasentidades do SI. Este mecanismo utiliza stored procedures geradas para implementar estasoperações.

Outras contribuições deste trabalho são:

8.3 Trabalhos Futuros 133

• a especificação de um modelo de dados conceitual (MMO) para representação dedados de SI.• a especificação dos mapeamentos, para esquema e procedimentos de manipulação,

do modelo conceitual (MMO) para o Modelo Relacional, e deste para o dialeto SQLdo SGBD PostgreSQL.• a definição de um conjunto de operações que automatizam a evolução do esquema

de BD em SI.

Algumas das ideias do presente trabalho foram publicadas em um artigo noXXIII Simpósio Brasileiro de Engenharia Software [21], onde é descrita a relação docomponente de persistência proposto neste trabalho com o restante do framework dedesenvolvimento de SI.

8.3 Trabalhos Futuros

A continuidade do trabalho aqui descrito visa implementar mapeamentos paradiferentes formas de persistência, incluindo outros SGBDs baseados em SQL e tambémoutras formas de armazenamento não baseadas em SQL.

Além disso, o framework de SI continua em evolução, trazendo novas demandaspor operações de geração e evolução automática de esquemas que não foram previstas naversão atual do software. Algumas destas demandas são:

• O suporte a aspectos temporais no modelo conceitual do BD.• Definir opções para mapear os conceitos do MMO para o MR, como por exemplo,

hierarquia de especialização e tipos de relacionamento.• Permitir que o esquema de SI seja exportado ou importado pelo framework e que o

esquema seja gerado a partir de um esquema exportado por exemplo, em XML.• Permitir que o usuário defina os campos para os quais devem ser criados índices de

acesso.• Permitir que as informações do MMO sejam armazenadas em arquivos XML.

O mecanismo de geração de esquema e de stored procedures pode ser melhoradono sentido de definir operações mais eficientes para o BD do SI. Para isso o mecanismodeveria considerar características específicas do SGBD alvo e não apenas transformaçõesgenéricas como os que foram descritas neste trabalho.

Outra melhoria que pode ser adicionada é a definição de uma notação gráficapara os conceitos do MMO, associada a um editor que permita o desenvolvimento de umesquema conceitual de forma visual, diferente da edição por formulários de cadastro.

Dentre os mapeamentos definidos para evolução de esquema (discutidos noCapítulo 6) somente foram implementadas a modificação de tipo de entidade (de forte

8.3 Trabalhos Futuros 134

para fraca) e a modificação do tamanho de atributo. Os demais mapeamentos podem serimplementados para um suporte completo às mofificações permitidas pelo framework.

Referências Bibliográficas

[1] ABRA PROJECT. Abra - light weight java persistence framework. http://abra.

sourceforge.net/, último acesso em janeiro de 2010.

[2] APACHE SOFTWARE FOUDATION. Apache ObJect Relational Bridge - OJB. http:

//db.apache.org/ojb/, último acesso em janeiro de 2010.

[3] APACHE SOFTWARE FOUDATION. Cayenne: Object relational mapping, persis-

tence and caching for java. http://cayenne.apache.org/, último acesso em

janeiro de 2010.

[4] AQUAFOLD. Aqua data studio. http://www.aquafold.com/, último acesso em

janeiro de 2010.

[5] AVAJE EBEAN ORM. Avaje Ebean ORM Persitence Layer. http://www.avaje.

org/, último acesso em janeiro de 2010.

[6] BALZER, R. Transformational implementation: An example. IEEE Transactions

Software Engineering, 7(1):3–14, 1981.

[7] BANERJEE, J.; KIM, W.; KIM, H.-J.; KORTH, H. F. Semantics and implementation

of schema evolution in object-oriented databases. In: SIGMOD ’87: Proceedings

of the 1987 ACM SIGMOD international conference on Management of data, p. 311–

322, New York, NY, USA, 1987. ACM.

[8] BERGIN, T. J. Computer-Aided Software Engineering. Idea Group Publishing,

1993.

[9] BERNSTEIN, P. A.; HO, H. Model management and schema mappings: theory

and practice. In: Proceedings of the 33rd international conference on Very large

data bases, VLDB ’07, p. 1439–1440. VLDB Endowment, 2007.

[10] BERNSTEIN, P. A.; MELNIK, S.; CHURCHILL, J. E. Incremental schema matching.

In: Proceedings of the 32nd international conference on Very large data bases, VLDB

’06, p. 1167–1170. VLDB Endowment, 2006.

http://abra.sourceforge.net/


http://db.apache.org/ojb/

http://db.apache.org/ojb/

http://cayenne.apache.org/

http://www.aquafold.com/

http://www.avaje.org/

http://www.avaje.org/


[11] BERNSTEIN, P. A.; MELNIK, S.; PETROPOULOS, M.; QUIX, C. Industrial-strength

schema matching. SIGMOD Rec., 33:38–43, December 2004.

[12] BOFF, G. Arquitetura e implementação de mecanismos para suporte a regras

de negócio em sistemas de informação. Master’s thesis, Universidade Federal de

Goiás - Instituto de Informática, Goiânia - Goiás, Abril 2010.

[13] BOFF, G.; DE OLIVEIRA, J. L. Modelagem, implementação e manutenção de

regras de negócio em sistemas de informação. VIII Simpósio Brasileiro de Qual-

idade de Software - VI WMSWM (Workshop de Manutenção de Software Moderna).

Ouro Preto, Minas Gerais, Brasil, 2009.

[14] BOUNIF, H.; POTTINGER, R. Schema repository for database schema evolution.

International Workshop on Database and Expert Systems Applications, 0:647–651,

2006.

[15] CA. CA erwin data modeler. http://www.ca.com/us/data-modeling.aspx,

último acesso em janeiro de 2010.

[16] CHEN, P. The entity-relationship model: Toward a unified view of data. ACM

Transactions on Database Systems, 1:9–36, 1976.

[17] CÂNDIDO, C. H. brModelo 2.0 - Modelagem ER. http://www.sis4.com/

brModelo/, último acesso em dezembro de 2010.

[18] DA SILVA, W. C. Gerência de Interfaces para Sistemas de Informação: uma

abordagem baseada em modelos. Master’s thesis, Universidade Federal de Goiás

- Instituto de Informática, Goiânia - Goiás, Abril 2010.

[19] DA SILVA, W. C.; DE OLIVEIRA, J. L. Gerência de interface homem-computador

para sistemas de informação empresariais: uma abordagem baseada em mo-

delos. iSys - Revista Brasileira de Sistemas de Informação, 2, 2009.

[20] DBVIS SOFTWARE. Dbvisualizer: The universal database tool. http://www.

dbvis.com/, último acesso em janeiro de 2010.

[21] DE ALMEIDA, A. C.; BOFF, G.; DE OLIVEIRA, J. L. A framework for modeling,

building and maintaining enterprise information systems software. XXIII Simpó-

sio Brasileiro de Engenharia de Software (SBES). Fortaleza - CE - Brasil, p. 115–125,

2009.

[22] DE OLIVEIRA, J. L. Tecnologia da informação para otimização da produção

de gado de corte. Relatório técnico final 505198/2004-5, projeto de pesquisa e

desenvolvimento - CNPq, Goiânia, Goiás, Abril, 2007.

http://www.ca.com/us/data-modeling.aspx

http://www.sis4.com/brModelo/

http://www.sis4.com/brModelo/

http://www.dbvis.com/

http://www.dbvis.com/


[23] DOMÍNGUEZ, E.; LLORET, J.; RUBIO, A. L.; ZAPATA, M. A. Medea: A database

evolution architecture with traceability. Data Knowl. Eng., 65(3):419–441, 2008.

[24] DOMÍNGUEZ, E.; LLORET, J.; ZAPATA, M. A. An architecture for managing

database evolution. In: Proceedings of the Workshop on Evolution and Change

in Data Management (ECDM 2002), volume 2784, p. 63–74. Springer, 2002.

[25] DUBIELEWICZ, I.; HNATKOWSKA, B.; HUZAR, Z.; TUZINKIEWICZ, L. Feasibility anal-

ysis of mda-based database design. In: DEPCOS-RELCOMEX ’06: Proceedings

of the International Conference on Dependability of Computer Systems, p. 19–26,

Washington, DC, USA, 2006. IEEE Computer Society.

[26] EDEN, A. Databind. http://databind.sourceforge.net/, último acesso em

janeiro de 2010.

[27] EMBLEY, D. W.; XU, M. Relational database reverse engineering: A model-

centric, transformational, interactive approach formalized in model theory.

Database and Expert Systems Applications, International Workshop on, p. 372, 1997.

[28] EXOLAB GROUP. The castor project. http://www.castor.org/, último acesso

em janeiro de 2010.

[29] FABFORCE. Dbdesigner. http://www.fabforce.net/dbdesigner4/index.php,


[30] FICKAS, S. F. Automating the transformational development of software. IEEE

Trans. Softw. Eng., 11(11):1268–1277, 1985.

[31] FRANCE, R.; RUMPE, B. Model-driven development of complex software: A

research roadmap. In: FOSE ’07: 2007 Future of Software Engineering, p. 37–54,

Washington, DC, USA, 2007. IEEE Computer Society.

[32] HAINAUT, J.-L.; CHANDELON, M.; TONNEAU, C.; JORIS, M. Contribution to a theory

of database reverse engineering. 1993.

[33] HALPIN, T. Object-role modeling. www.orm.net/, último acesso em março de

2010, 2009.

[34] HALPIN, T. A.; PROPER, H. A. Database schema transformation and optimiza-

tion. In: OOER ’95: Proceedings of the 14th International Conference on Object-

Oriented and Entity-Relationship Modelling, p. 191–203, London, UK, 1995. Springer-

Verlag.

http://databind.sourceforge.net/

http://www.castor.org/

http://www.fabforce.net/dbdesigner4/index.php

www.orm.net/


[35] HICK, J.-M.; HAINAUT, J.-L. Database application evolution: a transformational

approach. Data and Knowledge Engineering, 59(3):534–558, 2006.

[36] IBM. Ibm rational rose data modeler. http://www-01.ibm.com/software/

awdtools/developer/datamodeler/, último acesso em janeiro de 2010.

[37] ISO. Iso 9126 - software engineering – product quality – part 1:

Quality model. http://www.iso.org/iso/iso_catalogue/catalogue_tc/

catalogue_detail.htm?csnumber=22749, último acesso em janeiro de 2010.

[38] ISO/IEC/(IEEE). ISO/IEC 42010 (IEEE Std) 1471-2000 : Systems and Software

engineering - Recomended practice for architectural description of software-

intensive systems, 07 2007.

[39] JAHNKE, J. H.; WADSACK, J. P. Varlet: Human-centered tool support for database

reengineering. Proceedings of the Workshop on Software Reengineering, 1999.

[40] JAVA SUN. Annotations. http://abra.sourceforge.net/, último acesso em

janeiro de 2010.

[41] JBOSS COMMUNITY. Hibernate: Relational persistence for java and .net. http:

//www.hibernate.org/, último acesso em janeiro de 2010.

[42] KILDEN-PEDERSEN, N. OR Broker: JDBC Framework. http://orbroker.

sourceforge.net/, último acesso em janeiro de 2010.

[43] KLEPPE, A. G.; WARMER, J.; BAST, W. MDA Explained: The Model Driven

Architecture: Practice and Promise. Addison-Wesley Longman Publishing Co.,

Inc., Boston, MA, USA, 2003.

[44] KORPELA, M.; MURSU, A.; SORIYAN, H. A. Information systems development

as an activity. Journal Computer Supported Cooperative Work, 11:111–128, April

2002.

[45] LI, B.; LIU, S.; YU, Z. Applying mda in traditional database-based application

development. In: International Conference on Computer Supported Cooperative

Work in Design, volume 2, p. 1038–1041 Vol. 2, Los Alamitos, CA, USA, 2005. IEEE

Computer Society.

[46] MCBRIEN, P.; POULOVASSILIS, A. Data integration by bi-directional schema

transformation rules. International Conference on Data Engineering, p. 227, 2003.

[47] MIAN, N. A.; HUSSAIN, T. Database reverse engineering tools. In: SEPADS’08:

Proceedings of the 7th WSEAS International Conference on Software Engineering,

http://www-01.ibm.com/software/awdtools/developer/datamodeler/

http://www-01.ibm.com/software/awdtools/developer/datamodeler/

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22749

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22749


http://www.hibernate.org/

http://www.hibernate.org/

http://orbroker.sourceforge.net/

http://orbroker.sourceforge.net/


Parallel and Distributed Systems, p. 206–211, Stevens Point, Wisconsin, USA, 2008.

World Scientific and Engineering Academy and Society (WSEAS).

[48] OBJECT MANAGEMENT GROUP. Uml resource page. http://www.uml.org/,

último acesso em março de 2010, 2010.

[49] ORACLE AND/OR ITS AFFILIATES. Introduction to the java persistence api. http:

//download.oracle.com/javaee/6/tutorial/doc/bnbpz.html, último acesso

em novembro de 2010.

[50] PGADMIN POSTGRESQL TOOLS. Postgresql administration and management

tools. http://www.pgadmin.org/, último acesso em janeiro de 2010.

[51] PHILIPPI, S. Model driven generation and testing of object-relational mappings.

Journal of Systems and Software, 77(2):193–207, 2005.

[52] POSTGRESQL GLOBAL DEVELOPMENT GROUP. Pl/pgsql - sql procedural lan-

guage. http://www.postgresql.org/docs/8.4/static/plpgsql.html, último

acesso em janeiro de 2010.

[53] POSTGRESQL GLOBAL DEVELOPMENT GROUP. Postgresql - the world’s most

advanced open source database. www.postgresql.org, último acesso em janeiro

de 2010.

[54] QUEST SOFTWARE. Toad data modeler - database design tool. http://www.

toadsoft.com/toaddm/toad_data_modeler.htm, último acesso em janeiro de

2010.

[55] RAMEZ ELMASRI, S. N. Sistemas de Banco de Dados. Addison-Wesley, 2005.

[56] RAUH, O.; STICKEL, E. Standard transformations for the normalization of

er schemata. In: CAiSe ’95: Proceedings of the 7th International Conference

on Advanced Information Systems Engineering, p. 313–326, London, UK, 1995.

Springer-Verlag.

[57] REVER. Db-main - the modeling framework. http://www.db-main.eu/, último

acesso em janeiro de 2010.

[58] SCHMIDT, D. C. Model-driven engineering. In: IEEE Computer, vol. 39, no. 2, p.

25–31. doi:10.1109/MC.2006.58, 2006.

[59] SOFTWARE TREE. NJDX: A Powerful and Practical OR-Mapper for .NET. http:

//www.softwaretree.com/, último acesso em janeiro de 2010.

http://www.uml.org/

http://download.oracle.com/javaee/6/tutorial/doc/bnbpz.html

http://download.oracle.com/javaee/6/tutorial/doc/bnbpz.html

http://www.pgadmin.org/

http://www.postgresql.org/docs/8.4/static/plpgsql.html

www.postgresql.org

http://www.toadsoft.com/toaddm/toad_data_modeler.htm

http://www.toadsoft.com/toaddm/toad_data_modeler.htm

http://www.db-main.eu/

http://www.softwaretree.com/

http://www.softwaretree.com/


[60] SOLUTIONS DESIGN BV. Llblgen pro: The leading o/r mapper generator. http:

//www.llblgen.com/defaultgeneric.aspx, último acesso em janeiro de 2010.

[61] SUN DEVELOPER NETWORK. Jdbc overview. http://java.sun.com/products/

jdbc/overview.html, último acesso em janeiro de 2010.

[62] SYBASE. Powerdesigner - modeling and metadata management software tool.

http://www.sybase.com/products/modelingdevelopment/powerdesigner,


[63] TELERIK CORPORATION. Telerik Open Access ORM: Object-relational mapping

tool for .net. http://www.telerik.com/products/orm.aspx, último acesso em

janeiro de 2010.

[64] TORRES, A.; GALANTE, R.; PIMENTA, M. S. Towards a UML Profile for Model-

Driven Object-Relational Mapping. XXIII Simpósio Brasileiro de Engenharia de

Software (SBES). Fortaleza - CE - Brasil, 0:94–103, 2009.

[65] VELEGRAKIS, Y.; MILLER, J.; POPA, L. Preserving mapping consistency under

schema changes. The VLDB Journal, 13(3):274–293, 2004.

[66] VELEGRAKIS, Y.; MILLER, R. J.; POPA, L. Mapping adaptation under evolving

schemas. In: VLDB ’2003: Proceedings of the 29th international conference on Very

large data bases, p. 584–595, 2003.

[67] VISUAL PARADIGM. Database visual architect: Access database with object-

oriented technology. http://www.visual-paradigm.com/product/dbva/, úl-

timo acesso em janeiro de 2010.

[68] XDOCLET TEAM. Xdoclet : Attribute-oriented programming. http://xdoclet.

sourceforge.net/xdoclet/index.html, último acesso em janeiro de 2010.

[69] YOUNG, R. R. The Requirements Engineering Handbook. Artech House, 2004.

http://www.llblgen.com/defaultgeneric.aspx

http://www.llblgen.com/defaultgeneric.aspx

http://java.sun.com/products/jdbc/overview.html

http://java.sun.com/products/jdbc/overview.html

http://www.sybase.com/products/modelingdevelopment/powerdesigner

http://www.telerik.com/products/orm.aspx

http://www.visual-paradigm.com/product/dbva/

http://xdoclet.sourceforge.net/xdoclet/index.html

http://xdoclet.sourceforge.net/xdoclet/index.html

APÊNDICE AProtocolo para Avaliação da Ferramenta EBD

Este documento descreve um protocolo para avaliação experimental da ferra-menta EBD (Especialista em Bancos de Dados).

A.1 Objetivos da Avaliação

O presente procedimento tem como finalidade avaliar aspectos de funcionalidadee usabilidade da ferramenta EBD, de acordo com a Norma ISO 9126 [37].

A.2 Procedimentos da Avaliação

A avaliação será executada individualmente pelos participantes. Cada um delesdeverá executar as seguintes atividades:

1. Atividade de Nivelamento: duração de 30 minutos. Os participantes receberãotreinamento sobre os conceitos do MMO e sobre a forma de utilizar a ferramentaEBD para modelagem conceitual de bancos de dados.

2. Atividade de Entendimento: duração de 30 minutos. Os participantes receberãoinformações sobre o esquema de banco de dados que será utilizado na avaliação.Todos os participantes receberão o mesmo esquema de BD descrito com o MER;este esquema está definido na Seção A.4.

3. Atividade de Modelagem: duração livre. Os participantes receberão um esquemaconceitual de banco de dados descrito com o MER e deverão utilizar a ferramentaEBD para:

(a) gerar o esquema correspondente descrito com o MMO; e(b) gerar o esquema operacional correspondente em SQL no SGBD PostgreSQL.

4. Atividade de Validação: duração de 10 minutos. Os participantes deverão validaro esquema operacional (em SQL do SGBD PostgreSQL) de BD gerado pelaferramenta EBD com relação ao esquema conceitual de BD originalmente descritocom o MER.

Apêndice A 142

5. Atividade de Avaliação da Ferramenta: duração de 30 minutos. Após a realizaçãoda modelagem, cada participante irá responder ao questionário que consta no AnexoA.3.

O tempo gasto pelos participantes para realizar cada atividade será cronometradopelo pesquisador que controla o experimento de avaliação da ferramenta EBD. Da mesmaforma, esse pesquisador irá contabilizar o número de erros presentes nos resultados decada participante.

A.3 Questionário

1. Adequação: A ferramenta oferece um conjunto apropriado de funções para astarefas e objetivos especificados, ou seja, para criar um modelo conceitual de BD epara gerar um esquema operacional de BD a partir do modelo conceitual?( )Sim ( )Parcialmente ( )NãoJustifique se a resposta é diferente de Sim:____________________________________________________________________________________________________________________________________

2. Acurácia: O esquema conceitual modelado com a ferramenta repre-senta fielmente o esquema conceitual original (feito com o MER)?( )Sim ( )Parcialmente ( )NãoJustifique se a resposta é diferente de Sim:____________________________________________________________________________________________________________________________________

3. Conformidade: O esquema SQL gerado pela ferramenta repre-senta fielmente o esquema conceitual original (feito com o MER)?( )Sim ( )Parcialmente ( )NãoJustifique se a resposta é diferente de Sim:____________________________________________________________________________________________________________________________________

4. Inteligibilidade: As funcionalidades oferecidas pela ferramenta são facilmentepercebidas pelo usuário?( )Sim ( )Parcialmente ( )NãoJustifique se a resposta é diferente de Sim:__________________________________________________________________

Apêndice A 143

__________________________________________________________________

5. Inteligibilidade: As formas de uso das funcionalidades oferecidas pela ferramentapara criar um modelo conceitual de BD e para gerar um esquema operacionalde BD a partir do modelo conceitual são facilmente percebidas pelo usuário?( )Sim ( )Parcialmente ( )NãoJustifique se a resposta é diferente de Sim:____________________________________________________________________________________________________________________________________

6. Apreensibilidade: O treinamento recebido sobre o uso da ferramenta, com duraçãode 30 minutos, foi suficiente para possibilitar ao usuário aprender sua forma deaplicação na modelagem e geração de esquemas de BD?( )Sim ( )Parcialmente ( )NãoJustifique se a resposta é diferente de Sim:____________________________________________________________________________________________________________________________________

7. Operacionalidade: A forma de usar a ferramenta diminui o esforço necessário paraque o usuário possa modelar e gerar esquemas de BD, em comparação com outrasformas conhecidas de realizar essas atividades (por exemplo, outras ferramentas,ou realização manual dessas atividades)?( )Sim ( )Parcialmente ( )NãoJustifique se a resposta é diferente de Sim:____________________________________________________________________________________________________________________________________

8. Geral: O que poderia ser melhorado na ferramenta para atender as ne-cessidades do usuário interessado em modelar e gerar esquemas de BD?____________________________________________________________________________________________________________________________________

A.4 Modelo Conceitual de uma Empresa

Apêndice A 144

Pessoa FísicaNome Tipo Mín/Máx É Único ObservaçãonomePF String(99) (1,1) NÃOcpfPF String(11) (1,1) SIMdataNascPF Data (1,1) NÃOenderecoPF String(200) (0,1) NÃOtelefonePF Composto (0,N) NÃOtipoTelPF Enumerado (1,1) NÃO Valores do domínio:

fixo, celular, faxCompositor: telefonePF

prefixoTelPF Inteiro (1,1) NÃO Compositor: telefonePFnumeroTelPF Inteiro (1,1) NÃO Compositor: telefonePF

FuncionárioNome Tipo Mín/Máx É Único Observaçãosalario Inteiro (1,1) NÃO

DependenteNome Tipo Mín/Máx É Único ObservaçãonomeDepen String(99) (1,1) NÃOsexoDepen Enumerado (1,1) NÃO Valores do Domínio:

masculino, femininodataNascDepen Data (1,1) NÃOparentescoDepen String(99) (1,1) NÃO

ManutençãoNome Tipo Mín/Máx É Único ObservaçãoidManutencao String(10) (1,1) SIMitemManutencao String(50) (1,1) NÃO

DepartamentoNome Tipo Mín/Máx É Único ObservaçãonomeDep String(99) (1,1) SIMnumeroDep Inteiro (1,1) SIMlocalizacaoDep String(99) (1,1) NÃOtelefoneDep Composto (0,N) NÃOprefixoTelDep Inteiro (1,1) NÃO Compositor: telefoneDepnumeroTelDep Inteiro (1,1) NÃO Compositor: telefoneDep

ProjetoNome Tipo Mín/Máx É Único ObservaçãonomeProj String(99) (1,1) NÃOnumeroProj Inteiro (1,1) NÃOlocalizacaoProj String(200) (1,1) NÃO

Tabela A.1: Dicionário do Esquema de Empresa

Apêndice A 145

Figura A.1: Modelo Conceitual de Empresa (adaptado de [55])

APÊNDICE BMapeamentos do Modelo Relacional para SQL(PostgreSQL)

B.1 Entidade Fraca

A Tabela B.1 apresentada as operações CRUD sobre Tipo de Entidade Fraca.Os Códigos B.1, B.2, B.3, B.4, e B.5 apresentam as stored procedures de obtenção deinstâncias, obtenção de uma instância, inserção, remoção e atualização de instâncias deTipo de Entidade Fraca.

Tabela B.1: Mapeamento de Operações CRUD sobre Tipo de En-tidade Fraca

MR SQL

(a) Obtenção de Instâncias

πEntidadeProp.atribA,EntidadeFraca.atrib1,SELECT EntidadeProp.atribA, Entidade-

Fraca.atrib1,

EntidadeFraca.atrib2( EntidadeFraca.atrib2σ Ob jetoInternoParteChave.pkEnt=EntidadeFraca.pk FROM EntidadeFraca JOIN

AND ObjetoInternoParteChave

Ob jetoInternoParteChave.pkEntRe f=EntidadeProp.pk ON EntidadeFraca.pk =

(EntidadeFraca×ObjetoInternoParteChave× ObjetoInternoParteChave.pkEnt

EntidadeProp) JOIN EntidadeProp

) ON ObjetoInternoParteChave.pkEntRef =

EntidadeProp.pk

(b) Obtenção de Instância

πEntidadeProp.atribA,EntidadeFraca.atrib1,SELECT EntidadeProp.atribA, Entidade-

Fraca.atrib1,

EntidadeFraca.atrib2( EntidadeFraca.atrib2σ Ob jetoInternoParteChave.pkEnt=EntidadeFraca.pk FROM EntidadeFraca JOIN


Apêndice B 147

Continuação da Tabela B.1

MR SQLAND ObjetoInternoParteChave

Ob jetoInternoParteChave.pkEntRe f=EntidadeProp.pk ON EntidadeFraca.pk =

EntidadeProp.atribA=valA AND ObjetoInternoParteChave.pkEnt

EntidadeProp.atribB=valB AND JOIN EntidadeProp

EntidadeFraca.atrib1=val1 ON ObjetoInternoParteChave.pkEntRef =(EntidadeFraca×ObjetoInternoParteChave×EntidadeProp

EntidadeProp.pk

)WHERE EntidadeProp.atribA = valA AND

EntidadeProp.atribB = valBAND EntidadeFraca.atrib1 = val1

(c) Inserção de InstânciapkEntRef← πpk(σEntidadeProp.atribA=valA SELECT INTO pkEntRef pk

AND EntidadeProp.atribB=valB(EntidadeProp)) FROM EntidadePropWHERE EntidadeProp.atribA = valA AND

EntidadeRef.atribB = valB;

EntidadeFraca← EntidadeFraca ∪INSERT INTO EntidadeFraca(atrib1, atrib2)

VALUES (val1, val2);{(pk, val1, val2)}

pkEnt← maxpk(EntidadeFraca) SELECT INTO pkEnt * FROM lastval();mnmonicoObjInternoParteChave← mnmoni-

coObjInternoParteChave ∪INSERT INTO mnmonicoObjIn-

ternoParteChave(pkEntidade,{(pk, pkEnt, pkEntRef)} pkEntidadeRef)

VALUES (pkEnt, pkEntRef);

(d) Remoção de InstânciapkEntRef← πpk( SELECT INTO pkEntRef EntidadeProp.pk

σEntidadeProp.atribA=valA(EntidadeProp)) FROM EntidadePropWHERE EntidadeProp.atribA = valANMod

ANDEntidadeProp.atribB = valBNMod;

pkEnt← πEntidadeFraca.pk( SELECT INTO pkEnt EntidadeFraca.pk

σ Ob jetoInternoParteChave.pkEnt=EntidadeFraca.pkFROM EntidadeFraca JOIN ObjetoInt-

ernoParteChaveAND ON EntidadeFraca.pk =

Ob jetoInternoParteChave.pkEntRe f=EntidadeProp.pk ObjetoInternoParteChave.pkEnt

AND JOIN EntidadeProp


Apêndice B 148


MR SQLEntidadeFraca.atrib1=val1NMod ON ObjetoInternoParteChave.pkEntRef =(EntidadeFraca×ObjetoInternoParteChave×EntidadeProp)

EntidadeProp.pk

WHERE EntidadeProp.pk = pkEntRef AND

EntidadeFraca.atrib1 = val1NMod;

EntidadeFraca × ObjetoInternoParteChave × WHERE EntidadeProp.atribA = valA AND

EntidadeProp) EntidadeProp.atribB = valB AND

EntidadeFraca.atrib1 = val1;ObjetoInternoParteChave ← ObjetoInt-

ernoParteChave -DELETE FROM ObjetoInternoParteChave

σOb jetoInternoParteChave.pkEntRe f=pkEntRe f ANDWHERE ObjetoInternoParteChave.pkEntRef

= pkEntRefOb jetoInternoParteChave.pkEnt=pkEnt ObjetoInternoParteChave.pkEnt = pkEnt;

(ObjetoInternoParteChave)

EntidadeFraca← EntidadeFraca -DELETE FROM EntidadeFraca WHERE pk =

pkEnt;σEntidadeFraca.pk=pkEnt(EntidadeFraca)

(e) Atualização de InstânciapkEntRef← πpk( SELECT INTO pkEntRef EntidadeProp.pk

σEntidadeProp.atribA=valA(EntidadeProp)) FROM EntidadePropWHERE EntidadeProp.atribA = valANMod

ANDEntidadeProp.atribB = valBNMod;

pkEnt← πEntidadeFraca.pk( SELECT INTO pkEnt EntidadeFraca.pk

σ Ob jetoInternoParteChave.pkEnt=EntidadeFraca.pkFROM EntidadeFraca JOIN ObjetoInt-

ernoParteChaveAND ON EntidadeFraca.pk =

Ob jetoInternoParteChave.pkEntRe f=EntidadeProp.pk ObjetoInternoParteChave.pkEnt

AND JOIN EntidadeProp

EntidadeFraca.atrib1=val1NMod ON ObjetoInternoParteChave.pkEntRef =(EntidadeFraca×ObjetoInternoParteChave×EntidadeProp)

EntidadeProp.pk

WHERE EntidadeProp.pk = pkEntRef AND

EntidadeFraca.atrib1 = val1NMod;

EntidadeFraca←UPDATE EntidadeFraca SET atrib1 = val1,

atrib2 = val2


Apêndice B 149


MR SQLπatrib1←val1 ,atrib2←val2( WHERE pk = pkEnt;

σEntidadeFraca.pk=pkEnt (EntidadeFraca))

Código B.1 Stored Procedure Modelo para Obtenção de Instâncias de Tipo de EntidadeFraca

1 CREATE FUNCTION obterEntidadeFracaAtivo() RETURNS CURSOR AS $$

2 DECLARE

3 csr CURSOR;

4 BEGIN

5 OPEN csr FOR

6 SELECT EntidadeProp.atribA, EntidadeFraca.atrib1, EntidadeFraca.atrib

7 FROM EntidadeFraca JOIN ObjetoInternoParteChave

8 ON EntidadeFraca.pk = ObjetoInternoParteChave.pkEnt

9 JOIN EntidadeProp ON ObjetoInternoParteChave.pkEntRef =

10 EntidadeProp.pk;

11 RETURN csr;

12 END;


Código B.2 Stored Procedure Modelo para Obtenção de Instância de Tipo de EntidadeFraca

1 CREATE FUNCTION obterEntidadeFracaAtivo(valA TipoSQL,

2 val1 TipoSQL) RETURNS CURSOR AS $$

3 DECLARE

4 csr CURSOR;

5 BEGIN

6 OPEN csr FOR

7 SELECT EntidadeProp.atribA, EntidadeFraca.atrib1,

8 EntidadeFraca.atrib


10 ON EntidadeFraca.pk =

11 ObjetoInternoParteChave.pkEnt

12 JOIN EntidadeProp

13 ON ObjetoInternoParteChave.pkEntRef =

14 EntidadeProp.pk

15 WHERE EntidadeProp.atribA = valA AND

16 EntidadeProp.atribB = valB AND

17 EntidadeFraca.atrib1 = val1;

18

19 RETURN csr;

20 END;


Apêndice B 150

Código B.3 Stored Procedure Modelo para Inserção de Instância de Tipo de EntidadeFraca

1 CREATE FUNCTION inserirEntidadeFraca (valA TipoSQL,

2 valB TipoSQL, val1 TipoSQL, val2 TipoSQL) RETURNS BOOLEAN AS

3 BEGIN

4 SELECT INTO pkEntRef pk FROM EntidadeProp WHERE EntidadeProp.atribA = valA

5 AND EntidadeProp.atribB = valB;

6

7 INSERT INTO EntidadeFraca(atrib1, atrib2) VALUES (val1, val2);


9 INSERT INTO ObjetoInternoParteChave(pkEnt, pkRef) VALUES (pkEnt, pkEntRef);

10 RETURN TRUE;

11 END;


Código B.4 Stored Procedure Modelo para Remoção de Instância de Tipo de EntidadeFraca

1 CREATE FUNCTION desativarEntidadeFraca (valA TipoSQL,

2 valB TipoSQL, val1 TipoSQL) RETURNS BOOLEAN AS $$

3 BEGIN

4

5 SELECT INTO pkEntRef pk FROM EntidadeProp


7 EntidadeProp.atribB = valB;

8

9 SELECT INTO pkEnt EntidadeFraca.pk




13 JOIN EntidadeProp


15 EntidadeProp.pk


17 EntidadeProp.atribB = valB AND

18 EntidadeFraca.atrib1 = val1;

19

20 DELETE FROM ObjetoInternoParteChave

21 WHERE ObjetoInternoParteChave.pkEntRef = pkEntRef

22 AND ObjetoInternoParteChave.pkEnt = pkEnt;

23

24 DELETE FROM EntidadeFraca WHERE pk = pkEnt;

25 RETURN TRUE;

26 END;


Apêndice B 151

Código B.5 Stored Procedure Modelo para Atualização de Instância de Tipo de EntidadeFraca

1 CREATE FUNCTION atualizarEntidadeFraca (valANMod TipoSQL,

2 valNModB TipoSQL, valNMod1 TipoSQL, val1 TipoSQL, val2 TipoSQL)


4 BEGIN

5 SELECT INTO pkEnt EntidadeFraca.pk




9 JOIN EntidadeProp


11 EntidadeProp.pk

12 WHERE EntidadeProp.atribA = valANMod AND

13 EntidadeProp.atribB = valBNMod

14 AND EntidadeFraca.atrib1 = val1NMod;

15 UPDATE EntidadeFraca SET atrib1 = val1, atrib2 = val2


17 RETURN TRUE;

18 END;


B.2 Atributo Composto

A Tabela B.2 apresenta o mapeamento do Modelo Relacional para SQL paraoperação CRUD sobre atributo composto. Os Códigos B.6, B.7, B.8, e B.9 apresentamas stored procedures para as operações de obtenção, inserção, remoção e atualização deinstâncias de atributo composto.

Tabela B.2: Mapeamento de Operações CRUD sobre AtributoComposto

MR SQL

(a) Obtenção de InstânciaspkEnt← πpk( SELECT INTO pkEnt pk

σEntidade.atrib1=val1(Entidade)) FROM Entidade


πAtributoComp.subAtrib1,AtributoComp.subAtrib2,SELECT AtributoComp.subAtrib1, Atributo-

Comp.subAtrib2,

AtributoComp.subAtrib3( AtributoComp.subAtrib3


Apêndice B 152


MR SQLσ Entidade.pk=AtributoComp.pkEntidade AND FROM Entidade JOIN AtributoComp

AtributoComp.pkEntidade=pkEnt ON Entidade.pk = AtributoComp.pkEnt

(Entidade × AtributoComp) WHERE AtributoComp.pkEnt = pkEnt;

)

(a) Obtenção de InstânciapkEnt← πpk( SELECT INTO pkEnt pk



πAtributoComp.subAtrib1,AtributoComp.subAtrib2,SELECT AtributoComp.subAtrib1, Atributo-

Comp.subAtrib2,

AtributoComp.subAtrib3( AtributoComp.subAtrib3σ Entidade.pk=AtributoComp.pkEntidade AND FROM Entidade JOIN AtributoComp

AtributoComp.pkEntidade=pkEnt AND ON Entidade.pk = AtributoComp.pkEnt

AtributoComp.subAtrib1=subAtrib1NMod AND WHERE AtributoComp.pkEnt = pkEnt AND

AtributoComp.subAtrib2=subAtrib2NModAtributoComp.subAtrib1 = subAtrib1NMod

AND(Entidade × AtributoComp)) AtributoComp.subAtrib2 = subAtrib2NMod;

(b) Inserção de InstânciapkEnt← πpk( SELECT INTO pkEnt pk



pkNovo← maxpk(AtributoComp)

AtributoComp← AtributoComp ∪INSERT INTO AtributoComp (pkEnt, subA-

trib1, subAtrib2, subAtrib3){(pkNovo, pkEnt, subval1, subval2, subval3) VALUES (pkEnt, subval1, subval2, subval3);

(c) Remoção de InstânciapkEnt← πpk( SELECT INTO pkEnt pk



pkComp← πpk( SELECT INTO pkComp pk

σAtributoComp.pkEnt=pkEnt(AtributoComp)) FROM Entidade JOIN AtributoComp

ON AtributoComp.pkEnt = Entidade.pkWHERE AtributoComp.pkEnt = pkEnt AND

subAtrib1 = subval1 AND subAtrib2 = sub-

val2;


Apêndice B 153


MR SQL

AtributoComp← AtributoComp -DELETE FROM AtributoComp WHERE pk

= pkComp;σAtributoComp.pk=pkComp (AtributoComp)

(d) Atualização de InstânciapkEnt← πpk( SELECT INTO pkEnt pk



pkComp← πpk( SELECT INTO pkComp pkσAtributoComp.pkEnt=pkEnt AND FROM Entidade JOIN AtributoComp

AtributoComp.subAtrib1=subAtrib1NMod AND ON AtributoComp.pkEnt = Entidade.pk

AtributoComp.subAtrib2=subAtrib2NMod WHERE AtributoComp.pkEnt = pkEnt AND

(AtributoComp))subAtrib1 = subval1NMod AND subAtrib2 =

subval2NMod;AtributoComp← UPDATE AtributoComp

πsubAtrib1←subval1 , subAtrib2←subval2,SET subAtrib1 = subval1, subAtrib2 = sub-

val2, subAtrib3 = subval3

subAtrib3←subval3( WHERE pk = pkComp;

σAtributoComp.pk=pkComp (AtributoComp))

Código B.6 Stored Procedure Modelo para Obtenção de Instâncias de Atributo Composto1 CREATE FUNCTION obterAtributoCompAtivo(val1 TipoSQL) RETURNS CURSOR AS $$

2 DECLARE

3 csr CURSOR;

4 pkEnt INTEGER;

5 BEGIN


7

8 SELECT AtributoComp.subAtrib1, AtributoComp.subAtrib2,

9 AtributoComp.subAtrib3

10 FROM Entidade JOIN AtributoComp ON Entidade.pk = AtributoComp.pkEnt

11 WHERE AtributoComp.pkEnt = pkEnt;

12 RETURN TRUE;

13 END;


Apêndice B 154

Código B.7 Stored Procedure Modelo para Inserção de Instância de Atributo Composto1 CREATE FUNCTION inserirAtributoComp(val1 TipoSQL, subval1 TipoSQL,

2 subval2 TipoSQL,subval3 TipoSQL) RETURNS BOOLEAN AS $$

3 DECLARE

4 pkEnt INTEGER;

5

6 BEGIN



9

10 INSERT INTO AtributoComp (pkEnt,

11 subAtrib1, subAtrib2, subAtrib3) VALUES

12 (pkEnt, subval1, subval2, subval3);

13

14 RETURN TRUE;

15 END;


Código B.8 Stored Procedure Modelo para Remoção de Instância de Atributo Composto1 CREATE FUNCTION desativarAtributoComp(val1 TipoSQL,

2 subval1 TipoSQL, subval2 TipoSQL) RETURNS BOOLEAN AS $$

3 DECLARE

4 pkEnt INTEGER;

5 pkComp INTEGER;

6 BEGIN


8

9 SELECT INTO pkComp pk FROM Entidade JOIN AtributoComp

10 ON AtributoComp.pkEnt = Entidade.pk

11 WHERE AtributoComp.pkEnt = pkEnt AND

12 subAtrib1 = subval1 AND subAtrib2 = subval2;

13 DELETE FROM AtributoComp WHERE pk = pkComp;

14 RETURN TRUE;

15 END;


Apêndice B 155

Código B.9 Stored Procedure Modelo para Atualização de Instância de Atributo Com-posto

1 CREATE FUNCTION atualizarAtributoComp(val1 TipoSQL,

2 subval1NMod TipoSQL, subval2NMod TipoSQL, subval1 TipoSQL,

3 subval2 TipoSQL, subval3 TipoSQL) RETURNS BOOLEAN AS’

4 DECLARE

5 pkEnt INTEGER;

6 pkComp INTEGER;

7 BEGIN


9

10 SELECT INTO pkComp pk FROM Entidade JOIN AtributoComp

11 ON AtributoComp.pkEnt = Entidade.pk

12 WHERE AtributoComp.pkEnt = pkEnt AND

13 subAtrib1 = subval1NMod AND subAtrib2 = subval2NMod;

14

15 UPDATE AtributoComp

16 SET subAtrib1 = subval1, subAtrib2 = subval2, subAtrib3 = subval3

17 WHERE pk = pkComp;

18 RETURN TRUE;

19 END;


B.3 Atributo Simples Multivalorado

A Tabela B.3 apresenta o mapeamento do Modelo Relacional para SQL para asoperações de obtenção, inserção, e remoção de instâncias atributo simples multivalo-rado.

A stored procedures resultantes do mapeamentos das Tabela B.3 são apresen-tadas nos Códigos B.10, B.11, B.12 e B.13.

Apêndice B 156


pkEnt← πpk( SELECT INTO pkEnt pkσEntidade.atrib1=val1(Entidade)) FROM Entidade

WHERE Entidade.atrib1 = val1;πAtributo.valor( SELECT valor

σ Entidade.pk=Atributo.pkEnt AND FROM Entidade JOIN AtributoEntidade.pk=pkEnt ON Entidade.pk = Atributo.pkEnt

(Entidade × Atributo) WHERE Atributo.pkEntidade = pkEnt;)

(b) Inserção de InstânciapkEnt← πpk( SELECT INTO pkEnt pkσEntidade.atrib1=val1(Entidade)) FROM Entidade


Atributo← Atributo ∪ {(pkEnt, valor)INSERT INTO Atributo (pkEnt, valor)VALUES (pkEnt, val);

(c) Remoção de InstânciapkEnt← πpk( SELECT INTO pkEnt pkσEntidade.atrib1=val1(Entidade)) FROM Entidade


Atributo← Atributo - {(pkEnt, valor)DELETE FROM Atributo WHERE Atri-buto.pkEnt = pkEnt AND valor = val;

(c) Atualização de InstânciapkEnt← πpk( SELECT INTO pkEnt pkσEntidade.atrib1=val1(Entidade)) FROM Entidade


Atributo← πvalor←val

UPDATE Atributo SET valor = valWHERE Atributo.pkEnt = pkEnt ANDvalor = valNMod;

(σAtributo.pkEnt=pkEnt AND Atributo.valor=valNMod(Atributo))

Tabela B.3: Mapeamento das Operações CRUD sobre AtributoMultivalorado

Apêndice B 157

Código B.10 Stored Procedure Modelo para Obtenção de Instâncias de Atributo Multi-valorado

1 CREATE FUNCTION obterAtributoAtivo(val1 TipoSQL)


3 DECLARE

4 csr CURSOR;

5 pkEnt INTEGER;

6

7 BEGIN


9

10 SELECT valor FROM Entidade JOIN Atributo

11 ON Entidade.pk = Atributo.pkEnt WHERE Atributo.pkEnt = pkEnt;

12

13 RETURN csr;

14 END;


Código B.11 Stored Procedure Modelo para Inserção de Instância de Atributo Multival-orado

1 CREATE FUNCTION inserirAtributo(val1 TipoSQL,

2 val TipoSQL) RETURNS BOOLEAN AS’

3 DECLARE

4 pkEnt INTEGER;

5

6 BEGIN



9

10 INSERT INTO Atributo (pkEnt, valor)

11 VALUES (pkEnt, val);

12

13 RETURN TRUE;

14 END;


Apêndice B 158

Código B.12 Stored Procedure Modelo para Remoção de Instância de Atributo Multival-orado

1 CREATE FUNCTION desativarAtributo(val1 TipoSQL,

2 val TipoSQL) RETURNS BOOLEAN AS’

3 DECLARE

4 pkEnt INTEGER;

5

6 BEGIN



9

10 DELETE FROM mnmonicoAtributo

11 WHERE Atributo.pkEnt = pkEnt AND valor = val;

12

13 RETURN TRUE;

14 END;


Código B.13 Stored Procedure Modelo para Atualização de Instância de Atributo Multi-valorado

1 CREATE FUNCTION atualizarAtributo(val1 TipoSQL,

2 valNMod TipoSQL, val TipoSQL) RETURNS BOOLEAN AS’

3 DECLARE

4 pkEnt INTEGER;

5

6 BEGIN


8

9 UPDATE Atributo SET valor = val

10 WHERE Atributo.pkEnt = pkEnt AND valor = valNMod;

11

12 RETURN TRUE;

13 END;


APÊNDICE CLista de Abreviaturas e Siglas

• CRUD - Create, Read, Update e Delete ou Criar, Ler, Atualizar e Remover.• DBA - Database Administrator - Administrador de Banco de Dados.• EBD - Especialista em Banco de Dados.• IDE - Integrated Development Environment ou Ambiente de Desenvolvimento

Integrado.• MDD - Model Driven Development ou Desenvolvimento Dirigido por Modelos.• MER - Modelo Entidade-Relacionamento.• MMO - Modelo de Meta-Objetos.• MR - Modelo Relacional.• ORM - Object Relational Mapping ou Mapeamento Objeto Relacional.• PIM - Platform Independent Model ou Modelo Independente de Plataforma.• PSM - Platform Specific Model ou Modelo Específico de Plataforma.• SGBD - Sistema Gerenciador de Banco de Dados.• SI - Sistema de Informação.• SIA - Sistemas Integrados para Agronegócio.

um componente para geração e evolução de esquemas de

Documents