Desenvolver uma ferramenta de apoio ao Projeto - Projetos

UNIVERSIDADE FEDERAL DE SANTA CATARINA
CENTRO TECNOLÓGICO E CIENTÍFICO
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
CURSO DE BACHARELADO EM CIÊNCIAS DA COMPUTAÇÃO
Uma Ferramenta de Apoio ao
Projeto Lógico de Banco de Dados XML
Relatório de Trabalho de Conclusão do Curso
Claudio de Lima
Prof. Ronaldo dos Santos Mello
Orientador
Florianópolis, novembro de 2007
Uma Ferramenta de Apoio ao
Projeto Lógico de Banco de Dados XML
Relatório de Trabalho de Conclusão do Curso
Claudio de Lima
___________________________________________
Prof. Ronaldo dos Santos Mello, Dr.
Orientador
___________________________________________
Rebeca Schroeder.
Coorientadora
Banca Examinadora:
___________________________________________
Prof. Mário Dantas, PhD.
___________________________________________
Prof. Renato Fileto, Dr.
2
SUMÁRIO
LISTA DE FIGURAS
LISTA DE TABELAS
1. INTRODUÇÃO...............................................................................................6
1.1. Objetivos..........................................................................................6
1.1.1 Geral....................................................................................6
1.1.2 Específicos..........................................................................7
1.2. Motivação e Justificativa..................................................................7
1.3. Trabalhos Correlacionados..............................................................8
1.4. Organização do Trabalho.................................................................9
2. MODELOS DE DADOS...............................................................................10
2.1. Modelo EER...................................................................................10
2.1.1 Superclasses, Subclasses e Herança...............................10
2.1.2 Generalização e Especialização.......................................11
2.1.3 Categorias ou Tipo União..................................................11
2.2. Modelo Hierárquico........................................................................12
2.2.1 Relacionamento Pai-Filho e Esquemas Hierárquicos.......12
2.2.2 Relacionamento Pai-Filho Virtual......................................13
2.3. Modelo Lógico XML.......................................................................13
3. ABORDAGEM DE CONVERSÃO EER-LÓGICO XML..............................17
3.1 Regras de Conversão.....................................................................17
3.1.1 Entidades e Atributos........................................................17
3.1.2 Generalização/Especialização e Categorias.....................18
3.1.3 Relacionamentos...............................................................19
3.2 O processo......................................................................................20
4. A FERRAMENTA........................................................................................23
5. CONSIDERAÇÕES FINAIS........................................................................25
5.1.Trabalhos Futuros...........................................................................25
REFERÊNCIAS
3
LISTA DE FIGURAS
2.1 - Esquema Lógico XML..............................................................................14
2.2 - Esquema Conceitual EER.......................................................................15
4.1 - Esquema de classes do projeto...............................................................23
4
LISTA DE TABELAS
3.1 - Tabela de notações e definições do esquema lógico..............................17
3.2 - Tabela de Prioridades para Aplicação das regras de Generalização e
Categorias........................................................................................................19
3.3 - Tabela de Prioridades para Aplicação das regras de Relacionamentos
Associativos.....................................................................................................20
.
5
1. INTRODUÇÃO
Hoje em dia a linguagem XML (Extensible Markup Language) tem emergido e
se consolidado como um formato de representação de dados. O formato de
documentos XML tem sido um importante mecanismo em muitos contextos de
aplicação. Existem muitos esforços para resolver com a modelagem de dados XML
em diferentes níveis de abstração, alguns deles propõem novos formalismos para
formato de dado XML. No entanto não há consenso sobre metodologias para o
formato de banco de dados XML.
Como no formato tradicional de banco de dados, a modelagem em três níveis
é definida para o formato do banco de dados XML: níveis conceitual, lógico e físico.
Um modelo conceitual tradicional pode ser usado no primeiro nível, como o modelo
Entidade-Relacionamento Estendido (Extended Entity-Relationship – EER). O
modelo de dados XML é considerado no nível lógico, sendo que um esquema
conceitual é convertido para um esquema no modelo lógico XML. Um modelo lógico
XML deve considerar construtores e restrições específicos do modelo de dados
XML, e este deve ser capaz de abstrair diferentes modelos físicos XML, como
Document Type Definition (DTD) e XML Schema.
Este trabalho propõe um processo de conversão para gerar esquemas lógico
XML a partir do esquema conceitual EER. A nossa estratégia de conversão é gerar
estruturas hierárquicas para representar cada um dos tipos de associação EER. Esta
estratégia permite a geração de esquemas lógicos XML que são capazes de serem
convertidos para qualquer modelo físico XML.
O modelo EER foi escolhido como modelo conceitual porque é um modelo
simples e poderoso para prover uma abstração de alto nível para a informação do
domínio de aplicação. E também, EER é o modelo mais utilizado para modelagem
conceitual de banco de dados. Consideramos no processo de conversão todos os
construtores do EER bem como o conceito de categoria ou tipo união.
1.1. OBJETIVOS
1.1.1. GERAL
6
Desenvolver uma ferramenta de apoio ao Projeto Lógico de Banco de Dados
XML, na qual prestará suporte ao processo de conversão de um esquema conceitual
Entidade-Relacionamento Estendido (EER) para um esquema lógico XML.
1.1.2. ESPECÍFICOS
Através da sua interface gráfica (GUI), a ferramenta irá proporcionar ao
usuário criar seu próprio projeto (conceitual) de banco de dados, segundo o modelo
EER. Este projeto desenvolvido pelo usuário será traduzido em um documento XML
que conterá os dados da modelagem criada, e então, será interpretado como a
entrada do processo de conversão. Após o a conversão de todo o esquema a
ferramenta irá disponibilizar o esquema lógico XML como saída. Este modelo lógico
gerado deve suportar a representação hierárquica semi-estruturada do XML, sendo
capaz de abstrair diferentes modelos físicos XML.
1.2. MOTIVAÇÃO E JUSTIFICATIVA
XML é uma linguagem de marcação de padrão aberto, criado por um
grupo de empresas chamado World Wide Web Consortium (W3C) e adequada ao
armazenamento de dados estruturados e semi-estruturados [XML07]. Ela permite
que informações de diferentes sistemas sejam transmitidas através de arquivos que
possuem o formato XML (documentos XML), independente da plataforma utilizada
pelo sistema.
Devido ao crescente uso de dados XML por pessoas e aplicações, existe a
necessidade de um gerenciamento destes documentos XML por Sistemas de
Gerência de Banco de Dados (SGBDs). Atualmente, existem SGBDs para o
gerenciamento de dados XML, porém, estes não são considerados robustos devido
a algumas limitações encontradas, como armazenamento eficiente, segurança,
integridade, acessos simultâneos, metodologias de projeto de bancos de dados
XML, etc [RPBOURRET07].
Como mencionado, um dos tópicos de pesquisa em aberto com relação à
gerência de dados XML é a definição de metodologias para projeto de bancos de
dados XML. No que diz respeito a BDs relacionais, o projeto de um BD envolve três
etapas: (i) a criação de um esquema conceitual que é uma descrição do BD
independente da implementação em um SGBD; (ii) a modelagem lógica, que
7
representa a estrutura de um BD de acordo com um modelo de dados (por exemplo,
o modelo de dados relacional) e; (iii) a modelagem física, que descreve a
implementação do esquema lógico em um SGBD específico (por exemplo, um
SGBD relacional).
A tecnologia XML não possui um padrão de projeto consolidado para a
criação de um BD XML, que é uma categoria recente de BD disponível
comercialmente. Em função disto, uma metodologia de projeto de BD XML está
sendo desenvolvida como dissertação de mestrado no âmbito do Grupo de Banco
de Dados (GBD) da UFSC. A idéia deste Trabalho de Conclusão de Curso (TCC) é
contribuir com esta dissertação através da implementação de uma ferramenta que
preste suporte ao projeto lógico do BD XML.
1.3. TRABALHOS CORRELACIONADOS
Vários trabalhos têm sido propostos para modelagem de dados XML em
diferentes níveis de abstração. Algumas propõem uma tradução do modelo
conceitual tradicional para modelo XML. Outros propõem novos modelos e
formalismos para modelagem de dados XML. Podemos classificar eles em três
categorias de acordo com o modelo que é usado em suas conversões: (i) ER para
linguagem de esquema para XML. (ii) ER para um modelo lógico XML; (iii) novo
modelo conceitual para um modelo XML.
Alguns trabalhos estão inseridos na primeira categoria. [Pigozzo e Quintarelli
2005] propôs um algoritmo para gerar um XML Schema a partir de um esquema ER.
[Choi et al 2003] e [Fong et al 2006] apresentam um processo de conversão para
mapear esquemas EER para DTD Schema.
Outra categoria apresenta a conversão do modelo ER para o modelo lógico
XML. [Elmasri et al 2002] e [Lee et al 2001] convertem esquemas ER para
esquemas lógicos do modelo hierárquico. Este modelo lógico depende apenas da
estrutura baseada em árvore, e não representa o construtor e as restrições do
modelo de dados XML. O trabalho relacionado mais parecido com nosso estende o
modelo ER para representar a principal característica provida pelo XML e descreve
um algoritmo para traduzir um esquema EReX (ER estendido para XML) para um
esquema lógico XML definido por uma gramática [Mani 2004].
8
A última categoria compreende trabalhos que propõem um novo modelo de
formato de dados. Um novo modelo conceitual para XML é proposto por [Embley et
al 2004], chamado C-XML (XML conceitual). C-XML é um modelo equivalente ao
XML Schema e o mapeamento é proposto para esta específica linguagem de
esquema para XML. [Chang et al 2002] propôs uma modelagem XML baseada em
redes semânticas, e [Dobbie et al 2001] apresenta um novo modelo hierárquico para
representação de dados semi-estruturados.
1.4. ORGANIZAÇÃO DO TRABALHO
Este trabalho está dividido em mais quatro capítulos. No capítulo 2 são
apresentados os modelos de dados mais relevantes ao projeto, e que dará suporte
ao entendimento do processo de conversão proposto neste trabalho. O capítulo 3
apresenta uma abordagem de conversão do construtor EER para o modelo lógico
XML, detalhando as regras de conversão, e definindo o processo em que estas
regras serão utilizadas. O capítulo 4 abrange basicamente o projeto da ferramenta e
sua atual versão. No capítulo 5 apresenta quais as atividades a serem realizadas no
restante do desenvolvimento do presente trabalho.
9
2. MODELOS DE DADOS
2.1 MODELO EER
Os conceitos de modelagem ER são suficientes para a representação de
muitos esquemas para as aplicações de bancos de dados “tradicionais”, que
incluem, principalmente, as aplicações de processamento de dados na indústria e no
comércio. Desde o final dos anos 70, entretanto, os projetistas de banco de dados
têm tentado projetar esquemas de banco de dados mais exatos, que reflitam as
propriedades e as restrições dos dados mais precisamente Isso foi particularmente
importante nas, relativamente, recentes aplicações da tecnologia de banco de
dados, como os banco de dados para o projeto de engenharia e manufatura
(CAD/CAM), telecomunicações, sistemas de software complexos e Sistemas de
Informações Geográfica (GIS), entre outras. Muitos desses conceitos também foram
desenvolvidos independentemente, em áreas relacionadas da ciência da
computação, como nas áreas de modelagem de objeto da engenharia de software e
de representação de conhecimento da inteligência artificial.
O modelo EER engloba todos os conceitos de modelagem do modelo ER,
além disso, inclui os conceitos de superclasse e subclasse e os conceitos
relacionados de especialização e generalização, e ainda inclui o conceito de uma
categoria ou tipo união. Associado a esses conceitos está o importante mecanismo
de herança de atributo e relacionamento.
2.1.1. SUPERCLASSES, SUBCLASSES E HERANÇA
Em muitos casos, um tipo entidade tem numerosos subgrupos dessas
entidades, que são significativos e que necessitam ser representados explicitamente,
em virtude de sua importância para a aplicação de banco de dados. Por exemplo, as
entidades que são membros do tipo entidade Empregado podem ser posteriormente
agrupadas em Técnico, Engenheiro, Advogado, Empregado_Assalariado,
Empregado_Horista, e assim por diante. O conjunto de entidades de cada desses
grupos é um subconjunto das entidades que pertencem ao conjunto de entidades
Empregado, significando que toda entidade, é um membro de um desses subgrupos,
é também um empregado. Chamamos cada um desses subgrupos uma subclasse
do tipo Empregado, e do tipo entidade Empregado é conhecido como superclasse
para cada uma dessas subclasses.
Chamamos o relacionamento entre uma superclasse e qualquer uma de suas
subclasses relacionamento superclasse/subclasse (ou classe/subclasse). No
exemplo anterior, Empregado/Advogado é um relacionamento classe/subclasse.
Uma entidade pode ser incluída opcionalmente com membro de várias
subclasses. Por exemplo, um empregado assalariado que também é um advogado,
pertence às duas subclasses, Advogado e Empregado_Assalariado do tipo entidade
Empregado. Entretanto, não é necessário que toda entidade de uma superclasse
seja também membro de alguma subclasse.
Um importante conceito associado a subclasses é o de tipo de herança.
Dizemos que uma entidade, que é um membro de uma subclasse, herda todos os
atributos da entidade como membro da superclasse. A entidade também herda todos
os relacionamentos do qual a superclasse participa.
10
2.1.2. GENERALIZAÇÃO E ESPECIALIZAÇÃO
A especialização é o processo de definir um conjunto de subclasses de um
tipo entidade; este tipo entidade é chamado superclasse da especialização. O
conjunto de subclasses que forma uma especialização é definido como base em
algumas características de distinção das entidades da superclasse. Podemos ter
diversas especializações para o mesmo tipo entidade, baseadas nas diferentes
características que as distinguem. Por exemplo, uma especialização do tipo entidade
Empregado pode produzir os conjuntos de subclasses {Empregado_Assalariado,
Empregado_Horista} e {Técnico, Engenheiro, Advogado}; a primeira especialização
distingue os empregados com base na forma de pagamento, e a segunda com base
no tipo de trabalho.
Há duas razões para incluir relacionamentos classe/subclasse e
especializações em um modelo de dados. A primeira é que certos atributos podem
ser usados em algumas, mas não em todas as entidades da superclasse. Uma
subclasse é definida de forma a agrupar as entidades para as quais esses atributos
se aplicam. Os membros da subclasse podem, ainda, compartilhar a maioria de seus
atributos com os membros da superclasse. A segunda razão para usar as
subclasses é que apenas as entidades que sejam membros de alguma subclasse
possam participar de algum tipo relacionamento.
Em resumo, o processo de especialização nos permite fazer o seguinte: *
definir um conjunto de subclasses de um tipo entidade; * estabelecer atributos
específicos adicionais para cada subclasse; * estabelecer tipos relacionamento
adicionais específicos entre cada subclasse e outros tipos entidade, ou outras
subclasses.
Podemos pensar em um processo contrário de abstração, no qual suprimos
as diferenças entre os diversos tipos entidade, identificamos suas características
comuns e os generalizamos em uma única superclasse, da qual os tipos entidade
originais são subclasses especiais.
Duas restrições importantes podem ser aplicadas a uma especialização (e
generalização). A primeira é chamada restrição de integralidade, que pode ser total
ou parcial. Uma restrição de especialização total especifica que toda entidade na
superclasse deve ser um membro de pelo menos uma das subclasses na
especialização. Já uma restrição de especialização parcial admite-se que uma
entidade não pertença a nenhuma das subclasses. A segunda é a restrição de
disjunção, especificando que as subclasses da especialização devem ser
mutuamente exclusivas. Isto significa que uma entidade pode ser membro de no
máximo uma das subclasses da especialização.
2.1.3. CATEGORIAS OU TIPO UNIÃO
A possibilidade de surgir uma necessidade de modelar um único
relacionamento superclasse/subclasse com mais de uma superclasse, na qual a
superclasse represente os diferentes tipos entidade. Nesse caso a superclasse
representará uma coleção de objetos que é um subconjunto da União de diferentes
tipos entidade; chamamos essa subclasse tipo união ou categoria.
Por exemplo, suponha que tenhamos três tipos de entidade: Pessoa,
Empresa e Banco. Em um banco de dados para o registro de veículos, um
proprietário de um veículo pode ser uma pessoa, um banco (que possui o direito de
alienação de um veículo) ou uma empresa. Necessitamos criar uma classe (coleção
11
de entidades) que inclua entidades de todos os três tipos, para desempenharem o
papel de proprietário do veículo. Uma categoria Proprietário, que é a União dos três
conjuntos de entidade de Banco, Pessoa e Empresa, é criada com este propósito.
O atributo de herança trabalha mais seletivamente quando aplicado às
categorias. Cada entidade Proprietário (exemplo anterior) herda os atributos da
Empresa, do Banco, ou da Pessoa, dependendo da superclasse à qual a entidade
pertence.
Uma categoria pode ser total ou parcial. Uma categoria total controla a união
de todas as entidades em suas superclasses, ao passo que uma categoria parcial
pode controlar um subconjunto da união.
2.2 MODELO HIERÁRQUICO
O modelo de dados hierárquico foi desenvolvido, para modelar vários tipos de
organizações hierárquicas que existem no mundo real. Humanos têm usado
organizações hierárquicas de informação pra ajudar a melhor entender o mundo.
Existem muitos exemplos, como esquemas de classificação para espécies no mundo
das plantas e dos animais e esquemas de classificação de linguagens humana. O
modelo de dados hierárquicos representa organizações hierárquicas de uma forma
direta e natural e pode ser a melhor escolha em algumas situações, mas tem
problemas quando representa situações com relacionamentos não-hierárquicos.
2.2.1. RELACIONAMENTO PAI-FILHO E ESQUEMAS HIERÁRQUICOS
O modelo hierárquico emprega dois conceitos de estruturas de dados
principais: registros e relacionamentos pai-filho. Um registro é uma coleção de
valores de campo que provê informação sobre uma entidade ou uma instância de
relacionamento. Registros do mesmo tipo são agrupados em tipos registro. Ao tipo
registro é dado um nome e sua estrutura é definida por uma coleção de campos
nomeados ou itens de dado. Cada campo tem um certo tipo, com integer ou string.
O tipo relacionamento pai-filho (tipo RPF) é um relacionamento 1:N entre dois
tipos registro. O tipo registro no lado 1 é chamando registro tipo pai, e o lado N é
chamado registro tipo filho do tipo RPF. Uma instancia do tipo RPF consiste em um
registro de um registro tipo pai e um número de registros (zero ou mais) de registros
tipo filhos.
Um esquema de banco de dados hierárquicos consiste em um número de
esquemas hierárquicos. Cada esquema hierárquico (ou hierarquia) consiste em um
número de tipos registro e tipos RPF.
O esquema hierárquico é indicado como um diagrama hierárquico, onde cada
nome dos tipos registro é indicado em caixas retangulares e tipos RPF são indicados
com uma linha conectando o tipo registro pai ao tipo registro filho. Geralmente nos
referimos ao tipo RPF no esquema hierárquico listando o par (tipo registro pai, tipo
registro filho) entre parênteses.
O esquema hierárquico dos tipos registro e RPF devem seguir as seguintes
propriedades:
 Um tipo registro, chamado de raiz (root) do esquema hierárquico, não
