U NIVERSIDADE F EDERAL DE G OIÁS
I NSTITUTO DE I NFORMÁTICA
A LEXANDRE C LÁUDIO DE A LMEIDA
Um Componente para Geração e
Evolução de Esquemas de Bancos de
Dados como Suporte à Construção de
Sistemas de Informação
Goiânia
2010
U NIVERSIDADE F EDERAL DE G OIÁS
I NSTITUTO DE I NFORMÁTICA
AUTORIZAÇÃO PARA P UBLICAÇÃO DE D ISSERTAÇÃO
EM
F ORMATO E LETRÔNICO
Na qualidade de titular dos direitos de autor, AUTORIZO o Instituto de Informática da Universidade Federal de Goiás – UFG a reproduzir, inclusive em outro formato
ou mídia e através de armazenamento permanente ou temporário, bem como a publicar na
rede mundial de computadores (Internet) e na biblioteca virtual da UFG, entendendo-se
os termos “reproduzir” e “publicar” conforme definições dos incisos VI e I, respectivamente, do artigo 5o da Lei no 9610/98 de 10/02/1998, a obra abaixo especificada, sem que
me seja devido pagamento a título de direitos autorais, desde que a reprodução e/ou publicação tenham a finalidade exclusiva de uso por quem a consulta, e a título de divulgação
da produção acadêmica gerada pela Universidade, a partir desta data.
Título: Um Componente para Geração e Evolução de Esquemas de Bancos de Dados
como Suporte à Construção de Sistemas de Informação
Autor(a): Alexandre Cláudio de Almeida
Goiânia, 22 de Novembro de 2010.
Alexandre Cláudio de Almeida – Autor
Dr. Juliano Lopes de Oliveira – Orientador
A LEXANDRE C LÁUDIO DE A LMEIDA
Um Componente para Geração e
Evolução de Esquemas de Bancos de
Dados como Suporte à Construção de
Sistemas de Informação
Dissertação apresentada ao Programa de Pós–Graduação do
Instituto de Informática da Universidade Federal de Goiás,
como requisito parcial para obtenção do título de Mestre em
Nome do Programa de Pós-Graduação.
Área de concentração: Engenharia de Software.
Orientador: Prof. Dr. Juliano Lopes de Oliveira
Goiânia
2010
A LEXANDRE C LÁUDIO DE A LMEIDA
Um Componente para Geração e
Evolução de Esquemas de Bancos de
Dados como Suporte à Construção de
Sistemas de Informação
Dissertação defendida no Programa de Pós–Graduação do Instituto de
Informática da Universidade Federal de Goiás como requisito parcial
para obtenção do título de Mestre em Nome do Programa de PósGraduação, aprovada em 22 de Novembro de 2010, pela Banca Examinadora constituída pelos professores:
Prof. Dr. Juliano Lopes de Oliveira
Instituto de Informática – UFG
Presidente da Banca
Prof. Dr. Plínio de Sá Leitão Júnior
Instituto de Informática - UFG
Prof. Dr. Ronaldo dos Santos Mello
Departamento de Informática e de Estatística - UFSC
Todos os direitos reservados. É proibida a reprodução total ou parcial do
trabalho sem autorização da universidade, do autor e do orientador(a).
Alexandre Cláudio de Almeida
Graduou–se em Ciência da Computação na UFG - Universidade Federal de
Goiás. Durante o Mestrado, na UFG, foi bolsista do CNPq e desenvolveu
pesquisa empírica na área de Sistema de Informação com estudo de caso
em Sistema de Informação Agropecuário, sob orientação do Prof. Dr. Juliano
Lopes de Oliveira.
Dedico este trabalho aos meus pais, Antônio Carlos e Madalena, pelo apoio
incondicional e por acreditarem no meu potencial.
Agradecimentos
Agradeço primeiramente a Deus por me dar força e saúde para completar este
trabalho.
Aos meus pais, Antônio Carlos e Madalena, pelo incentivo e apoio não só no
periodo do mestrado mas em toda minha vida.
Ao meu orientador, Prof. Juliano Lopes de Oliveira, pelo incentivo, pela ajuda
em criar o corpo de conhecimento adquirido até aqui e por ser uma fonte de inspiração
como pessoa, não só na computação, mas na vida.
Aos meus irmãos, Adriano e André, pela amizade e por estar sempre junto nos
momentos bons e principalmente nos difíceis.
Aos amigos de mestrado, Glauber Boff, Wilane Carlos, Patrícia Gomes, Fabiana
Freitas, Valdemar Neto, Luiz Loja, Sofia Larissa e Victor Ribeiro pela ajuda e companheirismo durante o período do mestrado.
Aos professores do Instituto de Informática da UFG pela aprendizado.
Aos funcionários do Instituto de Informática da UFG, João Bosco Carmo Moraes
e Enio Perez Rodrigues, Edir de Jesus Borges Pinto, Justiniana César da Silva e principalmente para Berenice Vieira Silva pelo carinho e presteza durante todo o periódo de
graduação e mestrado.
Ao CNPq pelo apoio financeiro.
A mente que se abre a uma nova ideia jamais voltará ao seu tamanho
original.
Albert Einstein,
.
Resumo
Cláudio de Almeida, Alexandre. Um Componente para Geração e Evolução
de Esquemas de Bancos de Dados como Suporte à Construção de Sistemas
de Informação. Goiânia, 2010. 159p. Dissertação de Mestrado. Instituto de
Informática, Universidade Federal de Goiás.
Um Sistema de Informação (SI) Corporativo tem três aspectos principais: o banco de
dados, que contém dados que são processados para gerar informações do negócio; as
funções de aplicação, que transformam dados em informações; e as regras de negócio,
que controlam e restringem a manipulação dos dados pelas funções. Um SI precisa
evoluir continuamente para acompanhar as mudanças na corporação e, consequentemente,
o banco de dados deve ser modificado para atender aos novos requisitos de negócio.
Esta dissertação apresenta uma abordagem dirigida por modelos para a automatização
do processo de transformação na geração e evolução de bancos de dados de Sistema de
Informação. Para isso foi criado um componente de software denominado Especialista em
Banco de Dados (EBD). Dois conjuntos de mapeamentos são apresentados para a geração
de esquemas, um do modelo conceitual chamado Modelo de Meta Objeto (MMO),
utilizado para representação de SI, para o Modelo Relacional; e deste para o dialeto
SQL do SGBD PostgreSQL. O componente EBD faz parte de um framework que gera,
evolui e gerencia Sistemas de Informação. Este componente fornece também serviços para
outros componentes deste framework. Uma experimentação foi feita com engenheiros de
software com experiência em desenvolvimento de Sistema de Informação para validar a
abordagem proposta. As principais contribuições desta dissertação são: abordagem que
apoia ciclo de vida de BD de SI, arquitetura de software que permite a geração e evolução
de esquema de SI, especificação de um modelo de representação de dados de SI (MMO),
especificação de mapeamentos para geração de esquema e procedimentos de manipulação
e definição de um conjunto de operações que automatizam o processo de evolução de
esquema de BD de SI.
Palavras–chave
Sistema de Informação, Banco de Dados, Desenvolvimento Dirigido por Modelo
Abstract
Cláudio de Almeida, Alexandre. A Component to Generate and Evolve
Database Schema Supporting Information Systems Constrution. Goiânia,
2010. 159p. MSc. Dissertation. Instituto de Informática, Universidade Federal
de Goiás.
An Information System (IS) has three main aspects: a database that contains data which
is processed to generate business information; an application functions which transforms
data in information; and business rules which control and restrict data manipulated by
the functions. An IS evolves continuously to follow the corporation changes, and the
database should be change to attend the new requirements. This dissertation presents
a model driven approach to generate and evolve IS databases. A software component,
called Especialista em Banco de Dados (EBD), was developed. There are two mapping
sets for database generation: from Modelo de Meta Objeto (MMO) (used to representing
IS) to Relational Model (RM), and from this to DBMS PostgreSQL SQL dialect. The
component EBD is a part of a framework for modeling, building and maintaining enterprise information systems software. This component provides services to other framework
components. To validate the proposed approach, Software Engineers had developed IS using the component EBD. The Dissertation main contributions are an approach to support
IS database life cycle, a software architecture to generate and evolve IS database schema,
an IS data representation model (MMO), a mapping specification to generate schema and
stored procedures and the definition of automated operation sets to evolve IS database
schema.
Keywords
Information System, Database, Model Driven Development (MDD)
Sumário
Lista de Figuras
12
Lista de Tabelas
13
Lista de Códigos de Programas
15
1
16
16
17
18
19
19
Introdução
1.1
Ciclo de Vida de Sistemas de Informação
1.1.1
1.2
1.3
1.4
2
Motivação e Objetivos do Trabalho
Metodologia da Pesquisa Desenvolvida
Organização do Trabalho
Desenvolvimento Dirigido por Modelo em Bancos de Dados
2.1
2.2
2.3
3
Desafios e Soluções da Abordagem MDD
Desenvolvimento de Bancos de Dados e MDD
Comparação de Ferramentas MDD para BD
Arquitetura do Componente EBD - Especialista em Banco de Dados
3.1
3.2
Arquitetura do Framework
Modelo de Representação de Dados de SI - MMO
3.2.1
3.3
4
Banco de Dados em SI
Tipos de Atributo no MMO
Arquitetura dos Componentes de Transformação
3.3.1
Serviços de Acesso a Dados
3.3.2
Serviços de Geração de Esquema
3.3.3
Serviços de Evolução de Esquema
3.3.4
Serviço de Metadados e Dados de Entidade
Transformações entre Modelos
4.1
4.2
Mapeamentos do MMO para MR
4.1.1
Mapeamento de Entidades e Hierarquia de Especialização
4.1.2
Mapeamento de Tipos de Relacionamento (Objeto Interno)
4.1.3
Mapeamento de Entidade Fraca
4.1.4
Mapeamento de Atributo Multivalorado
Geração de DML para Operações CRUD
4.2.1
DML para Tipo de Entidade
4.2.2
DML para Tipo de Entidade Especializada
4.2.3
DML para Objeto Interno
4.2.4
DML para Tipo de Entidade Fraca
21
21
23
25
29
29
31
33
35
35
36
37
39
42
42
42
44
46
48
49
49
51
54
60
4.3
5
4.2.5
DML para Atributo Composto
4.2.6
DML para Atributo Simples Multivalorado
Mapeamento do MR para PostgreSQL
4.3.1
Geração de Tabelas
4.3.2
Geração de Stored Procedures (SP) em PL/pgSQL
Funcionamento do Componente EBD
5.1
5.2
Criação de Sistema de Informação
Utilização do Sistema de Informação
5.2.1
Operações CRUD
Inserção de Instância de uma Entidade
Obtenção de Instância de uma Entidade
Atualização de Instância de uma Entidade
Remoção de Instância de uma Entidade
5.3
Exemplo: SI para o Agronegócio
5.3.1
6
Aplicações de Mapeamentos na Evolução de Esquemas
6.1
6.2
6.3
6.4
7
Tipos de mudanças permitidas no esquema MMO
6.1.1
Mudanças de Tipo e Domínio de Atributo
6.1.2
Mudanças na chave lógica e no tipo de entidade
6.1.3
Mudanças em outras meta-informações
Mecanismo para Evolução de Esquema de BD
Evolução do Sistema de Informação
Exemplos de Evolução de Esquema
Experimentação do Componente EBD
7.1
7.2
7.3
8
Exemplos de Geração de Esquema
Metodologia
Coleta de Dados
Análise dos Resultados
Conclusões
8.1
8.2
8.3
Considerações Finais
Contribuições
Trabalhos Futuros
62
62
65
65
69
89
89
90
91
92
95
95
97
100
100
112
112
112
114
116
120
122
123
126
126
127
128
131
131
132
133
Referências Bibliográficas
135
A
141
141
141
142
143
Protocolo para Avaliação da Ferramenta EBD
A.1
A.2
A.3
A.4
B
Objetivos da Avaliação
Procedimentos da Avaliação
Questionário
Modelo Conceitual de uma Empresa
Mapeamentos do Modelo Relacional para SQL (PostgreSQL)
B.1
B.2
B.3
Entidade Fraca
Atributo Composto
Atributo Simples Multivalorado
146
146
151
155
C Lista de Abreviaturas e Siglas
159
Lista de Figuras
2.1
Transformação entre modelos (Adaptado de [43])
22
3.1
3.2
30
3.3
3.4
3.5
3.6
3.7
Arquitetura Funcional do Framework (adaptada de [21])
Metamodelo para representação conceitual de SI - Modelo de MetaObjetos (MMO) [22]
Arquitetura do Componente de Geração de Esquema
Arquitetura do Componente de Evolução de Esquema
Classe Metadados
Representação Gráfica de uma Instância de ObjetoApresentacao
Classe ObjetoApresentacao
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Mapeamento de Atributo Enumerado do MMO para o MR
Mapeamento de Hierarquia de Especialização do MMO para o MR
Mapeamento de Atributo Objeto Interno do MMO para o MR
Mapeamento do Atributo Objeto Interno (Agregação) do MMO para o MR
Mapeamento de Entidade Fraca do MMO para o MR
Mapeamento de Atributo Multivalorado do MMO para o MR
Mapeamento de Atributo Composto do MMO para o MR
44
45
45
47
47
48
48
32
37
38
40
41
41
Formulário para Cadastro de Tipo de Entidade do SI
90
Formulário para Cadastro de Atributo de Tipo de Entidade do SI
91
Exemplo de Tela de Manipulação de Pessoa Física gerada pelo framework 92
Modelo Estático das Classes Envolvidas nas Operações CRUD
93
Colaboração para mapeamento Objeto-Relacional na operação de Inserção 94
Colaboração para mapeamento Objeto-Relacional na operação de Consulta 96
Colaboração para mapeamento Objeto-Relacional na operação de Atualização
98
5.8 Colaboração para mapeamento Objeto-Relacional na operação de remoção 99
5.9 Modelo Conceitual Simplificado - Conceito de "Animal"
100
5.10 Modelo Conceitual Simplificado - Conceito de "Cor de Pelo de Animal"
107
5.1
5.2
5.3
5.4
5.5
5.6
5.7
113
115
6.4
6.5
6.6
Mudanças Possíveis em Tipo/Domínio de um Atributo
Mudanças possíveis no tipo de entidade
Colaboração no Mecanismo de Verificação e Adaptação para Evolução
de Esquema
Interface para Modificação das Instâncias da Entidade
Ligação das instâncias de Animal com Propriedade Rural
Modificação da Chave das Instâncias da Entidade Pessoa Física
A.1
Modelo Conceitual de Empresa (adaptado de [55])
145
6.1
6.2
6.3
120
121
124
125
Lista de Tabelas
2.1
Tabela de Comparação de Ferramentas ORM
28
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
Mapeamento de Entidades e Hierarquia de Entidades do MMO para o MR
Conversão de Tipo/Domínio do MMO para MR
Mapeamento de Objeto Interno do MMO para o MR
Mapeamento do Atributo Simples Multivalorado do MMO para o MR
Mapeamento do Atributo Composto Multivalorado do MMO para o MR
Operações CRUD sobre Tipo de Entidade
Operações CRUD sobre Tipo de Entidade Especializada
Operações CRUD sobre Atributo Objeto Interno
Obtenção de Instâncias de Atributo Objeito Interno (Agregação)
Operações CRUD sobre Entidade Fraca
Operações CRUD sobre Atributo Composto
Operações CRUD sobre Atributo Multivalorado
Conversão de Tipo/Domínio do MR para SQL
Mapeamento de Relação "Entidade" do MR para SQL
Mapeamento de Relação "Atributo Objeto Interno" do MR para o SQL
Mapeamento de Relação "Atributo Multivalorado" do MR para SQL do
PostgreSQL
Mapeamento de Relação "Atributo Composto" do MR para o SQL do
PostgreSQL
Mapeamento de Operações CRUD sobre Tipo de Entidade
Mapeamento de Operações CRUD sobre Tipo de Entidade Especializada
Mapeamento de Operações CRUD sobre Atributo Objeto Interno
Mapeamento de Operações CRUD sobre Atributo Objeito Interno (Agregação)
43
43
46
48
49
50
53
55
57
61
63
64
65
66
67
Tempos de Execução da Experimentação
Tempo de Desenvolvimento e Quantidade de Erros
Tempo de Desenvolvimento e Produtos Gerados
Respostas do Questionário de Avaliação da Experimentação da Ferramenta EBD
128
128
128
A.1
Dicionário do Esquema de Empresa
144
B.1
B.2
B.3
Mapeamento de Operações CRUD sobre Tipo de Entidade Fraca
Mapeamento de Operações CRUD sobre Atributo Composto
Mapeamento das Operações CRUD sobre Atributo Multivalorado
146
151
156
4.17
4.18
4.19
4.20
4.21
7.1
7.2
7.3
7.4
68
68
71
75
78
83
128
Lista de Códigos de Programas
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
5.1
5.2
5.3
Obtenção de Lista de Atributos Simples de uma Hierarquia de Especialização
52
Tabela Modelo em PostgreSQL
65
Tabela Modelo para Criação de Atributo Objeto Interno
67
Modelo de Stored Procedure em PL/pgSQL
69
Stored Procedure Modelo para Obtenção de Instâncias de Tipo de Entidade 70
Stored Procedure Modelo para Inserção de Instância de Tipo de Entidade 72
Stored Procedure Modelo para Remoção de Instância de Tipo de Entidade 72
Stored Procedure Modelo para Atualização de Instância de Tipo de Entidade 73
Stored Procedure Modelo para Obtenção de Instâncias de Tipo de Entidade Especializada
74
Stored Procedure Modelo para Inserção de Instância de Tipo de Entidade
Especializada
76
Stored Procedure Modelo para Remoção de Instância de Tipo de Entidade
Especializada
76
Stored Procedure Modelo para Atualização de Instância de Tipo de Entidade Especializada
77
Stored Procedure Modelo para Obtenção de Instâncias de Atributo Objeto
Interno
80
Stored Procedure Modelo para Inserção de Instância de Atributo Objeto
Interno
81
Stored Procedure Modelo para Remoção de Instância de Atributo Objeto
Interno
82
Stored Procedure Modelo para Atualização de Instância de Atributo
Objeto Interno
83
Stored Procedure Modelo para Obtenção de Instâncias de Atributo Objeto
Interno (Agregacao)
86
Stored Procedure Modelo para Inserção de Instância de Atributo Objeto
Interno (Agregação)
86
Stored Procedure Modelo para Remoção de Instância de Atributo Objeto
Interno (Agregação)
87
Stored Procedure Modelo para Atualização de Instância de Atributo
Objeto Interno (Agregação)
87
Tabela da Entidade Animal de Propriedade
101
Stored Procedure para Obtenção de Instâncias da Entidade Animal de
Propriedade
102
Stored Procedure para Obtenção de Instância da Entidade Animal de
Propriedade
103
5.4
5.5
5.6
5.7
5.8
5.9
5.10
B.1
B.2
B.3
B.4
B.5
B.6
B.7
B.8
B.9
B.10
B.11
B.12
B.13
Stored Procedure para Inserção de Instância da Entidade Animal de
Propriedade
104
Stored Procedure para Remoção de Instância da Entidade Animal de
Propriedade
105
Stored Procedure para Atualização de Instância da Entidade Animal de
Propriedade
106
Tabela do Atributo Objeto Interno Cor de Pelo Animal
108
Stored Procedure para Obtenção de Instâncias do Atributo Objeto Interno
Cor de Pelo Animal
109
Stored Procedure para Inserção de Instância do Atributo Objeto Interno
Cor de Pelo Animal
110
Stored Procedure para Remoção de Instância do Atributo Objeto Interno
Cor de Pelo Animal
111
Stored Procedure Modelo para Obtenção de Instâncias de Tipo de Entidade Fraca
149
Stored Procedure Modelo para Obtenção de Instância de Tipo de Entidade
Fraca
149
Stored Procedure Modelo para Inserção de Instância de Tipo de Entidade
Fraca
150
Stored Procedure Modelo para Remoção de Instância de Tipo de Entidade
Fraca
150
Stored Procedure Modelo para Atualização de Instância de Tipo de Entidade Fraca
151
Stored Procedure Modelo para Obtenção de Instâncias de Atributo Composto
153
Stored Procedure Modelo para Inserção de Instância de Atributo Composto 154
Stored Procedure Modelo para Remoção de Instância de Atributo Composto154
Stored Procedure Modelo para Atualização de Instância de Atributo
Composto
155
Stored Procedure Modelo para Obtenção de Instâncias de Atributo Multivalorado
157
Stored Procedure Modelo para Inserção de Instância de Atributo Multivalorado
157
Stored Procedure Modelo para Remoção de Instância de Atributo Multivalorado
158
Stored Procedure Modelo para Atualização de Instância de Atributo
Multivalorado
158
CAPÍTULO 1
Introdução
Sistemas de Informação apoiam a execução de processos de negócio e estão presentes em todos os tipos de organizações. Eles têm importância tanto no nível operacional,
automatizando e controlando as atividades organizacionais, quanto no nível estratégico,
possibilitando o gerenciamento de riscos e apoiando a tomada de decisões.
Este capítulo apresenta a motivação, os objetivos e a metodologia do trabalho
de criação de um componente de persistência de dados para um framework que apoia a
geração e evolução de Sistemas de Informação.
1.1
Ciclo de Vida de Sistemas de Informação
Um Sistema de Informação (SI) envolve diversos elementos, com destaque
para: software, bancos de dados, pessoas, documentação, hardware e procedimentos. O
software compreende programas de aplicação e software básico. Pessoas gerenciam e
operam o sistema. Bancos de dados (BD) são coleções de dados relacionados ao negócio.
A documentação abrange textos informativos e manuais de operação de sistema. Os
procedimentos definem o comportamento do SI na organização. O hardware envolve
computadores e dispositivos para processamento e transmissão de informações.
Normalmente o ciclo de vida de um SI envolve três fases [44]: a concepção
contempla atividades de análise do sistema, planejamento do projeto e análise de requisitos; a construção inclui atividades de projeto de software, implementação e testes; e a
manutenção envolve atividades de correção, adaptação e evolução do sistema.
Na fase de concepção são definidas necessidades, capacidades, características
ou fatores de qualidade de um sistema. Nesta fase são identificandos os stakeholders (são
todos os interessados no resultado de um projeto de software, por exemplo, gerente de
negócio, usuários finais e pessoal de apoio), obtendo destes o entendimento a respeito das
necessidades para o sistema planejado e suas expectativas com relação a este sistema.
Na fase de construção é elaborada e realizada uma estratégia para atender às
necessidades e características definidas para o sistema. Uma das atividades desta fase é a
codificação, que envolve a tradução do projeto dos componentes de software e de BD para
1.1 Ciclo de Vida de Sistemas de Informação
17
linguagens de implementação. Os testes são feitos para garantir que todas as necessidades
descritas na fase de concepção foram implementadas e que o sistema funciona de acordo
com o que foi previsto pelos stakeholders.
Na fase de manutenção são feitas correções, adaptações e inserções de novos
requisitos no sistema desenvolvido. Todas as fases anteriores são repetidas para incorporar
estas alterações.
1.1.1
Banco de Dados em SI
O componente de bancos de dados possui ciclo de vida em três fases, análogo
aos demais componentes do SI. A fase de Análise de Requisitos do SI provê informações
para elaborar o projeto conceitual dos bancos de dados. Essas informações incluem, por
exemplo, os grupos de usuários que utilizam certas funcionalidades da aplicação (visões),
o fluxo de informação do sistema (determinando os serviços providos pelo sistema de
bancos de dados) e as prioridades de usuários em relação a estes serviços. Erros nesta
fase levam ao retrabalho e ao aumento do custo de desenvolvimento [69].
O projeto conceitual de banco de dados pode ser dividido em duas etapas:
Projeto Conceitual do Esquema do BD e Projeto das Aplicações do BD. De acordo
com os requisitos identificados na análise é criado um esquema conceitual do Banco de
Dados. Este esquema é constituído de elementos e seus relacionamentos, de acordo com
o domínio do conhecimento que está sendo modelado.
Assim, o modelo conceitual de BD é uma descrição, em alto nível, de uma porção
do domínio de negócio, de forma independente de Sistema Gerenciador de Bancos de
Dados (SGBD). Esta descrição utiliza, em geral, linguagens de modelagem conceitual
como Entity-Relationship Model (ERM) [16], Unified Modeling Language (UML) [48] e
Object-Role Modeling (ORM) [33].
O projeto de aplicações identifica as aplicações necessárias para manipular
os dados definidos na modelagem conceitual. Essas aplicações envolvem, em geral,
operações básicas para manipulação das entidades do domínio do negócio. Tais operações
são conhecidas como operações CRUD (Criar, Ler, Atualizar e Remover - Create, Read,
Update e Delete). Operações mais complexas podem ser definidas, tanto para modificação
quanto para recuperação de informações armazenadas no banco de dados.
Uma atividade necessária para construção de bancos de dados é a escolha do
SGBD. Alguns aspectos que precisam ser levados em conta nesta escolha incluem: fatores econômicos, como o custo da aquisição do SGBD, treinamento da equipe de desenvolvimento, suporte técnico e manutenção; e fatores técnicos, como o tipo de SGBD
(Semi-Estruturado, Relacional, Orientado a Objeto), ferramentas para desenvolvimento,
linguagens de consulta de alto nível, entre outros.
1.2 Motivação e Objetivos do Trabalho
18
Depois da escolha do SGBD é feito o mapeamento do esquema conceitual, que
é independente de tecnologia, para o modelo operacional do SGBD. Esta etapa tem como
produto o mapeamento do esquema conceitual do BD para a linguagem de definição de
dados (DDL - Data Definition Language) do SGBD alvo. Aspectos de processamento
mais específicos, como taxa de processamento, tempo de resposta em transações e espaço
de armazenamento, são considerados no projeto operacional do banco de dados.
Depois de implementado o esquema do BD no SGBD, o banco de dados é
populado e as transações de manipulação de dados são criadas utilizando a linguagem
de manipulação de dados (DML - Data Manipulation Language) do SGBD.
A medida que o SI é utilizado são identificadas necessidades de manutenção
do banco de dados devido a fatores como mudança de requisitos, falta de eficiência das
operações do banco de dados ou mudança de SGBD.
A geração e a evolução de esquemas de BD consomem uma grande parte do
esforço alocado para o desenvolvimento do SI. A manutenção de bancos de dados é
particularmente complexa, pois ela tem potencial para impactar um grande número de
programas e regras de negócio em um Sistema de Informação.
1.2
Motivação e Objetivos do Trabalho
De acordo com [6, 30], o processo de desenvolvimento de software pode ser
formalizado em um conjunto de tranformações que levam à produção eficiente de software. Um dos desafios da Engenharia de Software é a especificação de transformações
formais de informações obtidas no projeto de software em programas, e a construção de
ferramentas que apoiam estas transformações.
Estas definições podem ser estendidas para o desenvolvimento de bancos de
dados em SI. No processo de criação do esquema do banco de dados de um SI são
definidas transformações do modelo conceitual para o modelo operacional do SGBD,
e deste para o modelo físico, de acordo com a plataforma computacional.
Transformações também são definidas para modificações do esquema conceitual
que levam a um conjunto de operações nos esquemas operacionais e físicos. Tais transformações devem ser regidas por regras que preservam a consistência dos dados armazenados
no esquema modificado.
Este trabalho tem como foco a definição de uma abordagem que apoie o ciclo
de vida de bancos de dados em SI. Tendo em vista a complexidade de criação de
ferramentas de BD que implementem estas tranformações de forma integrada com os
demais componentes de SI, este trabalho especifica necessidades e propõe uma solução
para geração e evolução de BD em SI.
1.3 Metodologia da Pesquisa Desenvolvida
19
Para isso o trabalho descreve o desenvolvimento de um componente de persistência de dados para um framework que gera, evolui e mantém SI. Este componente é denominado Especialista em Banco de Dados (EBD). A abordagem proposta utiliza o Desenvolvimento Dirigido por Modelo (MDD) [31] para criação e evolução de esquemas de
BD, e de operações CRUD que manipulam informações do SI. Além disso, o componente
oferece serviços: para acesso a dados e para manipulação de metadados do SI.
1.3
Metodologia da Pesquisa Desenvolvida
A primeira fase deste projeto incluiu atividades de pesquisa bibliográfica sobre
a abordagem MDD e a análise de ferramentas baseadas nesta abordagem. O objetivo foi
identificar requisitos necessários para o desenvolvimento deste projeto.
Ferramentas de Bancos de Dados e frameworks para mapeamento objeto relacional (ORM) foram analisadas com intuito de verificar os benefícios e limitações de
cada uma delas.
Após a definição de requisitos, foi feito o projeto e a implementação dos
mecanismos de geração, evolução de esquema e serviços de persistência de conceitos
do SI.
Em seguida foram feitos testes e integração com os demais componentes do
framework de suporte à construção de SI. O esquema de um SI de grande porte foi
gerado utilizando a arquitetura desenvolvida neste trabalho, com o propósito de avaliar
empiricamente as propostas.
Na última fase deste projeto foram feitos experimentos para validação da abordagem proposta. Estes experimentos contaram com a participação de desenvolvedores de
SI para criar um esquema de BD com base na ferramenta implementada neste projeto.
1.4
Organização do Trabalho
O Capítulo 2 analisa os conceitos de MDD e sua aplicação no desenvolvimento
e evolução de esquemas de BD. O capítulo também compara a abordagem proposta neste
trabalho com as ferramentas encontradas na primeira fase da pesquisa.
O Capítulo 3 apresenta a arquitetura do componente proposto no contexto
do framework para geração e evolução de SI, descrevendo o metamodelo utilizado na
representação de dados de SI.
O Capítulo 4 descreve um conjunto de padrões de mapeamento do metamodelo
adotado para o MR, e deste para um dialeto específico de SQL, para geração e evolução
de esquemas de BD de SI. O SGBD PostgreSQL [53] e sua linguagem procedural
(PL/pgSQL) são utilizados nestes mapeamentos.
1.4 Organização do Trabalho
20
O Capítulo 5 discute a criação e utilização de SI com base na proposta deste
trabalho. Além disso, o capítulo apresenta exemplos reais de utilização da arquitetura
implementada para geração de esquema em um SI para o Agronegócio.
O Capítulo 6 discute a aplicação de mapeamentos na evolução de esquema
propostos neste trabalho. Também são apresentados exemplos reais de evolução de
esquema em um SI para o Agronegócio.
O Capítulo 7 discute a validação empírica da proposta deste trabalho. Para isto,
o capítulo analisa a metodologia e os dados coletados em um experimento de utilização
do componente.
O Capítulo 8 apresenta as considerações finais deste trabalho de pesquisa,
propondo extensões e direções para trabalhos futuros.
CAPÍTULO 2
Desenvolvimento Dirigido por Modelo em
Bancos de Dados
O Desenvolvimento Dirigido por Modelo (Model-Driven Development - MDD)
é uma das propostas recentes que têm obtido resultados significativos para diminuir a
dificuldade na manutenção de SI [31]. Esta abordagem especifica conceitos relevantes
do domínio da aplicação, incluindo regras de negócio, relacionamentos e semântica de
dados, usando linguagens de modelagem de alto nível e independentes de plataforma,
para representar o sistema a ser criado.
Este capítulo discute os desafios e soluções da abordagem MDD aplicada a BD.
Ele também apresenta uma comparação entre ferramentas que utilizam esta abordagem e
o componente proposto neste trabalho.
2.1
Desafios e Soluções da Abordagem MDD
Tradicionalmente, as equipes de desenvolvimento e manutenção de software
compartilham os seguintes desafios [43, 45]:
1. Documentação Inconsistente - O processo de desenvolvimento de software produz
grande quantidade de documentação. Esta documentação rapidamente perde seu
valor, pois ao invés de ser uma exata especificação do código, os diagramas
geralmente tornam-se apenas figuras relacionadas ao código. Isso acontece porque
geralmente as modificações são feitas apenas no código fonte, já que atualizar toda
a documentação exige tempo que na maioria das vezes não está disponível.
2. Mudanças Frequentes de Tecnologia - Novas tecnologias aparecem de forma
muito rápida. Empresas que dependem destas tecnologias devem mudar antes que
ela fique obsoleta.
3. Interoperabilidade - Os sistemas não podem ser desenvolvidos de maneira isolada.
Eles devem ser desenvolvidos como componentes de software que se comunicam
com outros sistemas, de forma que a adaptação ou correção do sistema, ou mesmo
a inserção de novos requisitos de negócio, se torne mais fácil.
2.1 Desafios e Soluções da Abordagem MDD
22
4. Falta de Compreensão sobre Documentação - A documentação de sistemas geralmente não é boa porque aqueles que estão envolvidos com o desenvolvimento do
sistema, principalmente os programadores, estão apenas preocupados com atividades inerentes a codificação, não tendo ideia de que a documentação auxilia em
manutenções futuras dos sistema.
O MDD permite especificar conceitos relevantes do domínio da aplicação usando linguagens de modelagem de alto nível de abstração. Com estas linguagens são
criados modelos do sistema independentemente da plataforma utilizada para a sua implementação. Modelos em UML, por exemplo, são o padrão de fato utilizado pela indústria
de software. Esses modelos de alto nível são chamados de PIM (Platform Independent
Model - Modelo Independente de Plataforma).
A ideia central do MDD é a transformação de modelos em código executável
usando processos de tradução automática. Cada processo de tradução executa a transformação de um modelo (ou aspecto) conceitual do sistema para modelos específicos para
uma determinada plataforma de implementação (PSM - Plataform Specific Model). Esses
modelos específicos são, por sua vez, automaticamente traduzidos para o código que implementa o sistema de informação. Esta ideia é representada na Figura 2.1.
Figura 2.1: Transformação entre modelos (Adaptado de [43])
Os modelos PIM, PSM e o código fonte representam diferentes níveis de abstração na especificação de um sistema. A capacidade de transformar um PIM em um
PSM aumenta o nível de abstração no qual o desenvolvedor pode trabalhar, facilitando o
desenvolvimento de sistemas. Os desenvolvedores que trabalham com modelos independentes de tecnologia possuem menos trabalho a fazer porque os detalhes específicos de
plataformas não precisam ser analisados e projetados; eles já são tratados na definição da
transformação do modelo independente para o modelo específico.
Na transformação do modelo específico para código fonte há muito menos
trabalho a ser feito, pois muito código já foi gerado a partir da transformação do modelo de
alto nível. Os desenvolvedores gastam menos tempo realizando codificação e utilizam o
tempo para se preocuparem com a modelagem do negócio. Dessa forma, o benefício para
os usuários finais é grande. No entanto, o ganho de produtividade é alcançado somente
com a utilização de ferramentas que realizam a transformação entre os modelos.
A utilização do PIM também aumenta a portabilidade do sistema, visto que esse
modelo pode ser transformado para vários modelos específicos voltados para plataformas
variadas. Caso apareçam novas tecnologias, devem ser desenvolvidas novas definições
2.2 Desenvolvimento de Bancos de Dados e MDD
23
de transformações do modelo independente para essas novas tecnologias. No entanto, o
modelo independente já existente não necessita sofrer qualquer modificação.
Dessa forma, o PIM representa a documentação em mais alto nível de um
sistema. Toda modificação que é feita no sistema deve ser primeiramente feita neste
modelo. Depois disso, o modelo específico deve ser gerado novamente, assim como o
código da aplicação. Logo, a documentação do sistema sempre será consistente com o
código atual.
Apesar dos benefícios da utilização da abordagem MDD, algumas dificuldades
são enfrentadas. A tradução automática provê padronização do código gerado e produtividade, mas existe o problema relacionado à eficiência. Por exemplo, um código gerado por
uma ferramenta de geração de esquema pode não ter a mesma eficiência de um código
criado por um DBA (Database Administrator - Administrador de Bancos de Dados) experiente.
Outra dificuldade está relacionada à criação da ferramenta de transformação.
Uma ferramenta para geração de um SI leva em conta aspectos como representação dos
dados, regras de negócio e interface com o usuário. Criar ferramentas para automatizar
este tipo de tarefa ainda é um desafio para a comunidade científica de computação.
2.2
Desenvolvimento de Bancos de Dados e MDD
Embora a abordagem MDD tenha sido proposta para resolver problemas de desenvolvimento e manutenção de software, os seus princípios também podem ser aplicados
no contexto de bancos de dados, já que estes são um componente importante de qualquer
software [25].
No processo de desenvolvimento de banco de dados são feitas transformações
do modelo conceitual para o modelo operacional do SGBD e, em seguida, para o
modelo físico da plataforma computacional. A transformação é uma maneira sistemática
de mapeamento entre modelos. No processo de desenvolvimento de banco de dados
é frequente a utilização deste recurso em várias atividades, tais como normalização
de esquema [56], integração de esquemas [10, 9, 46], interoperabilidade de banco de
dados [46], engenharia reversa de banco de dados [47, 27, 32, 39], evolução de esquema
[35, 24, 65, 66], otimização de esquema [34], e mapeamento Objeto-Relacional [64, 51].
Ao longo do tempo a comunidade científica e a indústria vêm criando ferramentas que suportam o desenvolvimento de SI. Especificamente para bancos de dados podem
ser destacadas as seguintes ferramentas:
• Mapeamento Objeto-Relacional (ORM - Object-Relational Mapping) - A criação
de aplicações de banco de dados, na maioria da vezes, é um trabalho entediante devido à grande quantidade de código semelhante e ao trabalho repetitivo executado.
2.2 Desenvolvimento de Bancos de Dados e MDD
24
Em consequência disso, tem-se alto risco de erros na aplicação desenvolvida. Uma
das soluções para estes problemas são as ferramentas ORM que têm por objetivo
a simplificação da criação do componente de acesso a dados. Ferramentas ORM
estabelecem uma ligação bidirecional entre os dados no banco de dados relacional
e os objetos no código de aplicações orientadas a objetos.
• Ambientes de Desenvolvimento Integrado (IDE - Integrated Development Environment) - são ferramentas utilizadas por desenvolvedores e administradores de BD,
como por exemplo a ferramenta BrModelo [17]. Elas possuem uma grande variedade de funcionalidades, tais como: geração do esquema de banco de dados a
partir do modelo conceitual, modelagem conceitual, criação de instruções de manipulação de dados, engenharia reversa, sincronização entre modelo operacional e
esquema físico, tuning de consultas e estatísticas do custo de execução de instrução
ou script.
Existe uma variedade de frameworks ORM. Eles são mais populares para a
linguagem Java [41, 1, 28, 3, 26, 67, 42, 2, 5], mas existem frameworks para outras
linguagens, como .NET [41, 60, 59, 63]. Recursos mais sofisticados, como importação de
modelos, geração de scripts, suporte a vários SGBDs, e criação de modelos com diferentes
níveis de abstração (conceitual, lógico e físico), são encontrados em diversas ferramentas
[20, 4, 29, 36, 62, 54, 15, 57]. Estas ferramentas utilizam informações de modelos
independentes de plataforma para automatizar operações como geração e evolução do
esquema e operações de mapeamento de objetos para tabelas no banco de dados.
Nos frameworks ORM para Java as meta-informações são armazenadas de
diversas formas: em arquivos XML [1, 41, 28, 3, 26, 67, 42, 2, 5]; em annotations
[41, 67, 5]; ou em instruções de JavaDoc, chamadas XDoclets [2].
Alguns IDEs utilizam o banco de dados como meio de armazenamento das metainformações, como descrito em [29]. A maioria deles, no entanto, armazena as metainformações em formato proprietário e faz a geração e evolução do esquema de banco de
dados indiretamente, usando scripts, ou diretamente, usando conexões do tipo ODBC ou
JDBC.
O framework proposto nesta dissertação e os IDEs compartilham várias funcionalidades, como geração de esquema e suporte a evolução, mas existe uma diferença
básica. O framework participa do fluxo de processamento de informações na execução do
SI, diferentemente dos IDEs, que são utilizados na fase de construção ou manutenção do
SI.
2.3 Comparação de Ferramentas MDD para BD
2.3
25
Comparação de Ferramentas MDD para BD
Os frameworks ORM utilizam informações de um modelo conceitual independente de plataforma para fazer os mapeamentos necessários para criação, evolução e utilização do esquema de BD de uma aplicação. Os frameworks armazenam estas informações em arquivos externos ou no código da aplicação.
Os frameworks Hibernate, Abra, Castor, Cayenne, Databind, OR Broker, OJB e
Ebean apresentados respectivamente em [41, 1, 28, 3, 26, 42, 2, 5] utilizam arquivos XML
para armazenamento externo das informações utilizadas no mapeamento. O framework
DB Visual Architect [67] armazena o modelo conceitual em arquivos criados pela própria
ferramenta. Em Java, os frameworks Hibernate e Ebean utilizam annotations [40]. Os
frameworks Hibernate e OJB utilizam XDoclet [68] para armazenar as meta informações
diretamente no código.
No componente EBD, proposto neste trabalho, o modelo conceitual do SI é armazenado no próprio BD. As vantagens desta abordagem estão diretamente relacionadas
às vantagens de utilizar SGBD para armazenamento de informações: segurança, suporte
a alto volume de uso e acesso restrito às informações armazenadas.
Mapeamentos em arquivos externos possuem a desvantagem de manipulação
de vários arquivos onde estão as informações das entidades do sistema e problemas
em relação ao entendimento da sintaxe utilizada para armazenar tais informações. Estes
problemas não são encontrados no mapeamento direto no código da aplicação, mas outros
problemas são observados. O código da aplicação pode ficar dependente do mapeamento
específico de um certo framework e mudanças no BD levam a mudanças no código da
aplicação, ferindo o princípio de independência de dados.
Os frameworks Cayenne e DB Visual Architect fornecem editores gráficos para
obtenção das informações das entidades do SI. A inferface gráfica facilita o trabalho
de criação dos arquivos externos, pois os usuários da ferramenta não se preocupam
com a sintaxe da linguagem utilizada para armazenar as meta informações. O EBD
fornece formulários de cadastro para facilitar o processo de obtenção das informações
de representação das entidades do SI.
É comum entre os principais frameworks ORM usar as informações do modelo
conceitual para geração do esquema do banco de dados. Em alguns deles o esquema não
é gerado automaticamente, como pode ser observado nos frameworks Databind e OR
Broker. Mesmo assim é necessária a criação do arquivo de mapeamento, pois este é usado
na execução do framework. O EBD utiliza os conceitos MDD para geração automática do
esquema do BD do SI.
Além do esquema, alguns frameworks geram instruções SQL dinâmicas para manipulação das instâncias das entidades persistentes. Para tornar a manipulação eficiente, os
2.3 Comparação de Ferramentas MDD para BD
26
frameworks Hibernate, Castor, DB Visual Architect, OR Broker, OJB e Ebean permitem
a manipulação de instâncias via procedimentos armazenados (stored procedures). Dentre
estes, somente os frameworks DB Visual Architect e Ebean geram automaticamente estes
procedimentos. No EBD a manipulação das instâncias de entidade é feita através de um
conjunto de stored procedures geradas a partir do modelo conceitual de SI.
Para permitir a modelagem de sistemas complexos, o modelo conceitual dos
frameworks deve permitir construções de hierarquias de especialização, tipos de relacionamentos e coleções de tipos de dados (inteiros, string, datas, entre outros).
A modelagem de hierarquia de especialização é permitida nos frameworks Hibernate, Abra, Cayenne, DB Visual Architect, OR Broker, OJB e Ebean. Os frameworks
Hibernate e OJB permitem a escolha do tipo de mapeamento para hierarquia de especialização. Por exemplo, o usuário pode optar por mapear todos os atributos de super classes
e sub classes para uma mesma tabela. Outra opção disponível é mapear cada classe da
hierarquia para uma tabela distinta. O EBD permite a modelagem e geração de hierarquia
de especialização, mas o mapeamento é restrito: cada classe da hierarquia é mapeada para
uma tabela. Este mapeamento é discutido em detalhes no Capítulo 4.
Assim como os frameworks Hibernate, Castor, Abra, Cayenne, DB Visual Architect, OR Broker, OJB e Ebean, o EBD permite mapeamentos de tipos de relacionamento
com cardinalidade 1:1, 1:N e N:M. No EBD, os tipos de relacionamentos são manipulados através de um conjunto de stored procedures. Já nos frameworksHibernate, Abra e
OJB a manipulação é feita através de SQL dinâmico.
O EBD permite a manipulação de coleções de strings, inteiros, decimais e datas.
Os frameworks Hibernate, Abra, Castor, Cayenne, OR Broker e OJB também permitem a
manipulação de coleções destes tipos.
Além de gerar automaticamente o esquema do BD da aplicação, os frameworks
Hibernate, Cayenne e DB Visual Architect disponibilizam mecanismos para evolução de
esquema. Mudanças feitas no modelo conceitual são propagadas para o modelo físico
e para os dados do sistema. O EBD também conta com um mecanismo que analisa e
propaga as mudanças feitas no esquema conceitual do SI para o modelo físico e para os
dados correspondentes.
Assim, o componente EBD conta com os recursos típicos dos frameworks ORM
encontrados no mercado, mas não oferece algumas funcionalidades específicas. Por
exemplo, o framework DB Visual Architect conta com funcionalidades para geração de
relatórios, análise de impacto de mudanças no BD e suporte às ferramentas de controle
de versão. Os frameworks Hibernate, Ebean, Cayenne e Abra permitem a criação de
consultas e gerenciamento de transação. Essas funções fogem do escopo funcional do
EBD.
A entrada das meta informações da entidade, no EBD, é feita por formulário
2.3 Comparação de Ferramentas MDD para BD
27
textual, mas teria melhor usabilidade se a criação do esquema fosse feita a partir de um
editor gráfico. Tais funcionalidades são importantes, mas não foram implementadas no
componente EBD devido à limitação do tempo para desenvolvimento deste trabalho.
Além de possuir funcionalidades semelhantes às dos frameworks discutidos
nesta seção, o componente EBD possui um diferencial que é a integração com um
framework maior, que gera o SI propriamente dito, e não apenas o esquema do BD [21].
O Capítulo 3 sintetiza as principais características deste framework e discute os detalhes
da arquitetura do componente EBD.
A Tabela 2.1 apresenta uma comparação entre frameworks ORM para a linguagem Java e o componente EBD, proposto neste trabalho. Os critérios de comparação
entre os frameworks são: (a) Suporte a Herança - define se o framework permite a criação de cadeia de especilização, (b) Tipos de Relacionamento - permite relacionamentos
entre as entidade definidas no framework, (c) Interface Gráfica para coleta das informações conceituais, (d) Gera Esquema automaticamente, (e) Propaga Mudanças - estabelece se o framework faz a propagação das mudanças realizadas no modelo conceitual,
(f) Suporte a Stored Procedure - estabelece se o framework suporta a manipulação do
dados de entidade via procedimentos armazenados, (g) Suporte a Coleções - estabelece
se o framework permite a manipulação de coleções de strings, inteiros, números de ponto
flutuante, datas, etc e (h) Ferramenta Livre - define se a ferramenta é livre ou não.
Tais critérios foram obtidos durante a pesquisa das ferramentas ORM que utilizam a abordagem MDD. As características mais importantes de cada ferramenta foram
definidas, logo após estas informações foram confrontadas obtendo um conjunto de características comuns e algumas específicas. Dentre estas características, as mais relaventes
deram origem aos critérios de comparação.
Este capítulo discutiu os desafios e soluções da abordagem MDD aplicada a
BD e apresentou uma comparação entre ferramentas que utilizam esta abordagem e o
componente proposto neste trabalho.
SIM
Annotations
XML e XDoclet
XML
Mapeamento
Relacionamento
SIM
Tipo de
Tipos de
SIM
SIM
SIM
NÃO
SIM
NÃO
SIM
SIM
SIM
NÃO
SIM
NÃO
SIM
NÃO
NÃO
NÃO
SIM
SIM
Esquema
Gera
NÃO
NÃO
Oferece GUI
para
Mapeamento
SIM
NÃO
–
–
SIM
NÃO
SIM
–
NÃO
SIM
Mudanças
Propaga
Tabela 2.1: Tabela de Comparação de Ferramentas ORM
Abra
SIM
SIM
0.9.9 [1]
Castor
NÃO
SIM
XML
1.3.1 [28]
Cayenne
SIM
SIM
XML
3.0 [3]
Databind
–
NÃO
XML
0.4 [26]
DVA
SIM
SIM
Arquivo
5.2 [67]
próprio
OR Bro- SIM
SIM
XML
ker
2.0.3 [42]
OJB
SIM
SIM
XML e
1.0.4 [2]
XDoclet
Ebean
SIM
SIM
Annotations
ORM
2.6.0 [5]
e XML
EBD
SIM
SIM
BD
1.0
Legenda:
– : Informação não encontrada nas referências sobre a ferramenta
Hibernate
3.5.1 [41]
Suporte
a
Herança
SIM
SIM
SIM
SIM
SIM
NÃO
NÃO
SIM
–
Stored
Procedure
SIM
Suporta
SIM
–
SIM
SIM
–
NÃO
SIM
SIM
SIM
SIM
Coleções
Suporta
SIM
SIM
SIM
SIM
NÃO
SIM
SIM
SIM
SIM
SIM
Ferramenta
Livre?
2.3 Comparação de Ferramentas MDD para BD
28
CAPÍTULO 3
Arquitetura do Componente EBD - Especialista
em Banco de Dados
Uma arquitetura de software descreve uma organização de componentes, os seus
relacionamentos com o ambiente e as regras que definem o seu projeto e evolução [38].
Este capítulo sintetiza as principais características arquiteturais do framework
para geração e evolução de SI (Seção 3.1), detalhando o modelo de representação de
dados do SI (Seção 3.2) e analisando a arquitetura do componente de persistência EBD
(Seção 3.3).
3.1
Arquitetura do Framework
O componente EBD é um componente funcional de uma arquitetura maior que
não faz parte das propostas deste trabalho. Esta arquitetura apresenta um framework,
inspirado na abordagem MDD, que foi construído para geração e manutenção automática
de Sistemas de Informação usando modelos conceituais como entrada. Os componentes
de SI gerados pelo framework incluem: a) software de aplicação e interface com o usuário;
b) esquemas e restrições de integridade de bancos de dados; e c) regras de negócio que
podem ser disparadas a partir de eventos de bancos de dados ou de funções de aplicação.
A arquitetura funcional do framework é ilustrada na Figura 3.1. Três módulos
- Regras, Interface e Persistência - possuem processos e ferramentas de transformação
que mapeiam alguns aspectos dos modelos conceituais para os modelos específicos de
plataforma, gerando o código fonte correspondente.
O módulo Metadados constitui a base para o mecanismo MDD do framework.
Ele provê informações para todos os outros módulos, sendo responsável por gerenciar o
modelo conceitual de cada SI. Este modelo conceitual contém os metadados usados pelos
demais módulos para construir e gerenciar os códigos fonte do SI (aplicação, regras de
negócio e banco de dados).
O módulo Interface usa o modelo conceitual do SI (ou seja, os metadados que
descrevem conceitualmente o SI) para gerar a interface de usuário para aplicações do
3.1 Arquitetura do Framework
30
Figura 3.1: Arquitetura Funcional do Framework (adaptada de
[21])
SI. A geração é feita automaticamente, segundo os princípios de MDD, a partir de um
esquema de mapeamento dos metadados do SI para metadados de interface (chamados
de metadados de apresentação). Este mapeamento descreve, entre outros aspectos, como
apresentar cada conceito de negócio em uma interface padrão baseada nos conceitos
WIMP (Window, Icon, Menu, Pointer) [18, 19].
O módulo Interface Aplicação serve como adaptador entre os módulos Interface
e Aplicação. Seu objetivo principal é repassar mensagens da interface para a aplicação e
3.2 Modelo de Representação de Dados de SI - MMO
31
preparar dados vindos da camada de aplicação para serem enviados para a interface.
A responsabilidade do módulo Aplicação é realizar as operações das aplicações
do SI (incluindo operações CRUD), com o apoio dos módulos Persistência e Negócio.
Operações como inserir, alterar, remover, desativar e obter dados relacionados às entidades da aplicação são executadas pelo módulo Aplicação.
O módulo Negócio verifica se os dados vindos das camadas superiores estão de
acordo com as regras pré-estabelecidas (regras de negócio). Ele executa o controle para
que informações inseridas no Banco de Dados sejam válidas para o negócio subjacente
ao SI. Através das informações obtidas nos metadados, são tratados aspectos como
cardinalidade máxima e mínima dos dados, tipos de dados, valores máximos e mínimos,
regras de composição, dentre outras restrições de integridade.
O módulo Regras é responsável pelo controle centralizado do repositório de
regras de negócio do SI. Essa é uma característica diferencial do framework, pois trata as
Regras de Negócio como um aspecto independente dos demais aspectos (dados e funções)
[12, 13]. Este módulo traduz as definições de regras do modelo conceitual (definidas na
linguagem OCL) para código na linguagem específica da plataforma de implementação e
provê, em tempo de execução, facilidades para avaliação e execução destas regras quando
disparadas por eventos de BD ou de aplicação.
O módulo Persistência gerencia o mapeamento do modelo conceitual do SI para
o esquema operacional de banco de dados em um SGBD (e vice-versa). O módulo também
gerencia a evolução dos esquemas de bancos de dados de acordo com as mudanças
feitas nos metadados conceituais do SI. Este módulo gerencia, ainda, todo o acesso
aos dados persistentes do SI, isolando os demais módulos do framework de mudanças
na tecnologia de bancos de dados, ou seja, provendo independência de dados para as
aplicações construídas com o framework.
O presente trabalho descreve o projeto e a implementação do módulo Persistência do framework. Informações detalhadas sobre o framework e seus outros componentes
podem ser obtidos em [21, 13, 12, 19, 18].
3.2
Modelo de Representação de Dados de SI - MMO
Para representar os aspectos estruturais do domínio de um SI (tais como conceitos de negócio, instâncias desses conceitos, e relações e restrições sobre essas instâncias), o framework utiliza uma variante orientada a objetos do Modelo Entidade Relacionamento (MER) chamada de Modelo de Meta Objetos (MMO) [22]. Ele é um DSL
(Domain Specific Language - Linguagem Específica de Domínio) que específica também
aspectos de Interface Homem Computador (IHC) e de Regras de Negócio. A Figura 3.2
apresenta os principais conceitos de representação de dados deste metamodelo. Os con-
3.2 Modelo de Representação de Dados de SI - MMO
32
ceitos relacionados aos outros aspectos (IHC e Regras de Negócio) da DSL MMO foram
omitidos pois não fazem parte do escopo deste trabalho.
Figura 3.2: Metamodelo para representação conceitual de SI Modelo de Meta-Objetos (MMO) [22]
Usando estes elementos de modelagem é possível representar os conceitos de
um SI corporativo, independentemente da plataforma de implementação escolhida. Dessa
forma, somente detalhes do domínio de negócio aparecem no foco do projetista do SI.
Com o MMO é possível representar tipos de entidade, aquelas que possuem indentificação própria (Entidade Forte) e aquelas que possuem dependência de outra entidade para indentificar suas instâncias (Entidade Fraca). Além disso, é possível modelar
hierarquias de especialização de entidades, através do auto-relacionamento "especializada
em".
Para caracterizar um tipo de entidade o MMO disponibiliza os tipos de atributos
simples e composto. Estes tipos podem ser especializados em tipos mais específicos,
3.2 Modelo de Representação de Dados de SI - MMO
33
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 funcionalidades
comuns a todos os tipos de Atributos especializados do MMO. São características comuns
a todos os atributos:
• Mnemônico: representa o identificador do atributo. O mnemônico é case sensitive
e único dentro de todo o SI.
• Tipo de Atributo: define o tipo de atributo descrito. O valor dessa propriedade de
Atributo pode ser:
– BASICO: indica que é um atributo simples, com um domínio discreto de
valores definitos pelo sistema.
– ENUMERADO: indica que é um atributo simples, com um domínio discreto
de valores definidos pelo usuário.
– OBJETO EXTERNO: indica que o atributo é do tipo multimídia e possui
dependência de aplicações externas para ser editado (por exemplo, fotos,
vídeos e planilhas).
– OBJETO INTERNO: representa um relacionamento entre duas entidades do
SI. Tipos de relacionamento são representados, no MMO, pelo atributo do tipo
objeto interno. Por exemplo, o atributo gerencia da entidade funcionário pode
indicar um relacionamento entre as entidades funcionário e departamento.
– COMPOSTO: indica que o atributo é composto por outros atributos. Por
exemplo, o atributo telefone pode ser composto pelos atributos ddd e número.
• Tipo de Domínio: refere-se ao tipo de valor que o atributo simples básico armazena.
São tipos de domínio válidos no MMO: inteiro, decimal, alfanumérico, booleano e
data.
• Cardinalidade Mínima e Máxima: define a cardinalidade do atributo, ou seja, qual
o número mínimo e máximo de valores que o atributo pode ter.
• É Parte de Chave: indica que o atributo faz parte da chave lógica da entidade.
• É Único: determina que o valor do atributo não pode ser repetido em diferentes
instâncias de um tipo de entidade. Desta forma, não poderá haver dois valores iguais
no BD.
• É Atributo de Ligação: é uma informação que ajuda a identificar, no contexto do
negócio, a instância da entidade referenciada por um atributo do tipo objeto interno.
Dada a entidade B com os atributos atrib1, atrib2 e atrib3, simples monovalorados,
e a entidade A com o atribR do tipo objeto interno, se os atributos atrib1 e atrib2 são
definidos como atributos de ligação da entidade B, em uma consulta de instâncias
3.2 Modelo de Representação de Dados de SI - MMO
34
de atribR os atributos de B que aparecem nesta consulta são os atributos de ligação
atrib1 e atrib2. Por exemplo, se a entidade funcionário possui os atributos nome
e cpf, e estes são definidos como atributos de ligação desta entidade, e se a
entidade departamento possui o atributo gerente, do tipo objeto interno, indicando
o relacionamento com a entidade funcionário, uma consulta para obter todos os
gerentes do departamento apresentará os atributos nome e cpf.
O Atributo Simples Básico representa um dado atômico dentro da entidade da
qual ele faz parte. Ou seja, essa informação não pode ser dividida em partes menores com
semântica própria. O Atributo Simples contém as seguintes características:
• Tamanho: é a característica que limita o número máximo de caracteres que o
Atributo Simples pode conter.
• Menor e Maior Valor: caso o Atributo Simples seja do Tipo de Domínio numérico,
esta característica determina os valores mínimo e máximo permitidos para este
atributo.
O Atributo Simples Enumerado descreve dados oriundos de um conjunto de
valores definidos pelo usuário, isto é, uma enumeração de valores discretos. Um exemplo
de enumeração é o conjunto de valores {masculino, feminino} para o atributo sexo. O
Atributo Simples Enumerado possui as seguintes características:
• Domínio Enumerado: define o nome do conjunto onde estão determinados os
valores discretos possíveis para o atributo.
• Dados Enumerados: esta característica armazena os valores do domínio enumerado.
O Atributo Objeto Externo contém informações de entidades externas ao
sistema. O Atributo Objeto Externo possui as seguintes características:
• Extensão: descreve a extensão do objeto externo. Por exemplo, .gif e wma.
• Aplicativo: indica qual é o aplicativo que executa o objeto externo.
• Plataforma: indica qual é a plataforma necessária para o objeto externo.
O Atributo Composto é formado por um ou mais atributos que podem ser
simples ou compostos. Desta forma, é possível representar objetos complexos, que
são compostos por outros objetos também complexos. O Atributo Composto possui as
seguintes características:
• Subatributos: referencia o conjunto de atributos que compõem o Atributo Composto.
3.3 Arquitetura dos Componentes de Transformação
35
Um tipo notável de Atributo Composto é o Atributo Objeto Interno. Um
objeto interno é aquele que referencia alguma entidade do SI. Dessa forma, é possível
esbelecer relacionamentos entre entidades do sistema. A denominação “objeto interno”
decorre do fato de a entidade referenciada estar armazenada no próprio BD do SI. Além
das características herdadas de Atributo Composto, o Atributo Composto Objeto Interno
contém as seguintes:
• Entidade Referenciada: contém o mnemônico da entidade que o Atributo Composto Objeto Interno referencia. Por exemplo, o relacionamento gerencia entre as
entidades funcionário e departamento poderia ser definido por um atributo objeto
interno gerente, que pertence à entidade departamento e armazena o mnemônico
funcionário no campo Entidade Referenciada.
• Atributo Referenciado: contém o mnemônico de um Atributo Objeto Interno
pertencente à entidade de referência. Desta forma, o modelo permite representar relacionamentos entre relacionamentos. Por exemplo, em uma empresa uma
manutenção é requesitada somente por aquele funcionário que é gerente. O atributo objeto interno gerente determina o relacionamento entre as entidades departamento e funcionário. Por sua vez, a entidade manutenção possui o atributo objeto
interno requesitada por, que possui no campo Atributo Referenciado o mnemônico
do atributo gerente, definindo o relacionamento entre a entidade manutenção e o
relacionamento gerente da entidade departamento. No campo entidade referenciada
do objeto interno "requisitada por"contém a qual o objeto interno gerente pertence,
neste caso, a entidade departamento.
3.3
Arquitetura dos Componentes de Transformação
Os mecanismos de transformação para geração e evolução de esquemas e mapeamento objeto-relacional envolvem os módulos Negócio e Persistência, mostrados na
arquitetura de alto nível da Figura 3.1. A seguir, são apresentados os serviços do componente EBD para acesso a dados, geração de esquema, evolução de esquema e de metadados e dados de entidade.
3.3.1
Serviços de Acesso a Dados
O pacote Serviços de Acesso a Dados contém os serviços para mapeamento de
instâncias de entidades do MMO para o BD e vice versa. O framework disponibiliza as
operações de inserção, remoção, atualização e obtenção de instâncias de entidades do SI.
3.3 Arquitetura dos Componentes de Transformação
36
Estas operações contam com um conjunto de stored procedures geradas para
manipulação de instâncias de entidades. Em Java, a classe CallableStatement do pacote
java.sql é utilizada para manipulação de informações do BD através de stored procedures.
A preparação de chamada de stored procedure é feita em duas etapas.
Primeiramente, a stored procedure que será chamada é registrada no objeto da classe
CallableStatement através de uma string que contém o nome da stored procedure e a
quantidade de parâmetros que serão passados. Logo após, são registrados os valores dos
parâmetros no objeto CallableStatement.
A string tem o formato ?= call <nome-procedure>(?, ?, ?, ...). O componente EBD nomeia as stored procedures levando em conta o tipo da operação (inserir,
desativar, obter e atualizar) e o mnemônico do tipo de entidade ou atributo. Por exemplo,
supondo que o mnemônico do tipo de entidade pessoa física seja PesFis, o nome da stored
procedure de inserção é inserirPesFis.
A quantidade de pontos de interrogação (?) na string definem a quantidade de
parâmetros da stored procedure. No EBD, esta string é criada em tempo de execução e a
quantidade de parâmetros é obtida a partir da contagem de atributos simples monovalorados do tipo de entidade, do atributo composto ou do objeto interno.
O pacote Serviços de Acesso a Dados disponibiliza também serviços de controle
de transação (abertura, commit e rollback) e serviços de acesso ao BD utilizados pelo
componente Regra do framework.
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ços
para geração do esquema SQL e das stored procedures no SGBD utilizado na implementação do SI.
O pacote BibliotecaBD é um pacote externo ao Serviços de Geração de Esquema.
Ele possui informações e algoritmos de mapeamento para o processo de transformação do
modelo conceitual do SI, especificado de acordo com o MMO, para o modelo relacional,
e deste para o dialeto SQL alvo.
O pacote Gerador DDL oferece os serviços de mapeamento para geração do
esquema do banco de dados do SI. A manipulação dos dados do esquema gerado pelo
pacote Gerador DDL é feita por um conjunto de stored procedures para operações CRUD
geradas pelo pacote Gerador DML.
No processo de mapeamento para geração do esquema e de instruções de
manipulação de dados do SI são necessários serviços para obtenção de listas de atributos.
Por exemplo, para criar uma relação, no mapeamento do MMO para o modelo relacional,
é necessário obter uma lista dos mnemônicos dos atributos do tipo de entidade do MMO.
3.3 Arquitetura dos Componentes de Transformação
37
Figura 3.3: Arquitetura do Componente de Geração de Esquema
O pacote Serviços de Geração de Esquema disponibiliza serviços para:
• geração de DDL para entidade, atributo composto, atributo objeto interno e atributo
simples multivalorado, e
• geração de stored procedures de consulta, inserção, remoção e obtenção para entidade, atributo composto, atributo objeto interno e atributo simples multivalorado.
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 do
esquema e dos dados contidos em um SI quando o modelo conceitual do SI é alterado. A
Figura 3.4 mostra este pacote.
No componente EBD modificações permitidas no MMO são propagadas para
o esquema e, consequentemente, para os dados do SI. O pacote AvaliadorMudança
possui os serviços necessários para avaliação das propagações do modelo conceitual
(MMO) para o esquema do BD. Por exemplo, uma mudança de tamanho de um atributo
3.3 Arquitetura dos Componentes de Transformação
38
Figura 3.4: Arquitetura do Componente de Evolução de Esquema
alfanumérico pode ser aplicada se todos os valores daquele atributo no BD forem menores
ou iguais ao novo tamanho.
As mudanças na chave lógica de uma entidade ou atributo composto, tais como
inclusão ou remoção de atributos são executadas no pacote Chave Lógica. Outros tipos
de mudanças tratados neste pacote são transformações entre os tipos de entidade e nas
hierarquias de especialização.
Os serviços para propagação de mudanças de unicidade de um atributo são
tratadas no pacote Unicidade.
O pacote Domínio possui os serviços para mapeamento da propagação das
alterações de domínio de atributos do MMO.
As propagações de mudanças em relação a cardinalidades mínima e máxima dos
atributos são tratadas no pacote Cardinalidade.
A propagação da modificação de tamanho de atributo alfanumérico é tratada pelo
pacote Tamanho.
O pacote Composição possui os serviços para propagação de mudanças relacionadas aos atributos do domínio composto. Um atributo composto pode ser modificado
com adição ou remoção de um atributo, por exemplo.
3.3 Arquitetura dos Componentes de Transformação
39
A propagação de mudança de mnemônico de entidade e atributo é tratada pelos
serviços do pacote Mnemônico.
O pacote Serviços de Evolução de Esquema disponibiliza, em suma, serviços
para:
• criação e remoção de: atributo em entidade, atributo composto, atributo objeto
interno, atributo simples multivalorado.
• mudança de: domínio de atributo e de restrição de unicidade de atributo.
• transferência de atributo da entidade para um atributo composto ou atributo objeto
interno.
• mudança do mnemônico de entidade ou de atributo.
• criação e remoção de stored procedures de consulta, inserção, remoção e obtenção
para entidade, atributo composto, atributo objeto interno e atributo simples multivalorado.
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 sistema
foram definidas as classes Metadados e ObjetoApresentacao. A classe Metadados (Figura
3.5) do pacote Serviço de Metadados e Dados possui um vetor de atributos que armazena
as características de uma instância de tipo de entidade. Metadados disponibiliza serviços
para obtenção:
• do número de atributos dos Metadados. Este serviço retorna a quantidade de
atributos que a entidade possui. Por exemplo, se a entidade Pessoa Física possui
os atributos nome, cpf e endereço, o retorno deste serviço é o valor inteiro 3.
• de um atributo a partir de um índice. Este serviço retorna um atributo a partir de seu
índice recebido como entrada. No exemplo anterior, o índice 2 retorna o atributo
cpf.
• de um objeto Atributo a partir do mnemônico do Atributo. Dado o mnemônico, este
serviço retorna a instância de atributo correspondente.
• do índice do atributo nos Metadados. Este serviço retorna o índice do atributo dentro
dos metadados da entidade.
• dos valores dos atributos simples a partir de uma instância da entidade. Dada
uma instância da entidade, este serviço retorna os valores dos atributos simples
monovalorados.
• dos valores dos atributos que compõem a chave lógica da entidade. Dada uma
instância da entidade, este serviço retorna os valores dos atributos que compõem
a chave lógica da entidade.
3.3 Arquitetura dos Componentes de Transformação
40
• dos valores da chave parcial de um atributo composto. Este serviço retorna os
valores dos atributos que compõem a chave parcial do atributo composto. A entrada
deste serviço é o mnemônico do atributo composto ou objeto interno.
• dos valores simples do atributo composto. Este serviço retorna os dados dos
atributos simples do atributo composto ou objeto interno. A entrada deste serviço é
o mnemônico do atributo composto ou objeto interno.
A classe Metadados possui os métodos obterAtributoSimples, obterChaveLogica, obterChaveParcialComposto e obterValoresSimplesComposto que conceitualmente
deveria pertencer à classe ObjetoApresentacao, que fornece serviço para os dados de uma
instância de entidade. Eles ficaram na classe Metadados pois dependem de metainformações para sua execução. Por exemplo, o método obterChaveLogica necessita de um
serviço que retorne o índice dos atributos que fazem parte da chave lógica da entidade.
Figura 3.5: Classe Metadados
A instância de entidade é encapsulada no sistema pela classe ObjetoApresentacao (Figura 3.7). A classe ObjetoApresentacao do pacote Serviços de Metadados e Dados
possui o atributo valores que é um vetor de objetos. Neste vetor cada objeto é uma instância do atributo nos Metadados de mesma posição. Os atributos multivalorados são
armazenados em vetores de vetores, onde o vetor interno armazena cada uma das instâncias do atributo multivalorado e o vetor externo armazena este conjunto de instâncias. A
Figura 3.6 ilustra esta construção.
Os serviços de metadados e dados do componente de persistência EBD são
utilizados nas operações CRUD para instâncias de entidade, a serem apresentadas na
Seção 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 que
o valor do parâmetro indice são deslocados e o objeto valor é adicionado. Por sua vez,
o método adicionarValor que possui somente um parâmetro adiciona o objeto valor na
última posição do ObjetoApresentacao.
3.3 Arquitetura dos Componentes de Transformação
41
Figura 3.6: Representação Gráfica de uma Instância de ObjetoApresentacao
Figura 3.7: Classe ObjetoApresentacao
O método obterNumValores retorna a quantidade de objetos armazenados no ObjetoApresentacao. Por exemplo, este método retorna o valor 3 para o ObjetoApresentacao
da Figura 3.6.
O método obterValorEm retorna o objeto armazenado na posição indice do
ObjetoApresentacao. Por exemplo, a chamada deste método com o valor 1, para o
ObjetoApresentacao da Figura 3.6, retorna o valor 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 dados
do SI (Seção 3.2) e analisou a arquitetura do componente de persistência EBD (Seção
3.3).
CAPÍTULO 4
Transformações entre Modelos
O processo de geração automática do esquema de BD é logicamente dividido
em duas fases: primeiramente é feito o mapeamento do Modelo de Meta-Objetos (MMO)
para o Modelo Relacional (MR), na sequência as informações deste modelo são mapeadas
para um dialeto SQL.
Este capítulo apresenta, nas Seções 4.1 e 4.2, o mapeamento do MMO para o
MR em termos de estruturas e operações. A Seção 4.3 discute o mapeamento do MR para
o SQL do SGBD PostgreSQL.
4.1
Mapeamentos do MMO para MR
O MMO descreve um SI através de tipos de entidade, objetos internos (tipos de
relacionamento), atributos (que podem ser multivalorados e compostos), hierarquias de
especialização e restrições estruturais (domínio, chave, unicidade, cardinalidade mínima
e máxima de atributo e relacionamento). O componente EBD é capaz de mapear para o
Modelo Relacional (MR) todos estes conceitos utilizados para representar um SI.
4.1.1
Mapeamento de Entidades e Hierarquia de Especialização
A Tabela 4.1 apresenta informações do mapeamento de um tipo de entidade
no MMO para uma relação no MR. Basicamente, cada tipo de entidade no MMO será
mapeado para uma relação no MR. Todas as relações mapeadas pelo componente possuem
uma chave artificial (surrogate key) como chave primária.
O valor da chave artificial é gerado pelo EBD e não possui significado na
perspectiva do negócio. A chave artificial pk pertence ao domínio inteiro e é incrementada
automaticamente a cada inserção na relação.
O mnemônico do tipo de entidade do MMO é mapeado para o nome da relação
no MR. Os atributos do tipo de entidade mapeados para a relação correspondente são os
atributos simples monovalorados. No processo de mapeamento, os atributos de um atri-
4.1 Mapeamentos do MMO para MR
MMO
Mnemônico de Tipo de Entidade
Conjunto de Atributos Simples Monovalorados
Conjunto de Atributos com Restrições "É
parte de chave"
Restrição "É Único" sobre atributo
Restrição "É uma Especialização
de" referenciando um Tipo de Entidade
Genérico
43
MR
Nome da Relação
Conjunto de Atributos da Relação
Restrição de unicidade sobre o conjunto
de atributos
Restrição de Unicidade sobre atributo
Inclusão de atributo pk com restrição primary key
Restrição foreign key sobre o atributo pk
referenciando a relação correspondente ao
Tipo de Entidade Genérico
Tabela 4.1: Mapeamento de Entidades e Hierarquia de Entidades
do MMO para o MR
MMO
Tipo do Atributo Tipo de Domínio
Básico
Alfanumérico
Básico
Inteiro
Básico
Decimal
Básico
Data
Enumerado
Booleano
Enumerado
Alfanumérico
MR
Domínio
Alfanumérico
Inteiro
Decimal
Data
Booleano
Inteiro
Tabela 4.2: Conversão de Tipo/Domínio do MMO para MR
buto composto monovalorado são colocados na relação da entidade à qual eles pertencem.
Os nome desses atributos no MR são os respectivos mnemônicos no MMO.
No MMO é possível definir se um atributo é armazenado ou não. Quando um
atributo não é armazenado (derivado) então é associada a ele uma regra de derivação que
calcula o valor deste atributo. Por exemplo, o atributo idade de uma pessoa física é um
atributo derivado.
O mapeamento de tipos/domínios do MMO para o MR é apresentado na Tabela
4.2.
O atributo do tipo enumerado é mapeado com uma chave estrangeira para
uma relação Valor Enumerado que armazena todos os valores enumerados de todos
os domínios enumerados. Esta relação possui uma chave estrangeira para uma relação
Domínio Enumerado que contém todos os domínios enumerados definidos para o SI.
A relação Domínio Enumerado recebe os nomes dos domínios; como por exemplo, cor
primária e sexo. Já a relação Valor Enumerado recebe os valores do domínio; como por
exemplo, verde, azul e vermelho, para cores primárias, e masculino e feminino, para sexo.
A Figura 4.1 mostra a representação do atributo enumerado no MR.
As restrições de integridade de chave e unicidade do MMO são mapeadas para
4.1 Mapeamentos do MMO para MR
44
Figura 4.1: Mapeamento de Atributo Enumerado do MMO para o
MR
restrições de unicidade no MR. A chave primária é uma chave artificial (atributo pk)
gerada pelo mecanismo de mapeamento e não possui conceito correspondente no MMO.
Os atributos que compõem a chave lógica são definidos com a restrição de unicidade.
A abordagem utilizada para mapear hierarquias de especialização considera
cada tipo de entidade da hierarquia como uma relação. As vantagens desta abordagem
são: (i) facilidade de entendimento, pois o mapeamento feito entre entidade e relação é
um para um; (ii) facilidade de manutenção, pois modificações em uma superentidade não
afetam suas subentidades; (iii) e a quantidade de espaço armazenado é proporcional ao
número de objetos armazenados.
Os pontos fracos desta abordagem são o potencial número de relações criadas
e, consequentemente o aumento de junções, afetando a eficiência das consultas de informações na hierarquia. Essas limitações não são significativas, pois o próprio componente
EBD é responsável pela criação de relações e pela definição de operações de junção, que
podem ser otimizadas para cada plataforma alvo do SI.
A Figura 4.2 apresenta um exemplo de mapeamento de hierarquia de especialização do MMO para o MR. Para manter a integridade referencial entre instâncias das
superentidades e respectivas subentidades é criada uma restrição de chave estrageira da
relação da subentidade para a da superentidade. A chave estrangeira é a própria pk da
relação especializada. A superentidade é obtida da restrição "é uma especialização de" do
MMO.
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 desta
abordagem seria relacionada à possível ineficiência nas consultas, mas a manutenção é
beneficiada pois, em casos de mudança de cardinalidade, não é necessário mudar a forma
de mapeamento.
4.1 Mapeamentos do MMO para MR
45
Figura 4.2: Mapeamento de Hierarquia de Especialização do
MMO para o MR
A Tabela 4.3 descreve o esquema para o mapeamento de atributo do tipo objeto
interno do MMO para o MR. Primeiramente é criada uma relação com o nome definido
pelo mnemônico do atributo objeto interno no MMO. Esta relação possui os atributos
pk, pkEnt, pkEntRef no domínio inteiro, sendo as duas últimas chaves estrangeiras
para as entidades a que o atributo objeto interno pertence e para a entidade de referência,
respectivamente. Ambas as chaves possuem restrição de não nulidade.
Figura 4.3: Mapeamento de Atributo Objeto Interno do MMO para
o MR
O atributo do tipo objeto interno pode ter subatributos, que correspondem a
atributos do relacionamento. O mapeamento é feito da mesma forma descrita para o tipo
de entidade, ou seja, são considerados o mesmo mnemônico e a conversão de tipo do
MMO para o MR (Tabela 4.2).
4.1 Mapeamentos do MMO para MR
MMO
Mnemônico Objeto Interno
Restrição "Entidade Referenciada" indicando a Entidade do Relacionamento
Restrição "Atributo Referenciado" indicando o atributo Objeto Interno do Relacionamento. Só ocorre quando é definido
relacionamento com agregação
46
MR
Nome da Relação
Inclusão de atributo pk com restrição primary key
Inclusão de atributo pkEnt com restrição
de não nulidade foreign key referenciando
a relação correspondente à entidade que
contém o atributo objeto interno
Inclusão do atributo pkEntRef com restrição de não nulidade e foreign key referenciando a relação correspondente à Entidade Referenciada pelo atributo objeto interno
Inclusão do atributo pkAtribRef com restrição de não nulidade e foreign key referenciando a relação correspondente ao
Atributo Referenciado pelo atributo objeto
interno
Inclusão da restrição de unicidade para o
par (pkEnt, pkEntRef ) ou, no caso de relacionamento com agregação, (pkEnt, pkAtribRef )
Tabela 4.3: Mapeamento de Objeto Interno do MMO para o MR
Para representação de relacionamento com agregação, isto é, relacionamentos
entre relacionamentos, a relação do atributo do tipo objeto interno possui algumas
variáveis adicionais. A Figura 4.4 apresenta o mapeamento do MMO para o MR de
atributo do tipo objeto interno que representa relacionamento com agregação.
A relação que representa o atributo objeto interno possui uma chave estrangeira
para a relação que representa a entidade contendo o atributo que está sendo mapeado e
para a relação que representa o atributo de referência.
4.1.3
Mapeamento de Entidade Fraca
Pela definição de entidade fraca, não há a restrição de unicidade para os atributos
que fazem parte da chave parcial. As instâncias de uma entidade fraca são identificadas a
partir da chave lógica da entidade da qual ela depende mais a sua chave parcial.
No MMO, a chave lógica de um tipo de entidade é definida por um conjunto de
atributos simples. Para a entidade fraca, além dos atributos simples que compõem a chave
parcial é definido um atributo do tipo objeto interno que faz parte da chave lógica.
Para montar a chave lógica da entidade fraca, primeiramente são obtidos os
atributos da chave lógica da entidade de referência do atributo objeto interno que faz parte
4.1 Mapeamentos do MMO para MR
47
Figura 4.4: Mapeamento do Atributo Objeto Interno (Agregação)
do MMO para o MR
da chave e, posteriormente, são obtidos os atributos simples da chave parcial da entidade
fraca.
O mapeamento do atributo objeto interno que faz parte da chave da entidade
fraca é feito como descrito na Tabela 4.3.
A Figura 4.5 apresenta o mapeamento do MMO para o MR para entidade Fraca.
Figura 4.5: Mapeamento de Entidade Fraca do MMO para o MR
4.1 Mapeamentos do MMO para MR
MMO
Mnemônico do Atributo
48
MR
Nome da Relação
Inclusão de atributo pk com restrição de
não nulidade foreign key referenciando
a relação correspondente à entidade que
contém o atributo multivalorado
Inclusão de atributo com o nome valor na
relação
Inclusão da restrição de primary key sobre
o atributo pk e o atributo valor
Tabela 4.4: Mapeamento do Atributo Simples Multivalorado do
MMO para o MR
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 Tabela
4.4 descreve as regras deste mapeamento.
Figura 4.6: Mapeamento de Atributo Multivalorado do MMO para
o MR
No processo de mapeamento primeiramente é criada uma relação com o nome do
atributo multivalorado no MMO. A relação possui duas colunas: pk e valor. A coluna pk
é uma chave estrangeira para a relação que representa a entidade proprietária do atributo
multivalorado. O domínio da coluna valor é obtido através da conversão descrita na
Tabela 4.2. A chave primária da relação é composta pelas colunas pk e valor.
O atributo composto multivalorado do MMO também é mapeado para uma
relação no MR. A Figura 4.7 mostra um exemplo deste mapeamento.
Figura 4.7: Mapeamento de Atributo Composto do MMO para o
MR
O mapeamento inicia com a criação da relação com o mesmo nome do atributo
no modelo MMO. As colunas da relação são definidas pela lista de subatributos do
4.2 Geração de DML para Operações CRUD
MMO
Mnemônico do Atributo
Conjunto de Atributos Simples Monovalorados
Conjunto de SubAtributos com Restrição
"É parte de chave"
49
MR
Nome da Relação
Inclusão de atributo pk com restrição primary key
Inclusão de atributo pkEnt com restrição
de não nulidade foreign key referenciando
a relação correspondente à entidade que
contém o atributo multivalorado
Conjunto de Atributos da Relação
Inclusão da restrição de unicidade sobre o
atributo pkEnt e o conjunto de atributos
Tabela 4.5: Mapeamento do Atributo Composto Multivalorado do
MMO para o MR
atributo do tipo composto. Além destas colunas, a relação conta com as colunas pk
e pkEnt. A coluna pk é a chave primária da relação, e a coluna pkEnt é uma chave
estrangeira para a relação que representa a entidade proprietária do atributo composto.
Para garantir a unicidade dos valores, no MMO um atributo do tipo composto
possui chave parcial, como uma entidade fraca. A restrição de unicidade é criada a partir
dos atributos que compõem a chave parcial mais a coluna pkEnt.
4.2
Geração de DML para Operações CRUD
Esta seção discute a criação de instruções de manipulação para operações CRUD
para Entidade, Hierarquia de Especialização, Atributo Objeto Interno, Entidade Fraca,
Atributo Composto e Atributo Multivalorado.
A Álgebra Relacional foi utilizada para descrever o conjunto de operações
geradas para cada um desses conceitos do MMO.
4.2.1
DML para Tipo de Entidade
Para cada tipo de entidade há dois tipos de consultas implícitas no MMO: uma
para obtenção de todas as instâncias e outra para obtenção de uma instância específica.
A Tabela 4.6 (a) apresenta a consulta para obtenção de todas as instâncias de
um tipo de entidade. A consulta é feita na relação Entidade, lembrando que o nome da
relação é igual ao mnemônico do tipo de entidade no MMO.
A lista de atributos da operação project (π) é a lista de todos os atributos
simples monovalorados da entidade. A consulta para obtenção de uma instância de tipo
de entidade é apresentada pela Tabela 4.6 (b). A projeção leva em conta a mesma lista de
4.2 Geração de DML para Operações CRUD
50
Relação:
Entidade(pk, atributo1, atributo2, atributo3)
(a) Obtenção de Instâncias
πatributo1,atributo2,atributo3 (Entidade)
(b) Obtenção de Instância
πatributo1,atributo2,atributo3 (
σEntidade.atributo1=val1 AND Entidade.atributo2=val2 (Entidade)
)
(c) Inserção de Instância
pkEnt ← max pk (Entidade) + 1
Entidade ← Entidade ∪ {(pkEnt, val1, val2, val3)}
(d) Remoção de Instância
pkEnt ← π pk (σEntidade.atributo1=val1 AND
Entidade.atributo2=val2 (Entidade))
Entidade ← Entidade σEntidade.pk=pkEnt (Entidade)
(e) Atualização de Instância
pkEnt ← π pk (σEntidade.atributo1=val1NMod AND
Entidade.atributo2=val2NMod (Entidade))
Entidade ← πatributo1←val1 , atributo2←val2 , atributo3←val3 (
σEntidade.pk=pkEnt (Entidade))
)
Tabela 4.6: Operações CRUD sobre Tipo de Entidade
atributos da consulta para todas as instâncias. A projeção é feita a partir da seleção (σ) da
instância da entidade.
A condição de seleção da instrução σ é criada a partir do atributos que fazem
parte da chave da entidade. A condição é criada a partir do padrão Entidade.atributo =
valN, onde Entidade é mnemônico da entidade, atributo é mnemônico do atributo simples
monovalorado que faz parte da chave e valN é uma variável, sendo N a sua posição na
lista de atributos simples da entidade. A variável vali tem o mesmo domínio do atributo
atribi da relação Entidade.
As instruções para inserção de instância de entidade são apresentadas na
Tabela 4.6 (c). Antes de inserir a instância da entidade, primeiramente é calculado o valor
da chave primária, adicionando um ao maior valor na relação Entidade, armazenado na
variável pkEnt.
A tupla {(pkEnt, val1, val2, val3)} é formada com o valor da chave
primária artificial mais os valores val1, val2 e val3 para os atributos atrib1, atrib2 e
atrib3 respectivamente. Só então a nova tupla é inserida no conjunto de tuplas da relação
Entidade.
A Tabela 4.6 (d) apresenta o conjunto de instruções para remoção de instâncias
de tipo de entidade. A remoção é iniciada obtendo a chave primária através da chave
4.2 Geração de DML para Operações CRUD
51
lógica da entidade. A consulta é semelhante à consulta para obtenção de uma instância
de entidade. A diferença está na lista de projeção que considera somente o atributo pk. A
exclusão é feita a partir da seleção (σ) da tupla que possui o valor da chave primária igual
ao valor armazenado na variável pkEnt.
A operação de atualização de instância de entidade é apresentada na Tabela
4.6 (e). Da mesma forma que a remoção de instâncias, a atualização é feita em duas
etapas: uma para obter a chave primária da entidade e outra para executar a instrução de
atualização.
A instrução para obter a chave primária da instância que será atualizada é
semelhante à instrução definida no processo de remoção de instância de entidade. A
diferença está na condição da consulta onde os valores da chave lógica devem ser os
valores antes da modificação da instância da entidade.
Caso a chave lógica seja modificada, os valores armazenados em val1 e val2 não
podem ser utilizados na consulta para obtenção da chave primária, pois a consulta não
retornaria nada. Para isso, são definidas as variáveis va1NMod e val2NMod que recebem
os valores antes da modificação da chave lógica.
A instrução de atualização possui uma lista de atribuição que é definida pelo
formato atributoN ← valN, onde atributoN é o atributo N da relação, e valN é a
variável que armazena o novo valor do atributo.
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, lista
de junções e lista de atribuições na instrução de atualização) devem contemplar todas as
entidades da hierarquia.
Estas listas podem ser obtidas a partir de mecanismos recursivos. Por exemplo,
a lista de atributos da operação project em uma consulta de uma entidade especializada
pode ser obtida através do Código 4.1.
4.2 Geração de DML para Operações CRUD
52
Código 4.1 Obtenção de Lista de Atributos Simples de uma Hierarquia de Especialização
1
String obterListaAtributos( String mneEntidade )
2
{
3
String listaAtributos;
4
String superEntidade;
5
Vetor<String> atributos;
6
superEntidade = obterSuperEntidade (mneEntidade);
7
8
se superEntidade != nulo faça
9
listaAtributos = obterListaAtributos (superEntidade )
10
fim se;
11
12
atributos = obterAtributosEntidade (mneEntidade);
13
14
para cada elemento em atributos faça
15
listaAtributos = listaAtributos + ’,’ + atributos[i] + ’,’;
16
fim
17
18
retorne listaAtributos
19
20
}
O conjunto de operações CRUD sobre tipo de entidades especializadas é apresentado na Tabela 4.7. Nas operações de consulta, a lista de atributos da operação de
projeção é composta pelos atributos simples monovalorados da superentidade mais os
atributos simples monovalorados da subentidade.
Na operação de seleção (σ) são definidas as junções entre todas as tabelas
que participam da hierarquia de especialização. A lista de junções pode ser obtida
utilizando um algoritmo semelhante ao descrito no Código 4.1. Se a hierarquia de
especialização tiver apenas um nível, a lista de junção é definida como SuperEntidade
× SubEntidade e a condição de junção é SuperEntidade.pk = SubEntidade.pk.
A operação de consulta que retorna uma instância da entidade especializada é detalhada na Tabela 4.7 (b). Na operação de seleção (σ) além das condições de junção é criada a lista de comparação entre os atributos da chave lógica da superentidade e os valores
da chave lógica. Neste caso são considerados somente os atributos que identificam unicamente uma instância, por isso que esta lista não possui atributos da subentidade. Cada
cláusula da condição segue o padrão SuperEntidade.atribN = valN, onde SuperEntidade é mnemônico da entidade raiz da hierarquia, mnemonicoAtributo é mnemônico do
4.2 Geração de DML para Operações CRUD
53
Relações:
SubEntidade(pk, atrib1, atrib2, atrib3)
SuperEntidade(pk, atribA, atribB)
(a) Obtenção de Instâncias
πatribA,atribB,atrib1,atrib2,atrib3 (
σSuperEntidade.pk=SubEntidade.pk (SuperEntidade × SubEntidade)
)
(b) Obtenção de Instância
πatribA,atribB,atrib1,atrib2,atrib3 (
σSuperEntidade.pk=SubEntidade.pk AND SuperEntidade.atribA=valA
(SuperEntidade × SubEntidade)
)
(c) Inserção de Instância
pkEnt ← max pk (SuperEntidade) + 1
SuperEntidade ← SuperEntidade ∪ {(pkEnt, valA, valB)}
SubEntidade ← SubEntidade ∪ {(pkEnt, val1, val2, val3)}
(d) Remoção de Instância
pkEnt ← π pk (σSuperEntidade.atribA=valA (SuperEntidade))
SubEntidade ← SubEntidade σSubEntidade.pk=pkEnt (SubEntidade)
(e) Atualização de Instância
pkEnt ← π pk (σSuperEntidade.atribA=valANMod (SuperEntidade))
SuperEntidade ← πatribA←valA , atribB←valB (
σSuperEntidade.pk=pkEnt (SuperEntidade))
)
SubEntidade ← πatrib1←val1 , atrib2←val2 , atrib3←val3 (
σSubEntidade.pk=pkEnt (SubEntidade)
)
Tabela 4.7: Operações CRUD sobre Tipo de Entidade Especializada
atributo simples monovalorado que faz parte da chave, e valN é uma variável, sendo N a
posição na lista de atributos simples da superentidade raiz da hierarquia.
Na operação de inserção, a primeira instrução é a busca pelo maior valor do
atributo pk na relação SuperEntidade. O valor encontrado é incrementado de um e
armazenado na variável pkEnt.
A nova tupla da relação SuperEntidade {(pkEnt, valA, valB)} é formada
com o valor da chave primária artificial mais os valores valA e valB para os atributos
atribA e atribB, respectivamente. Só então a nova tupla é inserida no BD. Os atributos
atribA e atribB são os atributos simples monovalorados da entidade com o mnemônico
SuperEntidade.
A instrução para inserção da tupla da relação SubEntidade é obtida da mesma
forma que a instrução da relação SuperEntidade. O atributo pk recebe o mesmo valor da
4.2 Geração de DML para Operações CRUD
54
variável pkEnt garantindo que a chave da superentidade seja propagada por toda a cadeia
de especialização.
Na operação de remoção, primeiramente é feita a busca pela chave primária da
superentidade. Como o valor é o mesmo para as subentidades, na instrução para remover
a instância da subentidade SubEntidade a condição de seleção compara os valores pk da
relação com o valor da chave primária obtida da superentidade (pkEnt).
A consulta para obtenção da chave primária é criada da mesma forma que a
consulta para obtenção de uma instância de uma entidade especializada; a única diferença
está na lista de projeção que considera somente o valor pk da superentidade.
Na operação de atualização, a operação para obter a chave primária da superentidade é semelhante à utilizada na remoção de instância de entidade especializada; a
diferença está na condição da consulta, que segue o mesmo príncípio discutido na atualização de instância de entidade forte, com a busca sendo feita com o valor da chave lógica
não modificada. No caso descrito na Tabela 4.7 (e), a consulta é feita considerando o valor
da variável valANMod que armazena a chave de SuperEntidade.
A atualização é feita da raiz da especialização para as folhas, ou seja, da
superentidade para a cadeia de subentidades da hierarquia. Cada entidade na cadeia possui
uma instrução para atualização de seus atributos.
A geração de instruções para atualização de hierarquia de especialização pode
ser obtida com algoritmo semelhante ao apresentado no Código 4.1.
A atualização da instância da subentidade é feita depois de obtida a chave
primária da superentidade. A operação de projeção (π) possui uma lista de atribuições
definida a partir dos atributos simples da subentidade e dos novos valores para estes
atributos. A montagem desta lista de atribuições segue o mesmo princípio utilizado na
operação de atualização de instância de entidade.
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 o
atributo pertence, a relação do atributo objeto interno e a relação da entidade referenciada
por este atributo. Na Tabela 4.8 estes são, respectivamente, Entidade, Objeto Interno
e Entidade Referenciada.
A lista de atributos da operação de projeção (π) é definida pelos atributos
de ligação da entidade de referência mais os subatributos do atributo objeto interno.
Os atributos atribA e atribB da entidade EntidadeRef são definidos como atributos
de ligação. A lista de atributos é definida utilizando o padrão Entidade.atrib, onde
4.2 Geração de DML para Operações CRUD
Relações:
Entidade(pk, atrib1, atrib2, atrib3)
ObjetoInterno(pk, pkEntidade, pkEntidadeRef,
subAtrib1)
EntidadeRef(pk, atribA, atribB)
(a) Obtenção de Instância
πEntidadeRe f .atribA,EntidadeRe f .atribB (
σ Entidade.pk=Ob jetoInterno.pkEntidade AND
Ob jetoInterno.pkEntidadeRe f =EntidadeRe f .pk AND
Entidade.atrib1=val1 AND EntidadeRe f .atrib1=valA AND EntidadeRe f .atrib2=valB
(Entidade × ObjetoInterno × EntidadeRef)
)
(b) Obtenção de Instâncias
πEntidadeRe f .atribA,EntidadeRe f .atribB (
σ Entidade.pk=Ob jetoInterno.pkEntidade AND
Ob jetoInterno.pkEntidadeRe f =EntidadeRe f .pk AND
Entidade.atrib1=val1
(Entidade × ObjetoInterno × EntidadeRef)
)
(c) Inserção de Instância
pkEnt ← π pk (σEntidade.atrib1=val1 (Entidade))
pkEntRef ← π pk (
σEntidadeRe f .atribA=valA AND EntidadeRe f .atribB=valB (EntidadeRef)
)
pkNovo ← max pk (ObjetoInterno) + 1
ObjetoInterno ← ObjetoInterno ∪ {(pkNovo, pkEnt, pkEntRef, subAtrib1)}
(d) Remoção de Instância
pkEnt ← π pk (σEntidade.atrib1=val1 (Entidade))
pkEntRef ← π pk (
σEntidadeRe f .atrib1=valA AND EntidadeRe f .atrib2=valB (EntidadeRef)
)
ObjetoInterno ← ObjetoInterno σOb jetoInterno.pkEntidade=pkEnt AND
Ob jetoInterno.pkEntidadeRe f =pkEntRe f (ObjetoInterno)
(e) Atualização de Instância
pkEnt ← π pk (σEntidade.atrib1=val1 (Entidade))
pkEntRef ← π pk (
σEntidadeRe f .atrib1=valA AND EntidadeRe f .atrib2=valB (EntidadeRef)
)
ObjetoInterno ← πsubatrib1←subval1 (
σOb jetoInterno.pkEntidade=pkEnt AND
Ob jetoInterno.pkEntidadeRe f =pkEntRe f (ObjetoInterno)
)
Tabela 4.8: Operações CRUD sobre Atributo Objeto Interno
55
4.2 Geração de DML para Operações CRUD
56
Entidade é o mnemonico da entidade de referência, e atrib é o mnemonico do atributo
de ligação.
A condição da consulta é definida pelas condições de junção e pela condição para
seleção das instâncias. A consulta terá pelo menos duas condições de junção: uma para
junção entre Entidade e ObjetoInterno e outra para ObjetoInterno e EntidadeRef.
A outra parte da condição é definida pela comparação entre os atributos que formam
a chave lógica da entidade à qual o atributo objeto interno pertence e os valores dos
parâmetros da condição de seleção. Na Tabela 4.8 a chave da consulta é definida por
Entidade.atrib1 = val1, que é a chave lógica da entidade Entidade. Para obtenção
de uma instância, a condição de seleção também considera os atributos que fazem parte
da chave da entidade referenciada.
Na operação de inserção, primeiramente são obtidas as chaves primárias das
instâncias das entidades envolvidas no relacionamento. A chave primária da relação
Entidade é obtida através da consulta na qual a condição vem da comparação entre os atributos que compõem a chave lógica da entidade e seus valores, neste caso
Entidade.atrib1 = val1. A consulta para obtenção de chave primária de entidade referenciada utiliza o mesmo mecanismo. As variáveis pkEnt e pkEntRef armazenam a
chave primária da entidade e entidade de referência do atributo objeto interno.
A nova tupla da relação é definida por valor chave da relação pkNovo, pkEnt,
pkEntRef e a lista de subatributos do atributo objeto interno. No exemplo da Tabela 4.8
o objeto interno possui somente um subatributo, subAtrib1.
No processamento para remoção de instância do atributo do tipo objeto
interno, primeiramente obtém-se as chaves primárias da entidade proprietária do atributo
e da entidade de referência do atributo, da mesma forma feita no processamento para
inserção.
A criação da instrução de remoção é feita a partir da consulta da tupla do atributo
onde o valor da chave estrangeira para a entidade é igual ao valor da variável pkEnt, e
o valor da chave estrangeira para a entidade de referência possui o valor igual à variável
pkEntRef.
O processamento para atualização de atributo do tipo objeto interno é
necessário somente se o atributo possui subatributos. Caso contrário, a troca de instância da entidade de referência é considerada uma atualização, mas pode ser feita a partir
de uma remoção e uma inserção.
Semelhante ao processo de remoção, primeiramente devem ser obtidas as chaves
primárias da entidade proprietária do atributo e da entidade de referência do atributo.
A instrução de atualização de instância é semelhante a uma consulta, mas na
lista de projeção são definidas as atribuições de valores para os atributos da relação
ObjetoInterno. Esta lista é definida pelo formato subatribN ← subvalN, onde suba-
4.2 Geração de DML para Operações CRUD
57
tribN é o subatributo N do atributo e subvalN é a variável que armazena o novo valor.
A Tabela 4.9 apresenta as operações CRUD sobre objeto interno para agregação. A operação de consulta é feita de forma semelhante à consulta gerada pela Tabela
4.8 que define o processamento para consulta de instância de atributo objeto interno.
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 (
σ Entidade.pk=Ob jetoInterno.pkEntidade AND
Ob jetoInterno.pkmnemonicoAtribRe f =AtributoRe f .pk AND
AtributoRe f .pkmnemonicoEnt=Entidade.pk AND
AtributoRe f .pkEntidadeRe f =EntidadeRe f .pk AND
Entidade.atrib1=val1 AND
EntidadeRe f .atribA=valA AND EntidadeAtribRe f .atribX=valX
(Entidade × ObjetoInterno × AtributoRef ×
EntidadeRef × EntidadeAtribRef)
)
(b) Obtenção de Instância
πEntidadeRe f .atribA,EntidadeRe f .atribB,EntidadeAtribRe f .atribX (
σ Entidade.pk=Ob jetoInterno.pkEntidade AND
Ob jetoInterno.pkmnemonicoAtribRe f =AtributoRe f .pk AND
AtributoRe f .pkmnemonicoEnt=Entidade.pk AND
AtributoRe f .pkEntidadeRe f =EntidadeRe f .pk AND
Entidade.atrib1=val1
(Entidade × ObjetoInterno × AtributoRef ×
EntidadeRef × EntidadeAtribRef)
)
Continua na próxima página
4.2 Geração de DML para Operações CRUD
58
Continuação da Tabela 4.9
(c) Inserção de Instância
pkEnt ← π pk (σEntidade.atrib1=val1 (Entidade))
pkNovo ← max pk (ObjetoInterno) + 1
pkAtribRef ← π pk (
σ AtributoRe f .pkEntidadeRe f =EntidadeRe f .pk AND
AtributoRe f .pkEntidadeRe f =EntidadeAtribRe f .pk AND
EntidadeRe f .atribA=valA AND EntidadeAtribRe f .atribX=valX
(EntidadeRef × AtributoRef × EntidadeAtribRef)
ObjetoInterno ← ObjetoInterno ∪ {(pkNovo, pkEnt, pkAtribRef, subAtrib1)}
(d) Remoção de Instância
pkEnt ← π pk (σEntidade.atrib1=val1 (Entidade))
pkAtribRef ← π pk (
σ AtributoRe f .pkEntidadeRe f =EntidadeRe f .pk AND
AtributoRe f .pkEntidadeRe f =EntidadeAtribRe f .pk AND
EntidadeRe f .atribA=valA AND EntidadeAtribRe f .atribX=valX
(EntidadeRef × AtributoRef × EntidadeAtribRef)
ObjetoInterno ← ObjetoInterno σOb jetoInterno.pkEntidade=pkEnt AND
Ob jetoInterno.pkAtributoRe f =pkAtribRe f
(ObjetoInterno)
(e) Atualização de Instância
pkEnt ← π pk (σEntidade.atrib1=val1 (Entidade))
pkAtribRef ← π pk (
σ AtributoRe f .pkEntidadeRe f =EntidadeRe f .pk AND
AtributoRe f .pkEntidadeRe f =EntidadeAtribRe f .pk AND
EntidadeRe f .atribA=valA AND EntidadeAtribRe f .atribX=valX
(EntidadeRef × AtributoRef × EntidadeAtribRef)
)
ObjetoInterno ← πsubatrib1←subval1 (
σOb jetoInterno.pkEntidade=pkEnt AND
Ob jetoInterno.pkAtributoRe f =pkAtribRe f
(ObjetoInterno)
)
As diferenças estão na operação de projeção e na lista de relações da consulta. A
lista de atributos da operação de projeção é definida pelos atributos de ligação da entidade
de referência e da entidade de referência do atributo de referência, mais os subatributos do
atributo objeto interno, representados, respectivamente, por atribA, atribB, atribX
e subatrib1.
4.2 Geração de DML para Operações CRUD
59
A consulta é feita através da junção entre a relação da entidade à qual o atributo
pertence (relação do atributo) e a relação da entidade de referência, relação do atributo
de referência e a relação da entidade de referência do atributo de referência representadas no exemplo por Entidade, ObjetoInterno, EntidadeRef, EntidadeAtribRef e
AtributoRef. A Figura 4.4 apresenta o relacionamento entre estas relações.
A condição de seleção da operação de obtenção de uma instância leva em conta
a chave lógica do tipo de entidade à qual ele pertence (na Tabela 4.9 é o atributo atrib1) e
a chave lógica do atributo objeto interno de referência. A chave lógica deste atributo é a
chave lógica da entidade à qual ele pertence (atributo atribA) mais a chave da entidade de
referência (atributo atribX).
O processo de inserção de instâncias do atributo objeto interno para agregação é semelhante ao definido para o atributo objeto interno (Tabela 4.8), sendo
necessário obter as chaves primárias da entidade proprietária do atributo e do atributo
de referência que representa a agregação.
A consulta para obter a chave primária do atributo de referência é semelhante
à consulta para obtenção de instâncias de atributo objeto interno. A diferença está na
condição da seleção que considera os atributos que fazem parte da chave da entidade de
referência. A nova tupla é definida como ({(pkNovo, pkEnt, pkAtribRef, subAtrib1)}) e
inserida na relação ObjetoInterno.
No processamento para remoção de instância do atributo do tipo objeto
interno para relacionamento com agregação, primeiramente são obtidas e armazenadas
nas variáveis pkEnt e pkAtribRef, respectivamente, as chaves primárias da entidade
proprietária do atributo e do atributo de referência.
Então é feita uma seleção (σ) para obtenção da tupla que será removida. A chave
desta seleção são os valores pkEnt e pkAtribRef comparados, respectivamente, com a
chave estrangeira para a entidade e com a chave estrangeira para o atributo de referência.
Logo, a tupla obtida é removida do conjunto de tuplas da relação ObjetoInterno.
Nas instruções para atualização de instâncias do atributo do tipo objeto
interno para agregação, primeiramente são obtidas e armazenadas nas variáveis pkEnt
e pkAtribRef, respectivamente, as chaves primárias da entidade proprietária do atributo
e do atributo de referência. Então é feita uma seleção (σ) para obtenção da tupla que
será atualizada. A chave desta seleção são os valores pkEnt e pkAtribRef comparados,
respectivamente, com a chave estrangeira para a entidade e com a chave estrangeira para
o atributo de referência.
Na operação de projeção (π) é definida a lista de atribuição composta pelos
subatributos da relação ObjetoInterno e pelos novos valores, seguindo o formato
subatribN ← subvalN, onde subatribN é o subatributo N do atributo, e subvalN é a
variável que armazena o novo valor.
4.2 Geração de DML para Operações CRUD
4.2.4
60
DML para Tipo de Entidade Fraca
Uma entidade fraca possui, no conjunto de atributos que compõem a chave
parcial, um atributo do tipo objeto interno que identifica a entidade da qual a entidade
fraca tem dependência de identificação. A chave lógica da entidade fraca é composta
pelos atributos da chave lógica da entidade de referência do atributo objeto interno que
faz parte da chave (entidade identificadora) mais os atributos simples da chave parcial da
entidade fraca.
Os detalhes das operações CRUD sobre entidade fraca são apresentados na
Tabela 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 os
atributos simples da entidade fraca. A chave lógica da entidade identificadora é retornada,
pois a busca de instâncias de atributos multivalorados, compostos e objetos internos de
entidade fraca não seria possível somente com os valores da chave parcial.
Na operação de seleção (σ) são feitas as junções entre as relações que representam a entidade identificadora, o atributo objeto interno parte de chave e a entidade fraca.
No processamento para obtenção de uma instância da entidade fraca, a
consulta é semelhante à consulta definida na Tabela 4.10 (a). A diferença está na condição
da seleção que contém os atributos que compõem a chave lógica (chave lógica da entidade
identificadora mais chave parcial da entidade fraca).
Na operação de inserção de instância de tipo de entidade fraca, primeiramente
é obtida e armazenada na variável pkEntRef a chave primária da entidade identificadora.
Depois, são inseridos os valores dos atributos simples da entidade fraca na relação
correspondente. Em seguida é obtida e armazenada na variável pkEnt a chave primária da
entidade fraca e, finalmente, as instâncias da entidade identificadora e da entidade fraca
são associadas através da inserção na relação que representa o atributo objeto interno que
faz parte da chave da entidade fraca.
Na operação para remoção de instância de tipo de entidade fraca, o processamento é composto pelas operações de obtenção da chave primária da entidade identificadora e da entidade fraca armazenadas, respectivamente, nas variáveis pkEntRef e
pkEnt. Antes de remover a tupla da entidade fraca é removida a tupla da relação que representa o atributo objeto interno que associa as instâncias da entidade identificadora e da
entidade fraca. Finalmente, a instância da entidade fraca é excluída.
Para a atualização de instâncias de tipo de entidade fraca, a primeira operação
é a obtenção da chave primária da instância da entidade fraca a partir dos parâmetros da
chave lógica antes da modificação. Na operação de projeção (π) é definida a lista de
atribuição composta pelos atributos da relação EntidadeFraca e pelos novos valores,
seguindo o formato atribN ← valN, onde atribN é o atributo N da entidade fraca, e
valN é a variável que armazena o novo valor para atribN.
4.2 Geração de DML para Operações CRUD
Relações:
EntidadeProp(pk, atribA, atribB, atribC)
ObjetoInternoParteChave(pk, pkEntidadeProp, pkEntidadeFraca, subAtrib1)
EntidadeFraca(pk, atrib1, atrib2)
(a) Obtenção de Instâncias
πEntidadeProp.atribA,EntidadeProp.atribB,EntidadeFraca.atrib1,EntidadeFraca.atrib2 (
σ Ob jetoInternoParteChave.pkEnt=mneEntidadeFraca.pk AND
Ob jetoInternoParteChave.pkEntRe f =EntidadeProp.pk
(EntidadeFraca × ObjetoInternoParteChave × EntidadeProp)
)
(b) Obtenção de Instância
πEntidadeProp.atribA,EntidadeProp.atribB,EntidadeFraca.atrib1,EntidadeFraca.atrib2 (
σ Ob jetoInternoParteChave.pkEnt=mneEntidadeFraca.pk AND
Ob jetoInternoParteChave.pkEntRe f =EntidadeProp.pk AND
EntidadeProp.atribA=valA AND EntidadeFraca.atrib1=val1
(EntidadeFraca × ObjetoInternoParteChave × EntidadeProp)
)
(c) Inserção de Instância
pkEntRef ← π pk (σEntidadeProp.atribA=valA (EntidadeProp))
pkEnt ← max pk (EntidadeFraca)
EntidadeFraca ← EntidadeFraca ∪ {(pk, atrib1, atrib2)}
pkNovo ← max pk (mnmonicoObjInternoParteChave)
mnmonicoObjInternoParteChave ← mnmonicoObjInternoParteChave ∪ {(pkNovo,
pkEnt, pkEntRef)}
(d) Remoção de Instância
pkEntRef ← π pk (σEntidadeProp.atribA=valA (EntidadeProp))
pkEnt ← πEntidadeFraca.pk (
σ Ob jetoInternoParteChave.pkEnt=mneEntidadeFraca.pk AND
Ob jetoInternoParteChave.pkEntRe f =EntidadeProp.pk AND
EntidadeProp.atribA=valA AND
EntidadeFraca.atrib1=val1
(EntidadeFraca × ObjetoInternoParteChave × EntidadeProp)
mnmonicoObjInternoParteChave ← mnmonicoObjInternoParteChave σOb jetoInternoParteChave.pkEntidadeProp=pkEntRe f AND
Ob jetoInternoParteChave.pkEntidadeFraca=pkEnt (ObjetoInternoParteChave)
EntidadeFraca ← EntidadeFraca - σEntidadeFraca.pk=pkEnt (EntidadeFraca)
(e) Atualização de Instância
pkEntRef ← π pk (σEntidadeProp.atribA=valANMod (EntidadeProp))
pkEnt ← πEntidadeFraca.pk (
σ Ob jetoInternoParteChave.pkEnt=mneEntidadeFraca.pk AND
Ob jetoInternoParteChave.pkEntRe f =EntidadeProp.pk AND
EntidadeProp.atribA=valANMod AND
EntidadeFraca.atrib1=val1NMod
(EntidadeFraca × ObjetoInternoParteChave × EntidadeProp)
EntidadeFraca ← πatrib1←val1 , atrib2←val2 (σEntidadeFraca.pk=pkEnt (EntidadeFraca))
Tabela 4.10: Operações CRUD sobre Entidade Fraca
61
4.2 Geração de DML para Operações CRUD
4.2.5
62
DML para Atributo Composto
As operações CRUD sobre atributo composto são detalhadas na Tabela 4.11. Na
operação de projeção são considerados os subatributos simples monovalorados do atributo
composto (subAtrib1, subAtrib2, subAtrib3). Na operação de seleção é estabelecida a
junção entre as relações que representam a entidade e o atributo composto (Entidade ×
AtributoComp).
A lista de condições da operação de seleção possui a condição de junção
(Entidade.pk = AtributoComp.pkEntidade) e a condição de seleção da instância da
entidade à qual o atributo pertence. No exemplo, o atributo atrib1 é a chave lógica da
entidade. Para obtenção de uma instãncia de atributo composto a condição de seleção
considera também os atributos que fazem parte da chave parcial.
O processo de inserção de instâncias do atributo composto é iniciado com
a obtenção da chave primária da entidade. O valor da chave é armazenado na variável
pkEnt. Depois, é criada a nova tupla da relação AtributoComposto {(pkNovo, pkEnt,
subval1, subval2, subval3)}. A variável pkNovo é a chave primária da tupla obtida
a partir do maior valor do atributo pk mais um; pkEnt é a chave primária da entidade; e subval1, subval2, subval3 são os valores para os subatributos subatrib1,
subatrib2, subatrib3. A nova tupla é inserida no conjunto de tuplas da relação
AtributoComposto através da operador de união de conjuntos (∪).
Nas instruções para remoção de instâncias do atributo composto, o processamento é iniciado com a instrução para obter a chave primária da entidade. A chave é
armazenada na variável pkEnt. Depois, é obtida a chave primária do atributo composto
levando em conta os valores da chave lógica da entidade (pkEnt) mais a chave parcial
do atributo composto (subAtrib1 e subAtrib2). O valor da chave primária do composto
é armazenada na variável pkComp. Então é removida a tupla que possui chave primária
igual ao valor armazenado na variável pkComp.
O processamento para atualização de instâncias do atributo composto é
iniciado com a instrução para obter a chave primária da entidade. Depois, uma segunda
instrução obtém a chave primária do atributo composto, levando em conta a chave
primária da entidade mais a chave parcial do atributo composto não modificada. A tupla
na qual a chave primária tem o valor pkComp é obtida utilizando a operação de seleção.
Na operação de projeção são definidas as atribuições, considerando os subatributos do
atributo composto e seus novos valores.
4.2.6
DML para Atributo Simples Multivalorado
A Tabela 4.12 apresenta as operações sobre instâncias de atributo simples multivalorado. A operação de projeção é definida com o atributo valor da relação Atributo.
4.2 Geração de DML para Operações CRUD
Relações:
Entidade(pk, atrib1, atrib2, atrib3)
AtributoComp(pk, pkEntidade, subAtrib1, subAtrib2,
subAtrib3)
(a) Obtenção de Instâncias
πAtributoComp.subAtrib1,AtributoComp.subAtrib2,AtributoComp.subAtrib3 (
σ Entidade.pk=AtributoComp.pkEntidade AND
Entidade.atrib1=val1
(Entidade × AtributoComp)
)
(b) Obtenção de Instância
πAtributoComp.subAtrib1,AtributoComp.subAtrib2,AtributoComp.subAtrib3 (
σ Entidade.pk=AtributoComp.pkEntidade AND
Entidade.atrib1=val1
AtributoComp.subAtrib1=subval1 AND
AtributoComp.subAtrib2=subval2
(Entidade × AtributoComp)
)
(c) Inserção de Instância
pkEnt ← π pk (σEntidade.atrib1=val1 (Entidade))
pkNovo ← max pk (AtributoComposto) + 1
AtributoComp ← AtributoComp ∪ {(pkNovo, pkEnt, subval1,
subval2, subval3)
(d) Remoção de Instância
pkEnt ← π pk (σEntidade.atrib1=val1 (Entidade))
pkComp ← π pk (σAtributoComp.pkEntidade=pkEnt AND
AtributoComp.subAtrib1=subval1 AND
AtributoComp.subAtrib2=subval2 (AtributoComp))
AtributoComp ← AtributoComp - σAtributoComp.pk=pkComp (AtributoComp)
(e) Atualização de Instância
pkEnt ← π pk (σEntidade.atrib1=val1 (Entidade))
pkComp ← π pk (σAtributoComp.pkEntidade=pkEnt AND
AtributoComp.subAtrib1=subval1NMod AND
AtributoComp.subAtrib2=subval2NMod (AtributoComp))
AtributoComp ← πsubAtrib1←subval1 , subAtrib2←subval2 , subAtrib3←subval3 (
σAtributoComp.pk=pkComp (AtributoComp)
)
Tabela 4.11: Operações CRUD sobre Atributo Composto
63
4.2 Geração de DML para Operações CRUD
64
Relações:
Entidade(pk, atrib1, atrib2, atrib3)
Atributo(pk, valor)
(a) Obtenção de Instâncias
πAtributo.valor (
σ Entidade.pk=Atributo.pkEntidade AND Entidade.atrib1=val1 (Entidade × Atributo))
(b) Inserção de Instância
pkEnt ← π pk (σEntidade.atrib1=val1 (Entidade))
Atributo ← Atributo ∪ {(pkEnt, valor)}
(c) Remoção de Instância
pkEnt ← π pk (σEntidade.atrib1=val1 (Entidade))
Atributo ← Atributo - {(pkEnt, valor)}
(d) Atualização de Instância
pkEnt ← π pk (σEntidade.atrib1=val1 (Entidade))
Atributo ← πvalor←val (σAtributo.pkEnt=pkEnt AND Atributo.valor=valNMod (Atributo))
Tabela 4.12: Operações CRUD sobre Atributo Multivalorado
A operação de seleção é definida a partir da junção entre as relações da entidade e do
atributo multivalorado. A condição da operação de seleção possui a condição de junção
(Entidade.pk = Atributo.pkEntidade) e a condição de seleção de instância da entidade à
qual o atributo pertence. No exemplo o atributo atrib1 é a chave lógica da entidade com
a condição Entidade.atrib1 = val1.
Na operação de inserção de instâncias do atributo simples multivalorado, o
processamento é iniciado com a instrução para obter a chave primária da entidade. Depois,
é criada a nova tupla da relação Atributo (pkEnt, val), onde pkEnt é a chave primária
da entidade e val é o valor do atributo multivalorado. A nova tupla é inserida no conjunto
de tuplas da relação Atributo através da operador de união de conjuntos (∪).
O processamento da operação para remoção de instância do atributo simples
multivalorado é iniciado com a instrução para obter a chave primária da entidade. A
chave da entidade é armazenada na variável pkEnt. Depois, é removida a tupla que tem o
formato {(pkEnt, valor)} que é a chave da relação Atributo.
Na operação de atualização de instância do atributo simples multivalorado
o processamento é iniciado com a instrução para obtenção da chave primária da entidade
(valor do atributo pk). A busca da instância do atributo multivalorado é feita a partir da
condição de seleção que envolve a chave primária da entidade (armazenada na variável
pkEnt) e o valor do atributo antes da modificação (variável valNMod). O parâmetro val
contém o novo valor do atributo.
4.3 Mapeamento do MR para PostgreSQL
MR
Alfanumérico
Inteiro
Decimal
Data
Booleano
65
SQL (PostgreSQL)
VARCHAR
INTEGER
DOUBLE PRECISION
DATE
BOOLEAN
Tabela 4.13: Conversão de Tipo/Domínio do MR para SQL
4.3
Mapeamento do MR para PostgreSQL
O processo de geração do esquema do BD do SI no componente EBD é dividido
em duas etapas: a primeira é o mapeamento do MMO para o MR (MR); na segunda etapa
o MR é mapeado para um dialeto SQL. Nesta seção são apresentados os mapeamentos do
MR para o SQL do SGBD PostgreSQL 8.4 [53].
4.3.1
Geração de Tabelas
No mapeamento do MMO para o MR foi determinada como decisão de projeto
a criação de uma chave artificial para cada relação. Este atributo é um inteiro que é incrementado automaticamente toda vez que é feita um inserção na relação. O PostgreSQL
possui o domínio SERIAL com estas características.
Outra restrição em relação ao mapeamento para SQL é a utilização das instruções
ON UPDATE RESTRICT e ON DELETE RESTRICT na criação de chave estrangeira,
evitando a atualização ou remoção em cadeia de informações do SI.
Na geração das tabelas e das stored procedures é necessário mapear os domínios
dos atributos do MR para os tipos de dados em SQL. A Tabela 4.13 apresenta este
mapeamento.
A criação da tabela envolve a criação de duas listas: lista de atributos e lista
de restrições. O Código 4.2 apresenta um exemplo de estrutura de tabela modelo do
PostgreSQL.
Código 4.2 Tabela Modelo em PostgreSQL
1
2
3
4
5
6
7
CREATE TABLE mnemonicoEntidade (
pk SERIAL,
listaAtributos,
...
PRIMARY KEY (pk),
listaRestrições,
);
No mapeamento do MR para SQL as relações são mapeadas para tabelas. A
Tabela 4.14 apresenta este mapeamento. O nome da tabela é o mesmo nome da relação,
4.3 Mapeamento do MR para PostgreSQL
66
MR
SQL
Nome da Relação
Conjunto de Atributos da Relação
Restrição de unicidade sobre o conjunto
de atributos
Restrição de Unicidade sobre atributo
Inclusão do atributo pk com restrição primary key
Restrição foreign key sobre o atributo pk
referenciando a relação correspondente à
Entidade Genérica
Nome da Tabela
Conjunto de colunas da Tabela
Restrição UNIQUE sobre o conjunto de
atributos
Restrição UNIQUE sobre o atributo
Inclusão do atributo pk com tipo SERIAL
e restrição PRIMARY KEY
Restrição FOREIGN KEY sobre a coluna
pk referenciando a tabela que representa a
relação genérica da especialização.
Tabela 4.14: Mapeamento de Relação "Entidade" do MR para
SQL
assim como os nomes das colunas da relação são os mesmos dos atributos da tabela. Na
definição da tabela, cada atributo é associado a um tipo do SQL, conforme mapeamento
definido na Tabela 4.13.
As restrições de integridade, de chave primária e unicidade são mapeadas para as
cláusulas PRIMARY KEY e UNIQUE do SQL. A chave primária da tabela é o atributo pk,
e os atributos que formam a chave lógica são colocados na cláusula UNIQUE. Aqueles
atributos que possuem restrição de unicidade também são colocados em uma cláusula
UNIQUE.
No mapeamento de relação correspondente a entidade fraca, a única diferença
é que na relação da entidade fraca não há a cláusula UNIQUE com os atributos que fazem
parte da chave parcial.
No mapeamento de hierarquia de especialização o atributo pk da relação
especializada é mapeado para um atributo do tipo INTEGER.
O mapeamento definido na Tabela 4.14 especifica que a relação da subentidade
tem uma chave estrangeira para a superentidade. Na tabela da subentidade é utilizada a
cláusula FOREIGN KEY para definir esta restrição de integridade referencial.
Os atributos pk, pkEnt e pkEntRef que aparecem em relações correspondentes
ao mapeamento de objeto interno pertencem ao domínio inteiro no MR. Eles são mapeados para SERIAL, INTEGER e INTEGER, respectivamente em SQL. O atributo pk é
definido como PRIMARY KEY da tabela e os atributos pkEnt e pkEntRef são definidos
como chaves estrangeiras das tabelas Entidade e EntidadeRef, respectivamente, utilizando a cláusula FOREIGN KEY do SQL.
Para garantir a integridade do relacionamento, os atributos pkEnt e pkEntRef
recebem a restrição NOT NULL. A unicidade da ligação é mapeada utilizando a cláusula
UNIQUE aplicada aos atributos pkEnt e pkEntRef. O Código 4.3 apresenta a tabela
resultante do mapeamento da Tabela 4.15.
4.3 Mapeamento do MR para PostgreSQL
67
MR
SQL
Nome da Relação
Inclusão de atributo pk com restrição primary key
Inclusão de atributo pkEnt com restrição
de não nulidade foreign key referenciando
a relação correspondente à entidade que
contém o atributo objeto interno
Inclusão do atributo pkEntRef com restrição de não nulidade e foreign key referenciando a relação correspondente à Entidade Referenciada pelo atributo objeto interno
Inclusão do atributo pkAtribRef com restrição de não nulidade e foreign key referenciando a relação correspondente ao
Atributo Referenciado pelo atributo objeto
interno
Nome da Tabela
Criação da coluna pk com tipo SERIAL e
restrição PRIMARY KEY
Criação do Atributo pkEnt com restrição
FOREIGN KEY referenciando a tabela
representada pela relação da entidade à
qual o atributo objeto interno pertence
Inclusão da restrição de unicidade para o
par (pkEnt, pkEntRef ) ou no caso de relacionamento com agregação (pkEnt, pkAtribRef )
Criação do Atributo pkEntRef com restrição FOREIGN KEY referenciando a
tabela representada pela relação da entidade referenciada
Criação do Atributo pkAtribRef e com
restrição FOREIGN KEY referenciando a
tabela representada pela relação do atributo referenciado
Aplicação da restrição UNIQUE sobre o
par de colunas pkEnt, pkEntRef ou no par
pkEnt, pkAtribRef
Tabela 4.15: Mapeamento de Relação "Atributo Objeto Interno"
do MR para o SQL
Código 4.3 Tabela Modelo para Criação de Atributo Objeto Interno
1
2
3
4
5
CREATE TABLE ObjetoInterno (
pk SERIAL,
pkEnt INTEGER NOT NULL,
pkEntRef INTEGER NOT NULL,
lista de atributos do relacionamento (opcional),
6
PRIMARY KEY (pk),
FOREIGN KEY (pkEnt) REFERENCES Entidade(pk)
ON UPDATE RESTRICT ON DELETE RESTRICT,
7
8
9
10
FOREIGN KEY (pkEntRef) REFERENCES EntidadeRef(pk)
ON UPDATE RESTRICT ON DELETE RESTRICT,
FOREIGN KEY (pkAtribRef) REFERENCES AtributoRef(pk)
ON UPDATE RESTRICT ON DELETE RESTRICT,
UNIQUE (pkEnt, pkEntRef) -- ou restrição UNIQUE (pkEnt, pkAtribRef)
11
12
13
14
15
16
);
A Tabela 4.16 apresenta os detalhes do mapeamento de uma relação que corre-
4.3 Mapeamento do MR para PostgreSQL
68
MR
Nome da Relação
Inclusão de atributo pk com restrição de
não nulidade foreign key referenciando
a relação correspondente à entidade que
contém o atributo multivalorado
Inclusão do atributo com o nome valor na
relação
Inclusão da restrição de primary key sobre
o atributo pk e o atributo valor
SQL
Nome da Tabela
Criação da Coluna pk com a restrição
FOREIGN KEY para a tabela que corresponde a tabela da entidade
Criação da coluna valor; o domínio é
obtido através do mapeamento do MMO
para MR e deste para SQL
Aplicação da restrição PRIMARY KEY
sobre as colunas pk e valor
Tabela 4.16: Mapeamento de Relação "Atributo Multivalorado"
do MR para SQL do PostgreSQL
MR
SQL
Nome da Relação
Inclusão de atributo pk com restrição primary key
Inclusão de atributo pkEnt com restrição
de não nulidade foreign key referenciando
a relação correspondente à entidade que
contém o atributo multivalorado
Conjunto de Atributos da Relação
Inclusão da restrição de unicidade sobre o
atributo pkEnt e o conjunto de atributos
Nome da Tabela
Criação da coluna pk com a restrição PRIMARY KEY
Criação da coluna pkEnt com restrições
NOT NULL e FOREIGN KEY referenciando à tabela da entidade
Conjunto de colunas da tabela
Aplicação da restrição UNIQUE sobre a
coluna pkEnt e o subconjunto de colunas
Tabela 4.17: Mapeamento de Relação "Atributo Composto" do
MR para o SQL do PostgreSQL
sponde a um atributo multivalorado. A tabela recebe o mesmo nome da relação. A relação possui duas colunas, uma pk e valor, as quais possuem, respectivamente, domínio
inteiro e um domínio permitido no MR. Este domínio é definido a partir do domínio do
atributo que foi mapeado do MMO para MR.
As colunas pk e valor são definidas como PRIMARY KEY. A coluna pk é chave
estrangeira para a entidade à qual o atributo pertence.
Os detalhes do mapeamento para uma relação que corresponde a um atributo
composto são apresentados na Tabela 4.17. A coluna pkEnt é chave estrangeira para a
relação da entidade à qual o atributo pertence. Na Tabela 4.17 a clásula UNIQUE é a chave
lógica da tabela que representa o atributo composto. Esta chave é composta pela coluna
pkEnt e as colunas que fazem parte da chave parcial.
4.3 Mapeamento do MR para PostgreSQL
4.3.2
69
Geração de Stored Procedures (SP) em PL/pgSQL
Esta seção apresenta os mapeamentos de stored procedures (SP) para manipulação de instâncias de entidade, hierarquia de especialização, atributo do tipo objeto
interno, atributo composto e atributo simples multivalorado. A linguagem alvo utilizada
neste mapeamento é a linguagem procedural do SGBD PostgreSQL, a PL/pgSQL [52].
A maioria dos frameworks ORM para linguagem Java utilizam JPA [49] para
gerenciar o mapeamento objeto relacional. Nesta abordagem as operações são geradas em
tempo de execução. Um experimento foi feito para decidir entre stored procedures e SQL
dinâmico. Neste experimento, foi criada uma tabela com quatro colunas. Em um programa
Java foi criado um loop, que armazenava uma tupla na tabela a cada iteração. A eficiência
foi medida em relação ao número de tuplas persistidas utilizando stored procedure e SQL
dinâmico. No teste com centena de milhares de tuplas o programa travou, utilizando SQL
dinâmico. Com o mesmo número de tuplas, a stored procedure persistiu as informações
sem travar o programa.
O nome das stored procedures é obtido a partir da concatenação da operação
(inserir, desativar, atualizar, obter) com o nome da relação. O Código 4.4 apresenta o
modelo de stored procedure do PL/pgSQL. As stored procedures para operações de
inserção, remoção e atualização sempre retornam um valor booleano true (o tratamento
de exceções é feito no componente de persitência EBD no subpacote Serviços de Acesso
a Dados), enquanto as stored procedures de obtenção retornam um cursor. Em PL/pgSQL,
um cursor é uma estrutura que encapsula uma consulta e permite acessar algumas linhas
do resultado por vez.
Código 4.4 Modelo de Stored Procedure em PL/pgSQL
1
2
3
4
5
6
7
8
CREATE FUNCTION operacaoMnemonico(listaParametros) RETURNS Retorno AS $$
DECLARE
declaracaoVariaveis
BEGIN
instrucoes
RETURN ValorRetorno;
END;
$$ LANGUAGE ’plpgsql’;
O componente EBD faz a geração de dois tipos de stored procedure de consulta,
uma para consulta de todas as instâncias de uma entidade e outra para consulta de uma
instância específica. A Tabela 4.18 apresenta o mapeamento do MR para SQL para as
operações CRUD sobre tipo de entidade.
Nas operações de obtenção, a lista de atributos da operação de projeção (π) é
mapeada para a lista da cláusula SELECT do SQL. Na cláusula FROM é colocado o
nome da relação.
4.3 Mapeamento do MR para PostgreSQL
70
Para criar uma SP para obtenção de uma instância da entidade, o mapeamento
descrito na Tabela 4.18 é executado. A cláusula WHERE recebe a condição da operação
de seleção (σ), que faz a comparação dos atributos chave da relação (atrib1 e atrib2)
com os valores de pesquisa (val1 e val2).
A SP para obtenção de uma instância de entidade deve receber como parâmetro
os valores da chave lógica da entidade. As variáveis val1 e val2 são mapeadas para a
lista de parâmetros da stored procedure. A lista de parâmetros de uma stored procedure
em PL/pgSQL é definida com o nome da variável mais o tipo em SQL. O tipo é definido
a partir do domínio no MR, que é mapaeado para o tipo em SQL de acordo com a Tabela
4.13. O Código 4.5 apresenta o resultado do mapeamento descrito na Tabela 4.18 para a
operação de obtenção de uma instância.
Código 4.5 Stored Procedure Modelo para Obtenção de Instâncias de Tipo de Entidade
1
2
3
4
5
6
7
8
9
CREATE FUNCTION obterEntidadeAtivo(va1 TipoSQL, val2 TipoSQL) RETURNS
CURSOR AS $$
DECLARE
csr CURSOR;
BEGIN
OPEN csr FOR
SELECT atrib1, atrib2, atrib3
FROM Entidade
WHERE Entidade.atrib1 = val1 AND Entidade.atrib2 = val2;
10
11
12
13
RETURN csr;
END;
$$ LANGUAGE ’plpgsql’;
No mapeamento para geração de stored procedure de inserção de instância de
entidade, a instrução INSERT possui duas listas, uma com os atributos da tabela que
recebem os valores e uma com os valores dos parâmetros. A primeira lista é obtida a
partir da lista de atributos da relação menos o atributo pk e a lista de valores (val1,
val2, val3) da instrução de inserção no MR.
A instrução para calcular a chave primária da nova tupla (pkEnt ←
max pk (Entidade)) não precisa ser mapeada para o PostgreSQL, pois a variável pk
é mapeada com o tipo SERIAL, incrementada automaticamente toda vez que é feita uma
inserção na tabela.
A lista de parâmetros é formada pela lista de variáveis correspondentes aos
atributos da relação que representa a entidade. O Código 4.6 apresenta o modelo da stored
procedure gerada a partir do mapeamento da operação de inserção de instância de entidade
mapeada na Tabela 4.18.
4.3 Mapeamento do MR para PostgreSQL
MR
71
SQL
(a) Obtenção de Instâncias
πatrib1,atrib2,atrib3 (Entidade)
SELECT atrib1, atrib2, atrib3
FROM Entidade
(b) Obtenção de Instância
πatrib1,atrib2,atrib3 (
SELECT atrib1, atrib2, atrib3
σEntidade.atrib1=val1 AND Entidade.atrib2=val2
FROM Entidade
WHERE Entidade.atrib1 = val1 AND En(Entidade))
tidade.atrib2 = val2
(c) Inserção de Instância
pkEnt ← max pk (Entidade) + 1
mnmonicoEntidade ← Entidade ∪ INSERT INTO Entidade (atrib1, atrib2,
{(pkEnt, val1, val2, val3)}
atrib3) VALUES (val1, val2, val3)
(d) Remoção de Instância
pkEnt ← π pk (σEntidade.atrib1=val1 AND
SELECT INTO pkEnt pk
FROM Entidade
(Entidade))
Entidade.atrib2=val2
WHERE Entidade.atrib1 = val1 AND
Entidade.atrib2 = val2;
DELETE FROM Entidade WHERE pk =
Entidade ← Entidade pkEnt;
σEntidade.pk=pkEnt (Entidade)
(e) Atualização de Instância
pkEnt ← π pk (σEntidade.atrib1=val1NMod AND SELECT INTO pkEnt pk
FROM Entidade
Entidade.atrib2=val2NMod (Entidade))
WHERE Entidade.atrib1 = val1NMod
AND
Entidade.atrib2 = val2NMod;
Entidade ←
UPDATE Entidade
SET atrib1 = val1, atrib2 = val2, atrib3 =
πatrib1←val1 , atrib2←val2 , atrib3←val3 (
val3
σEntidade.pk=pkEnt (Entidade))
WHERE pk = pkEnt;
Tabela 4.18: Mapeamento de Operações CRUD sobre Tipo de Entidade
4.3 Mapeamento do MR para PostgreSQL
72
Código 4.6 Stored Procedure Modelo para Inserção de Instância de Tipo de Entidade
1
2
3
CREATE FUNCTION inserirEntidade(val1 TipoSQL,val2 TipoSQL,val3 TipoSQL)
RETURNS BOOLEAN AS $$
BEGIN
4
5
INSERT INTO Entidade (atrib1, atrib2, atrib3) VALUES (val1, val2, val3);
6
7
8
9
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
No mapeamento para remoção de instância de entidade, a instrução para obter
a chave primária (pk) é mapeada para SQL utilizando a instrução SELECT INTO. As
cláusulas FROM e WHERE da consulta são as mesmas usadas para obtenção de uma instância.
A operação de exclusão (Entidade ← Entidade - σEntidade.pk=pkEnt
(Entidade) é mapeada para a instrução DELETE, e a condição da seleção (σ) é
mapeada para a cláusula WHERE. A stored procedure recebe como parâmetro os valores
dos atributos que formam a chave lógica da relação. O modelo da stored procedure
resultante do mapeamento é apresentada no Código 4.7.
Código 4.7 Stored Procedure Modelo para Remoção de Instância de Tipo de Entidade
1
2
3
4
CREATE FUNCTION desativarEntidade (va1 TipoSQL, val2 TipoSQL)
RETURNS BOOLEAN AS $$
DECLARE
pkEnt INTEGER;
5
6
BEGIN
7
8
9
10
SELECT INTO pkEnt pk
FROM Entidade
WHERE Entidade.atrib1 = val1 AND Entidade.atrib2 = val2;
11
12
DELETE FROM Entidade WHERE pk = pkEnt;
13
14
15
16
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
No mapeamento para operação de atualização de instância de entidade, a
instrução para obtenção da chave primária é mapeada para a instrução SELECT INTO de
SQL. A cláusula WHERE é definida partir de uma lista de comparação da operação de
seleção no MR. Neste exemplo é a lista de condição Entidade.atrib1 = val1NMod
AND Entidade.atrib2 = val2NMod.
4.3 Mapeamento do MR para PostgreSQL
73
Na instrução UPDATE é definida uma lista de atribuição dos atributos, com seus
respectivos parâmetros separados por vírgula. Esta lista é obtida através da lista da
operação de projeção (π). Antes de atribuir a lista à cláusula SET é feita a conversão do
operador de atribuição (←) de álgebra relacional para o operador de atribuição no SQL
(=). A cláusula WHERE recebe a lista de condições da operação de seleção para obtenção
da tupla que será atualizada.
A lista de parâmetros da stored procedure é definida pelos valores da chave
lógica da entidade antes da modificação e pelos valores dos atributos da relação. Na stored
procedure do Código 4.8 a chave lógica da relação é composta pelos atributos atrib1 e
atrib2 e a lista de parâmetros é definida pelos valores val1NMod, val2NMod, val1,
val2 e val3.
Código 4.8 Stored Procedure Modelo para Atualização de Instância de Tipo de Entidade
1
2
3
4
5
CREATE FUNCTION atualizarEntidade (va1NMod TipoSQL,
val2NMod TipoSQL, val1 TipoSQL, val2 TipoSQL, val3 TipoSQL)
RETURNS BOOLEAN AS $$
DECLARE
pkEnt INTEGER;
6
7
BEGIN
8
9
10
11
12
SELECT INTO pkEnt pk
FROM Entidade
WHERE Entidade.atrib1 = val1NMod AND
Entidade.atrib2 = val2NMod;
13
14
15
16
UPDATE Entidade
SET atrib1 = val1, atrib2 = val2, atrib3 = val3
WHERE pk = pkEnt;
17
18
19
20
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
A Tabela 4.19 apresenta o mapeamento do MR para SQL para operações CRUD
sobre tipo de entidade especializada. Nas operações de consulta, a lista de atributos
da operação de projeção (π) é mapeada para a lista da cláusula SELECT. A lista de
relações da operação de seleção é mapeada para a cláusula FROM, substituindo o produto
cartesiano (×) pelo operador de junção (JOIN). No PostgreSQL a condição de junção
pode ficar na clásula FROM, então a condição da operação de seleção é mapeada para a
cláusula FROM da consulta em SQL.
4.3 Mapeamento do MR para PostgreSQL
74
Para criar a SP para obtenção de uma instância de entidade especializada, o
mapeamento segue a definição da Tabela 4.19. A cláusula WHERE recebe a condição
da operação de seleção (σ), que faz a comparação dos atributos chave da relação que
corresponde à superentidade (atribA) com os valores de pesquisa (valA).
A stored procedure para obtenção de uma instância de entidade especializada
recebe como parâmetro os valores da chave lógica da superentidade. A variável valA é
mapeada para a lista de parâmetros da stored procedure. O Código 4.9 apresenta o modelo
da SP resultante do mapeamento.
Código 4.9 Stored Procedure Modelo para Obtenção de Instâncias de Tipo de Entidade
Especializada
1
2
3
4
5
6
7
8
9
10
CREATE FUNCTION obterSubEntidadeAtivo(valA TipoSQL)
RETURNS CURSOR AS $$
DECLARE
csr CURSOR;
BEGIN
OPEN csr FOR
SELECT atribA, atribB, atrib1, atrib2, atrib3
FROM SuperEntidade JOIN SubEntidade
ON SuperEntidade.pk = SubEntidade.pk
WHERE SuperEntidade.atribA = valA;
11
12
13
14
RETURN csr;
END;
$$ LANGUAGE ’plpgsql’;
No mapeamento para geração de stored procedure de inserção de instância
de entidade especializada, primeiramente é inserida a instância da superentidade. A
instrução INSERT possui duas listas, uma com os atributos da tabela que recebem os
valores e uma com os parâmetros contendo os valores. A primeira lista é obtida a partir
da lista de atributos da relação da superentidade (menos o atributo pk) e a lista de valores
(valA, valB) vem da instrução de inserção no MR (menos a variável pkEnt).
A chave primária da superentidade é propagada para toda a cadeia de especialização, e para isso é definida a instrução pkEnt ← max pk (SuperEntidade) para obter
a chave após a inserção. Esta instrução é mapeada para a instrução SELECT INTO pkEnt
* FROM lastval() que obtém o último valor incrementado, dentro da transação, para
colunas do tipo SERIAL.
O mapeamento da instrução de inserção para subentidade segue o mesmo princípio da instrução para inserção de instância da superentidade. A stored procedure de inserção para entidade especializada recebe como parâmetros os valores dos atributos da
4.3 Mapeamento do MR para PostgreSQL
MR
75
SQL
(a) Obtenção de Instâncias
SELECT atribA, atribB, atrib1, atrib2,
πatribA,atribB,atrib1,atrib2,atrib3 (
atrib3
σSuperEntidade.pk=SubEntidade.pk
FROM SuperEntidade JOIN SubEntidade
(SuperEntidade × SubEntidade)
ON SuperEntidade.pk = SubEntidade.pk;
)
(b) Obtenção de Instância
SELECT atribA, atribB, atrib1, atrib2,
πatribA,atribB,atrib1,atrib2,atrib3 (
atrib3
σSuperEntidade.pk=SubEntidade.pk AND
FROM SuperEntidade JOIN SubEntidade
SuperEntidade.atribA=valA (SuperEntidade ×
ON SuperEntidade.pk = SubEntidade.pk
SubEntidade)
)
WHERE SuperEntidade.atribA = valA;
(c) Inserção de Instância
pkEnt ← max pk (SuperEntidade) + 1
SuperEntidade ← SuperEntidade ∪ INSERT INTO SuperEntidade (atribA,
{(pkEnt, valA, valB)}
atribB) VALUES (valA, valB);
pkEnt ← max pk (SuperEntidade)
SELECT INTO pkEnt * FROM lastval();
SubEntidade ← SubEntidade ∪ {(pkEnt, INSERT INTO SubEntidade (pk, atrib1,
val1, val2, val3)}
atrib2, atrib3) VALUES
(pkEnt, val1, val2, val3);
(d) Remoção de Instância
pkEnt ← π pk (
SELECT INTO pkEnt pk
σSuperEntidade.atribA=valA (SuperEntidade)) FROM SuperEntidade
WHERE SuperEntidade.atribA = valA;
DELETE FROM SubEntidade WHERE
SubEntidade ← SubEntidade pk = pkEnt;
σSubEntidade.pk=pkEnt (SubEntidade)
(e) Atualização de Instância
pkEnt ← π pk (
SELECT INTO pkEnt pk
σSuperEntidade.atribA=valANMod
FROM SuperEntidade
WHERE SuperEntidade.atribA = valAN(SuperEntidade))
Mod;
UPDATE SuperEntidade SET atribA =
SuperEntidade ←
valA, atribB = valB
πatribA←valA , atribB←valB (
WHERE pk = pkEnt;
σSuperEntidade.pk=pkEnt (SuperEntidade))
)
UPDATE SubEntidade SET atrib1 = val1,
SubEntidade ←
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 Entidade Especializada
4.3 Mapeamento do MR para PostgreSQL
76
superentidade e da subentidade. O Código 4.10 apresenta o modelo da stored procedure
resultante deste mapeamento.
Código 4.10 Stored Procedure Modelo para Inserção de Instância de Tipo de Entidade
Especializada
1
2
3
4
5
6
7
8
9
10
11
12
CREATE FUNCTION inserirSubEntidade (valA TipoSQL, valB TipoSQL,
val1 TipoSQL, val2 TipoSQL, val3 TipoSQL) RETURNS BOOLEAN AS
DECLARE
pkEnt INTEGER;
BEGIN
INSERT INTO SuperEntidade (atribA, atribB) VALUES (valA, valB);
SELECT INTO pkEnt * FROM lastval();
INSERT INTO SubEntidade (pk, atrib1, atrib2, atrib3)
VALUES (pkEnt, val1, val2, val3);
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
No mapeamento para geração de stored procedure de remoção de instância de
entidade especializada, a instrução pkEnt ← π pk (σSuperEntidade.atribA=valA (SuperEntidade))
é mapeada para a instrução SQL: SELECT INTO pkEnt pk FROM SuperEntidade
WHERE SuperEntidade.atribA = valA.
A instrução de exclusão em álgebra relacional é mapeada para a instrução
DELETE em SQL. A tabela da cláusula DELETE é o nome da relação, e a condição
da cláusula WHERE é a condição da operação de seleção (σ).
A SP de remoção para entidade especializada recebe como parâmetros os valores dos atributos que compõem a chave lógica da superentidade. O modelo da stored
procedure do Código 4.11 é obtido a partir do mapeamento descrito na Tabela 4.19.
Código 4.11 Stored Procedure Modelo para Remoção de Instância de Tipo de Entidade
Especializada
1
2
3
4
5
6
7
8
9
10
CREATE FUNCTION desativarSubEntidade (valA TipoSQL)RETURNS BOOLEAN AS $$
DECLARE
pkEnt INTEGER;
BEGIN
SELECT INTO pkEnt pk FROM SuperEntidade
WHERE SuperEntidade.atribA = valA;
DELETE FROM SubEntidade WHERE pk = pkEnt;
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
4.3 Mapeamento do MR para PostgreSQL
77
No mapeamento para geração de stored procedure de atualização de instância
de entidade especializada, cada entidade possui uma instrução UPDATE para atualização de seus atributos.
Na instrução UPDATE para superentidade é definida uma lista de atribuição dos
atributos com seus respectivos parâmetros separados por vírgula. Esta lista é obtida
através da lista da operação de projeção (π). Antes de atribuir a lista à cláusula SET é
feita a conversão do operador de atribuição (←) de álgebra relacional para o operador de
atribuição em SQL (=). O mapeamento da instrução de atualização para subentidade é
feito da mesma forma.
A cláusula WHERE recebe a lista de condições da operação de seleção para
obtenção da tupla que será atualizada. A stored procedure de atualização recebe como
parâmetros os valores dos atributos da chave lógica da superentidade antes da modificação, os valores de todos os atributos da superentidade e os valores dos atributos simples
da subentidade. O modelo da stored procedure resultante do mapeamento é apresentado
no Código 4.12
Código 4.12 Stored Procedure Modelo para Atualização de Instância de Tipo de Entidade
Especializada
1
2
3
4
CREATE FUNCTION atualizarSubEntidade (valANMod TipoSQL,
valA TipoSQL, valB TipoSQL, val1 TipoSQL, val2 TipoSQL,
val3 TipoSQL) RETURNS BOOLEAN AS $$
BEGIN
5
6
7
8
SELECT INTO pkEnt pk
FROM SuperEntidade
WHERE SuperEntidade.atribA = valANMod;
9
10
11
12
UPDATE SuperEntidade
SET atribA = valA, atribB = valB
WHERE pk = pkEnt;
13
14
15
16
UPDATE SubEntidade
SET atrib1 = val1, atrib2 = val2, atrib3 = val3
WHERE pk = pkEnt;
17
18
19
20
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
Todas as SP de operações CRUD para relações que representam atributo do
tipo objeto interno recebem como parâmetro os valores da chave lógica da entidade à
qual o atributo pertence. Na operação de consulta, somente a chave lógica da entidade é
4.3 Mapeamento do MR para PostgreSQL
78
passada como parâmetro. Nas operações de inserção e atualização, além da chave lógica
da entidade à qual o atributo pertence, é passada a chave lógica da entidade de referência
e, se for o caso, os subatributos. Na operação de remoção somente os valores das chaves
lógicas das entidades envolvidas são passados como parâmetro.
As consultas para obtenção da chave primária que fazem parte do processamento
para as operações de inserção, remoção e atualização são mapeadas da mesma forma que
a consulta para obtenção de instâncias de atributo objeto interno. A Tabela 4.20 apresenta
o mapeamento do MR para SQL para as operações CRUD sobre atributo objeto interno.
Tabela 4.20: Mapeamento de Operações CRUD sobre Atributo
Objeto Interno
MR
SQL
(a) Obtenção de Instâncias
SELECT INTO pkEnt pk FROM Entidade
WHERE Entidade.atrib1 = val1;
SELECT
EntidadeRef.atribA,
πEntidadeRe f .atrib1,EntidadeRe f .atrib2 (
Enti-
σ Entidade.pk=Ob jetoInterno.pkEntidade AND
dadeRef.atribB
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
ON ObjetoInterno.pkEntidadeRef = Enti-
(Entidade × ObjetoInterno × EntidadeRef))
dadeRef.pk WHERE Entidade.pk = pkEnt
AND EntidadeRef.atribA = valA And EntidadeRef.atribB = valB;
(b) Obtenção de Instância
SELECT INTO pkEnt pk FROM Entidade
WHERE Entidade.atrib1 = val1;
SELECT
EntidadeRef.atribA,
πEntidadeRe f .atrib1,EntidadeRe f .atrib2 (
Enti-
σ Entidade.pk=Ob jetoInterno.pkEntidade AND
dadeRef.atribB
FROM Entidade JOIN ObjetoInterno
Ob jetoInterno.pkEntidadeRe f =EntidadeRe f .pk AND
ON Entidade.pk = ObjetoInterno.pkEntidade
Entidade.atrib1=val1
JOIN EntidadeRef
ON ObjetoInterno.pkEntidadeRef = Enti-
(Entidade × ObjetoInterno × EntidadeRef))
pkEnt ← π pk (σEntidade.atribA=valA
dadeRef.pk WHERE Entidade.pk = pkEnt;
(c) Inserção de Instância
SELECT INTO pkEnt pk
Continua na próxima página
4.3 Mapeamento do MR para PostgreSQL
79
Continuação da Tabela 4.20
MR
SQL
FROM Entidade WHERE Entidade.atrib1 =
(Entidade))
val1;
SELECT INTO pkEntRef pk
pkEntRef ← π pk (
σEntidadeRe f .atribA=valA AND
FROM EntidadeRef
EntidadeRe f .atribB=valB (EntidadeRef)
WHERE EntidadeRef.atribA = valA AND
)
EntidadeRef.atribB = valB
pkNovo ← max pk (ObjetoInterno)
ObjetoInterno ← ObjetoInterno ∪ {(pkNovo,
pkEnt, pkEntRef, subAtrib1)}
pkEnt ← π pk (σEntidade.atribA=valA
(Entidade))
INSERT INTO ObjetoInterno(pkEntidade,
pkEntidadeRef) VALUES (pkEnt, pkEntRef,
subval1);
(d) Remoção de Instância
SELECT INTO pkEnt pk
FROM Entidade WHERE Entidade.atrib1 =
val1;
SELECT INTO pkEntRef pk
pkEntRef ← π pk (
σEntidadeRe f .atribA=valA AND
FROM EntidadeRef
EntidadeRe f .atribB=valB (EntidadeRef)
WHERE EntidadeRef.atribA = valA AND
)
EntidadeRef.atribB = valB;
ObjetoInterno ← ObjetoInterno -
DELETE FROM ObjetoInterno WHERE
pkEntidade = pkEnt AND pkEntidadeRef =
σOb jetoInterno.pkEntidade=pkEnt AND
Ob jetoInterno.pkEntidadeRe f =pkEntRe f
pkEntRef;
(ObjetoInt-
erno)
(e) Atualização de Instância
pkEnt ← π pk (σEntidade.atribA=valA
SELECT INTO pkEnt pk
FROM Entidade WHERE Entidade.atrib1 =
(Entidade))
val1;
pkEntRef ← π pk (
SELECT INTO pkEntRef pk
σEntidadeRe f .atribA=valA AND
FROM EntidadeRef
WHERE EntidadeRef.atribA = valA AND EnEntidadeRe f .atribB=valB (EntidadeRef))
tidadeRef.atribB = valB;
ObjetoInterno ← πsubatrib1←subval1 (
UPDATE ObjetoInterno
σOb jetoInterno.pkEntidade=pkEnt AND
SET subatrib1 = subval1
(ObjetoInt- WHERE pkEntidade = pkEnt AND pkEntiOb jetoInterno.pkEntidadeRe f =pkEntRe f
erno))
dadeRef = pkEntRef;
Continua na próxima página
4.3 Mapeamento do MR para PostgreSQL
80
Continuação da Tabela 4.20
MR
SQL
A lista de atributos da operação de projeção (π) é mapeada para a lista da
cláusula SELECT de SQL. A lista de relações da operação de seleção é mapeada para
a cláusula FROM, substituindo o produto cartesiano (×) pelo operador de junção (JOIN).
A condição da operação de seleção é mapeada para a cláusula FROM da consulta em SQL.
Na cláusula WHERE é inserida a condição da consulta, que é composta pela comparação
entre os valores e os atributos que compõem a chave lógica da entidade à qual o atributo
objeto interno pertence.
O Mapeamento para consulta de atributo objeto interno para agregação descrito
na Tabela 4.21 é feito da mesma forma. Os modelos das SPs resultante dos mapeamentos
das Tabelas 4.20 e 4.21 são apresentados nos Códigos 4.13 e 4.17, repectivamente.
Código 4.13 Stored Procedure Modelo para Obtenção de Instâncias de Atributo Objeto
Interno
1
2
3
4
5
CREATE FUNCTION obterObjetoInternoAtivo(val1 TipoSQL)
RETURNS CURSOR AS $$
DECLARE
csr CURSOR;
pkEnt INTEGER;
6
7
8
9
10
BEGIN
SELECT INTO pkEnt pk
FROM Entidade
WHERE Entidade.atrib1 = val1;
11
12
13
14
15
16
17
18
OPEN csr FOR
SELECT EntidadeRef.atribA, EntidadeRef.atribB
FROM Entidade JOIN ObjetoInterno
ON Entidade.pk = ObjetoInterno.pkEntidade
JOIN EntidadeRef
ON ObjetoInterno.pkEntidadeRef = EntidadeRef.pk
WHERE Entidade.pk = pkEnt;
19
20
21
22
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
No mapeamento para geração de stored procedure de inserção de instâncias de
atributo objeto interno o nome da relação é mapeado para o nome da tabela na instrução
INSERT. Esta instrução possui duas listas, uma com os atributos da tabela que recebem os
valores, e uma com os parâmetros contendo os valores. A primeira lista é obtida a partir
4.3 Mapeamento do MR para PostgreSQL
81
da lista de atributos da relação do atributo menos o atributo pk, e a segunda lista de valores
(pkNovo, pkEnt, pkEntRef, subval1) vem da instrução de inserção no MR menos a
variável pkNovo.
O Mapeamento para inserção de instâncias de atributo objeto interno para
agregação, descrito na Tabela 4.20, é feito da mesma forma.
Os modelos das stored procedures, de inserção resultantes dos mapeamentos das
Tabelas 4.20 e 4.21 são apresentados, respectivamente, nos Códigos 4.14 e 4.18.
Código 4.14 Stored Procedure Modelo para Inserção de Instância de Atributo Objeto
Interno
1
2
3
4
5
6
7
8
9
10
11
CREATE FUNCTION inserirObjetoInterno(val1 TipoSQL,
vala TipoSQL, valB TipoSQL, subval1) RETURNS BOOLEAN AS $$
DECLARE
pkEnt INTEGER;
pkEntRef INTEGER;
BEGIN
SELECT INTO pkEnt pk FROM Entidade
WHERE Entidade.atrib1 = val1;
SELECT INTO pkEntRef pk FROM EntidadeRef
WHERE EntidadeRef.atribA = valA AND
EntidadeRef.atribB = valB;
12
13
14
INSERT INTO ObjetoInterno(pkEntidade,
pkEntidadeRef) VALUES (pkEnt, pkEntRef, subval1);
15
16
17
18
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
No mapeamento para geração de stored procedure de remoção de instâncias de
atributo objeto interno a instrução de exclusão em álgebra relacional é mapeada para a
instrução DELETE em SQL. A tabela da cláusula DELETE é a relação na instrução em
álgebra relacional, e a condição da cláusula WHERE é a condição da operação de seleção
(σ).
O Mapeamento para remoção de instâncias de atributo objeto interno para
agregação, descrito na Tabela 4.21, é feito da mesma forma. Os modelos das stored
procedures de remoção de instância resultantes dos mapeamentos das Tabelas 4.20 e 4.21
são apresentados nos Códigos 4.15 e 4.19, respectivamente.
4.3 Mapeamento do MR para PostgreSQL
82
Código 4.15 Stored Procedure Modelo para Remoção de Instância de Atributo Objeto
Interno
1
2
3
4
5
6
7
8
9
10
11
CREATE FUNCTION desativarObjetoInterno (val1 TipoSQL,
vala TipoSQL, valB TipoSQL) RETURNS BOOLEAN AS $$
DECLARE
pkEnt INTEGER;
pkEntRef INTEGER;
BEGIN
SELECT INTO pkEnt pk FROM Entidade
WHERE Entidade.atrib1 = val1;
SELECT INTO pkEntRef pk FROM EntidadeRef
WHERE EntidadeRef.atribA = valA AND
EntidadeRef.atribB = valB;
12
13
14
15
DELETE FROM ObjetoInterno
WHERE pkEntidade = pkEnt AND
pkEntidadeRef = pkEntRef;
16
17
18
19
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
No mapeamento para geração de stored procedure de atualização de instâncias
de atributo objeto interno a instrução de atualização em álgebra relacional é mapeada
para a instrução UPDATE, e o nome da relação na instrução em álgebra relacional é o
nome da tabela na instrução UPDATE. A lista de atribuições da operação de projeção
(πsubatrib1←subval1 ) é mapeada para a cláusula SET, convertendo o operador de atribuição
(←) de álgebra relacional para o operador de atribuição em SQL (=). A cláusula WHERE
recebe a lista de condições da operação de seleção (ObjetoInterno.pkEntidade =
pkEnt AND ObjetoInterno.pkEntidadeRef = pkEntRef).
O Mapeamento para atualização de instâncias de atributo objeto interno para
agregação, descrito na Tabela 4.21, é feito da mesma forma.
Os modelos das stored procedures resultantes dos mapeamentos para operação
de atualização das Tabelas 4.20 e 4.21 são apresentados nos Códigos 4.16 e 4.20,
respectivamente.
4.3 Mapeamento do MR para PostgreSQL
83
Código 4.16 Stored Procedure Modelo para Atualização de Instância de Atributo Objeto
Interno
1
2
3
4
5
6
7
8
9
10
11
CREATE FUNCTION atualizarObjetoInterno (val1 TipoSQL,
vala TipoSQL, valB TipoSQL, subval1) RETURNS BOOLEAN AS $$
DECLARE
pkEnt INTEGER;
pkEntRef INTEGER;
BEGIN
SELECT INTO pkEnt pk FROM Entidade
WHERE Entidade.atrib1 = val1;
SELECT INTO pkEntRef pk FROM EntidadeRef
WHERE EntidadeRef.atribA = valA AND
EntidadeRef.atribB = valB;
12
13
14
15
16
UPDATE ObjetoInterno
SET subatrib1 = subval1
WHERE pkEntidade = pkEnt AND
pkEntidadeRef = pkEntRef;
17
18
19
20
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
Tabela 4.21: Mapeamento de Operações CRUD sobre Atributo
Objeito Interno (Agregação)
MR
SQL
(a) Obtenção de Instâncias
SELECT INTO pkEnt pk FROM Entidade
πEntidadeRe f .atribA,EntidadeRe f .atribB,
WHERE Entidade.atrib1 = val1;
SELECT
EntidadeRef.atribA,
EntidadeAtribRe f .atribX (
dadeRef.atribB,
EntidadeAtribRef.atribX
σ Entidade.pk=Ob jetoInterno.pkEntidade AND
FROM Entidade JOIN ObjetoInterno
Ob jetoInterno.pkAtributoRe f =AtributoRe f .pk AND
AtributoRe f .pkEnt=Entidade.pk AND
AtributoRe f .pkEntRe f =EntidadeRe f .pk AND
Entidade.atrib1=val1
(Entidade × ObjetoInterno × AtributoRef ×
Enti-
ON Entidade.pk = ObjetoInterno.pkEntidade
JOIN AtributoRef
ON ObjetoInterno.pkAtributoRef = AtributoRef.pk
JOIN EntidadeAtribRef
ON AtributoRef.pkEntRef = EntidadeAtribRef.pk
Continua na próxima página
4.3 Mapeamento do MR para PostgreSQL
84
Continuação da Tabela 4.21
MR
SQL
EntidadeRef × EntidadeAtribRef))
WHERE Entidade.pk = pkEnt;
(b) Obtenção de Instância
SELECT INTO pkEnt pk FROM Entidade
WHERE Entidade.atrib1 = val1;
SELECT
EntidadeRef.atribA,
πEntidadeRe f .atribA,EntidadeRe f .atribB,
Enti-
EntidadeAtribRe f .atribX (
dadeRef.atribB,
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
ON ObjetoInterno.pkAtributoRef = Atribu-
AtributoRe f .pkEntRe f =EntidadeRe f .pk AND
toRef.pk
JOIN EntidadeAtribRef
ON AtributoRef.pkEntRef = EntidadeAtri-
Entidade.atrib1=val1 AND EntidadeRe f .atribA=valA
EntidadeAtribRe f .atribX=valX)
bRef.pk
WHERE Entidade.pk = pkEnt;
(Entidade × ObjetoInterno × AtributoRef
× EntidadeRef × EntidadeAtribRef))
pkEnt ← π pk (
σEntidade.atribA=valA (Entidade))
(c) Inserção de Instância
SELECT INTO pkEnt pk
FROM Entidade WHERE Entidade.atrib1 =
val1;
SELECT INTO pkAtribRef pk
pkAtribRef ← π pk (
σ AtributoRe f .pkEntidadeRe f =EntidadeRe f .pk AND
FROM EntidadeRef JOIN AtributoRef
ON EntidadeRef.pk = AtributoRef.pkEntRef
AtributoRe f .pkEntRe f =EntidadeAtribRe f .pk AND
EntidadeRe f .atribA=valA AND
EntidadeAtribRe f .atribX=valX (EntidadeRef
×
AtributoRef
× EntidadeAtribRef)
JOIN EntidadeAtribRef
ON AtributoRef.pkEntidadeAtribRef = EntidadeAtribRef.pk
WHERE EntidadeRef.atribA = valA AND
EntidadeAtribRef.atribX = valX;
pkNovo ← max pk (ObjetoInterno)
ObjetoInterno ← ObjetoInterno ∪ {(pkNovo,
INSERT INTO ObjetoInterno(pkEnt, pkAtri-
pkEnt, pkAtribRef, subAtrib1)}
bRef) VALUES (pkEnt, pkAtribRef, subval1);
pkEnt ← π pk (
σEntidade.atribA=valA (Entidade))
(d) Remoção de Instância
SELECT INTO pkEnt pk
FROM Entidade WHERE Entidade.atrib1 =
val1;
Continua na próxima página
4.3 Mapeamento do MR para PostgreSQL
85
Continuação da Tabela 4.21
MR
SQL
pkAtribRef ← π pk (
σ AtributoRe f .pkEntidadeRe f =EntidadeRe f .pk AND
SELECT INTO pkAtribRef pk
AtributoRe f .pkEntRe f =EntidadeAtribRe f .pk AND
ON EntidadeRef.pk = AtributoRef.pkEntRef
EntidadeRe f .atribA=valA AND
JOIN EntidadeAtribRef
ON AtributoRef.pkEntidadeAtribRef = Enti-
EntidadeAtribRe f .atribX=valX (EntidadeRef
FROM EntidadeRef JOIN AtributoRef
×
dadeAtribRef.pk
WHERE EntidadeRef.atribA = valA AND
AtributoRef
× EntidadeAtribRef)
EntidadeAtribRef.atribX = valX;
DELETE FROM ObjetoInterno WHERE
ObjetoInterno ← ObjetoInterno -
pkEntidade = pkEnt AND pkAtributoRef =
pkAtribRef;
σOb jetoInterno.pkEntidade=pkEnt AND
Ob jetoInterno.pkAtributoRe f =pkAtribRe f
(ObjetoInt-
erno)
pkEnt ← π pk (
σEntidade.atribA=valA (Entidade))
(e) Atualização de Instância
SELECT INTO pkEnt pk
FROM Entidade WHERE Entidade.atrib1 =
val1;
SELECT INTO pkAtribRef pk
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 EntidadeAtribRef
ON AtributoRef.pkEntidadeAtribRef = Enti-
EntidadeAtribRe f .atribX=valX (EntidadeRef
×
AtributoRef
× EntidadeAtribRef)
dadeAtribRef.pk
WHERE EntidadeRef.atribA = valA AND
EntidadeAtribRef.atribX = valX;
ObjetoInterno ← πsubatrib1←subval1 (
σOb jetoInterno.pkEntidade=pkEnt AND
Ob jetoInterno.pkAtributoRe f =pkAtribRe f (ObjetoInt-
UPDATE ObjetoInterno
erno)
toRef = pkAtribRef;
SET subatrib1 = subval1
WHERE pkEntidade = pkEnt AND pkAtribu-
4.3 Mapeamento do MR para PostgreSQL
86
Código 4.17 Stored Procedure Modelo para Obtenção de Instâncias de Atributo Objeto
Interno (Agregacao)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CREATE FUNCTION obterObjetoInternoAtivo(val1 TipoSQL)
RETURNS CURSOR AS $$
DECLARE
csr REFCURSOR;
pkEnt INTEGER;
BEGIN
SELECT INTO pkEnt pk FROM Entidade WHERE Entidade.atrib1 = val1;
OPEN csr FOR
SELECT EntidadeRef.atribA, EntidadeRef.atribB, EntidadeAtribRef.atribX
FROM Entidade JOIN ObjetoInterno ON Entidade.pk = ObjetoInterno.pkEntidade
JOIN AtributoRef ON ObjetoInterno.pkAtribRef = AtributoRef.pk
JOIN EntidadeRef ON AtributoRef.pkEntRef = EntidadeRef.pk
JOIN EntidadeAtribRef ON AtributoRef.pkEntRef = EntidadeAtribRef.pk
WHERE Entidade.pk = pkEnt;
RETURN csr;
END;
$$ LANGUAGE ’plpgsql’;
Código 4.18 Stored Procedure Modelo para Inserção de Instância de Atributo Objeto
Interno (Agregação)
1
2
3
4
5
6
7
CREATE inserirObjetoInterno(val1 TipoSQL, valATipoSQL, valX TipoSQL,
subAtrib1 TipoSQL) RETURNS BOOLEAN AS’
DECLARE
pkEnt INTEGER;
pkAtribRef INTEGER;
BEGIN
SELECT INTO pkEnt pk FROM Entidade WHERE Entidade.atrib1 = val1;
8
9
10
11
12
13
14
SELECT INTO pkAtribRef pk FROM EntidadeRef JOIN AtributoRef
ON EntidadeRef.pk = AtributoRef.pkEntidadeRef
JOIN EntidadeAtribRef
ON AtributoRef.pkEntidadeAtribRef = EntidadeAtribRef.pk
WHERE EntidadeRef.atribA = valA AND
EntidadeAtribRef.atribX = valX;
15
16
17
18
19
20
INSERT INTO ObjetoInterno(pkEntidade, pkAtributoRef, subAtrib1)
VALUES (pkEnt, pkAtribRef, subval1);
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
4.3 Mapeamento do MR para PostgreSQL
87
Código 4.19 Stored Procedure Modelo para Remoção de Instância de Atributo Objeto
Interno (Agregação)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
CREATE FUNCTION desativarObjetoInterno(val1 TipoSQL, valATipoSQL, valX TipoSQL)
RETURNS BOOLEAN AS’
DECLARE
pkEnt INTEGER;
pkAtribRef INTEGER;
BEGIN
SELECT INTO pkEnt pk FROM Entidade WHERE Entidade.atrib1 = val1;
SELECT INTO pkAtribRef pk FROM EntidadeRef JOIN AtributoRef
ON EntidadeRef.pk = AtributoRef.pkEntidadeRef
JOIN EntidadeAtribRef
ON AtributoRef.pkEntidadeAtribRef = EntidadeAtribRef.pk
WHERE EntidadeRef.atribA = valA AND
EntidadeAtribRef.atribX = valX;
DELETE FROM ObjetoInterno WHERE pkEntidade = pkEnt AND
pkAtributoRef = pkAtribRef;
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
Código 4.20 Stored Procedure Modelo para Atualização de Instância de Atributo Objeto
Interno (Agregação)
1
2
3
4
5
6
7
8
9
10
11
CREATE FUNCTION atualizarObjetoInterno(val1 TipoSQL, valATipoSQL,
valX TipoSQL, subAtrib1 TipoSQL) RETURNS BOOLEAN AS’
DECLARE
pkEnt INTEGER;
pkAtribRef INTEGER;
BEGIN
SELECT INTO pkEnt pk FROM Entidade WHERE Entidade.atrib1 = val1;
SELECT INTO pkAtribRef pk FROM EntidadeRef
JOIN AtributoRef ON EntidadeRef.pk = AtributoRef.pkEntidadeRef
JOIN EntidadeAtribRef ON AtributoRef.pkEntidadeAtribRef = EntidadeAtribRef.pk
WHERE EntidadeRef.atribA = valA AND EntidadeAtribRef.atribX = valX;
12
13
14
15
16
17
UPDATE ObjetoInterno SET subatrib1 = subval1
WHERE pkEntidade = pkEnt AND pkAtributoRef = pkAtribRef;
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
Os mapeamentos do MR para SQL para Entidade Fraca, Atributo Composto e
Atributo Simples Multvalorado são apresentados no Apêndice B, pois a ideia aplicada
a estes mapeamentos são análogas às apresentadas nos mapeamentos discutidos nesta
4.3 Mapeamento do MR para PostgreSQL
88
seção. O próximo capítulo traz exemplos da utilização desses mapeamentos em aplicações
do componente EBD.
Este capítulo apresentou os mapeamentos do MMO para o MR em termos de
estruturas e operações (Seções 4.1 e 4.2), e deste para o SQL do SGBD PostgreSQL
(Seção 4.3).
CAPÍTULO 5
Funcionamento do Componente EBD
Este capítulo apresenta a criação (Seção 5.1) e utilização (Seção 5.2) de SI
a partir do framework do qual o componente EBD faz parte. A Seção 5.3 apresenta
exemplos de criação de uma pequena porção do esquema de um SI real do domínio
agropecuário.
5.1
Criação de Sistema de Informação
Os componentes de SI gerados pelo framework incluem [21]: a) software de
aplicação e interface com o usuário; b) esquemas e restrições de integridade de bancos de
dados; e c) regras de negócio que podem ser disparadas a partir de eventos de bancos de
dados ou de funções de aplicação. Em [12] são encontrados detalhes sobre o mecanismo
de geração de regras do framework. O mecanismo de geração de interface do framework
é detalhado em [18].
As meta-informações do SI são obtidas a partir de um formulário de cadastro
de Tipo de Entidade, mostrado na Figura 5.1. Neste cadastro são registradas informações
sobre representação e apresentação de dados utilizadas, respectivamente, na geração do
banco de dados e da interface.
Cada tipo de entidade possui um conjunto de atributos e as informações de cada
um deles são obtidas a partir do formulário de cadastro da Figura 5.2.
O MMO não permite a definição de regras dinâmicas, tais como regras de
derivação. No entanto, o framework permite a utilização de Object Constraint Language
(OCL) [13]. Para cadastrar as regras de um tipo de entidade é utilizado o editor de OCL
do framework. As regras dinâmicas de tipo de entidade e regras de atributos são definidas
neste editor e são associadas aos respectivos atributos ou tipo de entidade pelo cadastro
da Figura 5.1.
Utilizando o cadastro de Tipo de Entidade e o editor de Regras é possível definir
as informações de um tipo de entidade do SI, que são validadas e armazenadas no
BD. Persistidas as informações, o framework gera automaticamente as tabelas e stored
procedures para manipulação e validação de informações do tipo de entidade gerado,
5.2 Utilização do Sistema de Informação
90
Figura 5.1: Formulário para Cadastro de Tipo de Entidade do SI
utilizando os mapeamentos apresentados no Capítulo 4. A partir desta geração, o SI fica
disponível para uso.
5.2
Utilização do Sistema de Informação
Após a geração das tabelas e stored procedures os formulários para manipulação
dos dados das entidades são disponibilizados para uso.
Quando o usuário acessa um formulário, o framework manda uma requisição
para o módulo de Interface (conforme a Figura 3.1) que obtém os metadados da entidade
e gera, em tempo de execução, a interface para manipulação de informações. A Figura 5.3
apresenta um exemplo de formulário para manipulação de instâncias do tipo de entidade
pessoa física.
A interface gerada pelo framework possui duas áreas principais: uma onde
estão todas as instâncias de um tipo de entidade e outra destinada ao formulário para
manipulação destas instâncias.
Nas operações de inserção, remoção e atualização de instância, o módulo Interface obtém a instância da entidade que está sendo manipulada e repassa para o módulo
Interface Aplicação, o qual repassa os dados para o módulo Aplicação.
5.2 Utilização do Sistema de Informação
91
Figura 5.2: Formulário para Cadastro de Atributo de Tipo de Entidade do SI
5.2.1
Operações CRUD
Os serviços de manipulação de metadados e dados disponibilizados pelas classes
Metadados e ObjetoApresentação (discutidos na Seção 3.3.4) são utilizados nos mecanismos de mapeamento para as operações de inserção, obtenção, atualização e remoção de
instâncias de entidade. A Figura 5.4 apresenta o modelo estático das classes envolvidas
nestas operações.
A classe AplicacaoCadastro fornece as operações CRUD de manipulação de
instâncias de entidades. Ela utiliza os métodos da classe ObjetoNegocio para fazer
validações de restrições estáticas (cardinalidades mínima, máxima, unicidade e chave
lógica).
Além de validar as restrições, a classe ObjetoNegocio extrai as informações da
instância de entidade (ObjetoApresentacao) de forma que estas sejam passadas para o
mecanismo de persistência. Por exemplo, o método tratarInsercaoComposto de ObjetoNegocio sabe que para persistir uma instância de um atributo composto é necessário
passar a chave lógica da entidade mais os valores simples monovalorados da instância
deste atributo composto.
A classe BDMecanismo é uma fachada para o mecanismo de BD do framework.
Ela tem a função de repassar os parâmetros para as stored procedure no BD através do
Objeto CallableStatement do pacote externo java.sql. Ela possui alguns serviços, como
verificar se o valor da chave lógica de uma entidade existe no BD, obter o valor de atributo
5.2 Utilização do Sistema de Informação
92
Figura 5.3: Exemplo de Tela de Manipulação de Pessoa Física
gerada pelo framework
derivado e obter metadados de entidade.
A classe Persistencia tem como função abrir e fechar conexão, abrir transação,
fazer commit de transação e executar operações no BD (seleção, inserção, remoção,
atualização ou outros serviços disponíveis no framework). A seguir, são apresentados os
mecanismos para inserção, obteção, atualização e remoção de instâncias de entidades de
SI.
Inserção de Instância de uma Entidade
O processamento para persistir uma instância de entidade envolve uma série
de operações, tais como controle de transação, validação dos dados na instância e
mapeamento dos dados para o esquema da entidade no BD. A Figura 5.5 mostra a
colaboração das classes das camadas de Aplicação, Negócio e Persistência para executar
a inserção de uma instância de entidade.
A camada Aplicação é responsável pelo controle de transações nas operações de
manipulações de instâncias de entidade. Antes de fazer o desmembramento da instância
em partes que são repassadas para o BD, são executadas operações de validação. As
restrições estruturais de domínio, chave, unicidade, cardinalidade mínima e máxima
de atributos e relacionamentos são verificadas pela classe ObjetoNegocio, enquanto as
validações de regras dinâmicas são tratadas pela classe Regras.
5.2 Utilização do Sistema de Informação
93
Figura 5.4: Modelo Estático das Classes Envolvidas nas Operações CRUD
Feitas as validações, a instância da entidade é passada para a classe ObjetoNegocio. No método inserir o processo de persistência da instância é iniciado com a extração
dos dados que serão mapeados para a tabela que armazena as instâncias da entidade. A
classe Metadados possui o conhecimento para extrair as informações da instância da entidade.
Os dados são repassados para o método inserirMono da classe BDMecanismo
que vai criar uma instrução para passar os dados para a stored procedure que faz a inserção
dos dados da entidade. Esta instrução é criada a partir do padrão: tipo de operação (neste
caso é inserir) concatenado com o mnemônico da entidade.
Os atributos multivalorados do tipo Basico, Enumerado, Composto e Objeto Interno possuem tabelas para armazenar suas instâncias. O método tratarInsercaoMulti trata
o mapeamento das instâncias de atributos do tipo Basico e Enumerados para suas respec-
5.2 Utilização do Sistema de Informação
94
Figura 5.5: Colaboração para mapeamento Objeto-Relacional na
operação de Inserção
tivas tabelas. O mesmo processamento é feito no método tratarInsercaoComposto para
atributos do tipo Composto e Objeto Interno. Estes métodos recebem como parâmetro o
5.2 Utilização do Sistema de Informação
95
objeto que representa o atributo multivalorado, as instâncias deste atributo e a chave lógica
da entidade. Este método repassa para a classe BDMecanismo o mnemônico do atributo, a
chave lógica da entidade e uma instância do atributo. Este processo é repetido até que todas as instâncias do atributo sejam passadas. O processo de criação da instrução que passa
os parâmetros para a stored procedure é idêntico ao processo descrito anteriormente para
instâncias de entidade.
Obtenção de Instância de uma Entidade
O mecanismo de obtenção de instâncias permite busca de todas as instâncias da
entidade ou busca de uma só instância. A Figura 5.6 mostra o diagrama de colaboração
para obtenção de instâncias de entidade.
O processamento inicia com a consulta no BD de todas as instâncias de uma
entidade. A consulta retorna todos os atributos que pertecem à entidade que não são mapeados para tabelas separadas, como atributos multivalorados do tipo Básico, Enumerado,
Objeto Externo ou mesmo Composto e Objeto Interno.
A consulta dos atributos multivalorados é feita separadamente. A partir do objeto
Metadados da entidade estes atributos são localizados e repassados para os métodos que
fazem o tratamento da obtenção. O método recebe o mnemônico do atributo e a chave
lógica da entidade. Com estas informações é possível obter todas as instâncias do atributo
para a instância da entidade identificada pela chave lógica. As instâncias são empacotadas
e retornadas.
O método obterAtivos recebe as instâncias manipuladas pelos metodos tratarObtencaoComposto e tratarObtencaoMulti e os coloca na instância da entidade representada
pelo ObjetoApresentacao. Este processamento é feito até que todas as instâncias da entidade sejam mapeadas para o ObjetoApresentacao.
Atualização de Instância de uma Entidade
O processo de atualização de uma instância de entidade é feito a partir da
comparação de duas instâncias: a instância que sofreu modificações do usuário e a
instância que está armazenada no BD. A Figura 5.7 mostra a colaboração no mapeamento
Objeto-Relacional na operação de Atualização.
O método atualizar da classe AplicacaoCadastro recebe estas duas instâncias.
Utilizando o mecanismo de extração de dados da classe Metadados são extraídos os valores que são mapeados para a tabela da entidade de cada um dos ObjetoApresentacao
(sem modificação e com modificação). Estes valores são comparados e, se houve modificação, então estes dados são repassados para a stored procedure de atualização dos dados
da entidade.
5.2 Utilização do Sistema de Informação
96
Figura 5.6: Colaboração para mapeamento Objeto-Relacional na
operação de Consulta
O próximo passo é a atualização dos dados de atributos multivalorados. Para
tratar a atualização destes atributos dois métodos são utilizados: tratarAtualizacaoComposto, para os atributos do tipo Compostos e ObjetoInterno; e tratarAtualizacaoMulti,
para os atributos do tipo Basico, Enumerado, Objeto Externo multivalorados.
A atualização de atributos multivalorados pode ser feita através de três operações: inserir uma nova instância no atributo, remover uma instância existente e modificar
uma instância existente.
Os métodos tratarAtualizacaoComposto e tratarAtualizacaoMulti recebem
5.2 Utilização do Sistema de Informação
97
como parâmetro a instância sem modificação e a instância com modificação. O método
deve comparar as instâncias e verificar quais operações devem ser executadas para que
as modificações feitas pelo usuário sejam aplicadas nas instâncias que estão armazenadas
no BD. Por exemplo, a atualização de um atributo do tipo Basico multivalorado segue os
seguintes passos:
• Para inserir utilize todos os valores que estão na instância modificada e não estão
na instância sem modificação.
• Para remover utilize todos os valores que estão na instância sem modificação, mas
não estão na instância modificada.
A utilização deste algoritmo para atualização de instâncias de atributos do
tipo Composto pode ter implicações negativas na eficiência para atributos com muitas
instâncias. Por exemplo, em um atributo composto com três atributos que possui cem
instâncias, se o usuário modificar um dos três em todas as instâncias o mecanismo fará
cem remoções e cem inserções, ao invés de fazer somente cem atualizações.
A solução utilizada no framework é a indexação da operação (inserir, remover e
atualizar) em cada uma das instâncias do composto, permitindo que o mecanismo saiba
qual operação executar sem necessidade de comparação entre os conjuntos de instâncias.
Remoção de Instância de uma Entidade
A remoção de uma instância de entidade envolve operações semelhantes a
remoção de nós em árvores. Neste caso somente as folhas podem ser removidas. Este
processo é feito até que o nó raiz seja também folha. A remoção da instância da entidade
é permitida somente se todas as referências provenientes de atributos multivalorados,
compostos ou objeto interno forem removidas. A Figura 5.8 mostra a colaboração para o
processo de mapeamento objeto relacional na operação de remoção.
No ínicio do processamento para remoção é obtida a instância da entidade no
BD e comparada com a instância que será removida. Esta verificação é necessária para
evitar que uma instância da entidade modificada concorrentemente por um outro usuário
seja removida.
O processamento da remoção é iniciado na classe ObjetoNegocio com a busca
por atributos multivalorados. Os métodos tratarDesativacaoComposto e tratarDesativacaoMulti possuem a finalidade de remover todas as instâncias do atributo que é passado
como parâmetro. O método tratarDesativacaoComposto recebe como parâmetro o objeto
que representa o atributo Composto, a chave lógica da entidade e as instâncias do atributo.
Utilizando o serviço de extração de dado de Metadados, a chave parcial do atributo composto é extraída. Esta chave associada com a chave lógica da entidade e a chave parcial
do composto permite remover a instância do composto no BD.
5.2 Utilização do Sistema de Informação
98
Figura 5.7: Colaboração para mapeamento Objeto-Relacional na
operação de Atualização
O mesmo processamento é feito no método tratarDesativacaoMulti, os parâmetros que são passados para stored procedure de remoção considera a chave parcial do atributo, que é o próprio valor. Após remover todos os atributos multivalorados, o mecanismo
remove a instância da entidade do BD.
5.2 Utilização do Sistema de Informação
Figura 5.8: Colaboração para mapeamento Objeto-Relacional na
operação de remoção
99
5.3 Exemplo: SI para o Agronegócio
5.3
100
Exemplo: SI para o Agronegócio
O sistema SIA (Sistemas Integrados de Agronegócio) foi desenvolvido dentro
de um projeto de pesquisa no Instituto de Informática da UFG e provê infra-estrutura
de Tecnologia da Informação para otimizar a produção de gado de corte. O objetivo
principal 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 de
pastagem.
O SIA é um sistema de informação bastante complexo e trabalha com grande
quantidade 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 entidades
de negócio e um repositório de regras que contém mais de 150 regras de negócio
especificadas e implementadas no SI.
O esquema de banco de dados operacional gerado a partir do framework descrito
na Seção 3.1, contém cerca de 590 tabelas e mais de 3200 stored procedures, incluindo
aquelas 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 para
geraçã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 apresenta
estes conceitos do modelo conceitual do BD do SIA.
Figura 5.9: Modelo Conceitual Simplificado - Conceito de "Animal"
5.3 Exemplo: SI para o Agronegócio
101
No SIA, existe também o conceito de "Animal de Catálogo" que é um animal de
elite, não pertencente à propriedade rural, mas utilizado para definir a árvore genealógica
de animais da propriedade.
Como Animal de Propriedade faz parte de uma hierarquia de especialização
entã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 Propriedade
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CREATE TABLE animalProd
(
pk integer NOT NULL,
datanascanimal date,
pkcondicaoreprodanimal integer NOT NULL,
pktipoidfisicomanejo integer,
pksituacaoanimal integer NOT NULL,
PRIMARY KEY (pk),
FOREIGN KEY (pk) REFERENCES animal (pk)
ON UPDATE RESTRICT ON DELETE RESTRICT,
FOREIGN KEY (pkcondicaoreprodanimal) REFERENCES valorenumerado (pk)
ON UPDATE RESTRICT ON DELETE RESTRICT,
FOREIGN KEY (pksituacaoanimal) REFERENCES valorenumerado (pk)
ON UPDATE RESTRICT ON DELETE RESTRICT,
FOREIGN KEY (pktipoidfisicomanejo) REFERENCES valorenumerado (pk)
ON UPDATE RESTRICT ON DELETE RESTRICT
)
As stored procedures para obtenção, inserção, remoção e atualização de instâncias de Animal de Propriedade são geradas a partir dos mapeamentos para hierarquia de
especializaçã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 para
as operações de obtenção de instâncias, obtenção de uma instância, inserção, remoção e
atualização da entidade Animal de Propriedade.
No Código 5.1, a linha 1 indica a entidade que está sendo mapeada. A linha 3
traz o campo gerado para a chave primária (surrogate key), que não tem correspondente no
esquema conceitual, já que é gerada pelo componente EBD. Nas linhas 4 a 7 descrevem
os atributos específicos da entidade mapeada. As linhas 5, 6 e 7 descrevem os atributos
enumerados com suas respectivas restrições de chave estrangeira, nas linhas 11, 13 e 15.
5.3 Exemplo: SI para o Agronegócio
102
Código 5.2 Stored Procedure para Obtenção de Instâncias da Entidade Animal de Propriedade
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
CREATE OR REPLACE FUNCTION obterAnimalProdativo() RETURNS refcursor AS $$
DECLARE
csr REFCURSOR;
BEGIN
OPEN csr FOR
SELECT PropRur.codigoPropRur , PropRur.nomePropRur , Animal.idAnimal ,
Animal.nomeAnimal , enumsexoAnimal.mnemonico , AnimalProd.dataNascAnimal ,
enumsituacaoAnimal.mnemonico , enumcondicaoReprodAnimal.mnemonico ,
enumtipoMatrizAnimal.mnemonico , AnimalProd.criadorAnimal
FROM PropRur JOIN propRurAnimal ON PropRur.pk = propRurAnimal.pkPropRur
JOIN Animal ON Animal.pk = propRurAnimal.pkAnimal
JOIN ValorEnumerado AS enumsexoAnimal ON Animal.pksexoAnimal = enumsexoAnimal.pk
JOIN AnimalProd ON Animal.pk = AnimalProd.pk
JOIN ValorEnumerado AS enumtipoIdFisicoManejo ON AnimalProd.pktipoIdFisicoManejo =
enumtipoIdFisicoManejo.pk
JOIN ValorEnumerado AS enumsituacaoAnimal ON AnimalProd.pksituacaoAnimal =
enumsituacaoAnimal.pk
JOIN ValorEnumerado AS enumcondicaoReprodAnimal ON
AnimalProd.pkcondicaoReprodAnimal = enumcondicaoReprodAnimal.pk ;
RETURN csr;
END;
$$ LANGUAGE ’plpgsql’;
5.3 Exemplo: SI para o Agronegócio
103
Código 5.3 Stored Procedure para Obtenção de Instância da Entidade Animal de Propriedade
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
CREATE OR REPLACE FUNCTION obteranimalprodativo(codigoproprurger VARCHAR,
idanimalger VARCHAR) RETURNS refcursor AS $$
DECLARE
csr REFCURSOR;
BEGIN
SELECT PropRur.codigoPropRur , PropRur.nomePropRur , Animal.idAnimal ,
Animal.nomeAnimal , enumsexoAnimal.mnemonico , AnimalProd.dataNascAnimal ,
enumsituacaoAnimal.mnemonico , enumcondicaoReprodAnimal.mnemonico ,
enumtipoMatrizAnimal.mnemonico , AnimalProd.criadorAnimal
FROM PropRur JOIN propRurAnimal ON PropRur.pk = propRurAnimal.pkPropRur
JOIN Animal ON Animal.pk = propRurAnimal.pkAnimal
JOIN ValorEnumerado AS enumsexoAnimal ON Animal.pksexoAnimal = enumsexoAnimal.pk
JOIN AnimalProd ON Animal.pk = AnimalProd.pk
JOIN ValorEnumerado AS enumtipoIdFisicoManejo ON AnimalProd.pktipoIdFisicoManejo =
enumtipoIdFisicoManejo.pk
JOIN ValorEnumerado AS enumsituacaoAnimal ON AnimalProd.pksituacaoAnimal =
enumsituacaoAnimal.pk
JOIN ValorEnumerado AS enumcondicaoReprodAnimal ON
AnimalProd.pkcondicaoReprodAnimal = enumcondicaoReprodAnimal.pk
WHERE PropRur.codigoPropRur = codigoPropRurGER AND Animal.idAnimal = idAnimalGER;
RETURN csr;
END;
$$ LANGUAGE ’plpgsql’;
Nos Códigos 5.2 e 5.3 as listas das cláusulas SELECT, na linha 6, estão todos os
atributos da entidade AnimalProd, Animal e PropRur.
Na cláusula FROM, para cada atributo enumerado é feita uma junção com
ValorEnumerado, que é a tabela que contém todos os valores dos domínios enumerados
do SI.
5.3 Exemplo: SI para o Agronegócio
104
Código 5.4 Stored Procedure para Inserção de Instância da Entidade Animal de Propriedade
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
CREATE OR REPLACE FUNCTION inseriranimalprod(codigoproprurger VARCHAR, idanimalger
VARCHAR, nomeanimalger VARCHAR, sexoanimalger VARCHAR, tipoidfisicomanejoger VARCHAR,
datanascanimalger date, situacaoanimalger VARCHAR, condicaoreprodanimalger VARCHAR)
RETURNS boolean AS $$
DECLARE
pkEnumtipoIdFisicoManejo INTEGER;
pkEnumsituacaoAnimal INTEGER;
pkEnumcondicaoReprodAnimal INTEGER;
pkEnumsexoAnimal INTEGER;
pkEnt INTEGER;
BEGIN
SELECT INTO pkEnumtipoIdFisicoManejo ValorEnumerado.pk
FROM DominioEnum JOIN ValorEnumerado ON DominioEnum.pk = ValorEnumerado.pkDominioEnum
WHERE DominioEnum.DominioEnumNome = ’EnumTipoIdFisicoAnimal’
AND ValorEnumerado.mnemonico = tipoIdFisicoManejoGER;
SELECT INTO pkEnumsituacaoAnimal ValorEnumerado.pk
FROM DominioEnum JOIN ValorEnumerado ON DominioEnum.pk = ValorEnumerado.pkDominioEnum
WHERE DominioEnum.DominioEnumNome = ’EnumSituacaoAnimal’
AND ValorEnumerado.mnemonico = situacaoAnimalGER;
SELECT INTO pkEnumcondicaoReprodAnimal ValorEnumerado.pk
FROM DominioEnum JOIN ValorEnumerado ON DominioEnum.pk = ValorEnumerado.pkDominioEnum
WHERE DominioEnum.DominioEnumNome = ’EnumCondicaoReprodutiva’
AND ValorEnumerado.mnemonico = condicaoReprodAnimalGER;
SELECT INTO pkEnumsexoAnimal ValorEnumerado.pk
FROM DominioEnum JOIN ValorEnumerado ON DominioEnum.pk = ValorEnumerado.pkDominioEnum
WHERE DominioEnum.DominioEnumNome = ’EnumSexo’ AND
ValorEnumerado.mnemonico = sexoAnimalGER;
28
29
30
SELECT INTO pkEntRef PropRur.pk FROM PropRur WHERE
PropRur.codigoPropRur = codigoPropRurGER;
31
32
33
34
35
INSERT INTO Animal (idAnimal, nomeAnimal, pksexoAnimal) VALUES
(idAnimalGER , nomeAnimalGER , pkEnumsexoAnimal);
SELECT INTO pkEnt * FROM lastval();
INSERT INTO propRurAnimal (pkAnimal , pkPropRur) VALUES (pkEnt , pkEntRef);
36
37
38
39
40
INSERT INTO AnimalProd (pk, dataNascAnimal, pksituacaoAnimal, pkcondicaoReprodAnimal)
VALUES (pkEnt , dataNascAnimalGER , pkEnumsituacaoAnimal , pkEnumcondicaoReprodAnimal);
RETURN TRUE;
END; $$ LANGUAGE ’plpgsql’;
No Código 5.4, as linhas 12, 16, 20 e 24 são instruções que obtém o valor da
chave estrangeira dos atributos enumerados. A linha 29 obtém o valor da chave primária
5.3 Exemplo: SI para o Agronegócio
105
da entidade identificadora (PropRur). A linha 32 apresenta a instrução que insere da
entidade Animal, e na sequência, na linha 36, a instrução faz a ligação entre as entidade
PropRur e Animal. Finalmente, os dados da entidade AnimalProd são inseridos, de acordo
com a instrução da linha 37. A instância da entidade AnimalProd possui o mesmo valor
de 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 Propriedade
1
2
3
4
5
6
7
8
9
10
11
12
CREATE OR REPLACE FUNCTION desativaranimalprod(codigoproprurger VARCHAR,
idanimalger VARCHAR) RETURNS boolean AS $$
DECLARE
pkEnt INTEGER;
pkEntRef INTEGER;
BEGIN
SELECT INTO pkEnt Animal.pk
FROM PropRur
JOIN propRurAnimal ON PropRur.pk = propRurAnimal.pkPropRur
JOIN Animal ON Animal.pk = propRurAnimal.pkAnimal
WHERE PropRur.codigoPropRur = codigoPropRurGER AND
Animal.idAnimal = idAnimalGER;
13
14
15
16
SELECT INTO pkEntRef PropRur.pk
FROM PropRur
WHERE PropRur.codigoPropRur = codigoPropRurGER;
17
18
19
20
21
DELETE FROM AnimalProd WHERE pk = pkEnt;
DELETE FROM propRurAnimal WHERE pkAnimal = pkEnt AND
pkPropRur = pkEntRef ;
DELETE FROM Animal WHERE pk = pkEnt;
22
23
24
25
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’
No Código 5.5, primeiramente obtém-se o valor das chaves das entidades fraca
e identificadora, respectivamente, nas linhas 7 e 14. Em seguida, a instância da entidade
AnimalProd é removida, seguindo com a instância do atributo objeto interno parte de
chave propRurAnimal, e finalmente a instância da entidade Animal é removida (instrução
da linha 21).
5.3 Exemplo: SI para o Agronegócio
106
Código 5.6 Stored Procedure para Atualização de Instância da Entidade Animal de
Propriedade
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE OR REPLACE FUNCTION atualizaranimalprod(codigoproprurger1 VARCHAR, idanimalger1
VARCHAR, idanimalger VARCHAR, nomeanimalger VARCHAR, sexoanimalger VARCHAR,
tipoidfisicomanejoger VARCHAR, datanascanimalger date, situacaoanimalger VARCHAR,
condicaoreprodanimalger VARCHAR) RETURNS boolean AS $$
DECLARE
pkEnumtipoIdFisicoManejo INTEGER;
pkEnumsituacaoAnimal INTEGER;
pkEnumcondicaoReprodAnimal INTEGER;
pkEnumsexoAnimal INTEGER;
pkEnt INTEGER;
BEGIN
SELECT INTO pkEnumtipoIdFisicoManejo ValorEnumerado.pk
FROM DominioEnum JOIN ValorEnumerado ON DominioEnum.pk = ValorEnumerado.pkDominioEnum
WHERE DominioEnum.DominioEnumNome = ’EnumTipoIdFisicoAnimal’
AND ValorEnumerado.mnemonico = tipoIdFisicoManejoGER;
16
17
18
19
20
SELECT INTO pkEnumsituacaoAnimal ValorEnumerado.pk
FROM DominioEnum JOIN ValorEnumerado ON DominioEnum.pk = ValorEnumerado.pkDominioEnum
WHERE DominioEnum.DominioEnumNome = ’EnumSituacaoAnimal’
AND ValorEnumerado.mnemonico = situacaoAnimalGER;
21
22
23
24
25
SELECT INTO pkEnumcondicaoReprodAnimal ValorEnumerado.pk
FROM DominioEnum JOIN ValorEnumerado ON DominioEnum.pk = ValorEnumerado.pkDominioEnum
WHERE DominioEnum.DominioEnumNome = ’EnumCondicaoReprodutiva’
AND ValorEnumerado.mnemonico = condicaoReprodAnimalGER;
26
27
28
29
30
SELECT INTO pkEnumsexoAnimal ValorEnumerado.pk
FROM DominioEnum JOIN ValorEnumerado ON DominioEnum.pk = ValorEnumerado.pkDominioEnum
WHERE DominioEnum.DominioEnumNome = ’EnumSexo’ AND
ValorEnumerado.mnemonico = sexoAnimalGER;
31
32
33
34
35
SELECT INTO pkEnt Animal.pk
FROM PropRur JOIN propRurAnimal ON PropRur.pk = propRurAnimal.pkPropRur
JOIN Animal ON Animal.pk = propRurAnimal.pkAnimal
WHERE PropRur.codigoPropRur = codigoPropRurGER1 AND Animal.idAnimal = idAnimalGER1;
36
37
38
39
40
41
UPDATE Animal SET idAnimal = idAnimalGER , nomeAnimal = nomeAnimalGER ,
pksexoAnimal = pkEnumsexoAnimal WHERE pk = pkEnt;
UPDATE AnimalProd SET pktipoIdFisicoManejo = pkEnumtipoIdFisicoManejo ,
dataNascAnimal = dataNascAnimalGER , pksituacaoAnimal = pkEnumsituacaoAnimal ,
pkcondicaoReprodAnimal = pkEnumcondicaoReprodAnimal WHERE pk = pkEnt;
42
43
44
45
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
5.3 Exemplo: SI para o Agronegócio
107
No Código 5.6, da mesma forma que no Código 5.4, o processamento inicia com
as instruções, nas linhas 12, 17, 22 e 27, de obtenção de chave estrangeira dos atributos
enumerados 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ão
atualizados 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 definido
com 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 mapeamentos das Tabelas 4.3 e 4.15. A tabela resultante destes mapeamentos é apresentada no
Código 5.7.
As stored procedures para obtenção inserção, remoção e atualização de instâncias de Cor de Pelo de Animal são geradas a partir dos mapeamentos das Tabelas 4.9 e
4.21. Os Códigos 5.8, 5.9 e 5.10, apresentam as stored procedures para as operações de
obtençã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 o
relacionamento pertence (AnimalProd) e para o atributo de referência (corPeloRaca). As
linhas 7 e 9 apresentam as restrições de chave estrangeiras para os campos das linhas 3 e
4, respectivamente.
Figura 5.10: Modelo Conceitual Simplificado - Conceito de "Cor
de Pelo de Animal"
5.3 Exemplo: SI para o Agronegócio
108
Código 5.7 Tabela do Atributo Objeto Interno Cor de Pelo Animal
1
2
3
4
CREATE TABLE corDePeloAnimal(
pk serial NOT NULL,
pkanimalProd INTEGER NOT NULL,
pkcorPeloRaca INTEGER NOT NULL,
5
PRIMARY KEY (pk),
FOREIGN KEY (pkanimalprod) REFERENCES animalprod (pk)
ON UPDATE RESTRICT ON DELETE RESTRICT,
FOREIGN KEY (pkcorPeloRaca ) REFERENCES corPeloRaca (pk)
ON UPDATE RESTRICT ON DELETE RESTRICT,
UNIQUE (pkanimalprod, pkcorPeloRaca)
6
7
8
9
10
11
12
)
No Código 5.8, a linha 7 apresenta a instrução para obtenção da chave primária
da entidade AnimalProd a partir da chave lógica. Na linha 14, a operação de seleção
retorna todos valores do relacionamento corPeloDeAnimal.
5.3 Exemplo: SI para o Agronegócio
109
Código 5.8 Stored Procedure para Obtenção de Instâncias do Atributo Objeto Interno Cor
de Pelo Animal
1
2
3
4
5
6
7
8
9
10
11
12
CREATE OR REPLACE FUNCTION obtercordepeloanimalativo(codigoproprurger VARCHAR,
idanimalger VARCHAR) RETURNS refcursor AS $$
DECLARE
csr REFCURSOR;
pkEnt INTEGER;
BEGIN
SELECT INTO pkEnt AnimalProd.pk
FROM PropRur
JOIN propRurAnimal ON PropRur.pk = propRurAnimal.pkPropRur
JOIN Animal ON Animal.pk = propRurAnimal.pkAnimal
JOIN AnimalProd ON Animal.pk = AnimalProd.pk
WHERE PropRur.codigoPropRur = codigoPropRurGER AND Animal.idAnimal = idAnimalGER;
13
14
15
16
17
18
19
20
21
22
23
OPEN csr FOR
SELECT enumnomeRaca.mnemonico , enumnomeCorPelo.mnemonico
FROM Raca
JOIN ValorEnumerado AS enumnomeRaca ON Raca.pknomeRaca = enumnomeRaca.pk
JOIN corDePeloAnimal ON Raca.pk = corDePeloAnimal.pkRaca
JOIN AnimalProd ON AnimalProd.pk = corDePeloAnimal.pkAnimalProd
JOIN (CorPeloAnimal JOIN ValorEnumerado AS enumnomeCorPelo
ON CorPeloAnimal.pknomeCorPelo = enumnomeCorPelo.pk )
ON CorPeloAnimal.pk = corDePeloAnimal.pkCorPeloAnimal
WHERE corDePeloAnimal.pkAnimalProd = pkEnt;
24
25
26
27
RETURN csr;
END;
$$ LANGUAGE ’plpgsql’;
No Código 5.9, a instruções das linhas 8 e 13 obtém o valor das chaves estrangeiras para entidade AnimalProd e para o atributo objeto interno corPeloRaca. No
Código 5.10, as instruções para obtenção de chave estrangeira são as mesmas instruções
encontradas no Código da stored procedure de inserção.
5.3 Exemplo: SI para o Agronegócio
110
Código 5.9 Stored Procedure para Inserção de Instância do Atributo Objeto Interno Cor
de Pelo Animal
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
CREATE OR REPLACE FUNCTION inserircordepeloanimal(codigoproprurger VARCHAR,
idanimalger VARCHAR, nomeracager VARCHAR, nomecorpeloger VARCHAR)
RETURNS boolean AS $$
DECLARE
pkEnt INTEGER;
pkAtribRef INTEGER;
BEGIN
SELECT INTO pkEnt AnimalProd.pk FROM PropRur
JOIN propRurAnimal ON PropRur.pk = propRurAnimal.pkPropRur
JOIN Animal ON Animal.pk = propRurAnimal.pkAnimal
JOIN AnimalProd ON Animal.pk = AnimalProd.pk
WHERE PropRur.codigoPropRur = codigoPropRurGER AND Animal.idAnimal = idAnimalGER;
SELECT INTO pkAtribRef corPeloRaca.pk FROM CorPeloAnimal
JOIN ValorEnumerado AS enumnomeCorPelo ON
CorPeloAnimal.pknomeCorPelo = enumnomeCorPelo.pk
JOIN corPeloRaca ON CorPeloAnimal.pk = corPeloRaca.pkCorPeloAnimal
JOIN Raca ON Raca.pk = corPeloRaca.pkRaca
WHERE enumnomeRaca.mnemonico = nomeRacaGER AND
enumnomeCorPelo.mnemonico = nomeCorPeloGER;
INSERT INTO corDePeloAnimal (pkAnimalProd, pkcorPeloRaca) VALUES
(pkEnt , pkAtribRef);
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
5.3 Exemplo: SI para o Agronegócio
111
Código 5.10 Stored Procedure para Remoção de Instância do Atributo Objeto Interno Cor
de Pelo Animal
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
CREATE OR REPLACE FUNCTION desativarcordepeloanimal(codigoproprurger VARCHAR,
idanimalger VARCHAR, nomeracager VARCHAR, nomecorpeloger VARCHAR)
RETURNS boolean AS $$
DECLARE
pkEnt INTEGER;
pkComp INTEGER;
BEGIN
SELECT INTO pkEnt AnimalProd.pk FROM PropRur
JOIN propRurAnimal ON PropRur.pk = propRurAnimal.pkPropRur
JOIN Animal ON Animal.pk = propRurAnimal.pkAnimal
JOIN AnimalProd ON Animal.pk = AnimalProd.pk
WHERE PropRur.codigoPropRur = codigoPropRurGER AND Animal.idAnimal = idAnimalGER;
SELECT INTO pkAtribRef corPeloRaca.pk FROM CorPeloAnimal
JOIN ValorEnumerado AS enumnomeCorPelo ON
CorPeloAnimal.pknomeCorPelo = enumnomeCorPelo.pk
JOIN corPeloRaca ON CorPeloAnimal.pk = corPeloRaca.pkCorPeloAnimal
JOIN Raca ON Raca.pk = corPeloRaca.pkRaca
WHERE enumnomeRaca.mnemonico = nomeRacaGER AND
enumnomeCorPelo.mnemonico = nomeCorPeloGER;
DELETE FROM corDePeloAnimal WHERE pkAnimalProd = pkEnt And
pkcorPeloRaca = pkAtribRef;
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’
Este capítulo apresentou a criação (Seção 5.1) e utilização (Seção 5.2) de SI
a partir do framework do qual o componente EBD faz parte. A Seção 5.3 apresentou
exemplos de criação de uma pequena porção do esquema de um SI real do domínio
agropecuário.
CAPÍTULO 6
Aplicações de Mapeamentos na Evolução de
Esquemas
Este capítulo discute as operações permitidas na evolução de esquemas de BD
de SI (Seção 6.1). A Seção 6.2 introduz o mecanismo de evolução de esquemas de BD
no 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 de
evoluçã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 é mapeada
do MMO para o MR, e deste para o SQL. Antes de efetuar a mudança, a consistência dos
dados é garantida para o novo esquema [23, 24]. Os mapeamentos envolvidos na evolução
de 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 para
os dados do SI. A Seção 6.1.1 analisa as mudanças de tipo e domínio de atributo. A Seção
6.1.2 avalia as mudanças permitidas na chave lógica de entidade. A Seção 6.1.3 aborda
mudanç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 é um
tipo/domínio de atributo no MMO e as transições definem as operações permitidas para
passar de um estado para outro.
O SGBD PostgreSQL oferece suporte às transformações 1, 3, 4, 6 e 8, mas não
permite 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 existir
valores 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 atributo 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 conversor
de Varchar para Integer. O mesmo algoritmo pode ser usado para permitir as transições 5
e 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 mapeado
para um atributo do tipo Básico Alfanumérico. As seguintes operações são necessárias
para 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 passo
anterior.
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 as
seguintes operações:
1. Todos os valores do atributo alfanumérico são testados, contra os valores da relação
ValorEnumerado, para verificar se pertencem ao domínio escolhido. O teste fica
restrito 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 o
atributo pkDom na Figura 4.1.
3. Para cada valor do atributo alfanumérico é obtido o valor do atributo pk na relação
ValorEnumerado e atribuído ao atributo criado no passo anterior.
4. O atributo alfanumérico é removido da relação.
6.1 Tipos de mudanças permitidas no esquema MMO
6.1.2
114
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 feita
com os seguintes passos: (i) criar o novo atributo na entidade; (ii) mapear a entidade para
o 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 do
mapeamento para o BD. Tais modificações de ampliação do conjunto de atributos chave
são necessárias apenas nos casos em que a entidade do mundo real modifica a sua forma
de identificação. Por exemplo, a entidade funcionário poderia ter o campo matrícula como
chave. Com a criação de filiais para empresa em que o funcionário trabalha, a matrícula
poderia não mais ser única na empresa, e sim em cada filial. Neste caso a nova chave da
entidade funcionário deveria ser composta de matrícula e filial.
Para remover um atributo da chave são definidas as seguintes operações: verificar
se a chave lógica possui mais de um atributo; verificar se o conjunto de atributos que
compõem a chave, menos o atributo que será retirado, satifaz a restrição de unicidade
entre as instâncias da entidade no BD. Se sim, o atributo é retirado da chave da entidade
e é 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 em
chave lógica de entidade podem ser aplicadas da mesma forma para o tipo de entidade
fraca, só que neste caso são considerados os atributos que formam a chave parcial da
entidade.
No caso de entidades que estão envolvidas em uma especialização, os procedimentos descritos anteriormente são aplicados somente às superentidades, pois são estas
que 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 Entidade
está relacionada ao seu tipo ("Forte", Fraca e Especializada). A Figura 6.2 mostra as
possí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. Para
executar 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.
6.1 Tipos de mudanças permitidas no esquema MMO
115
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 atributo
objeto interno definido no passo anterior. A criação da relação é feita utilizando o
mapeamento 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) é processada
como segue: verificar se as instâncias dos atributos que formam a chave parcial da
entidade 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 parcial
de modo que eles sejam únicos entre si. O framework disponibiliza uma aplicação para
modificaçã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 forte
em entidade especializada) segue os seguintes passos:
1. Escolher a instância de tipo de entidade que será modificada, e a superentidade para
esta instância.
2. Criar um atributo inteiro, na relação da subentidade, com a restrição de chave
estrangeira para a relação da superentidade (conforme a Figura 4.2); e ligar as
instâ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 Figura
6.2 pode ser executada da seguinte forma:
1.
2.
3.
4.
5.
replicar na subentidade todos os atributos da superentidade;
copiar todos os valores correspondentes para os atributos criados no primeiro passo;
criar as restrições de integridade (chave primária, chave estrangeira e unicidade);
remover a chave estrangeira que liga a subentidade com a superentidade;
remover todas as instâncias da superentidade correspondente as instâncias da antiga
subentidade.
6.1 Tipos de mudanças permitidas no esquema MMO
116
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 valores
dos 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 chave
primária para o atributo pk e a restrição de unicidade para o atributo cpf. Finalmente
são removidas a restrição de chave estrangeira da entidade funcionário para a entidade
pessoa 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, é mapeada
diretamente para mudança do nome da relação ou atributo. Primeiramente, verifica-se
o novo mnemônico satisfaz a restrição de unicidade (mnemônico de tipo de entidade e
atributo deve ser único no SI).
Um atributo pode pertencer a uma entidade ou a outro atributo. No processo de
evolução do BD pode ser necessária mudança na qual um atributo que pertença a uma
entidade passe a pertencer a um atributo composto ou vice-versa. Neste tipo de mudança
deve ser considerada a cardinalidade máxima do atributo composto.
A mudança que envolve composto monovalorado não tem impacto no nível de
instância no BD pois os atributos de um atributo composto monovalorado são colocados
na 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 e
apelido. Tornando o atributo apelido componente do composto dados pessoais o mapeamento para o SQL continua o mesmo, pois todos os atributos do composto monovalorado
são mapeados para a relação da entidade.
Já a mudança de um atributo pertencente a uma entidade para um atributo
composto multivalorado envolve as seguintes operações:
1. Cada atributo conhece o atributo ao qual ele pertence: se o valor do atributo
compositor for vazio então o atributo pertence a entidade. Então, o atributo em
questã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.
6.1 Tipos de mudanças permitidas no esquema MMO
117
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ível
armazenar 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 para
uma entidade não foi definida, pois o resultado desta operação seria uma tabela com
apenas um atributo e valores que fazem sentido somente no composto em questão. Por
exemplo, o atributo multivalorado telefone é composto pelos atributos ddd e número, os
valores do atributo ddd não faz sentido fora do composto telefone.
No MMO é possível definir se um atributo é armazenado ou não. Quando um
atributo não é armazenado (derivado) então é associada a ele uma regra de derivação que
calcula o valor deste atributo. Por exemplo, o atributo idade de uma pessoa física é um
atributo derivado. Um atributo pode ser modificado de armazenado para derivado e viceversa. Para passar um atributo armazenado para derivado são necessárias as seguintes
operações:
1. É Armazenado é um atributo booleano do metadado Atributo. Nesta transformação
o 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 os
seguintes passos devem ser seguidos:
1. O atributo É Armazenado do Atributo que está sendo modificado recebe o valor
true.
2. No mapeamento para SQL é feito um ALTER TABLE para criar o atributo na tabela
que 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 atributo
pode 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 Esquema
apresentada na Seção 6.2.
6.1 Tipos de mudanças permitidas no esquema MMO
118
Em relação à cardinalidade mínima de um atributo, duas operações de
manutenção podem ser aplicadas: Uma quando há mudança da cardinalidade mínima de
zero para maior ou igual a um, e outra quando se tem a cardinalidade mínima maior que
um 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 igual
a 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 cada
instâ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 ser
executada 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 monovalorado em multivalorado ou vice-versa. Basta mudar a cardinalidade máxima de um para
um valor maior que um, no primeiro caso, ou mudar o valor maior que um para um, no
segundo caso. A mudança de cardinalidade máxima de um atributo de um para maior que
um 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 na
Seção 4.1.4.
(b) Copiar os valores do atributo para a nova tabela e associar a instância do
atributo com a instância da entidade.
(c) Com ALTER TABLE remover o atributo da tabela que o contém.
6.1 Tipos de mudanças permitidas no esquema MMO
119
O processo inverso em relação a cardinalidade máxima pode ser feito da seguinte
maneira:
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 e
copiar este valor;
(b) Com DROP TABLE remover a tabela que contém os valores do atributo
modificado.
No MMO, o atributo "Único"do metadado Atributo tem a mesma semântica
da claúsula UNIQUE de SQL, que é definir como uma restrição de integridade que
as instâncias do atributo devem ser únicas na relação. Ele é definido com um valor
booleano, onde true indica que o atributo é único, e false o contrário. Para um atributo ser
contemplado 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 do
tamanho 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 representa 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 igual
ao novo tamanho:
A. Sim. Com ALTER TABLE, atualizar o valor do tamanho na coluna
que representa o atributo;
B. Não. Não faz nada.
6.2 Mecanismo para Evolução de Esquema de BD
6.2
120
Mecanismo para Evolução de Esquema de BD
A evolução do esquema conceitual de entidades do MMO é feita através do
cadastro de tipo de entidade. Primeiramente a instância da entidade é modificada através
do 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 mecanismo
descrito na Seção 5.2.1, mas a atualização é feita através de uma classe específica para
evolução de tipo de entidade (classe AplicacaoEvolucao), apresentada na Figura 6.3. A
classe AplicacaoEvolucao é uma subclasse da classe AplicacaoCadastro.
Figura 6.3: Colaboração no Mecanismo de Verificação e Adaptaçã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 da
instância de tipo de entidade foram modificadas.
Para cada característica modificada é feita uma avaliação se a mudança pode ou
nã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âncias
armazenadas. Para algumas modificações são necessárias adaptações no esquema operacional do BD. Por exemplo, a inclusão de um atributo na chave lógica de uma entidade
exige 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 podem
ser aplicadas no BD devido aos dados da entidade não serem compatíveis com a modificaçã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 desta
aplicação.
Cada linha da planilha contém uma instância da entidade modificada. A área das
instâncias é divida em outras duas: área dos atributos de ligação da entidade (atributos
que 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ão
todos aqueles que foram modificados e necessitam de ajuste das instâncias para permitir
a propagação.
A interface possui também uma área para atualização múltipla dos valores dos
atributos. 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 o
valor 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 a
avaliação for positiva, a modificação no esquema operacional é aplicada.
6.3 Evolução do Sistema de Informação
6.3
122
Evolução do Sistema de Informação
Quando o contexto do negócio muda, é necessário evoluir o modelo conceitual
do 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 de
Entidade (Figura 5.1), também utilizado para geração do SI. O processo de manipulação
de metadados é o mesmo processo utilizado para os dados, como foi definido na Seção
5.2.
O processo de evolução das Regras de Negócio do SI do framework é feito no
módulo Regra. Ele recebe a regra modificada (em OCL) e faz todas as validações em
relaçã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ífico
para tratar essa evolução: Serviço de Evolução de Esquema.
A seguinte sequência de atividades deve ser executada no processo de evolução
de BD no framework:
1. O módulo de Persistência recebe uma versão modificada dos metadados de um tipo
de entidade e faz uma cópia da versão não modificada. Esta cópia é armazenada
como metadados, no próprio banco de dados do SI, semelhante ao mecanismo de
shadow 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 processo
verifica todas as modificações, comparando as duas versões do esquema: a versão
original e a versão modificada.
3. Modificações no modelo conceitual levam a um conjunto de operações de evolução
que devem ser propagadas para o modelo operacional (incluindo tanto o código em
SQL-DDL quanto o código das stored procedures).
4. Depois de verificar a consistência da nova versão, o processador gera o conjunto
de operações de evolução de esquema pertinente. Estas operações são aplicadas
no esquema operacional, modificando as instruções SQL-DDL e os procedimentos
armazenados, além de todas as instâncias do tipo de entidade armazenadas no banco
de 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 o
módulo de Negócio) não sofrem impacto quando modificações no modelo conceitual são
aplicadas.
6.4 Exemplos de Evolução de Esquema
6.4
123
Exemplos de Evolução de Esquema
Esta seção apresenta dois exemplos de evolução do esquema obtidos do projeto
SIA [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, contemplando
informações sobre animais, manejos e estoques de produtos, por exemplo.
Este fato limitava a aplicação do SIA em relação à necessidade de proprietários
que possuem duas ou mais propriedades. Para adaptar o SIA a esta necessidade foi
necessário modificar algumas entidades, tornando-as dependentes da propriedade rural.
Por exemplo, a entidade Animal foi transformada em entidade fraca da entidade Propriedade 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 foi
criado um atributo objeto interno que faz parte da chave da entidade (atributo
propRurAnimal)
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ão
modifica as instâncias armazenadas.
(b) Adaptação do Esquema: através do mecanismo de mapeamento (Tabelas 4.3 e
4.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. As
duas 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 faz
a 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 do
CPF. Porém, existiam casos de pessoas que não possuiam este documento. Para permitir a
flexibilidade da identificação, o esquema da entidade Pessoa Física foi modificado usando
as 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 o
valor do documento.
2. A propagação desta mudança foi executada através das atividades:
6.4 Exemplos de Evolução de Esquema
124
Figura 6.5: Ligação das instâncias de Animal com Propriedade
Rural
(a) Avaliação da mudança: neste caso a mudança não tem impacto pois não
modifica as instâncias armazenadas.
(b) Adaptação do Esquema: os dois atributos foram mapeados para a tabela da
entidade Pessoa Física.
(c) Adaptação das Instâncias: as instâncias de Pessoa Física foram atualizadas a
partir da inteface da Figura 6.6
(d) Para finalizar a coluna CPF foi removida da tabela e foi aplicada às duas
colunas criadas a restrição UNIQUE.
Na Figura, as duas primeiras colunas são os atributos de ligação da entidade
Pessoa Física (Nome e CPF). As outras duas colunas são referentes aos dois novos
atributos (Tipo Identificador e Valor Identificador)
Este capítulo discutiu as operações permitidas na evolução de esquemas de BD
de SI (Seção 6.1). A Seção 6.2 introduziu o mecanismo de evolução de esquemas de BD
no 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 reais
de evolução de um SI agropecuário.
6.4 Exemplos de Evolução de Esquema
Figura 6.6: Modificação da Chave das Instâncias da Entidade Pessoa Física
125
CAPÍTULO 7
Experimentação do Componente EBD
Este capítulo apresenta o procedimento utilizado para avaliar aspectos de funcionalidade 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 de
software. 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 que
atendam às necessidades explícitas e implícitas, quando o software estiver sendo utilizado
sob condições especificadas. A norma ISO 9126 indica as subcaracterísticas que deveriam
ser avaliadas para assegurar que a funcionalidade é apropriada, dentre as quais o protocolo
de experimentação definido contempla:
• Adequação: Capacidade do produto de software de prover um conjunto apropriado
de 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 normas, convenções ou regulamentações previstas em leis e prescrições similares relacionadas à funcionalidade.
Já a Usabilidade é definida como a capacidade do produto de software de ser
compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições especificadas [37]. No procedimento de experimentação definido são avaliadas as seguintes
subcaracterísticas de usabilidade do componente EBD:
• Inteligibilidade: Capacidade do produto de software de possibilitar ao usuário
compreender se o software é apropriado e como ele pode ser usado para tarefas
e condições de uso específico;
7.2 Coleta de Dados
127
• Apreensibilidade: Capacidade do produto de software de possibilitar ao usuário
aprender 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 no
protocolo 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 envolvem
o tempo utilizado para a realização das atividades e o número de erros presentes
nos resultados das atividades.
As subcaracterísticas Interoperabilidade e Segurança de Acesso de Funcionalidade, Atratividade e Conformidade de Usabilidade assim como as características Confiabilidade, Eficiência, Manutenibilidade e Portabilidade não foram abordadas neste experimento. 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 desenvolvedores (D1, D2, D3, D4 e D5) que satisfazem o seguinte perfil:
• experiência de pelo menos um ano em desenvolvimento de software para Sistemas
de 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ção
da experimentação e conta com um procedimento que possui cinco atividades, nivelamento, 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 fornecidos
aos desenvolvedores.
A Tabela 7.1 apresenta o tempo gasto pelos cinco desenvolvedores para execução
das atividades de treinamento e desenvolvimento.
A Tabela 7.2 apresenta a quantidade de erros de cada desenvolvedor na atividade de desenvolvimento. Os erros foram coletados pelo pesquisador que coordenou o
experimento, a medida em que aconteciam.
A Tabela 7.3 apresenta a quantidade de tabela e stored procedures geradas pelos
cinco desenvolvedores em relação ao tempo de desenvolvimento.
7.3 Análise dos Resultados
Treinamento
Desenvolvimento
Total
128
D1
90min
101min
171min
D2
90min
136min
226min
D3
50min
79min
129min
D4
45min
101min
146min
D5
50min
110min
160min
Tabela 7.1: Tempos de Execução da Experimentação
Desenvolvimento
Número de Erros
Média (erros/10min)
D1
101 min
19
1,9
D2
136 min
13
0,9
D3
79 min
09
1,1
D4
101 min
17
1,7
D5
110 min
22
2
Tabela 7.2: Tempo de Desenvolvimento e Quantidade de Erros
Desenvolvimento
Número de Tabelas
Número de Procedures
Elementos do Esquema
Média (elemento/min)
D1
101 min
15
42
57
0,56
D2
136 min
15
42
57
0,41
D3
79 min
15
42
57
0,72
D4
101 min
15
42
57
0,56
D5
110 min
15
42
57
0,51
Tabela 7.3: Tempo de Desenvolvimento e Produtos Gerados
Questão/Subcaracterística
1. Adequação
2. Acurácia
3. Conformidade
4. Inteligibilidade (Percepção)
5. Inteligibilidade (Facilidade de Uso)
6. Apreensibilidade
7. Operacionalidade
SIM
5
5
5
3
3
2
5
PARCIALMENTE
0
0
0
2
2
2
0
NÃO
0
0
0
0
0
1
0
Tabela 7.4: Respostas do Questionário de Avaliação da Experimentação da Ferramenta EBD
Na atividade de avaliação da ferramenta os desenvolvedores responderam o
questionário descrito na Seção A.3 do Apêndice A. A Tabela 7.4 apresenta a quantificação
das respostas deste questionário.
7.3
Análise dos Resultados
Pelas respostas obtidas dos desenvolvedores, a ferramenta EBD possui um
conjuntos 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 sofre
perda de informação em relação ao modelo conceitual original e, da mesma forma, o
modelo em SQL gerado é consistente com o modelo conceitual original.
7.3 Análise dos Resultados
129
Com as respostas da Questão 8 do formulário os participantes apontaram algumas melhorias para o componente como: a necessidade de visualização do esquema antes
ou mesmo depois de ser gerado; geração do atributo sequencial (este atributo define a
ordem dos atributos de uma entidade no MMO); teclas de atalho e modificação da aplicação, permitindo editar os atributos em uma planilha, onde cada linha seria um atributo
da entidade.
Em relação à percepção das funcionalidades oferecidas pela ferramenta, dois dos
cinco desenvolvedores tiveram certa dificuldade de assimilar alguns conceitos do MMO.
Como por exemplo, o mapeamento para relacionamento feito pelo atributo do tipo objeto
interno e o momento em que o esquema operacional do BD deveria ser gerado. Os erros
detectados 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 erros
foi pequena para todos os desenvolvedores, como mostra a Tabela 7.2. A menor taxa de
erro 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 nenhum dos cinco desenvolvedores, devido à grande quantidade de conceitos apresentados.
Um dos participantes marcou como negativa a apreensiblidade, apesar de justificar que no
tempo do treinamento todos os conceitos foram passados, permitindo assim a utilização
do componente.
Foi consenso entre os participantes que a ferramenta diminui o esforço em
relação à modelagem e geração de esquema em relação ao processo manual. A Tabela
7.3 traz a média de produção de cada um dos desenvolvedores. O melhor caso criou um
elemento do esquema (tabela ou stored procedure) em pouco mais de um minuto, tempo
significamente mais curto do que necessário para criar um destes elementos manualmente.
Neste experimento o tamanho do esquema utilizado foi pequeno (6 entidades
e 7 relacionamentos), mas a partir dele foram exercitados grande parte dos conceitos
para definição de esquemas no MMO. Também foi consenso entre os participantes que
a utilização do componente ajuda na produtividade em relação à criação de BD de SI.
7.3 Análise dos Resultados
130
Este capítulo apresentou o procedimento utilizado para avaliar aspectos de
funcionalidade e usabilidade da ferramenta EBD. Foram apresentados também os dados
coletados e a análise destes dados.
CAPÍTULO 8
Conclusõ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 indica
trabalhos futuros e possíveis extensões.
8.1
Considerações Finais
No ciclo de vida de BD são utilizados mecanismos de transformação para
geração e evolução do esquema e das aplicações do BD. Esses processos (geração e
evolução de esquema) quando executados de forma manual, estão sujeitos a erros no
momento 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 aplicadas
diretamente no modelo físico (ou operacional) do BD; tornando o modelo conceitual
desatualizado. Outro problema que dificulta os processos de geração e evolução de
esquema 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 e
evolução de bancos de dados de Sistemas de Informação (SI). Para isso foi projetado e
implementado um componente nomeado de Especialista em Banco de Dados (EBD).
O EBD é um componente de um framework de software que constroi, evolui e
gerencia SI com base na abordagem dirigida por modelos [58]. O processo de criação e
evolução de esquemas de BD de SI proposto neste trabalho envolve dois tipos de transformação: do Modelo de Meta Objetos (MMO) para o Modelo Relacional; e deste para um
dialeto do SQL. Além do esquema do BD, são gerados procedimentos armazenados para
operações do tipo Criação, Recuperação, Atualização e Remoção (CRUD) para manipulação dos dados das entidades modeladas, o que facilita o desenvolvimento de aplicações
de BD.
As informações do modelo conceitual (metadados) são armazenadas no próprio
BD 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 disponibilidade fornecida pelo SGBD.
Uma possível limitação desta prática é a mudança do SGBD onde estão armazenadas as informações que representam o SI. No entanto, na abordagem proposta
neste trabalho, o uso de técnicas de engenharia de software baseada em modelos garante
a independência de SGBD, bastando que o mecanismo de transformação de modelos seja
ajustado para o SGBD alvo.
Além da geração e evolução do esquema, o componente EBD fornece serviços
para outros componentes do framework. Por exemplo, obtenção de metadados de tipo de
entidade, verificação de existência de chave lógica de uma entidade e serviços utilizados
para 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 ferramentas
encontradas que atendem necessidades gerais de evolução e geração de BD, mas não
atendem as necessidades específicas das aplicações de SI.
A automatização do processo de transformação dos modelos, segundo a abordagem MDD, trata problemas relacionados ao desenvolvimento de sistema de software e
também de BD. Há uma diminuição de erros relacionados a transformação, que é feita por
ferramentas e de forma automática. O esquema conceitual permanece sempre atualizado,
pois as modificações são executadas no esquema conceitual e propagadas automaticamente para os esquemas lógico e físico.
Além disso, há um ganho de produtividade, pois ao término da modelagem o
esquema é gerado automaticamente. Outra vantagem está relacionada à portabilidade da
aplicação, pois a lógica de negócio é separada da linguagem utilizada para implementação.
A principal dificuldade desta abordagem MDD é o custo de desenvolvimento
de ferramentas de transformação automática de esquemas, como a que é proposta neste
trabalho.
8.2
Contribuições
A principal contribuição deste trabalho é a definição de uma abordagem que
apóia todo o ciclo de vida de BD de SI. Esta abordagem contempla uma arquitetura
de sofware que permite a geração e evolução do esquema em SI. Foi criado também
um mecanismo que oferece as operações básicas para manipulação das instâncias das
entidades do SI. Este mecanismo utiliza stored procedures geradas para implementar estas
operaçõ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 de
dados 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 SQL
do 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 no
XXIII Simpósio Brasileiro de Engenharia Software [21], onde é descrita a relação do
componente de persistência proposto neste trabalho com o restante do framework de
desenvolvimento de SI.
8.3
Trabalhos Futuros
A continuidade do trabalho aqui descrito visa implementar mapeamentos para
diferentes formas de persistência, incluindo outros SGBDs baseados em SQL e também
outras formas de armazenamento não baseadas em SQL.
Além disso, o framework de SI continua em evolução, trazendo novas demandas
por operações de geração e evolução automática de esquemas que não foram previstas na
versã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 melhorado
no sentido de definir operações mais eficientes para o BD do SI. Para isso o mecanismo
deveria considerar características específicas do SGBD alvo e não apenas transformações
genéricas como os que foram descritas neste trabalho.
Outra melhoria que pode ser adicionada é a definição de uma notação gráfica
para os conceitos do MMO, associada a um editor que permita o desenvolvimento de um
esquema conceitual de forma visual, diferente da edição por formulários de cadastro.
Dentre os mapeamentos definidos para evolução de esquema (discutidos no
Capí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 ser
implementados para um suporte completo às mofificações permitidas pelo framework.
Referências Bibliográficas
[1] A BRA P ROJECT . Abra - light weight java persistence framework. http://abra.
sourceforge.net/, último acesso em janeiro de 2010.
[2] A PACHE S OFTWARE F OUDATION . Apache ObJect Relational Bridge - OJB. http:
//db.apache.org/ojb/, último acesso em janeiro de 2010.
[3] A PACHE S OFTWARE F OUDATION . Cayenne: Object relational mapping, persistence 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 E BEAN ORM. Avaje Ebean ORM Persitence Layer. http://www.avaje.
org/, último acesso em janeiro de 2010.
[6] B ALZER , R. Transformational implementation: An example. IEEE Transactions
Software Engineering, 7(1):3–14, 1981.
[7] B ANERJEE , J.; K IM , W.; K IM , 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] B ERGIN , T. J. Computer-Aided Software Engineering. Idea Group Publishing,
1993.
[9] B ERNSTEIN , P. A.; H O, 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] B ERNSTEIN , P. A.; M ELNIK , S.; C HURCHILL , 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.
Referências Bibliográficas
136
[11] B ERNSTEIN , P. A.; M ELNIK , S.; P ETROPOULOS , M.; Q UIX , C. Industrial-strength
schema matching. SIGMOD Rec., 33:38–43, December 2004.
[12] B OFF , 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] B OFF , G.; DE O LIVEIRA , J. L. Modelagem, implementação e manutenção de
regras de negócio em sistemas de informação. VIII Simpósio Brasileiro de Qualidade de Software - VI WMSWM (Workshop de Manutenção de Software Moderna).
Ouro Preto, Minas Gerais, Brasil, 2009.
[14] B OUNIF, H.; P OTTINGER , 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] C HEN , 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 S ILVA , 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 S ILVA , W. C.; DE O LIVEIRA , J. L. Gerência de interface homem-computador
para sistemas de informação empresariais: uma abordagem baseada em modelos. iSys - Revista Brasileira de Sistemas de Informação, 2, 2009.
[20] D B V IS S OFTWARE . Dbvisualizer: The universal database tool. http://www.
dbvis.com/, último acesso em janeiro de 2010.
[21] DE A LMEIDA , A. C.; B OFF , G.; DE O LIVEIRA , 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 O LIVEIRA , 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.
Referências Bibliográficas
137
[23] D OMÍNGUEZ , E.; L LORET, J.; RUBIO, A. L.; Z APATA , M. A. Medea: A database
evolution architecture with traceability. Data Knowl. Eng., 65(3):419–441, 2008.
[24] D OMÍNGUEZ , E.; L LORET, J.; Z APATA , 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] D UBIELEWICZ , I.; H NATKOWSKA , B.; H UZAR , Z.; T UZINKIEWICZ , L. Feasibility analysis 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] E DEN , A. Databind. http://databind.sourceforge.net/, último acesso em
janeiro de 2010.
[27] E MBLEY, D. W.; X U, 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] E XOLAB G ROUP . The castor project. http://www.castor.org/, último acesso
em janeiro de 2010.
[29] FABFORCE . Dbdesigner. http://www.fabforce.net/dbdesigner4/index.php,
último acesso em janeiro de 2010.
[30] F ICKAS , S. F. Automating the transformational development of software. IEEE
Trans. Softw. Eng., 11(11):1268–1277, 1985.
[31] F RANCE , 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] H AINAUT, J.-L.; C HANDELON , M.; TONNEAU, C.; J ORIS , M. Contribution to a theory
of database reverse engineering. 1993.
[33] H ALPIN , T. Object-role modeling. www.orm.net/, último acesso em março de
2010, 2009.
[34] H ALPIN , T. A.; P ROPER , H. A. Database schema transformation and optimization. In: OOER ’95: Proceedings of the 14th International Conference on ObjectOriented and Entity-Relationship Modelling, p. 191–203, London, UK, 1995. SpringerVerlag.
Referências Bibliográficas
138
[35] H ICK , J.-M.; H AINAUT, 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 softwareintensive systems, 07 2007.
[39] J AHNKE , J. H.; WADSACK , J. P. Varlet: Human-centered tool support for database
reengineering. Proceedings of the Workshop on Software Reengineering, 1999.
[40] J AVA S UN . Annotations. http://abra.sourceforge.net/, último acesso em
janeiro de 2010.
[41] JBOSS C OMMUNITY . Hibernate: Relational persistence for java and .net. http:
//www.hibernate.org/, último acesso em janeiro de 2010.
[42] K ILDEN -P EDERSEN , N.
OR Broker: JDBC Framework.
http://orbroker.
sourceforge.net/, último acesso em janeiro de 2010.
[43] K LEPPE , A. G.; WARMER , J.; B AST, W.
MDA Explained: The Model Driven
Architecture: Practice and Promise. Addison-Wesley Longman Publishing Co.,
Inc., Boston, MA, USA, 2003.
[44] KORPELA , M.; M URSU, A.; S ORIYAN , H. A. Information systems development
as an activity. Journal Computer Supported Cooperative Work, 11:111–128, April
2002.
[45] L I , B.; L IU, S.; Y U, 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] M C B RIEN , P.; P OULOVASSILIS , A.
Data integration by bi-directional schema
transformation rules. International Conference on Data Engineering, p. 227, 2003.
[47] M IAN , N. A.; H USSAIN , T. Database reverse engineering tools. In: SEPADS’08:
Proceedings of the 7th WSEAS International Conference on Software Engineering,
Referências Bibliográficas
139
Parallel and Distributed Systems, p. 206–211, Stevens Point, Wisconsin, USA, 2008.
World Scientific and Engineering Academy and Society (WSEAS).
[48] O BJECT M ANAGEMENT G ROUP .
Uml resource page. http://www.uml.org/,
último acesso em março de 2010, 2010.
[49] O RACLE AND / OR I TS A FFILIATES . Introduction to the java persistence api. http:
//download.oracle.com/javaee/6/tutorial/doc/bnbpz.html, último acesso
em novembro de 2010.
[50] PG A DMIN P OSTGRE SQL TOOLS . Postgresql administration and management
tools. http://www.pgadmin.org/, último acesso em janeiro de 2010.
[51] P HILIPPI , S. Model driven generation and testing of object-relational mappings.
Journal of Systems and Software, 77(2):193–207, 2005.
[52] P OSTGRE SQL G LOBAL D EVELOPMENT G ROUP . Pl/pgsql - sql procedural language. http://www.postgresql.org/docs/8.4/static/plpgsql.html, último
acesso em janeiro de 2010.
[53] P OSTGRE SQL G LOBAL D EVELOPMENT G ROUP . Postgresql - the world’s most
advanced open source database. www.postgresql.org, último acesso em janeiro
de 2010.
[54] Q UEST S OFTWARE . Toad data modeler - database design tool. http://www.
toadsoft.com/toaddm/toad_data_modeler.htm, último acesso em janeiro de
2010.
[55] R AMEZ E LMASRI , S. N. Sistemas de Banco de Dados. Addison-Wesley, 2005.
[56] R AUH , O.; S TICKEL , E.
er schemata.
Standard transformations for the normalization of
In: CAiSe ’95: Proceedings of the 7th International Conference
on Advanced Information Systems Engineering, p. 313–326, London, UK, 1995.
Springer-Verlag.
[57] R EVER . Db-main - the modeling framework. http://www.db-main.eu/, último
acesso em janeiro de 2010.
[58] S CHMIDT, D. C. Model-driven engineering. In: IEEE Computer, vol. 39, no. 2, p.
25–31. doi:10.1109/MC.2006.58, 2006.
[59] S OFTWARE T REE . NJDX: A Powerful and Practical OR-Mapper for .NET. http:
//www.softwaretree.com/, último acesso em janeiro de 2010.
Referências Bibliográficas
140
[60] S OLUTIONS D ESIGN BV. Llblgen pro: The leading o/r mapper generator. http:
//www.llblgen.com/defaultgeneric.aspx, último acesso em janeiro de 2010.
[61] S UN D EVELOPER N ETWORK . Jdbc overview. http://java.sun.com/products/
jdbc/overview.html, último acesso em janeiro de 2010.
[62] S YBASE . Powerdesigner - modeling and metadata management software tool.
http://www.sybase.com/products/modelingdevelopment/powerdesigner,
último acesso em janeiro de 2010.
[63] T ELERIK C ORPORATION . 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.; G ALANTE , R.; P IMENTA , M. S. Towards a UML Profile for ModelDriven Object-Relational Mapping. XXIII Simpósio Brasileiro de Engenharia de
Software (SBES). Fortaleza - CE - Brasil, 0:94–103, 2009.
[65] V ELEGRAKIS , Y.; M ILLER , J.; P OPA , L. Preserving mapping consistency under
schema changes. The VLDB Journal, 13(3):274–293, 2004.
[66] V ELEGRAKIS , Y.; M ILLER , R. J.; P OPA , 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] V ISUAL PARADIGM . Database visual architect: Access database with objectoriented technology. http://www.visual-paradigm.com/product/dbva/, último acesso em janeiro de 2010.
[68] XD OCLET T EAM . 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.
APÊNDICE A
Protocolo para Avaliação da Ferramenta EBD
Este documento descreve um protocolo para avaliação experimental da ferramenta EBD (Especialista em Bancos de Dados).
A.1
Objetivos da Avaliação
O presente procedimento tem como finalidade avaliar aspectos de funcionalidade
e 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 deles
deverá executar as seguintes atividades:
1. Atividade de Nivelamento: duração de 30 minutos. Os participantes receberão
treinamento sobre os conceitos do MMO e sobre a forma de utilizar a ferramenta
EBD para modelagem conceitual de bancos de dados.
2. Atividade de Entendimento: duração de 30 minutos. Os participantes receberão
informaçõ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 esquema
conceitual de banco de dados descrito com o MER e deverão utilizar a ferramenta
EBD 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 validar
o esquema operacional (em SQL do SGBD PostgreSQL) de BD gerado pela
ferramenta EBD com relação ao esquema conceitual de BD originalmente descrito
com o MER.
Apêndice A
142
5. Atividade de Avaliação da Ferramenta: duração de 30 minutos. Após a realização
da modelagem, cada participante irá responder ao questionário que consta no Anexo
A.3.
O tempo gasto pelos participantes para realizar cada atividade será cronometrado
pelo pesquisador que controla o experimento de avaliação da ferramenta EBD. Da mesma
forma, esse pesquisador irá contabilizar o número de erros presentes nos resultados de
cada participante.
A.3
Questionário
1. Adequação: A ferramenta oferece um conjunto apropriado de funções para as
tarefas e objetivos especificados, ou seja, para criar um modelo conceitual de BD e
para gerar um esquema operacional de BD a partir do modelo conceitual?
( ) Sim
( ) Parcialmente
( ) Não
Justifique se a resposta é diferente de Sim:
__________________________________________________________________
__________________________________________________________________
2. Acurácia: O esquema conceitual modelado com a ferramenta representa fielmente o esquema conceitual original (feito com o MER)?
( ) Sim
( ) Parcialmente
( ) Não
Justifique se a resposta é diferente de Sim:
__________________________________________________________________
__________________________________________________________________
3. Conformidade: O esquema SQL gerado pela ferramenta representa fielmente o esquema conceitual original (feito com o MER)?
( ) Sim
( ) Parcialmente
( ) Não
Justifique se a resposta é diferente de Sim:
__________________________________________________________________
__________________________________________________________________
4. Inteligibilidade: As funcionalidades oferecidas pela ferramenta são facilmente
percebidas pelo usuário?
( ) Sim
( ) Parcialmente
( ) Não
Justifique se a resposta é diferente de Sim:
__________________________________________________________________
Apêndice A
143
__________________________________________________________________
5. Inteligibilidade: As formas de uso das funcionalidades oferecidas pela ferramenta
para criar um modelo conceitual de BD e para gerar um esquema operacional
de BD a partir do modelo conceitual são facilmente percebidas pelo usuário?
( ) Sim
( ) Parcialmente
( ) Não
Justifique se a resposta é diferente de Sim:
__________________________________________________________________
__________________________________________________________________
6. Apreensibilidade: O treinamento recebido sobre o uso da ferramenta, com duração
de 30 minutos, foi suficiente para possibilitar ao usuário aprender sua forma de
aplicação na modelagem e geração de esquemas de BD?
( ) Sim
( ) Parcialmente
( ) Não
Justifique se a resposta é diferente de Sim:
__________________________________________________________________
__________________________________________________________________
7. Operacionalidade: A forma de usar a ferramenta diminui o esforço necessário para
que o usuário possa modelar e gerar esquemas de BD, em comparação com outras
formas conhecidas de realizar essas atividades (por exemplo, outras ferramentas,
ou realização manual dessas atividades)?
( ) Sim
( ) Parcialmente
( ) Não
Justifique se a resposta é diferente de Sim:
__________________________________________________________________
__________________________________________________________________
8. Geral: O que poderia ser melhorado na ferramenta para atender as necessidades do usuário interessado em modelar e gerar esquemas de BD?
__________________________________________________________________
__________________________________________________________________
A.4
Modelo Conceitual de uma Empresa
Apêndice A
Nome
nomePF
cpfPF
dataNascPF
enderecoPF
telefonePF
tipoTelPF
144
Tipo
String(99)
String(11)
Data
String(200)
Composto
Enumerado
prefixoTelPF
numeroTelPF
Inteiro
Inteiro
Nome
salario
Tipo
Inteiro
Nome
nomeDepen
sexoDepen
Tipo
String(99)
Enumerado
dataNascDepen
parentescoDepen
Data
String(99)
Nome
idManutencao
itemManutencao
Nome
nomeDep
numeroDep
localizacaoDep
telefoneDep
prefixoTelDep
numeroTelDep
Nome
nomeProj
numeroProj
localizacaoProj
Pessoa Física
Mín/Máx É Único
(1,1)
NÃO
(1,1)
SIM
(1,1)
NÃO
(0,1)
NÃO
(0,N)
NÃO
(1,1)
NÃO
(1,1)
NÃO
(1,1)
NÃO
Funcionário
Mín/Máx É Único
(1,1)
NÃO
Dependente
Mín/Máx É Único
(1,1)
NÃO
(1,1)
NÃO
(1,1)
NÃO
(1,1)
NÃO
Manutenção
Tipo
Mín/Máx É Único
String(10)
(1,1)
SIM
String(50)
(1,1)
NÃO
Departamento
Tipo
Mín/Máx É Único
String(99)
(1,1)
SIM
Inteiro
(1,1)
SIM
String(99)
(1,1)
NÃO
Composto
(0,N)
NÃO
Inteiro
(1,1)
NÃO
Inteiro
(1,1)
NÃO
Projeto
Tipo
Mín/Máx É Único
String(99)
(1,1)
NÃO
Inteiro
(1,1)
NÃO
String(200)
(1,1)
NÃO
Observação
Valores do domínio:
fixo, celular, fax
Compositor: telefonePF
Compositor: telefonePF
Compositor: telefonePF
Observação
Observação
Valores do Domínio:
masculino, feminino
Observação
Observação
Compositor: telefoneDep
Compositor: telefoneDep
Tabela A.1: Dicionário do Esquema de Empresa
Observação
Apêndice A
145
Figura A.1: Modelo Conceitual de Empresa (adaptado de [55])
APÊNDICE B
Mapeamentos 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 de
instâncias, obtenção de uma instância, inserção, remoção e atualização de instâncias de
Tipo de Entidade Fraca.
Tabela B.1: Mapeamento de Operações CRUD sobre Tipo de Entidade Fraca
MR
SQL
(a) Obtenção de Instâncias
SELECT EntidadeProp.atribA,
πEntidadeProp.atribA,EntidadeFraca.atrib1,
Entidade-
EntidadeFraca.atrib2 (
Fraca.atrib1,
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
SELECT EntidadeProp.atribA,
πEntidadeProp.atribA,EntidadeFraca.atrib1,
EntidadeFraca.atrib2 (
σ Ob jetoInternoParteChave.pkEnt=EntidadeFraca.pk
Entidade-
Fraca.atrib1,
EntidadeFraca.atrib2
FROM EntidadeFraca JOIN
Continua na próxima página
Apêndice B
147
Continuação da Tabela B.1
MR
SQL
AND
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 = valB
AND EntidadeFraca.atrib1 = val1
(c) Inserção de Instância
pkEntRef ← π pk (σEntidadeProp.atribA=valA
SELECT INTO pkEntRef pk
AND EntidadeProp.atribB=valB (EntidadeProp))
FROM EntidadeProp
WHERE EntidadeProp.atribA = valA AND
EntidadeRef.atribB = valB;
EntidadeFraca ← EntidadeFraca ∪
INSERT INTO EntidadeFraca(atrib1, atrib2)
VALUES (val1, val2);
{(pk, val1, val2)}
pkEnt ← max pk (EntidadeFraca)
mnmonicoObjInternoParteChave ← mnmoni-
SELECT INTO pkEnt * FROM lastval();
INSERT
INTO
mnmonicoObjIn-
coObjInternoParteChave ∪
{(pk, pkEnt, pkEntRef)}
ternoParteChave(pkEntidade,
pkEntidadeRef)
VALUES (pkEnt, pkEntRef);
pkEntRef ← π pk (
(d) Remoção de Instância
SELECT INTO pkEntRef EntidadeProp.pk
σEntidadeProp.atribA=valA (EntidadeProp))
FROM EntidadeProp
WHERE EntidadeProp.atribA = valANMod
AND
EntidadeProp.atribB = valBNMod;
pkEnt ← πEntidadeFraca.pk (
σ Ob jetoInternoParteChave.pkEnt=EntidadeFraca.pk
SELECT INTO pkEnt EntidadeFraca.pk
FROM EntidadeFraca JOIN ObjetoInt-
AND
ernoParteChave
ON EntidadeFraca.pk =
Ob jetoInternoParteChave.pkEntRe f =EntidadeProp.pk
ObjetoInternoParteChave.pkEnt
AND
JOIN EntidadeProp
Continua na próxima página
Apêndice B
148
Continuação da Tabela B.1
MR
SQL
ON ObjetoInternoParteChave.pkEntRef =
EntidadeFraca.atrib1=val1NMod
(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 σOb jetoInternoParteChave.pkEntRe f =pkEntRe f AND
Ob jetoInternoParteChave.pkEnt=pkEnt
DELETE FROM ObjetoInternoParteChave
WHERE ObjetoInternoParteChave.pkEntRef
= pkEntRef
ObjetoInternoParteChave.pkEnt = pkEnt;
(ObjetoInternoParteChave)
EntidadeFraca ← EntidadeFraca -
DELETE FROM EntidadeFraca WHERE pk =
pkEnt;
σEntidadeFraca.pk=pkEnt (EntidadeFraca)
pkEntRef ← π pk (
(e) Atualização de Instância
SELECT INTO pkEntRef EntidadeProp.pk
σEntidadeProp.atribA=valA (EntidadeProp))
FROM EntidadeProp
WHERE EntidadeProp.atribA = valANMod
AND
EntidadeProp.atribB = valBNMod;
pkEnt ← πEntidadeFraca.pk (
σ Ob jetoInternoParteChave.pkEnt=EntidadeFraca.pk
SELECT INTO pkEnt EntidadeFraca.pk
FROM EntidadeFraca JOIN ObjetoInt-
AND
ernoParteChave
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 ←
EntidadeFraca.atrib1 = val1NMod;
UPDATE EntidadeFraca SET atrib1 = val1,
atrib2 = val2
Continua na próxima página
Apêndice B
149
Continuação da Tabela B.1
MR
πatrib1←val1 , atrib2←val2 (
SQL
WHERE pk = pkEnt;
σEntidadeFraca.pk=pkEnt (EntidadeFraca))
Código B.1 Stored Procedure Modelo para Obtenção de Instâncias de Tipo de Entidade
Fraca
1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE FUNCTION obterEntidadeFracaAtivo() RETURNS CURSOR AS $$
DECLARE
csr CURSOR;
BEGIN
OPEN csr FOR
SELECT EntidadeProp.atribA, EntidadeFraca.atrib1, EntidadeFraca.atrib
FROM EntidadeFraca JOIN ObjetoInternoParteChave
ON EntidadeFraca.pk = ObjetoInternoParteChave.pkEnt
JOIN EntidadeProp ON ObjetoInternoParteChave.pkEntRef =
EntidadeProp.pk;
RETURN csr;
END;
$$ LANGUAGE ’plpgsql’;
Código B.2 Stored Procedure Modelo para Obtenção de Instância de Tipo de Entidade
Fraca
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CREATE FUNCTION obterEntidadeFracaAtivo(valA TipoSQL,
val1 TipoSQL) RETURNS CURSOR AS $$
DECLARE
csr CURSOR;
BEGIN
OPEN csr FOR
SELECT EntidadeProp.atribA, EntidadeFraca.atrib1,
EntidadeFraca.atrib
FROM EntidadeFraca JOIN ObjetoInternoParteChave
ON EntidadeFraca.pk =
ObjetoInternoParteChave.pkEnt
JOIN EntidadeProp
ON ObjetoInternoParteChave.pkEntRef =
EntidadeProp.pk
WHERE EntidadeProp.atribA = valA AND
EntidadeProp.atribB = valB AND
EntidadeFraca.atrib1 = val1;
18
19
20
21
RETURN csr;
END;
$$ LANGUAGE ’plpgsql’;
Apêndice B
150
Código B.3 Stored Procedure Modelo para Inserção de Instância de Tipo de Entidade
Fraca
1
2
3
4
5
CREATE FUNCTION inserirEntidadeFraca (valA TipoSQL,
valB TipoSQL, val1 TipoSQL, val2 TipoSQL) RETURNS BOOLEAN AS
BEGIN
SELECT INTO pkEntRef pk FROM EntidadeProp WHERE EntidadeProp.atribA = valA
AND EntidadeProp.atribB = valB;
6
7
8
9
10
11
12
INSERT INTO EntidadeFraca(atrib1, atrib2) VALUES (val1, val2);
SELECT INTO pkEnt * FROM lastval();
INSERT INTO ObjetoInternoParteChave(pkEnt, pkRef) VALUES (pkEnt, pkEntRef);
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
Código B.4 Stored Procedure Modelo para Remoção de Instância de Tipo de Entidade
Fraca
1
2
3
CREATE FUNCTION desativarEntidadeFraca (valA TipoSQL,
valB TipoSQL, val1 TipoSQL) RETURNS BOOLEAN AS $$
BEGIN
4
5
6
7
SELECT INTO pkEntRef pk FROM EntidadeProp
WHERE EntidadeProp.atribA = valA AND
EntidadeProp.atribB = valB;
8
9
10
11
12
13
14
15
16
17
18
SELECT INTO pkEnt EntidadeFraca.pk
FROM EntidadeFraca JOIN ObjetoInternoParteChave
ON EntidadeFraca.pk =
ObjetoInternoParteChave.pkEnt
JOIN EntidadeProp
ON ObjetoInternoParteChave.pkEntRef =
EntidadeProp.pk
WHERE EntidadeProp.atribA = valA AND
EntidadeProp.atribB = valB AND
EntidadeFraca.atrib1 = val1;
19
20
21
22
DELETE FROM ObjetoInternoParteChave
WHERE ObjetoInternoParteChave.pkEntRef = pkEntRef
AND ObjetoInternoParteChave.pkEnt = pkEnt;
23
24
25
26
27
DELETE FROM EntidadeFraca WHERE pk = pkEnt;
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
Apêndice B
151
Código B.5 Stored Procedure Modelo para Atualização de Instância de Tipo de Entidade
Fraca
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
B.2
CREATE FUNCTION atualizarEntidadeFraca (valANMod TipoSQL,
valNModB TipoSQL, valNMod1 TipoSQL, val1 TipoSQL, val2 TipoSQL)
RETURNS BOOLEAN AS $$
BEGIN
SELECT INTO pkEnt EntidadeFraca.pk
FROM EntidadeFraca JOIN ObjetoInternoParteChave
ON EntidadeFraca.pk =
ObjetoInternoParteChave.pkEnt
JOIN EntidadeProp
ON ObjetoInternoParteChave.pkEntRef =
EntidadeProp.pk
WHERE EntidadeProp.atribA = valANMod AND
EntidadeProp.atribB = valBNMod
AND EntidadeFraca.atrib1 = val1NMod;
UPDATE EntidadeFraca SET atrib1 = val1, atrib2 = val2
WHERE pk = pkEnt;
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
Atributo Composto
A Tabela B.2 apresenta o mapeamento do Modelo Relacional para SQL para
operação CRUD sobre atributo composto. Os Códigos B.6, B.7, B.8, e B.9 apresentam
as stored procedures para as operações de obtenção, inserção, remoção e atualização de
instâncias de atributo composto.
Tabela B.2: Mapeamento de Operações CRUD sobre Atributo
Composto
MR
pkEnt ← π pk (
SQL
(a) Obtenção de Instâncias
SELECT INTO pkEnt pk
σEntidade.atrib1=val1 (Entidade))
πAtributoComp.subAtrib1,AtributoComp.subAtrib2,
AtributoComp.subAtrib3 (
FROM Entidade
WHERE Entidade.atrib1 = val1;
SELECT AtributoComp.subAtrib1, AtributoComp.subAtrib2,
AtributoComp.subAtrib3
Continua na próxima página
Apêndice B
152
Continuação da Tabela B.1
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;
)
pkEnt ← π pk (
(a) Obtenção de Instância
SELECT INTO pkEnt pk
σEntidade.atrib1=val1 (Entidade))
FROM Entidade
πAtributoComp.subAtrib1,AtributoComp.subAtrib2,
WHERE Entidade.atrib1 = val1;
SELECT AtributoComp.subAtrib1, Atributo-
AtributoComp.subAtrib3 (
Comp.subAtrib2,
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.subAtrib1 = subAtrib1NMod
AtributoComp.subAtrib2=subAtrib2NMod
AND
AtributoComp.subAtrib2 = subAtrib2NMod;
(Entidade × AtributoComp))
(b) Inserção de Instância
SELECT INTO pkEnt pk
pkEnt ← π pk (
σEntidade.atrib1=val1 (Entidade))
FROM Entidade
WHERE Entidade.atrib1 = val1;
pkNovo ← max pk (AtributoComp)
AtributoComp ← AtributoComp ∪
{(pkNovo, pkEnt, subval1, subval2, subval3)
pkEnt ← π pk (
INSERT INTO AtributoComp (pkEnt, subAtrib1, subAtrib2, subAtrib3)
VALUES (pkEnt, subval1, subval2, subval3);
(c) Remoção de Instância
SELECT INTO pkEnt pk
σEntidade.atrib1=val1 (Entidade))
FROM Entidade
WHERE Entidade.atrib1 = val1;
pkComp ← π pk (
SELECT INTO pkComp pk
σAtributoComp.pkEnt=pkEnt (AtributoComp))
FROM Entidade JOIN AtributoComp
ON AtributoComp.pkEnt = Entidade.pk
WHERE AtributoComp.pkEnt = pkEnt AND
subAtrib1 = subval1 AND subAtrib2 = subval2;
Continua na próxima página
Apêndice B
153
Continuação da Tabela B.1
MR
AtributoComp ← AtributoComp -
SQL
DELETE FROM AtributoComp WHERE pk
= pkComp;
σAtributoComp.pk=pkComp (AtributoComp)
pkEnt ← π pk (
(d) Atualização de Instância
SELECT INTO pkEnt pk
σEntidade.atrib1=val1 (Entidade))
FROM Entidade
WHERE Entidade.atrib1 = val1;
pkComp ← π pk (
σAtributoComp.pkEnt=pkEnt AND
SELECT INTO pkComp pk
AtributoComp.subAtrib1=subAtrib1NMod AND
ON AtributoComp.pkEnt = Entidade.pk
AtributoComp.subAtrib2=subAtrib2NMod
WHERE AtributoComp.pkEnt = pkEnt AND
subAtrib1 = subval1NMod AND subAtrib2 =
(AtributoComp))
AtributoComp ←
πsubAtrib1←subval1 , subAtrib2←subval2,
subAtrib3←subval3 (
FROM Entidade JOIN AtributoComp
subval2NMod;
UPDATE AtributoComp
SET subAtrib1 = subval1, subAtrib2 = subval2, subAtrib3 = subval3
WHERE pk = pkComp;
σAtributoComp.pk=pkComp (AtributoComp))
Código B.6 Stored Procedure Modelo para Obtenção de Instâncias de Atributo Composto
1
2
3
4
5
6
CREATE FUNCTION obterAtributoCompAtivo(val1 TipoSQL) RETURNS CURSOR AS $$
DECLARE
csr CURSOR;
pkEnt INTEGER;
BEGIN
SELECT INTO pkEnt pk FROM Entidade WHERE Entidade.atrib1 = val1;
7
8
9
10
11
12
13
14
SELECT AtributoComp.subAtrib1, AtributoComp.subAtrib2,
AtributoComp.subAtrib3
FROM Entidade JOIN AtributoComp ON Entidade.pk = AtributoComp.pkEnt
WHERE AtributoComp.pkEnt = pkEnt;
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
Apêndice B
154
Código B.7 Stored Procedure Modelo para Inserção de Instância de Atributo Composto
1
2
3
4
CREATE FUNCTION inserirAtributoComp(val1 TipoSQL, subval1 TipoSQL,
subval2 TipoSQL,subval3 TipoSQL) RETURNS BOOLEAN AS $$
DECLARE
pkEnt INTEGER;
5
6
7
8
BEGIN
SELECT INTO pkEnt pk FROM Entidade
WHERE Entidade.atrib1 = val1;
9
10
11
12
INSERT INTO AtributoComp (pkEnt,
subAtrib1, subAtrib2, subAtrib3) VALUES
(pkEnt, subval1, subval2, subval3);
13
14
15
16
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
Código B.8 Stored Procedure Modelo para Remoção de Instância de Atributo Composto
1
2
3
4
5
6
7
CREATE FUNCTION desativarAtributoComp(val1 TipoSQL,
subval1 TipoSQL, subval2 TipoSQL) RETURNS BOOLEAN AS $$
DECLARE
pkEnt INTEGER;
pkComp INTEGER;
BEGIN
SELECT INTO pkEnt pk FROM Entidade WHERE Entidade.atrib1 = val1;
8
9
10
11
12
13
14
15
16
SELECT INTO pkComp pk FROM Entidade JOIN AtributoComp
ON AtributoComp.pkEnt = Entidade.pk
WHERE AtributoComp.pkEnt = pkEnt AND
subAtrib1 = subval1 AND subAtrib2 = subval2;
DELETE FROM AtributoComp WHERE pk = pkComp;
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
Apêndice B
155
Código B.9 Stored Procedure Modelo para Atualização de Instância de Atributo Composto
1
2
3
4
5
6
7
8
CREATE FUNCTION atualizarAtributoComp(val1 TipoSQL,
subval1NMod TipoSQL, subval2NMod TipoSQL, subval1 TipoSQL,
subval2 TipoSQL, subval3 TipoSQL) RETURNS BOOLEAN AS’
DECLARE
pkEnt INTEGER;
pkComp INTEGER;
BEGIN
SELECT INTO pkEnt pk FROM Entidade WHERE Entidade.atrib1 = val1;
9
10
11
12
13
SELECT INTO pkComp pk FROM Entidade JOIN AtributoComp
ON AtributoComp.pkEnt = Entidade.pk
WHERE AtributoComp.pkEnt = pkEnt AND
subAtrib1 = subval1NMod AND subAtrib2 = subval2NMod;
14
15
16
17
18
19
20
B.3
UPDATE AtributoComp
SET subAtrib1 = subval1, subAtrib2 = subval2, subAtrib3 = subval3
WHERE pk = pkComp;
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
Atributo Simples Multivalorado
A Tabela B.3 apresenta o mapeamento do Modelo Relacional para SQL para as
operações de obtenção, inserção, e remoção de instâncias atributo simples multivalorado.
A stored procedures resultantes do mapeamentos das Tabela B.3 são apresentadas nos Códigos B.10, B.11, B.12 e B.13.
Apêndice B
156
MR
SQL
(a) Obtenção de Instâncias
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 Atributo
ON Entidade.pk = Atributo.pkEnt
Entidade.pk=pkEnt
(Entidade × Atributo)
WHERE Atributo.pkEntidade = pkEnt;
)
(b) Inserção de Instância
pkEnt ← π pk (
SELECT INTO pkEnt pk
σEntidade.atrib1=val1 (Entidade))
FROM Entidade
WHERE Entidade.atrib1 = val1;
INSERT INTO Atributo (pkEnt, valor)
Atributo ← Atributo ∪ {(pkEnt, valor)
VALUES (pkEnt, val);
(c) Remoção de Instância
pkEnt ← π pk (
SELECT INTO pkEnt pk
σEntidade.atrib1=val1 (Entidade))
FROM Entidade
WHERE Entidade.atrib1 = val1;
DELETE FROM Atributo WHERE AtriAtributo ← Atributo - {(pkEnt, valor)
buto.pkEnt = pkEnt AND valor = val;
(c) Atualização de Instância
pkEnt ← π pk (
SELECT INTO pkEnt pk
σEntidade.atrib1=val1 (Entidade))
FROM Entidade
WHERE Entidade.atrib1 = val1;
UPDATE Atributo SET valor = val
Atributo ← πvalor←val
WHERE Atributo.pkEnt = pkEnt AND
valor = valNMod;
(σAtributo.pkEnt=pkEnt AND Atributo.valor=valNMod
(Atributo))
Tabela B.3: Mapeamento das Operações CRUD sobre Atributo
Multivalorado
Apêndice B
157
Código B.10 Stored Procedure Modelo para Obtenção de Instâncias de Atributo Multivalorado
1
2
3
4
5
CREATE FUNCTION obterAtributoAtivo(val1 TipoSQL)
RETURNS CURSOR AS $$
DECLARE
csr CURSOR;
pkEnt INTEGER;
6
7
8
BEGIN
SELECT INTO pkEnt pk FROM Entidade WHERE Entidade.atrib1 = val1;
9
10
11
SELECT valor FROM Entidade JOIN Atributo
ON Entidade.pk = Atributo.pkEnt WHERE Atributo.pkEnt = pkEnt;
12
13
14
15
RETURN csr;
END;
$$ LANGUAGE ’plpgsql’;
Código B.11 Stored Procedure Modelo para Inserção de Instância de Atributo Multivalorado
1
2
3
4
CREATE FUNCTION inserirAtributo(val1 TipoSQL,
val TipoSQL) RETURNS BOOLEAN AS’
DECLARE
pkEnt INTEGER;
5
6
7
8
BEGIN
SELECT INTO pkEnt pk FROM Entidade
WHERE Entidade.atrib1 = val1;
9
10
11
INSERT INTO Atributo (pkEnt, valor)
VALUES (pkEnt, val);
12
13
14
15
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
Apêndice B
158
Código B.12 Stored Procedure Modelo para Remoção de Instância de Atributo Multivalorado
1
2
3
4
CREATE FUNCTION desativarAtributo(val1 TipoSQL,
val TipoSQL) RETURNS BOOLEAN AS’
DECLARE
pkEnt INTEGER;
5
6
7
8
BEGIN
SELECT INTO pkEnt pk FROM Entidade
WHERE Entidade.atrib1 = val1;
9
10
11
DELETE FROM mnmonicoAtributo
WHERE Atributo.pkEnt = pkEnt AND valor = val;
12
13
14
15
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
Código B.13 Stored Procedure Modelo para Atualização de Instância de Atributo Multivalorado
1
2
3
4
CREATE FUNCTION atualizarAtributo(val1 TipoSQL,
valNMod TipoSQL, val TipoSQL) RETURNS BOOLEAN AS’
DECLARE
pkEnt INTEGER;
5
6
7
BEGIN
SELECT INTO pkEnt pk FROM Entidade WHERE Entidade.atrib1 = val1;
8
9
10
UPDATE Atributo SET valor = val
WHERE Atributo.pkEnt = pkEnt AND valor = valNMod;
11
12
13
14
RETURN TRUE;
END;
$$ LANGUAGE ’plpgsql’;
APÊNDICE C
Lista 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.