participa como tipo registro filho em nenhum tipo RPF.
 Todo tipo registro exceto o raiz participa como tipos registro filho em
exatamente um tipo RPF.
12



O tipo registro pode participar como tipo registro pai muitas vezes (zero ou
mais) em tipos RPF.
O tipo registro que não participa como tipo registro pai em nenhum tipo RPF
é chamado de folha do esquema hierárquico.
Se um tipo registro participa como pai em mais que um tipo RPF, então seus
tipos registros filho são ordenados. A ordem é indicada por convenção da
esquerda para a direita em diagramas hierárquicos.
2.2.2 RELACIONAMENTO PAI-FILHO VIRTUAL
O modelo hierárquico tem problemas quando modela certos tipos de
relacionamentos. Estes incluem os seguintes relacionamentos e situações:
1 - Relacionamentos M:N.
2 - O caso onde o tipo registro participa como filho em mais de um tipo RPF.
3 - Relacionamentos N-ários com mais do que dois participantes tipo registro.
O caso 1 pode ser representado como um tipo RPF com o custo de
duplicação de instâncias de registros do tipo registro filho. O caso 2 também pode
ser representado de forma similar, com mais duplicação de registros. Já o Caso 3
apresenta problema porque o RPF é um relacionamento binário.
Duplicação de registros, além do desperdício de armazenamento, causa
problemas para manter a consistência de cópias duplicadas do mesmo registro. A
idéia é incluir mais do que um esquema hierárquico no esquema de banco de dados
hierárquicos e usar ponteiros dos nodos de um esquema hierárquico para outro para
representar relacionamentos.
O tipo registro virtual (ou ponteiro) é o tipo registro com a propriedade que
cada registro contém um ponteiro para o registro de outro tipo registro virtual. O tipo
registro virtual utiliza filho virtual e pai virtual em RPF virtuais. Cada instância de
registro c de tipo registro virtual aponta para exatamente uma instância registro p do
pai virtual. Ao invés de duplicar o registro do pai virtual em uma árvore de instâncias,
nós incluímos o registro virtual c que contém o ponteiro para p. Diversos registros
virtuais podem apontar para p, mas apenas uma simples copia de p é armazenada
no banco de dados.
O modelo hierárquico oferece muitas opções para representar esquemas ER.
A eficiência no acesso a dados e o limite de redundância versus facilidade de
recuperação são importantes na escolha de uma representação em particular. O
modelo hierárquico é geralmente considerado inferior na capacidade de modelagem
do que no modelo relacional, pelas seguintes razões:
 Relacionamentos M:N pode ser representado apenas adicionando registros
redundantes ou usando relacionamentos pai e filho virtuais e ponteiros de
registro.
 Todo relacionamento na hierarquia deve ser mantido na mesma direção.
 Um registro na hierarquia pode ter dois pais - o real e o virtual.
2.3 MODELO LÓGICO XML
O modelo lógico é definido para representar o modelo de dados XML. Este
modelo não é um novo formalismo de modelagem lógica XML, mas uma adaptação
de modelos hierárquicos para modelagem de dados semi-estruturados.
13
A Figura 2.1 apresenta o esquema correspondente em modelo lógico para o
esquema EER apresentado na Figura 2.2. Introduzimos a notação para elemento
simples (simple element), representado de forma tracejada (como contact).
Um atributo (attribute), representado por um círculo, modela uma propriedade
do elemento que é definido por um valor único. Um atributo tipo normal é uma
propriedade de elemento genérica, como emission. Um atributo tipo identificador é
um atributo que age como um elemento identificador, como code. Um atributo tipo
referência é um atributo que referencia para um ou mais valores de atributos
identificadores e outros elementos, como CICode.
Um elemento complexo (complex element), representado de forma sólida,
modela uma informação que é composta por elementos e/ou atributos. O tipo
suportado do elemento complexo pode ser vazio (empty), livre (free), ou composto
(composite).
Um elemento vazio não possui modelo suportável, como Product e Service.
Um elemento vazio permite qualquer tipo de elementos no seu modelo suportável. E
o elemento composto contém atributos, elementos ou uma mistura de elementos e
valores textuais.
Um elemento composto pode ser misto ou não. Um elemento misto tem um
modelo que suportável que é uma mistura de elementos componentes e valores
textuais, como Customer.
Figura 2.1 : Esquema Lógico XML (Saída).
Um elemento componente (component element) de um elemento composto
são organizados por um de dois construtores de ordem: ordem (order) ou exclusivo
(exclusive). Um construtor de ordem define ‘n’ elementos componentes ordenados,
com ‘n’ >= 1. Um constructor exclusive define ‘n’ alternativas para elementos
componentes, com ‘n’ > 1. Os elementos Customer e ProductService são exemplos
de elementos compostos com construtores de ordem e exclusivo, respectivamente.
Os
relacionamentos
hierárquicos
(hierarchical
relationships)
são
representados por linhas entre o conceito fonte e o conceito alvo. Um
relacionamento define as ocorrências mínima e máxima do conceito alvo no conceito
fonte. O relacionamento entre Order e o componente orderItem é um exemplo: Order
14
pode ter zero ou mais orderItems, e um orderItem deve ser componente do elemento
Order. O default de ocorrências mínima e máxima para conceitos alvo é 1.
Figura 2.2: Esquema Conceitual EER (Entrada).
Para definir as regras de conversão do esquema EER para o esquema lógico
XML, uma notação baseada em tupla foi introduzida no modelo lógico.
O esquema lógico é denotado pela 4-upla s = <SE, A, CE, R>, onde SE é um
conjunto de elementos simples, A é um conjunto de atributos, CE é um conjunto de
elementos complexos e R é um conjunto de relacionamentos binários entre
conceitos. Um elemento simples ‘se’ Є SE é uma 2-upla ‘se’ = <n, dt>, onde ‘n’ é o
label de ‘se’ e ‘dt’ é um tipo de dado ‘se’, com ‘dt’ Є {string, integer, decimal, boolean,
date, time}. Um atributo ‘a’ Є A é a 3-upla ‘a’ = <n, dt, t>, onde ‘n’ é o label de ‘a’, ‘dt’
é o tipo de dado de ‘a’, com ‘dt’ Є {string, integer, decimal, boolean, date, time}, e ‘t’
é o tipo de ‘a, com ‘t’ Є {“normal”, “id”, “reference”}. Um atributo normal é um atributo
‘na’ com ‘na.t’ = “normal”. Um atributo normal denota uma propriedade de elemento
genérico e isso é o valor default para propriedade ‘t’. Um atributo id é um atributo ‘ia’
com ‘ia.t’ = “id”. Um atributo id age como um elemento identificador. Um atributo
reference é um atributo ‘ra’ com ‘ra.t’ = “reference”. Um atributo reference faz
referência para um ou mais valores de atributos id de elementos.
Um elemento complexo ‘ce’ Є CE é uma 3-upla ‘ce’ = <n, t, ct>, onde ‘n’ é um
label do ‘ce’, ‘t’ é o tipo de ‘ce’, com ‘t’ Є {“complex, “root”, “container”}, e ‘ct’ é o tipo
suportado do ‘ce’, com ‘ct’ Є {“empty”, “free”, “composite”}. O valor default para a
propriedade ‘t’ é “complex”. Um elemento root é um elemento complexo ‘rt’ com ‘rt.t’
= “root”. Um elemento container ée um elmento complexo ‘cte’ com ‘cte.t’ =
“container”. Um elemento container encapsula componentes de um elemento
complexo. Um elemento empty é um elemento complexo ‘ece’ com ‘ece.ct’ = “empty”
e sem modelo suportável. Um elemento free é um elemento complexo ‘fce’ com
‘fce.ct’ = “free” e qualquer tipo de elemento do esquema seu modelo suporta. Um
15
elemento composto é um elemento complexo ‘cce’ com ‘cce.ct’ = “composite” e duas
propriedades adicionais ‘m’ e ‘oc’, onde ‘m’, com ‘m’ Є {“true”, “false”}, especifica se
o modelo suportável é misto (mixed) o não, e ‘oc’ denota a construção ordenada
XML para elementos componentes, com ‘oc’ Є {“order, “exclusive”}. O valor default
para propriedade ‘m’ é “false”. Um elemento ordenado ‘or’ é um elemento composto
com ‘or.oc’ = “order”. Um elemento exclusivo ‘ex’ é um elmento composto com
‘ex.oc’ = “exclusive”. O valor default para propriedade ‘oc’ do elemento composto é
“order”.
Um relacionamento binário ‘r’ Є R é uma 4-upla ‘r’ = <s, tg, min, Max>, onde
‘s’ é o elemento fonte, ‘tg’ é o elemento ou atributo alvo, e min e max são
respectivamente, a mínima e máxima ocorrência de ‘tg’ em ‘s’. O relacionamento ‘r’
denota um relacionamento hierárquico, onde ‘r.s’ Є {CE}, ‘r.tg’ Є {SE, A, CE}, ‘r.min’
Є {0,1} e ‘r.max’ Є {1,N}. ‘S’ e ‘TG’ são, respectivamente, o conjunto de elementos
fonte e alvo.
16
3. ABORDAGEM DE CONVERSÃO EER – LÓGICO XML
Este capítulo apresenta uma descrição sucinta das regras de conversão, e o
processo de conversão num todo. A tabela a seguir esquematiza algumas notações
e definições do modelo lógico trabalhados no projeto.
Conceito
Atributo
Propriedades
nome (n), tipo de dado (td)
Notação Gráfica
○ nome
nome (n), tipo de dado (td)

nome
nome (n), tipo de dado (td)
#
○ nome
Atributo
Identificador
Atributo de
referência
Elemento
Simples
Elemento
Complexo
Elemento Vazio
nome (n), tipo de dado (td)
nome
nome (n), tipo de dado (td),
construtor de ordem (co)
nome (n), tipo de dado (td)
nome
nome 
Elemento Livre
nome (n), tipo de dado (td)
nome *
Elemento Misto
nome (n), tipo de dado (td),
construtor de ordem (co)
Origem (o), destino (d),
cardinalidade mínima (min) e
cardinalidade máxima (max)
default: min=1 e max=1 [1..1]
o  {EC, EV, EL, EM}
Relacionamento
Restrição de
Identificação
Restrição de
Referência
Nome do elemento a ser
identificado, lista de atributos
identificadores
Nome do elemento que faz a
referência, lista de atributos
referência, nome da restrição de
identificação a que se refere
nome
nome
nome1 ○nome2
○nome3
[0..1]
key(Elemento) =
{atributoIdentificador1,
atributoIdentificador_N}
Elemento
(atributoReferencia1,
atributoReferencia_N)
refer key(Elemento)
Tabela 3.1 – Notações e definições do esquema lógico.
3.1 REGRAS DE CONVERSÃO
As regras de conversão são propostas para conversão do construtor do
esquema EER para a representativa composição lógica XML. Estas regras são
propostas em três partes: (1) Regras para Entidade e Atributos; (2) Regras para
Generalização/Especialização e Categorias; (3) Regras para Relacionamento. A
seguir será descrito sucintamente cada uma das três partes.
3.1.1. ENTIDADES E ATRIBUTOS
As regras de conversão de entidades e atributos são relativamente simples:
para uma entidade criar um elemento; para atributo mono-valorado obrigatório,
17
incluí-lo como atributo do seu respectivo elemento, se for opcional atribuir a
cardinalidade [0..1]; para atributo multi-valorado criar sub-elemento (simples) para
esse atributo, e no construtor de ordem do seu respectivo elemento (entidade
convertida) torná-lo “ordered” e atribuir a cardinalidade [0..n]; para atributo composto
mono-valorado, incluir “cada atributo” como atributo do seu respectivo elemento, se
for multi-valorado criar um sub-elemento e incluir neste, “cada atributo”; para atributo
identificador, adicioná-lo como atributo identificador do seu respectivo elemento e
criar uma restrição de identificação (para uso posterior).
3.1.2. GENERALIZAÇÃO/ESPECIALIZAÇÃO E CATEGORIAS
A seguir são apresentadas, sucintamente, as regras para conversão aplicadas
à generalização/especialização e categorias, e em seguida a tabela de prioridades
para aplicação de tais regras.
Regra 1:
Criar elementos para superclasse e subclasse (se já não foram criados). Se
for disjunta tornar o construtor de ordem do elemento da superclasse “exclusive”,
senão “ordered”. Se for parcial a cardinalidade dos elementos das subclasses deve
ser [0..1], senão [1..1].
Se superclasse já havia sido convertida e o elemento que a representa é
exclusivo, criar um sub-elemento agrupador (com construtor de ordem “exclusive”)
para a superclasse e coloque como sub-elementos do agrupador todos os subelementos que já existiam. Então proceda a conversão da generalização em
questão: se a generalização em questão é exclusiva, então crie um outro subelemento agrupador (com construtor de ordem “exclusive”) para a superclasse e
coloque todos os elementos para representar as subclasses como filhos desse
agrupador.
Pré-condições: Pelo menos uma subclasse não foi processada por outra
generalização/categoria como filha de outro elemento; Obs.: Para as demais que já
foram processadas como filha de outro elemento, deve-se criar atributos de
referência para estes elementos.
Observação: Ao se tratar da conversão de uma categoria, lembrar que os
papéis das superclasses e subclasse devem ser invertidos para esta regra. Isto é, o
elemento que representa a subclasse deve ser o elemento pai dos elementos que
representam as superclasses.
Regra 2:
Criar elementos somente para as subclasses. Em cada elemento da
subclasse adicionar os atributos da superclasse.
Pré-condições: As subclasses não foram processadas por outra
generalização/categoria como filhas de outros elementos; O número de atributos da
superclasse ser menor ou igual ao número máximo de atributos que uma
superclasse/conjunto de subclasses pode ter; O número de relacionamentos
associativos com a superclasse deve ser menor ou igual ao número máximo de
relacionamentos associativos que uma superclasse pode ter.
Pós-condições: Um mesmo valor para o atributo identificador da superclasse
não deve ser assumido por ambas as subclasses (somente se ocorre disjunção,
para generalização); Outros relacionamentos com a superclasse devem ser
mapeados para cada uma das subclasses; Se houver disjunção na generalização,
18
os atributos que eram identificadores nas subclasses (se existirem) tornam-se
atributos simples, e os atributos que eram identificadores na superclasse, tornam-se
os atributos identificadores dos elementos das subclasses, senão, se existiam
atributos identificadores para as subclasses eles se tornam os identificadores dos
elementos criados, e os identificadores da superclasse tornam-se atributos simples
(ocorre em categorias). Caso contrário ocorre o mesmo processo com disjunção.
Observação: Ao se tratar da conversão de uma categoria, lembrar que os
papéis das superclasses e subclasse devem ser invertidos para esta regra. Isto é,
deve-se apenas representar as superclasses através de elementos.
Regra 3:
Criar um elemento apenas para a superclasse. Adicionar neste elemento os
atributos das subclasses como opcional. Adicionar um elemento simples TYPE com
uma cardinalidade que represente as restrições ([0..1] se for parcial e disjunta; [0..n]
se for parcial e compartilhada; [1..1] se for total e disjunta; [1..n] se for total e
compartilhada.)
Pré-condições: As subclasses não foram processadas por outras
generalizações/categorias como filhas de outros elementos; Subclasses não podem
ter outros relacionamentos (associativos, generalização ou categorias); A somatória
de atributos de subclasse deve ser menor ou igual ao número máximo de atributos
que uma superclasse/conjunto de subclasses pode ter.
Pós-condições: A aplicação deverá tratar e garantir a disjunção (se existir)
entre atributos das subclasses (com base no atributo TYPE); Os atributos que eram
identificadores nas subclasses (se existirem), tornam-se atributos simples.
Observação: Ao se tratar da conversão de uma categoria, lembrar que os
papéis das superclasses e subclasse devem ser invertido para esta regra. Isto é,
deve-se apenas representar a subclasse através de elemento.
Regra 4:
Criar elementos para superclasse e subclasses. No elemento da superclasse
criar atributos de referência para as subclasses. Nos elementos das subclasses criar
atributo de referência para a superclasse.
Tipo Generalização
Total e Compartilhada
Total e Disjunta
Parcial e Compartilhada
Parcial e Disjunta
Tipo Categoria
Total
Parcial
Regra 1
3º
2º
2º
Regra2
2º
-
Regra 3
1º
1º
1º
1º
Regra 4
2º
4º
3º
3º
3º
-
2º
1º
1º
-
4º
2º
Tabela 3.2 - Prioridades para Aplicação das Regras de Generalização e Categorias.
3.1.3. RELACIONAMENTOS
A seguir são apresentadas, sucintamente, as regras para conversão aplicadas
à relacionamentos associativos, e em seguida a tabela de prioridades para aplicação
de tais regras.
Regra 1:
19
É criado um elemento único para representar E1 (entidade 1) e E2 (entidade
2).
Pré-condições: Ser relacionamento binário; E2 não foi processada por outros
relacionamentos associativos como um sub-elemento de outro elemento, ou por
fusão com outro elemento.
Regra 2:
São criados elementos para representar cada entidade envolvida no
relacionamento. E1 torna-se o elemento pai de E2. A cardinalidade de E2 em E1
deve ser definida conforme a sua cardinalidade definida para esse relacionamento
no esquema conceitual. Os tributos do relacionamento ficam em E2.
Se o elemento que representa E1 já havia sido criado como exclusivo, criar
um sub-elemento agrupador (com construtor de ordem “exclusive”) para E1 e
coloque todos os sub-elementos que existiam como filhos do agrupador.
Pré-condições: E2 não foi processada por outros relacionamentos
associativos como um sub-elemento de outro elemento, ou por fusão com outro
elemento.
Regra 3:
É criado um elemento para representar E1 e outro elemento para representar
o relacionamento juntamente com seus atributos. O elemento do relacionamento se
torna filho de E1. São criados elementos à parte para as demais entidades
participantes do relacionamento. A associação com esses elementos (demais
entidades participante) é estabelecida por meio de atributos de referência no
elemento que representa o relacionamento.
Se o elemento que representa E1 já havia sido criado como exclusivo, criar
um sub-elemento agrupador (com construtor de ordem “exclusive”) para E1 e
coloque todos os sub-elementos que existiam como filhos do agrupador.
Tipo
Relacionamento
(0,1) – (0,1)
(0,1) – (1,1)
(1,1) – (1-1)
Regra 1
1º
1º
Alternativas de Mapeamento
Regra 2
2º
2º
Regra 3
1º
3º
3º
(0,1) – (0,N)
(0,1) – (1,N)
(1,1) – (0,N)
(1,1) – (1,N)
-
1º
1º
1º
1º
2º
2º
N–N
N-ários (n>2)
-
-
1º
1º
Tabela 3.3 - Prioridades para Aplicação das Regras de Relacionamentos Associativos.
3.2 O PROCESSO
O processo de conversão é baseado em um algoritmo que promove uma
seqüência de procedimentos de conversão. Este algoritmo está estruturado,
atualmente, da seguinte forma:
20
ALGORITMOEER2XML
ENTRADA:
- Um esquema conceitual EER (EC);
- Uma entidade de partida (ENTIDADE_PARTIDA);
- Número máximo de atributos que uma superclasse/conjunto de subclasses pode ter (MAX_ATT);
- Número máximo de relacionamentos associativos que uma superclasse pode ter (MAS_REL);
SAÍDA: Um esquema lógico XML (EL);
INICIO
GENERAL_CAT := conjunto de generalizações do EC {G1,G2,…,Gn} + conjunto de categorias do
EC {C1,C2,…,Cn};
/*Cada objeto de GENERAL_CAT já se encontra ordenado, no caso de existir uma hierarquia de
multi-nível*/
converterGeneralizacoesCategorias(GENERAL_CAT);
RELACIONAMENTOS := conjunto de relacionamentos do EC {R1,R2,…,Rn};
converterRelacionamentos(RELACIONAMENTOS);
definirElementoRoot(EL);
END;
PROCEDIMENTO converterGeneralizacoesCategorias(GENERAL_CAT)
INICIO
ENQUANTO existir Gi em GENERAL_CAT não processada FAÇA
INÍCIO
/* Escolher a melhor regra a ser aplicada, considere:
a) O tipo de generalização/categoria;
b) a tabela de prioridades das regras para cada tipo;
c) precondições das regras. */
Marque Gi como processada;
FIM
FIM
PROCEDIMENTO converterRelacionamentos(RELACIONAMENTOS, ENTIDADE_PARTIDA)
INICIO
ENQUANTO existir Ri em RELACIONAMENTOS não processado FACA
INICIO
SE ENTIDADE_PARTIDA não está marcada como processada ENTAO
INICIO
Marque ENTIDADE_PARTIDA como entidade de continuação;
Marque ENTIDADE_PARTIDA como entidade de primeiro nível do EL;
FIM
SENÃO
INICIO
SE existe alguma entidade não processada ENTAO
INICIO
Marque tal entidade como entidade de continuação;
Marque tal entidade como entidade de primeiro nível do EL;
FIM
SENAO
INICIO
Obtenha um Ri não processado e marque uma de suas entidades
participantes como entidade de continuação;
Marque tal entidade como entidade de primeiro nível do EL;
FIM
FIM
ENQUANTO existir Ri não processado envolvendo uma entidade marcada
como entidade de continuação FAÇA
INÍCIO
21
E1 := entidade de continuação
SE (Ri é binário) E ((E1 tem maxCard=N) OU (E1 e E2 tem maxCar=1)) E
(E2 não é uma entidade associativa não-processada)
ENTAO
INICIO
/* Para escolher a melhor regra a ser aplicada para o
Ri, considere:
a) o tipo de relacionamento
b) a tabela de prioridades das regras para cada tipo;
c) precondições das regras. */
SE E2 tem minCard=1 e maxCard=1 ENTAO
INICIO
Marque E2 como uma entidade de continuação;
FIM
FIM
SENAO
INICIO
Aplique regra RR3;
FIM
Marque Ri e todas as entidades envolvidas nele como processados;
FIM
FIM
FIM
PROCEDIMENTO definirElementoRoot(EL)
INÍCIO
SE somatório de elementos de primeiro nível de EL for maior que 1
ENTAO
INICIO
Crie um novo elemento para representar o root, e defina todos os
elementos de primeiro nível do esquema como filhos do elemento
root;
FIM
SENAO
INICIO
Defina o único elemento de primeiro nível como elemento root do
EL;
FIM
FIM
22
4. A FERRAMENTA
A ferramenta tem como objetivo contribuir com a dissertação de mestrado (em
desenvolvimento na UFSC) e visa dar suporte ao processo de conversão de um
esquema conceitual Entidade-Relacionamento Estendido (EER) para um esquema
lógico XML.
A ferramenta está sendo desenvolvida na linguagem de programação Java,
com o uso da IDE Netbeans. A formato de dados XML é gerado como entrada do
processo de conversão a partir do projeto conceitual criado, e também
posteriormente como saída para disponibilizar o modelo lógico XML gerado.
As atividades de implementação serão desenvolvidas em 3 etapas, a partir do
processo de conversão apresentado em capítulos anteriores. A primeira tratou da
implementação de módulos dos (construtores) modelos EER e lógico XML, das
regras de conversão do modelo EER para o modelo lógico XML, e por fim foram
realizados alguns testes. A segunda etapa, que atualmente está em
desenvolvimento, trata da implementação do Processo em si, ou seja, ocorre a
manipulação dos módulos da primeira etapa para criar o Processo de Conversão
num todo. Na etapa três será desenvolvida a interface gráfica (GUI) da ferramenta.
A seguir é apresentado o diagrama de classes do projeto, de forma
esquemática e simplificada e da atual versão da ferramenta:
Figura 4.1: Esquema de classes do projeto.
O pacote “EERmodel” contém as classes que tratam do construtor do EER, já
o pacote “XMLmodel” possui os elementos que serão gerados a partir do primeiro. E
o pacote “ConversionRules” é quem faz a tradução do primeiro para o segundo, ou
seja, ele trata das regras de conversão. É importante ressaltar que as classes de
Category
e
GeneralizationSpecialization
implementam
a
interface
MultiLevalHierarchy,
que
é
responsável
por
ordenar
categorias
e
generalizações/especializações em níveis.
23
Como entrada, temos um documento XML que contém o projeto conceitual
(EER) que será traduzido para os respectivos elementos contidos no pacote
“EERmodel”, e que por fim será tratado pelo processo (ConversionProcess).
O processo interage basicamente com as regras de conversão (pacote
“ConversionRules”) e ao fim do processo de conversão, deverá gerar um documento
XML como saída, de acordo com o modelo lógico XML proposto neste trabalho.
24
5. CONSIDERAÇÕES FINAIS
5.1 TRABALHOS FUTUROS
Como atividades previstas para Projetos II, estão a finalização da
implementação do processo de conversão, seguido de muitos testes, e
posteriormente, a inclusão da interface gráfica (GUI). O detalhamento do
desenvolvimento da ferramenta será incluído no capítulo 4 e, finalmente, a inclusão
das conclusões obtidas com o desenvolvimento do trabalho para finalizar a
monografia.
25
REFERÊNCIAS
SCHROEDER, Rebeca. MELO, Ronaldo dos Santos. A Conversion Process
of EER Conceptual Schemas to XML Logical Schemas. Florianópolis,
2007. GBD – UFSC.
SCHROEDER, Rebeca. Abordagem de Conversão de Esquemas
Conceituais EER para Esquemas Lógicos XML. Florianópolis, maio 2007.
GBD – UFSC.
BARCAROLI, Velcir. MELO, Ronaldo dos Santos. Análise Comparativa de
Linguagens de Consulta para Banco de Dados XML Nativos.
Florianópolis, mar. 2005. GBD – UFSC.
ELMASRI, Ramez. NAVATHE, Shamkant. Sistemas de Banco de Dados. 4ª
edição. São Paulo, 2005. Pearson / Prentice Hall.
[RPBOURRET, 2007] XML and Databases. Disponível em: <http://www.
rpbourret.com/xml/XMLAndDatabases.htm>. Acesso em: 22 abr. 2007.
[XML, 2007] Extensible Markup Language (XML). Disponível em: <http://
www.w3.org/XML>. Acesso em: 22 Abr. 2007.
W3C Schools. XML Tutorials. Disponível em: <http://www.w3schools.com/
xml>. Acesso em: 15 jun. 2007 .
Pigozzo, P. and Quintarelli, E. (2005). An algorithm for generating XML
26
Schema
from ER Schemas. In Italian Symposium on Advanced
Database
Systems, pages
192-199, Brixen-Bressanone, Italy.
Fong, J., Fong, A., Wong, H. and Yu, P. (2006). Translating Relational
Schema
with Constraints into XML schema. In International Journal of
Software
Engineering and Knowledge Engineering, pages 201-244.
Choi, M., Lim, J. and Joo, K. (2003). Developing a Unified Design
Methodology
Based on Extended Entity-Relationship Model for
XML. In International
Conference on Computational Science, pages 920-
929, Melbourne, Australia and
St. Petersburg, Russia. Springer.
Elmasri, R., Wu, Y., Hojabri, B., Li, C. and Fu, J. (2002). Conceptual
Modeling for Customized XML Schemas. In International Conference on
Conceptual Modeling (ER2002), pages 429-443, Tampere, Finland. SpringerVerlag.
Lee, M., Lee, S., Ling, T., Dobbie, G. and Kalinichenko, L. (2001). Designing
Semistructured Databases: A Conceptual Approach. In International
Conference on Database Expert Systems Applications (DEXA2001), pages
12-21, Munich, Germany. Springer-Verlag.
Mani, M. (2004). EReX: A Conceptual Model for XML. In International XML
Database Symposium, pages 128-142, Toronto, Canada. Springer-Verlag.
Chang, E., Dillon, T. and Feng, L. (2002). A Semantic Network-Based
Design Methodology for XML Documents. In ACM Transactions on
Information Systems, pages 390-421. ACM.
Embley, D., Liddle, S. and Kamha, S. (2004). Enterprise Modeling with
Conceptual XML. In International Conference on Conceptual Modeling
(ER2004),
pages 150-165, Shanghai, China. Springer-Verlag.
Dobbie, G., Xiaoying, W., Ling, T. and Lee, M. (2001). ORA-SS: An ObjectRelationship-Attribute Model for Semi-Structured Data. Technical Report
TR21/00 – National University of Singapore.
27