SQLXML

Capítulo 1
SQL/XML
Vânia Maria Ponte Vidal, Fernando Lemos
1.1 Introdução
XML se estabeleceu como o formato padrão para a publicação, integração e
troca de dados na Web. Esse sucesso se deve a sua capacidade de represen-
tar informações através de uma estrutura hierárquica simples e auto-descritiva.
Essa estrutura também facilita a exibição dos dados em páginas Web, devido à
similaridade que existe entre XML e a estrutura em HTML usada para repre-
sentar os dados. Outro fator importante para a popularização do XML é que as
mensagens trocadas entre aplicações Web seguem especificações bem definidas,
as quais geralmente possuem natureza hierárquica e podem facilmente ser im-
plementadas usando XML.
Entretanto, a imensa maioria dos dados de negócio, incluindo dados de apli-
cações Web, continua sendo armazenada em SGBDs relacionais. Essa tendência
tende a se manter dada a segurança, escalabilidade, desempenho e quantidade
de ferramentas associadas aos SGBDs relacionais [1]. Atualmente, em muitos
cenários, a mesma informação é armazenada e consultada em SGBDs relacionais,
mas exibida e compartilhada no formato XML. Em geral, essas representações
são completamente distintas devido às diferenças entre os modelos.
Consequentemente, publicar dados relacionais no formato XML é um prob-
lema de extrema relevância e não trivial. Enquanto o modelo relacional é
baseado em tabelas bidimensionais, as quais não possuem hierarquia ou or-
dem, o XML é baseado em árvores, nas quais a ordem é significante. Diante
disso, muitas soluções foram propostas no sentido de minimizar o problema
[2, 3, 4, 5, 6, 7, 8, 9]. Em comum, todas definem uma linguagem usada para es-
pecificar como os dados relacionais serão convertidos em dados XML, e propõem
uma implementação que executa a conversão especificada pela linguagem.
Neste capítulo, estamos interessados no padrão SQL/XML, uma extensão
do SQL que provê suporte a XML no contexto de um SGBD relacional. O
1
CAPÍTULO 1. SQL/XML 2
padrão SQL/XML é uma solução natural para a necessidade de integrar dados

XML e dados relacionais usando SQL. Ele permite armazenar documentos XML
em SGBDRs, consultar tais documentos usando XPath e XQuery, e publicar
dados relacionais no formato XML. Estamos particularmente interessados nos
recursos do SQL/XML que permitem ao usuário construir consultas declarativas
que retornam dados XML a partir de dados relacionais. O XML resultante da
consulta pode ter a estrutura que o projetista desejar, e as consultas podem
ser arbitrariamente complexas. Para um programador SQL, SQL/XML é de
fácil aprendizagem, pois envolve um grupo pequeno de adições à linguagem
SQL existente. Além disso, uma vez que SQL é uma linguagem madura, existe
um grande número de ferramentas e infra-estrutura disponíveis que podem ser
facilmente adaptadas para suportar o novo padrão. Por exemplo, a versão 4 da
API JDBC já suporta a linguagem SQL/XML.
O restante desse capítulo está organizado da seguinte forma. Na Seção 1.2,
introduzimos um breve histórico sobre o surgimento do padrão SQL/XML. Na
Seção 1.3, apresentamos o tipo de dados XML, o qual permite gerenciar e ma-
nipular dados XML de forma nativa em SGBDs relacionais. Na Seção 1.4,
discutimos as funções de publicação do padrão SQL/XML, as quais contituem
a parte do padrão que provê a publicação de dados relacionais em um formato
XML. Apresentamos também o mapeamento definido pelo padrão para trans-
formar tabelas relacionais em um documento XML canônico. Na Seção 1.5,
apresentamos uma metodologia para a criação de visões SQL/XML em bancos
de dados que possuem tal mecanismo de visão. Também abordamos um frame-
work que permite a criação de visões SQL/XML em bancos relacionais que não
possuem mecanismo de visão SQL/XML. Por fim, na Seção 1.6, apresentamos
a função XMLQUERY, a qual permite, através de consultas XQuery, recuperar
fragmentos de dados XML armazenados em SGBDs relacionais. Também ap-
resentamos a função XMLTABLE, a qual permite gerar estruturas tabulares a
partir de dados XML.
1.2 Histórico
A partir do final de 1982, o comitê técnico H2 da organização INCITS1 começou
a padronizar uma versão do modelo de dados relacional tendo como base a
linguagem SEQUEL doada pela IBM. A linguagem foi renomeada para SQL
e, em 1986, a versão básica da linguagem foi adotada como um padrão pelo
Instituto Nacional Americano de Padrões (ANSI)2 . Desde então, a linguagem foi
revista e melhorada. Em 1992, o comitê apresentou a mais importante revisão
da linguagem até então, e a esta foi dado o nome de SQL-92. O SQL-92 foi
desenvolvido para ser o padrão para SGBDs relacionais e serviu como base para
1 http://www.incits.org
2 http://www.ansi.org
várias outras tecnologias como JDBC3 , SQLJ4 , SQL-19995 e ODMG OQL6 . A

partir dessa versão, o padrão SQL foi publicado como sendo composto de um
documento base (SQL/Foundation) e de um conjunto de partes independentes.
Com o franco crescimento da linguagem XML nos últimos anos e sua influên-
cia em aplicações, ferramentas e novos padrões, os comitês H2 e SC32/WG37
(da ISO/IEC) resolveram, na segunda metade do ano 2000, apresentar um pro-
jeto para uma nova parte do SQL. Tal parte foi nomeada de Especificações
Relacionadas à XML (codinome SQL/XML) e iria constituir a parte 14 da es-
pecificação SQL. O projeto demandava, entre outros: (i) especificações para a
representação de dados relacionais como XML e vice-versa; (ii) especificações
para o mapeamento entre esquemas relacionais e XML; e (iii) especificações para
uso da linguagem SQL com XML.
Após o anúncio do projeto, surgiu o SQLX Group [10, 11], um consórcio in-
dustrial formado por Oracle, IBM, Microsoft, Sybase e DataDirect Technologies,
com o objetivo de discutir e desenvolver propostas para a parte 14 da especifi-
cação SQL. Das reuniões do grupo surgiram os primeiros rascunhos do que seria
o SQL/XML e, em outubro de 2000, o grupo foi oficialmente formalizado junto
ao INCITS como Task Group H2.3.
A primeira edição do padrão SQL/XML a ser publicada foi a SQL/XML:2003
[11, 12, 13]. Essa edição abordou principalmente os seguintes tópicos:
• Mapeamento de tabelas, schemas e catálogos relacionais em documentos
XML;
• Geração de um esquema XML correspondente ao documento XML gerado
a partir de dados relacionais;
• Tipo de dados XML;
• Funções de publicação para a geração de dados XML a partir de consultas
SQL.
Em seguida, em 2006, foi publicada a segunda versão do padrão, denominada
SQL/XML:2006 [14, 15]. Essa edição abordou principalmente os seguintes tópi-
cos:
• Adoção do modelo de dados XQuery8 em substituição ao modelo Infoset,
definido na primeira edição;
• Associação de dados XML a esquemas XML;
• Refinamento do tipo de dados XML;
3 http://java.sun.com/javase/technologies/database
4 ISO/IEC 9075-10:2008 Information technology – Database languages – SQL – Part 10:
Object Language Bindings (SQL/OLB)

5 ISO/IEC 9075-2:1999 Information technology – Database languages – SQL – Part 2:
Foundation (SQL/Foundation)
6 http://www.odbms.org
7 http://jtc1sc32.org
8 http://www.w3.org/TR/xquery
(1233)
(<pedido codigo="2405"/>)
(<?xml version="1.0"?><clientes><cliente nome="Pedro Afonso"/>
<cliente nome="Paula Parente"/></clientes>)
(<cliente><nome>Pedro Afonso</nome></cliente>, "São Paulo")
(1233, <pedido codigo="2405"/>, <?xml version="1.0"?><clientes>
<cliente nome="Pedro Afonso"/><cliente nome="Paula Parente"/>
</clientes>, "São Paulo", <cliente><nome>Pedro Afonso</nome>)
Tabela 1.1: Exemplos de instâncias do tipo de dados XML.
• Novas funções de publicação e novos predicados (suporte à XQuery);
• Mapeamento de dados XML em estruturas relacionais.
1.3 Tipo de dados XML

O tipo de dados XML [13, 11] é um tipo de dados da mesma natureza dos tipos
integer e date, por exemplo. Deste modo, ele pode ser usado na definição de
colunas, variáveis e parâmetros. O tipo XML permite gerenciar e manipular da-
dos XML de forma nativa, o que elimina a necessidade de recorrer a adaptações
restritivas como o uso do CLOB. Além disso, a existência de um tipo XML
nativo proporcionou a adição de predicados e funções específicos do domínio,
facilitando assim a criação de consultas SQL que realizem operações sobre dados
XML no próprio banco.
São instâncias do tipo XML o valor nulo (NULL) e qualquer sequência,
como definido no modelo de dados da XQuery. Neste modelo de dados, uma
sequência XQuery é uma lista de zero ou mais itens, onde um item pode ser
um valor atômico ou um nó. Por sua vez, um nó pode ser do tipo documento,
elemento, atributo, texto, namespace, instrução de processamento, e comentário.
Diferente dos outros tipos de nós, o nó documento não corresponde ele mesmo
a nenhum item visível no documento; ele representa o documento em si e não
impõe que o documento representado seja bem-formado ou válido. A Tabela
1.1 apresenta alguns exemplos de instâncias do tipo de dados XML.
Uma coluna do tipo XML pode conter um documento XML bem formado
para cada linha da tabela ou o valor NULL. Os documentos XML de uma
coluna XML podem estar associados a um esquema XML. A associação se dá
por documento e não por coluna. O tipo XML não tem tamanho máximo
associado a ele. Em geral, a implementação ou o protocolo de comunicação no
qual será transferido o documento XML é que pode impor isso.
1.3.1 Refinamentos do Tipo XML

O tipo XML pode ser refinado através de dois modificadores opcionais. O
primeiro modificador pode ser: SEQUENCE, CONTENT ou DOCUMENT.
XML(DOCUMENT(UNTYPED)) XML(CONTENT(UNTYPED))
XML(SEQUENCE)
XML(DOCUMENT(ANY)) XML(CONTENT(ANY))
XML(DOCUMENT(XMLSCHEMA)) XML(CONTENT(XMLSCHEMA))
Figura 1.3.1: Relação entre os subtipos XML [16].
SEQUENCE não determina nenhuma restrição; qualquer sequência XQuery é

válida. CONTENT determina que a sequência XQuery consista de um único nó
documento. DOCUMENT determina que a sequência consista de um único nó
documento contendo um único nó elemento (mais comentários e instruções de
processamento).
O segundo modificador pode ser: UNTYPED, ANY ou XMLSCHEMA. UN-
TYPED determina que não exista nenhum esquema XML associado. XMLSCHEMA
determina que exista um documento XML associado e deva-se indicar qual é o
esquema XML. Isso pode ser feito através de um identificador do esquema previ-
amente registrado no SGBD ou através de uma URI. ANY determina que possa
ou não existir um esquema XML associado. Figura 1.3.1 apresenta a relação
entre os subtipos XML gerados a partir dos modificadores.
1.4 Publicando Dados Relacionais como XML

1.4.1 Abordagens de publicação
Existem diversas formas de gerar dados XML a partir de dados relacionais.
Uma abordagem ainda bastante utilizada é o uso de APIs XML, como SAX e
DOM, juntamente com APIs de acesso à SGBDs, como JDBC e ODBC. Neste
caso, o projetista deve definir as consultas SQL que farão a extração dos dados
relacionais relevantes, e, em seguida, deve escrever o código que gera o dado
XML usando uma API XML. Essa abordagem garante a independência do banco
de dados, mas gera uma enorme quantidade de código de díficil manutenção.
Outra solução é o uso de extensões XML proprietárias oferecidas pelos
SGBDs. Em geral, essas extensões facilitam a geração do dado XML, uma vez
que a consulta que extrai os dados relacionais também realiza a transformação
para XML. Essas extensões tendem a ser simples, porém ferem a independência
REFERENCIAS ARTIGOS AUTORIAS AUTORES

ARTIGO (FK) FK1 ID ARTIGO (FK) ID
REFERENCIA (FK) FK3 AUTOR (FK) FK4
TITULO NOME
RESUMO INSTITUICAO
FK2 DATA EMAIL
STATUS RUA
ANO_PUB FK5 CIDADE
LOCAL PAIS
REVISOES LOGIN
SENHA
ARTIGO (FK)
REVISOR (FK)
DATA_REVISAO
VERSAO
TEXTO
Figura 1.4.1: Esquema relacional ARTIGOS_REL.
do banco. Além disso, muitas delas são restritas e não permitem gerar estruturas
XML complexas [17].
Uma última abordagem é o uso de funções de publicação SQL/XML. Assim
como as extensões XML proprietárias, as funções de publicação têm a vantagem
de poderem ser embutidas em consultas SQL para a geração automática do dado
XML. E, como fazem parte do padrão SQL, a tendência é que os principais
SGBDs assimilem essas funções e as adaptem às suas ferramentas. Além disso,
as funções SQL/XML são muito poderosas e permitem a criação de qualquer
estrutura XML que o usuário deseje.
1.4.2 Funções de Publicação SQL/XML

No padrão SQL/XML, as funções de publicação constituem a parte que provê a
publicação de dados relacionais em um formato XML. As funções de publicação
são usadas diretamente na consulta SQL e permitem criar qualquer estrutura
XML a partir do esquema relacional. O resultado de uma função de publi-
cação é sempre uma instância do tipo de dados XML. No restante dessa seção,
apresentamos as principais funções de publicação do padrão SQL/XML.
Para os exemplos a seguir, considere o esquema relacional da Figura 1.4.1 e
uma instância desse esquema, apresentada na Figura 1.4.2.
XMLELEMENT A função XMLELEMENT constrói um elemento XML. A

consulta do Exemplo 1 gera, para cada tupla da tabela ARTIGOS, um elemento
artigo, o qual contém dois atributos, codigo e DATA, e dois subelementos,
titulo e resumo.
Example 1. Consulta SQL/XML:
SELECT
XMLELEMENT(NAME "artigo",
XMLATTRIBUTES(AR.ID AS "codigo", AR.DATA),
XMLELEMENT(NAME "titulo", AR.TITULO),
XMLELEMENT(NAME "resumo", AR.RESUMO)) AS "ARTIGOS 2002"
ARTIGOS
ID TITULO RESUMO DATA STATUS ANO_PUB LOCAL
Um Mediador para o Processamento de Este artigo descreve uma ferramenta EM_
301 01-08-07
Consultas sobre Bases XML Distribuídas que implementa uma arquitetura para … PRODUCAO
Distributed XML Repositories: Top-downXML is increasingly used not only for
347 2003
Design and Transparent Query data exchange but also to represent ...
Distributed Query Evaluation on Semistructured data is modeled as a ACM
352 2002
Semistructured Data rooted, labeled graph. The … TODS
Mediators in the Architecture of Future
For single databases, primary Morgan
353 1992
Information Systems hindrances for end-user access are the Kaufman
This paper proposes an approach to EM_
355 Automatic Generation of SQL/XML Views 22-02-06
generate XML views of relational ... PRODUCAO
AUTORES AUTORIAS
ID NOME INSTITUICAO EMAIL … ARTIGO AUTOR
117 Guilherme Figueiredo COPPE/UFRJ g.coelho@cos.ufrj.br 301 117
132 Vanessa Braganholo IM/UFRJ braganholo@dcc.ufrj.br 301 132
133 Marta Mattoso COPPE/UFRJ marta@cos.ufrj.br 301 133
145 Jan-Marco Bremer University of California bremer@cs.ucdavis.edu 347 145
168 Michel Gertz University of California gertz@cs.ucdavis.edu 347 168
170 Dan Suciu University of Washington suciu@cs.washington.edu 352 170
192 Gio Wiederhold Stanford University wiederhold@cs.stanford.edu 353 192
195 Vânia Vidal UFC vvidal@lia.ufc.br 355 195
196 Marco Antonio Casanova PUC-Rio casanova@inf.puc-rio.br 355 196
197 Fernando Lemos UFC fernandocl@lia.ufc.br 355 197
REFERENCIAS REVISOES
ARTIGO REFERENCIA ARTIGO REVISOR DATA_REVISAO VERSAO TEXTO
301 322 <secao titulo ="Introdução" numero="s1">
301 347 301 117 22-09-2009 0.8 <paragrafo>O processamento distribuído de…
301 352 <paragrafo>Técnicas de fragmentação de bases…
301 353 <secao titulo="Mediador" numero="s2.1">
301 132 15-09-2009 0.6 <paragrafo>O Mediador é o principal …
<paragrafo>O diagrama da Figura 2 segue a …
<secao titulo="Mediador" numero="s2.1">
301 133 03-11-2009 1.0 <paragrafo>O Mediador é o principal …
<paragrafo>O diagrama da Figura 2 segue …
<secao titulo="Introduction" numero="s1">
355 195 22-02-2006 0.1 <paragrafo>XML has emerged as the standard …
<paragrafo>The exported view may be either …
Figura 1.4.2: Instância do esquema relacional ARTIGOS_REL.

FROM ARTIGOS AR
WHERE EXTRACT(YEAR FROM AR.DATA) >= 2002
Resultado:
ARTIGOS 2002
-----------------------------------------------------------------
<artigo codigo="301" data="2007-08-01"><titulo>Um Mediador para
o Processamento de Consultas sobre Bases XML Distribuídas</titulo
><resumo>Este artigo descreve uma ferramenta que implementa uma a
rquitetura para o processamento de consultas...</resumo></artigo>
<artigo codigo="355" data="2006-02-22"><titulo>Automatic Generat
ion of SQL/XML Views</titulo><resumo>This paper proposes an appro
ach to generate XML views of relational ...</resumo></artigo>
(2 linhas)
O primeiro argumento da função XMLELEMENT é o nome do elemento

a ser produzido, o qual deve ser um valor escalar precedido da palavra-chave
NAME. O segundo argumento, uma chamada para a função XMLATTRIBUTES,
é opcional e permite definir os atributos do elemento resultante. As expressões
que definem os atributos devem ser separadas por vírgula e devem retornar
sempre um único valor escalar. No Exemplo 1, a primeira expressão define o
atributo codigo e recebe o valor da coluna ID da tabela ARTIGOS. A segunda
expressão não define um alias para o atributo e, por isso, o nome do atributo é
o mesmo da coluna usada na expressão.
Os demais argumentos de XMLELEMENT definem o conteúdo do elemento
e cada um deve ser uma expressão escalar que retorne um valor único. A con-
versão do valor relacional no valor XML correspondente é embutida na função
SQL/XML. No Exemplo 1, a função que cria o elemento artigo contém duas
outras chamadas à função XMLELEMENT. Essas chamadas criam os subele-
mentos titulo e resumo. O resultado da consulta é uma tabela com uma única
coluna e uma linha contendo um elemento XML artigo.
SELECT
XMLELEMENT(NAME "autor",
XMLATTRIBUTES(AU.ID AS "codigo"),
XMLELEMENT(NAME "nome", AU.NOME),
XMLELEMENT(NAME "email", AU.EMAIL),
XMLELEMENT(NAME "cidade", AU.CIDADE)
) AS "AUTORES"
FROM AUTORES AU
WHERE AU.INSTITUICAO = ’UFC’ OR AU.INSTITUICAO = ’COPPE/UFRJ’
Resultado:
AUTORES
-----------------------------------------------------------------
<autor codigo="117"><nome>Guilherme Figueiredo</nome><email>g.co
elho@cos.ufrj.br</email><cidade/></autor>
<autor codigo="133"><nome>Marta Mattoso</nome><email>marta@cos.u
frj.br</email><cidade/></autor>
<autor codigo="195"><nome>Vânia Vidal</nome><email>vvidal@lia.uf
c.br</email><cidade/></autor>
<autor codigo="197"><nome>Fernando Lemos</nome><email>fernandocl
@lia.ufc.br</email><cidade/></autor>
(4 linhas)
O Exemplo 2 ilustra a criação de um elemento XML que representa os au-
tores. Neste caso, a função XMLELEMENT que gera o elemento autor possui
cinco argumentos:
• o nome do elemento a ser gerado;
• uma chamada à função XMLATTRIBUTES para criar o atributo codigo;
• uma chamada à função XMLELEMENT que gera o subelemento nome;
• uma chamada à função XMLELEMENT que gera o subelemento email;
• uma chamada à função XMLELEMENT que gera o subelemento cidade.
XMLFOREST A função XMLFOREST gera uma floresta de elementos XML

a partir de seus argumentos, os quais são expressões escalares com aliases op-
cionais. A consulta do Exemplo 3 gera, para cada tupla da tabela AUTORES, um
elemento autor, o qual contém o atributo codigo e três subelementos (nome,
email e cidade).
SELECT
XMLELEMENT(NAME "autor",
XMLATTRIBUTES(AU.ID AS "codigo"),
XMLFOREST(AU.NOME AS "nome",
AU.EMAIL AS "email",
AU.CIDADE AS "cidade")) AS "AUTORES"
FROM AUTORES AU
Resultado:
AUTORES
-----------------------------------------------------------------
<autor codigo="117"><nome>Guilherme Figueiredo</nome><email>g.co
elho@cos.ufrj.br</email></autor>
<autor codigo="133"><nome>Marta Mattoso</nome><email>marta@cos.u
frj.br</email></autor>
<autor codigo="195"><nome>Vânia Vidal</nome><email>vvidal@lia.uf
c.br</email></autor>
<autor codigo="197"><nome>Fernando Lemos</nome><email>fernandocl
@lia.ufc.br</email></autor>
(4 linhas)
Cada expressão é convertida em um elemento XML e, caso um alias tenha

sido atribuído, este será o identificador do elemento gerado. Relembrando o
Exemplo 2, três chamadas à função XMLELEMENT foram usadas para criar
três subelementos XML do elemento autor. No Exemplo 3, as três chamadas
foram substituídas por uma única chamada à função XMLFOREST com três
parâmetros, um para cada subelemento a ser gerado.
Ao contrário da função XMLELEMENT, na função XMLFOREST, expressões
que resultam em nulo não geram elementos. Note que, quando o valor da coluna
CIDADE é nulo, o elemento XML correspondente não é gerado. Essa caracterís-
tica é muito útil, por exemplo, quando temos diversas colunas em uma tabela
que representam um mesmo conceito no mundo real.
Outra diferença é que os elementos gerados pela função XMLFOREST são
simples e a eles não se pode adicionar atributos ou subelementos. É importante
deixar claro que duas chamadas seguidas à função XMLELEMENT geram duas
instâncias XML independentes, enquanto que uma chamada à função XML-
FOREST contendo duas expressões relacionais gera uma única instância XML
contendo os dois elementos XML gerados.
XMLAGG A função XMLAGG é uma função de agregação no mesmo sentido

das funções AVG, MIN, COUNT, etc. A consulta do Exemplo 4 recupera, para
cada instituição, a lista de autores que pertencem à instituição.
SELECT
AU.INSTITUICAO,
XMLAGG(
XMLELEMENT(NAME "autor", AU.NOME)
) AS "AUTORES"
FROM AUTORES AU
GROUP BY AU.INSTITUICAO
Resultado:
INSTITUICAO | AUTORES
--------------------------+--------------------------------------
PUC-Rio | <autor>Marco Antonio Casanova</autor>
UFC | <autor>Vânia Vidal</autor><autor>Fern
ando Lemos</autor>
COPPE/UFRJ | <autor>Guilherme Figueiredo</autor><a
utor>Marta Mattoso</autor>
University of Washington | <autor>Dan Suciu</autor>
Stanford University | <autor>Gio Wiederhold</autor>
University of California | <autor>Jan-Marco Bremer</autor><autor
>Michel Gertz</autor>
IM/UFRJ | <autor>Vanessa Braganholo</autor>
(7 linhas)
A função tem como entrada somente um parâmetro, o qual deve ser uma
expressão que retorne uma única instância XML. No Exemplo 4, a consulta
agrupa os artigos por instituição e, para cada agrupamento, a função XMLAGG
executa a expressão XMLELEMENT(NAME "autor", AU.NOME) sobre cada tupla do
agrupamento. A expressão retorna uma instância XML contendo um elemento
XML representando o autor. Em seguida, as instâncias XML são agrupadas em
um agregado XML que é retornado pela função XMLAGG. Quando nenhum
agrupamento é definido pela consulta, a função considera o resultado da consulta
como um agrupamento.
SELECT XMLELEMENT(NAME "autor",

XMLFOREST(AU.NOME AS "nome", AU.EMAIL AS "e-mail"),
(SELECT XMLAGG( XMLELEMENT(NAME "artigo",
XMLATTRIBUTES(AR.STATUS AS "status"),
XMLELEMENT(NAME "titulo", AR.TITULO)))
FROM ARTIGOS AR, AUTORIAS AT
WHERE AT.AUTOR = AU.ID AND AT.ARTIGO = AR.ID)
) AS "AUTORES"
FROM AUTORES AU
Resultado:
AUTORES
-----------------------------------------------------------------
<autor><nome>Guilherme Figueiredo</nome><e-mail>g.coelho@cos.ufr
j.br</e-mail><artigo status="EM_PRODUCAO"><titulo>Um Mediador par
a o Processamento de Consultas sobre Bases XML Distribuídas</titu
lo></artigo></autor>
<autor><nome>Marta Mattoso</nome><e-mail>marta@cos.ufrj.br</e-ma
il><artigo status="EM_PRODUCAO"><titulo>Um Mediador para o Proces
samento de Consultas sobre Bases XML Distribuídas</titulo></artig
o></autor>
<autor><nome>Vânia Vidal</nome><e-mail>vvidal@lia.ufc.br</e-mail
><artigo status="EM_PRODUCAO"><titulo>Automatic Generation of SQL
/XML Views</titulo></artigo></autor>
<autor><nome>Fernando Lemos</nome><e-mail>fernandocl@lia.ufc.br<
/e-mail><artigo status="EM_PRODUCAO"><titulo>Automatic Generation
of SQL/XML Views</titulo></artigo></autor>
(4 linhas)
A consulta do Exemplo 5 retorna o nome, o email e a lista de artigos de

cada autor. A lista de artigos é obtida através de uma subconsulta, a qual gera
um elemento XML para cada artigo e agrega esses elementos através da função
XMLAGG. Sem a chamada à função XMLAGG, o resultado da subconsulta
seria uma tabela de elementos "artigo", o que não é permitido.
XMLCONCAT A função XMLCONCAT recebe como parâmetros instâncias

XML e as concatena em uma única instância XML. A consulta do Exemplo
6 retorna duas colunas: uma contendo um elemento XML representando os
autores e outra contendo dois elementos XML representando o cliente do pedido.
SELECT AU.ID AS "autor",

XMLCONCAT(
XMLELEMENT(NAME "nome_autor", AU.NOME),
XMLELEMENT(NAME "e-mail", AU.EMAIL)
) AS "AUTORES"
FROM AUTORES AU
Resultado:
autor | AUTORES
-------+---------------------------------------------------------
117 | <nome_autor>Guilherme Figueiredo</nome_autor><e-mail>g.c
oelho@cos.ufrj.br</e-mail>
133 | <nome_autor>Marta Mattoso</nome_autor><e-mail>marta@cos.
ufrj.br</e-mail>
195 | <nome_autor>Vânia Vidal</nome_autor><e-mail>vvidal@lia.u
fc.br</e-mail>
197 | <nome_autor>Fernando Lemos</nome_autor><e-mail>fernandoc
l@lia.ufc.br</e-mail>
(4 linhas)
No Exemplo 6, a função XMLCONCAT concatena os resultados das duas

chamadas à função XMLELEMENT. Caso a função XMLCONCAT tivesse sido
omitida, a consulta retornaria três colunas. Ela difere da função XMLFOREST,
a qual primeiramente recebe uma lista de expressões relacionais, gera elementos
XML a partir do resultado das expressões e, por fim, concatena esses elementos
em uma única instância XML.
XMLCOMMENT A função XMLCOMMENT permite criar comentários.

SELECT XMLCONCAT(
XMLCOMMENT(’Autores da Universidade da Califórnia’),
XMLAGG(
) ) AS "AUTORES"
FROM AUTORES AU
WHERE AU.INSTITUICAO = ’University of California’
Resultado:
AUTORES
-----------------------------------------------------------------
<autor>Jan-Marco Bre
mer</autor><autor>Michel Gertz</autor>
(1 linha)
XMLPI A função XMLCOMMENT permite criar instruções de processa-

mento XML, as quais são informações que se deseja passar para as aplicações.
No Exemplo 8, a consulta adiciona uma instrução que especifica a página de
estilos a ser usada pelo fragmento XML resultante.
SELECT
XMLCONCAT(
XMLPI(NAME "xml-stylesheet",
’href="headlines.css" type="text/css"’),
XMLAGG(
) ) AS "AUTORES"
FROM AUTORES AU
Resultado:
AUTORES
-----------------------------------------------------------------
<?xml-stylesheet href="headlines.css" type="text/css"?><autor>Gu
ilherme Figueiredo</autor><autor>Vanessa Braganholo</autor><autor
>Marta Mattoso</autor><autor>Jan-Marco Bremer</autor><autor>Miche
l Gertz</autor><autor>Dan Suciu</autor><autor>Gio Wiederhold</aut
or><autor>Vânia Vidal</autor><autor>Marco Antonio Casanova</autor
><autor>Fernando Lemos</autor>
(1 linhas)
As instruções de processamento sempre começam com "<?" e terminam

com "?>"; em seguida ao "<?" aparece o nome da instrução de processamento.
Uma importante instrução de processamento é a XML, a qual geralmente define
a versão XML e a codificação usadas. Assim, como os comentários, elas não são
textualmente parte do documento XML.
1.4.3 Mapeamento de tabelas relacionais em documentos

XML
Além das funções de publicação, o padrão SQL/XML define um mapeamento
de tabelas relacionais para um documento XML. O mapeamento pode ser re-
alizado a partir de uma única tabela, das tabelas de um esquema relacional ou
ainda das tabelas de um catálogo relacional. A geração do documento XML
considera estrutura e valores das uma ou mais tabelas de entrada. Para isso, o
<ARTIGOS>
<id>301</id>
<titulo>Um Mediador para o Processamento de Consul...</titulo>
<resumo>Este artigo descreve uma ferramenta que im...</resumo>
<data>2007-08-01</data>
<status>EM_PRODUCAO</status>
</ARTIGOS>
<ARTIGOS>
<id>347</id>
<titulo>Distributed XML Repositories: Top-down Des...</titulo>
<resumo>XML is increasingly used not only for data...</resumo>
<ano_pub>2003</ano_pub>
</ARTIGOS>
...
Figura 1.4.3: Documento XML gerado a partir da tabela ARTIGOS usando a

forma de um único elemento XML.
padrão SQL/XML também define mapeamentos de identificadores, dados e val-

ores relacionais para identificadores, dados e valores XML [XX], evitando assim
qualquer incompatibilidade entre os dois formatos.
O mapeamento considera duas formas de gerar o documento XML a partir
de uma tabela relacional. Na primeira forma, a tabela é mapeada em um único
elemento XML. Neste caso, o nome da tabela é usado como o nome do elemento
XML raiz e cada linha da tabela é mapeada em um elemento aninhado chamado
row, o qual contém os elementos representando as colunas da tabela. Na segunda
forma, a tabela é mapeada em uma sequência de elementos XML. Neste caso,
cada linha da tabela é mapeada em um elemento com o nome da tabela.
Juntamente com o documento XML é gerado um esquema XML que descreve
sua estrutura. Tal esquema contém um tipo XML para cada coluna, linha,
tabela, esquema e catálogo relacional envolvido no mapeamento.
A seguir, apresentamos alguns exemplos de como se dá o mapeamento de
tabelas relacionais em XML. Considere a tabela ARTIGOS do esquema relacional
ARTIGOS_REL da Figura 1.4.1. As Figuras 1.4.3 e 1.4.4 apresentam, respecti-
vamente, o documento e o esquema XML resultantes do mapeamento aplicado
à tabela ARTIGOS usando a forma de um único elemento XML. Figuras 1.4.5 e
1.4.6 apresentam o documento e o esquema XML resultantes usando a forma de
uma sequência de elementos XML.
O mapeamento para esquemas e coleções relacionais é feito de forma similar
adicionando-se um elemento com o nome do esquema e/ou coleção englobando
os fragmentos XML das tabelas.
Apesar de a especificação precisar como mapear tabelas relacionais no for-
mato XML, o padrão não descreve nenhuma função que aplica esse mapeamento.
Apesar disso, alguns SGBDs saíram na frente e definiram suas próprias funções.
O Oracle, por exemplo, possui a função ora:view [18], a qual pode ser usada
diretamente em consultas XQuery embutidas na função XMLQuery, como vere-
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:simpleType name="INTEGER">...
<xsd:simpleType name="VARCHAR">...
<xsd:simpleType name="UDT.artigos.pg_catalog.text">...
<xsd:simpleType name="DATE">...
<xsd:simpleType name="CHAR">...
<xsd:complexType name="RowType.artigos.public.artigos">
<xsd:sequence>
<xsd:element name="id" type="INTEGER" minOccurs="0"/>
<xsd:element name="titulo" type="VARCHAR" minOccurs="0"/>
<xsd:element name="resumo"
type="UDT.artigos.pg_catalog.text" minOccurs="0"/>
<xsd:element name="data" type="DATE" minOccurs="0"/>
<xsd:element name="status" type="VARCHAR" minOccurs="0"/>
<xsd:element name="ano_pub" type="CHAR" minOccurs="0"/>
<xsd:element name="local" type="VARCHAR" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="artigos"
type="RowType.artigos.public.artigos"/>
</xsd:schema>
Figura 1.4.4: Esquema XML gerado a partir da tabela ARTIGOS usando a forma
de um único elemento XML.
<ARTIGOS>
<row>
<id>301</id>
<titulo>Um Mediador para o Processamento de Con...</titulo>
<resumo>Este artigo descreve uma ferramenta que...</resumo>
<data>2007-08-01</data>
<status>EM_PRODUCAO</status>
</row>
<row>
<id>347</id>
<titulo>Distributed XML Repositories: Top-down Des...</titulo>
<resumo>XML is increasingly used not only for data...</resumo>
<ano_pub>2003</ano_pub>
</row>
...
</ARTIGOS>
Figura 1.4.5: Documento XML gerado a partir da tabela ARTIGOS usando a

forma de uma sequência de elementos XML.
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:simpleType name="INTEGER">...
<xsd:simpleType name="VARCHAR">...
<xsd:simpleType name="UDT.artigos.pg_catalog.text">...
<xsd:simpleType name="DATE">...
<xsd:simpleType name="CHAR">...
<xsd:complexType name="RowType.artigos.public.artigos">
<xsd:sequence>
<xsd:element name="id" type="INTEGER" minOccurs="0"/>
<xsd:element name="titulo" type="VARCHAR" minOccurs="0"/>
<xsd:element name="resumo"
type="UDT.artigos.pg_catalog.text" minOccurs="0"/>
<xsd:element name="data" type="DATE" minOccurs="0"/>
<xsd:element name="status" type="VARCHAR" minOccurs="0"/>
<xsd:element name="ano_pub" type="CHAR" minOccurs="0"/>
<xsd:element name="local" type="VARCHAR" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="TableType.artigos.public.artigos">
<xsd:sequence>
<xsd:element name="row" type="RowType.artigos.public.artigos"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="artigos"
type="TableType.artigos.public.artigos"/>
</xsd:schema>
Figura 1.4.6: Esquema XML gerado a partir da tabela ARTIGOS usando a forma
de uma sequência de elementos XML.
mos na Seção 1.6. Já o SGBD PostgreSQL [19] possui as funções table_to_xml

e table_to_xmlschema para gerar, respectivamente, o documento e o esquema
XML a partir de uma tabela/esquema/coleção relacional.
1.5 Consultando dados relacionais através de Visões

SQL/XML
Visões constituem interfaces através das quais os usuários consultam e atualizam
uma base de dados. Além das vantagens já conhecidas das visões relacionais,
as visões XML permitem ainda a coexistência e o compartilhamento de dados
armazenados em base de dados relacional com diversas aplicações usando tec-
nologia XML. Consequentemente, visões XML definidas sobre dados relacionais
provêem uma técnica poderosa para se impor uma ou mais visões lógicas, rica-
mente estruturadas, sobre uma base de dados já existente. Dessa forma, dados
relacionais podem ser disponibilizados em uma estrutura XML, sem que seja
necessário mudar o esquema da base de dados. Nesta seção, tratamos somente
de visões XML virtuais, ou seja, os dados ainda persistem em bases relacionais,
enquanto as aplicações acessam os dados no formato XML através da visão.
Até o momento, somente os SGBDs Oracle [18], PostgreSQL [19] e DB2
[20] provêem um mecanismo de visão SQL/XML. A publicação de uma visão
SQL/XML nesses SGBDs é similar à publicação de uma visão relacional: o
usuário escreve a consulta SQL/XML que define a visão e a publica no banco
através do comando CREATE VIEW. Em geral, essas visões podem ser consultadas
através de expressões XPath ou consultas XQuery, ambas embutidas em funções
definidas pelo padrão SQL/XML. A seguir, apresentamos um exemplo de criação
de uma visão SQL/XML em um SGBD relacional.
Considere o esquema relacional ARTIGOS_REL e o tipo XML TArtigo, cu-
jas representações gráficas são mostradas nas Figuras 1.4.1 (Seção 1.4.2) e
1.5.1, respectivamente. Para gerar instâncias de TArtigo a partir do esquema
ARTIGOS_REL, definimos a visão SQL/XML Artigos_XML mostrada na Figura
1.5.2. A consulta SQL/XML da Figura 1.5.2 define como, para cada tupla da
tabela ARTIGOS, a visão XML usa as funções de publicação do padrão SQL/XML
para construir uma instância do tipo XML TArtigo.
Mais detalhadamente, considere o estado da base de dados ARTIGOS_REL
mostrado na Figura 1.4.2. O estado correspondente da visão Artigos_XML é
mostrado na Figura 1.5.3. Este estado da visão contém uma seqüência de ele-
mentos artigo, os quais são os elementos primários da visão. Cada elemento
artigo é construído a partir de uma tupla da tabela de ARTIGOS usando a função
XMLELEMENT do SQL/XML. Os sub-elementos e atributos de artigo são
construídos através de subconsultas SQL/XML. Por exemplo,
• O atributo data é construído pela subconsulta da linha 2. A função XM-
LATTRIBUTES produz, a partir do seu argumento, o atributo data do
elemento artigo.
TArtigo
@data
autor* (TAutor)
nome
instituicao
endereco (TEndereco)
rua
cidade
pais
email
titulo
resumo
referencia* (TReferencia)
@id
titulo
autor*
ano
local
Figura 1.5.1: Tipo XML TArtigo.
• A coleção de sub-elementos autor é gerada pela subconsulta nas linhas

3-10. A função de agregação XMLAGG produz uma floresta de elementos
XML a partir da coleção de elementos XML autor, os quais são gerados
pela função XMLELEMENT nas linhas 3-8. Neste caso, temos que, para
cada artigo, as tuplas relevantes da tabela AUTORES são recuperadas e
convertidas em uma seqüência de elementos autor.
• O sub-elemento titulo é construído usando a subconsulta na linha 11.
1.5.1 Geração de Visões SQL/XML

Para criar uma visão SQL/XML, primeiro deve-se definir o tipo dos elementos
da visão. Em seguida, define-se a visão através de uma consulta SQL/XML, a
qual especifica como os elementos da visão são sintetizados a partir dos dados
da base de dados. Definir uma consulta que realize o mapeamento de tuplas
de tabelas relacionais em elementos de estrutura complexa é tarefa que exige
conhecimentos avançados de SQL/XML.
Em [21], é proposto um enfoque de três passos para facilitar geração de
visões SQL/XML sobre bases de dados relacionais. (i) Primeiro, o usuário
define o esquema da visão. (ii) Em seguida, o usuário define os mapeamentos
entre o esquema da visão e o esquema da base de dados. (iii) Por fim, é gerada
a consulta SQL/XML que define a visão.
Passo 1 Definição do esquema XML da visão

A definição do esquema XML da visão deve ser feita com base no esquema
relacional subjacente. Em [21], os elementos da visão têm relacionamento direto
1. CREATE VIEW Artigos_XML AS SELECT XMLELEMENT(NAME "artigo",

2. XMLATTRIBUTES(AR.DATA as "data"),
3. (SELECT XMLAGG( XMLELEMENT(NAME "autor",
4. XMLELEMENT(NAME "nome", AU.NOME),
5. XMLELEMENT(NAME "instituicao", AU.INSTITUICAO),
6. XMLELEMENT(NAME "endereco",
7. XMLFOREST(AU.RUA AS "rua", AU.CIDADE AS "cidade",
8. AU.PAIS AS "pais", AU.EMAIL AS "email") ) ) )
9. FROM AUTORES AU, AUTORIAS AT
10. WHERE AT.ARTIGO = AR.ID AND AT.AUTOR = AU.ID),
11. XMLELEMENT(NAME "titulo", AR.TITULO),
12. XMLELEMENT(NAME "resumo", AR.RESUMO),
13. (SELECT XMLAGG( XMLELEMENT(NAME "referencia",
14. XMLATTRIBUTES(AR2.ID),
15. XMLELEMENT(NAME "titulo", AR2.TITULO),
16. (SELECT XMLAGG( XMLELEMENT(NAME "autor", AU.NOME) )
17. FROM AUTORIAS AT, AUTORES AU
18. WHERE AT.ARTIGO = AR2.ID AND AT.AUTOR = AU.ID),
19. XMLELEMENT(NAME "ano", AR2.ANO_PUB),
20. XMLELEMENT(NAME "local", AR2.LOCAL) ) )
21. FROM REFERENCIAS RF, ARTIGOS AR2
22. WHERE RF.ARTIGO = AR.ID AND RF.REFERENCIA = AR2.ID) ) AS "XML"
23. FROM ARTIGOS AR
24. WHERE AR.STATUS = ’EM_PRODUCAO’
Figura 1.5.2: Consulta SQL/XML que define a visão Artigos_XML.

<artigo data="2007-01-08">
<autor>
<nome>Guilherme Figueiredo</nome>
<instituicao>COPPE/UFRJ</instituicao>
<endereco>
<email>g.coelho@cos.ufrj.br</email>
</endereco>
</autor>
<autor>
<nome>Vanessa Braganholo</nome>
<instituicao>IM/UFRJ</instituicao>
<endereco>
<email>braganholo@dcc.ufrj.br</email>
</endereco>
</autor>
<autor>
<nome>Marta Mattoso</nome>
<instituicao>COPPE/UFRJ</instituicao>
<endereco>
<email>marta@cos.ufrj.br</email>
</endereco>
</autor>
<titulo>Um Mediador para o Processamento de Consu ...</titulo>
<resumo>Este artigo descreve uma ferramenta que i ...</resumo>
<referencia id="322">
<titulo>On Distributing XML Repositories</titulo>
<autor>Jan-Marco Bremer</autor>
<autor>Michel Gertz</autor>
<ano>2003</ano>
<local>WebDB</local>
</referencia>
<referencia id="347">
<titulo>Distributed XML Repositories: Top-down ...</titulo>
<autor>Jan-Marco Bremer</autor>
<autor>Michel Gertz</autor>
<ano>2003</ano>
<local/>
</referencia>
...
</artigo>
Figura 1.5.3: Estado da visão Artigos_XML.

com as tuplas de uma tabela relacional, denominada tabela pivô. No caso

da visão Artigos_XML, cada elemento da visão corresponde a uma tupla da
tabela pivô ARTIGOS. Deste modo, o tipo TArtigos considera não somente a
estrutura do esquema relacional, como também as relações entre as tabelas.
Essa restrição facilita o trabalho do projetista, uma vez que este pode iniciar
a definição do esquema com base em um conceito já representado no esquema
relacional e, portanto, já conhecido. No caso em que não existe uma tabela
relacional representando o conceito que se deseja, uma visão relacional pode ser
criada para esse fim.
Passo 2 Definição dos mapeamentos da visão

A definição dos mapeamentos entre o esquema da visão e o esquema rela-
cional permite ao usuário de se abstrair dos detalhes da linguagem de baixo
nível, no caso SQL/XML, e se concentrar nas equivalências semânticas entre
dois modelos.
Em [21], o formalismo das assertivas de correspondência [22] é usado para
definir os mapeamentos da visão. Uma assertiva de correspondência expressa
como um elemento ou atributo da visão é definido em termos de um atributo
ou caminho do esquema relacional. A geração dos mapeamentos utiliza uma
abordagem top-down: (i) primeiro, são definidos os mapeamentos dos elementos
da visão com os atributos/caminhos da tabela pivô; (ii) em seguida, o mesmo
procedimento é realizado recursivamente para os elementos de tipo complexo.
Por exemplo, considere a visão Artigos_XML. As assertivas de Artigos_XML são
apresentadas na Figura 1.5.4.
A definição dos mapeamentos da visão começa pela definição das assertivas
entre o tipo TArtigo e a tabela ARTIGOS. As assertivas de data, titulo e resumo
são simples, uma vez que correspondem a atributos presentes na tabela pivô:
DATA, TITULO e RESUMO, respectivamente. Neste caso, por exemplo, a assertiva
T Artigo/titulo ≡ ART IGOS/T IT U LO relaciona o elemento XML titulo com
o atributo relacional TITULO.
Os elementos autor e referencia não possuem relacionamento direto com
nenhum atributo da tabela ARTIGOS. Os autores de um artigo são obtidos a par-
tir das tuplas relevantes da tabela AUTORES. Tais tuplas são obtidas através do
relacionamento m-n que existe entre ARTIGOS e AUTORES, o qual é implementado
pelas chaves estrangeiras FK3 e FK4. Deste modo, a partir de uma tupla da tabela
ARTIGOS, podemos obter seus autores através do caminho F K3−1 /F K4 . Logo,
assertiva do elemento autor é da seguinte forma T Artigo/autor ≡ ART IGOS/F K3−1 /F K4 .
Como o elemento autor é de tipo complexo TAutor, definimos em seguida as
assertivas entre o tipo TAutor e a tabela AUTORES. A definição dos mapeamentos
termina quando forem definidas assertivas para todos os atributos ou elementos
XML que compõem o esquema da visão.
Um resumo do formalismo e as restrições para a definição das assertivas
são apresentados na Tabela 1.2. A tabela considera a definição da assertiva
de um elemento ou atributo e de um tipo XML T em termos de um atributo
ou caminho de uma tabela relacional R. A coluna CONTEXTO XML classifica
TArtigo ARTIGOS AR
@data TArtigo/data º ARTIGOS/DATA ID
autor* TArtigo/autor º ARTIGOS/FK3-1/FK4 TITULO

RESUMO
nome TAutor/nome º AUTORES/NOME DATA AUTORIAS AT
s... ARTIGO (FK)
instituicao TAutor/instituicao º AUTORES/INSTITUICAO AUTOR (FK)
REVISOES
FK3-1 AUTORIAS AT ARTIGO (FK)
endereco TEndereco/endereco º AUTORES/NULL FK5-1
REVISOR (FK)
ARTIGO (FK)
rua TEndereco/rua º AUTORES/RUA FK4AUTOR (FK)
AUTORES AU
DATA_REVISAO
VERSAO
cidade TEndereco/cidade º AUTORES/CIDADE ID
TEXTO
pais TEndereco/pais º AUTORES/PAIS NOME
INSTITUICAO
email TEndereco/email º AUTORES/EMAIL EMAIL
titulo TArtigo/titulo º ARTIGOS/TITULO RUA
CIDADE
resumo TArtigo/resumo º ARTIGOS/RESUMO PAIS
REFERENCIAS RE
s...
referencia* TArtigo/referencia º ARTIGOS/FK1-1/FK2 ARTIGO (FK)
FK1-1 REFERENCIA (FK)
REFERENCIAS RE
@id TArtigo/id º ARTIGOS/ID
ARTIGO (FK)
titulo TArtigo/titulo º ARTIGOS/TITULO REFERENCIA (FK)
FK2 ARTIGOS AR2
autor* TArtigo/autor º ARTIGOS/FK3-1/FK4/NOME ID
ano TArtigo/ano º ARTIGOS/ANO TITULO
...
local TArtigo/local º ARTIGOS/LOCAL s
ANO_PUB
AUTORIAS AT2
LOCAL AUTORES AU2
ARTIGO
ID (FK)
LEGENDA AUTOR (FK)
FK3-1 AUTORIAS
NOMEAT2
Assertivas entre TArtigo & ARTIGOS ARTIGO (FK)
INSTITUICAO
AUTOR (FK)
EMAIL
Assertivas entre TAutor & AUTORES FK4 AUTORES
RUA AU2
Assertivas entre TEndereco & AUTORES CIDADE
ID
PAIS
NOME
Assertivas entre TReferencia & ARTIGOS s
...
INSTITUICAO
EMAIL
RUA
CIDADE
Figura 1.5.4: Assertivas de Correspondência da visão Artigos_XML. PAIS
s
elementos/atributos da visão de acordo com a sua cardinalidade e tipo. A

coluna CONTEXTO RELACIONAL apresenta quais objetos relacionais podem
se relacionar com o contexto XML correspondente. A terceira coluna, por fim,
apresenta a assertiva correspondente.
Passo 3 Geração da consulta SQL/XML que define a visão

A geração da consulta SQL/XML a partir das assertivas da visão também
utiliza uma abordagem top-down. (i) Primeiro, é gerado o esqueleto da consulta
principal. (ii) Em seguida, para cada elemento do tipo da visão, a sua assertiva
é analisada e convertida na subconsulta SQL/XML correspondente. No caso de
um elemento de tipo complexo, (iii) são geradas as subconsultas para os seus
sub-elementos.
Dada uma assertiva da forma T /e ≡ R/exp, a Tabela 1.3 apresenta os
modelos de subconsulta SQL/XML que computam o elemento e a partir da
expressão exp. A coluna CONTEXTO XML classifica e segundo seu tipo e
sua cardinalidade, enquanto a coluna CONTEXTO RELACIONAL apresenta
os possíveis valores que exp pode assumir. Por fim, a coluna SUBCONSULTA
SQL/XML apresenta o modelo da subconsulta SQL/XML equivalente.
No caso da visão Artigos_XML, os passos para a geração da consulta SQL/XML
que define a visão são apresentados na Figura 1.5.5. A figura também apresenta
CONTEXTO XML CONTEXTO RELACIONAL ASSERTIVA CORRESPONDENTE
a : atributo da tabela R T/e  R/a
OCORRÊNCIA : atributo de uma tabela R' T/e  R//a

que possui relacionamento  é um caminho de uma ou mais
ÚNICA /a
1-1 com a tabela R chaves estrangeiras que representa o
relacionamento 1-1 entre R e R'
: atributo de uma tabela R' T/e  R//a
que possui relacionamento  é um caminho de uma ou mais
TIPO /a 1-n ou m-n com a tabela R chaves estrangeiras que representa o
ATÔMICO relacionamento 1-n ou m-n entre R e
R'
OCORRÊNCIA
: conjunto de atributos da
MÚLTIPLA {a1, ..., an} T/e  R/{a1, ..., an}
tabela R
: conjunto de atributos da
tabela R', a qual possui
/{a1, ..., an} T/e  R//{a1, ..., an}
relacionamento 1-1 com a
tabela R
: relacionamento 1-1 entre T/e  R/
OCORRÊNCIA R e uma tabela R'  é um caminho de uma ou mais

ÚNICA chaves estrangeiras que representa o
relacionamento 1-1 entre R e R'
TIPO
COMPLEXO : relacionamento 1-n ou m- T/e  R/
n entre R e uma tabela R'  é um caminho de uma ou mais
OCORRÊNCIA
 chaves estrangeiras que representa o
MÚLTIPLA
relacionamento 1-n ou m-n entre R e
R'
: usado quando o
elemento/ atributo e não
DEFAULT NULL possui nenhuma T/e  R/NULL
correspondência no
esquema relacional
Tabela 1.2: Definição de uma assertiva entre um atributo/elemento e de um

tipo XML T e um atributo/caminho de uma tabela relacional R.
CONTEXTO SUBCONSULTA
CASO CONTEXTO XML
RELACIONAL SQL/XML
ATRIBUTO
1 a r.a AS "e"
DEFAULT
2 /a (SELECT r'.a FROM R, …, R' WHERE RR') AS "e"
3 a XMLFOREST(r.a AS "e")
OCORRÊNCIA
XMLFOREST( (SELECT r'.a FROM R, …, R' WHERE R⋈R')
4 ÚNICA /a
AS "e")
SELECT XMLAGG( XMLFOREST(r'.a AS "e") )
5 TIPO /a FROM R, …, R'
ATÔMICO WHERE R⋈R
OCORRÊNCIA
6 {a1, ..., an} XMLFOREST( r.a1 AS "e", ..., r.an AS "e")
MÚLTIPLA
ELEMENTO
(SELECT XMLFOREST( r'.a1 AS "e", ..., r'.an AS "e")

7 /{a1, ..., an} FROM R, ..., R'
WHERE R⋈R' )
(SELECT XMLELEMENT("e", )
OCORRÊNCIA
8  FROM R, ..., R'
ÚNICA
TIPO WHERE R⋈R' )
COMPLEXO (SELECT XMLAGG( XMLELEMENT("e", ) )
OCORRÊNCIA
9  FROM R, ..., R'
MÚLTIPLA
WHERE R⋈R'
10 DEFAULT NULL XMLELEMENT("e", )
NOTA:
- Considere  = FK1/.../FKn um caminho de chaves estrangeiras da tabela R para a tabela R'.
- Considere R⋈R a expressão SQL que realiza a junção definida pelo caminho .
Tabela 1.3: Geração da sub-consulta SQL/XML para uma assertiva da forma

T /e ≡ R/exp.
o caso que gerou cada subconsulta. A seguir, detalhamos os passos da Figura

1.5.5.
1. Primeiro, é gerado o esqueleto da consulta principal. Essa consulta é
definida sobre a tabela pivô (ARTIGOS) e contém uma chamada à função
XMLELEMENT para gerar o elemento da visão.
2. Em seguida, são geradas as subconsultas para cada atributo/elemento do
tipo da visão (TArtigo).
3. Como o elemento autor é de tipo complexo, então é necessário obter as
subconsultas para todos os seus sub-elementos.
4. O elemento endereço também é complexo e, logo, são geradas também as

subconsultas para os seus sub-elementos.
5. Por fim, são geradas as subconsultas para os sub-elementos do elemento
referencia. A cláusula WHERE que filtra somente os artigos em status
de produção pode ser facilmente adicionada ao fim da consulta principal.
1
CREATE VIEW Artigos_XML
SELECT XMLELEMENT("artigo",
)
FROM ARTIGOS AR
3
(SELECT XMLAGG( XMLELEMENT(NAME "autor",
4
2
CREATE VIEW Artigos_XML XMLFOREST(NAME "nome", AU.NOME), caso 3 XMLELEMENT(NAME "endereco",
SELECT XMLELEMENT("artigo", XMLFOREST(AU.RUA AS "rua") caso 3
XMLFOREST(NAME "instituicao", AU.INSTITUICAO), caso 3
XMLATTRIBUTES(AR.DATA as "data"), caso 1
XMLELEMENT(NAME "endereco", caso 10 XMLFOREST(AU.CIDADE AS "cidade") caso 3
(SELECT XMLAGG( caso 9 )
XMLELEMENT(NAME "autor", XMLFOREST(AU.PAIS AS "pais") caso 3
)) ))
FROM AUTORES AU, AUTORIAS AT FROM AUTORES AU, AUTORIAS AT XMLFOREST(AU.EMAIL AS "email") caso 3
WHERE AT.ARTIGO = AR.ID AND AT.AUTOR = AU.ID), WHERE AT.ARTIGO = AR.ID AND AT.AUTOR = AU.ID),
)
XMLFOREST(NAME "titulo", AR.TITULO), caso 3
5
(SELECT XMLAGG( XMLELEMENT(NAME "referencia",
XMLFOREST(NAME "resumo", AR.RESUMO), caso 3
XMLATTRIBUTES(AR2.ID), caso 1
(SELECT XMLAGG( caso 9
XMLELEMENT(NAME "referencia", XMLFOREST(NAME "titulo", AR2.TITULO), caso 3
))
(SELECT XMLAGG( caso 5
FROM REFERENCIAS RF, ARTIGOS AR2
XMLELEMENT(NAME "autor", AU.NOME) )
WHERE RF.ARTIGO = AR.ID AND
FROM AUTORIAS AT, AUTORES AU
RF.REFERENCIA = AR2.ID)
WHERE AT.ARTIGO = AR2.ID AND AT.AUTOR = AU.ID),
)
FROM ARTIGOS AR XMLFOREST(NAME "ano", AR2.ANO_PUB), caso 3
XMLFOREST(NAME "local", AR2.LOCAL) caso 3
))
FROM REFERENCIAS RF, ARTIGOS AR2
WHERE RF.ARTIGO = AR.ID AND
RF.REFERENCIA = AR2.ID)
Figura 1.5.5: Passos para a geração da consulta SQL/XML da visão

Artigos_XML.
1.5.2 Ferramenta XML View by Assertion (XVBA)

Em [23], é proposta uma ferramenta para a geração e manutenção de visões
SQL/XML. Uma visão simplificada da arquitetura do XVBA é mostrada na
Figura 1.5.6.
Através do componente GUI, o usuário define o esquema da visão XML e
carrega o esquema relacional. Em seguida, o usuário define graficamente os
mapeamentos entre o esquema da visão e o esquema relacional com a ajuda do
componente Gerador de Mapeamentos (vide Figura 1.5.7). O Gerador de Ma-
peamentos gera o documento que contém um conjunto de assertivas de corre-
spondência que especifica o esquema da visão em termos do esquema relacional.
Por fim, o componente Gerador da Consulta SQL/XML recebe como entrada
os mapeamentos e gera a consulta SQL/XML que define a visão.
1.5.3 Middlewares que Implementam Visões XML

Diversos middlewares e frameworks foram propostos para solucionar o problema
de publicação de dados relacionais no formato XML [7, 3, 2]. No XTables [7]
e SilkRoute [3], uma visão XML é definida como uma consulta XQuery sobre
uma visão XML canônica, que representa o esquema relacional. Esta consulta
especifica o esquema da visão e os mapeamentos que descrevem como o esquema
da visão está relacionado com a visão canônica. Uma consulta XQuery sobre a
visão é traduzida em consultas SQL e os resultados SQL são rotulados (tagged)
produzindo um documento XML.
No Framework de Três Fases do Clio [2], uma visão é definida por um con-
XVBA
GUI Gerador de
esquema da Mapeamentos
Gerador de
visão
Consulta
SQL/XML
esquema
usuário relacional
mapeamentos
BDR consulta SQL/XML

que define a visão
Figura 1.5.6: Arquitetura do XVBA.
Figura 1.5.7: Gerador de Mapeamentos do XVBA.

junto de tuple-generating dependencies (tgds) [24], que representam os mapea-

mentos. Estes mapeamentos podem ser gerados com ajuda da ferramenta Clio
[24]. O framework recebe como entrada os tgds e: (i) para cada tgd, os dados
relevantes são extraídos da fonte de dados. Então, (ii) fragmentos XML são
gerados a partir dos dados relevantes. Finalmente, (iii) os fragmentos XML são
mesclados/agrupados para produzir o resultado final. O framework é utilizado
para transformação e transporte de dados entre esquemas fonte-alvo.
No framework RelP [25], uma visão XML é especificada por um conjunto
de assertivas de correspondência, as quais representam o mapeamento entre o
esquema da visão e o esquema relacional. A partir das assertivas, são gerados
os templates de consulta da visão, os quais são fragmentos SQL/XML gerados
em tempo de projeto. Uma consulta XQuery definida sobre o esquema de uma
visão XML é traduzida em uma única consulta SQL/XML equivalente sobre o
esquema relacional. A tradução é realizada através da composição dos fragmen-
tos SQL/XML relevantes. A seguir apresentamos esse framework em detalhes.
1.5.4 Geração de Visões SQL/XML no RelP

RelP[25] é um framework para publicação e consulta de dados relacionais
através de visões XML. No RelP, uma consulta XQuery definida sobre o es-
quema de uma visão XML é traduzida em uma única consulta SQL/XML equiv-
alente sobre o esquema relacional. Uma visão no RelP é definida por um con-
junto de assertivas de correspondência, as quais definem o mapeamento entre o
esquema da visão e o esquema relacional subjacente.
Uma visão simplificada dos componentes e interfaces de RelP é mostrada
na Figura 1.5.8. A Ferramenta de Publicação de Visões permite criar, de forma
gráfica, uma visão XML sobre um esquema relacional. A ferramenta gera auto-
maticamente os templates de consulta da visão, os quais são usados no processo
de tradução de consultas. O esquema da visão e seus templates de consulta são
armazenados através do Gerenciador de Catálogo.
O Serviço de Acesso a Dados fornece a interface padrão de acesso às visões
XML. A Ferramenta de Consulta de Visões permite aos usuários definir grafica-
mente uma consulta sobre uma visão XML publicada. O Tradutor de Consulta
traduz uma consulta XQuery definida em termos do esquema XML de uma visão
em uma consulta SQL/XML sobre o esquema relacional. A fim de traduzir a
consulta, o componente utiliza os templates de consulta armazenados no Catál-
ogo.
O Serviço de Acesso a Dados fornece os seguintes métodos: (i) getCapa-
bilities: retorna as capacidades do serviço (especificamente, retorna as visões
XML servidas), (ii) describeViewType: retorna o esquema XML de uma visão,
(iii) query: requisita a execução de uma consulta XQuery sobre uma visão XML.
O Gerenciador de Requisições redireciona as requisições para os componentes
apropriados.
Ferramenta de Gerenciador do
Publicação de Visões Catálogo
Designer
Catálogo
(Esquema da Visão e
Templates de Consulta)
Serviço Web de
Acesso a Dados
Ferramenta de Gerenciador de
Consulta de Visões Requisições
Cliente
Tradutor de Consulta
Applicação
RelP Framework
SGBDR
Figura 1.5.8: Arquitetura do RelP.
1.5.4.1 Publicando Visões XML com o RelP

A publicação de uma visão XML no RelP consiste de duas etapas: (i) Primeiro,
com a ajuda da Ferramenta de Publicação de Visões, o usuário define o esquema
XML da visão e as assertivas de correspondência entre o esquema da visão e
o esquema relacional. (ii) Em seguida, os templates de consulta são gerados
automaticamente com base nas assertivas da visão. Os templates de consulta
de uma visão são representados por uma árvore, na qual cada nó possui um
modelo de subconsulta SQL/XML. Cada subconsulta é responsável por gerar
um elemento ou atributo da visão.
Considere a visão XML Artigos_XML (vide Figura 1.5.1), definida sobre o
esquema relacional ARTIGOS_REL da Figura 1.4.1. Considere também as asserti-
vas de correspondência da visão definidas na Figura 1.5.4. Os templates de
consulta, gerados a partir das assertivas da visão, são apresentados na Figura
1.5.9. Mais detalhes sobre a geração dos templates de consulta a partir das
assertivas da visão podem ser encontrados em [25].
1.5.4.2 Consultando Visões XML com RelP

O usuário pode consultar uma visão XML através do Serviço Web de Acesso
a Dados usando a linguagem XQuery. O RelP restringe a expressividade de
consultas XQuery para garantir eficiência no processamento de consulta. Para
tanto, o RelP aceita somente consultas que possam ser modeladas como Tree
Pattern Queries (TPQ). Uma TPQ é uma árvore com as seguintes característi-
cas:
• Os nós são rotulados por nomes de elementos/atributos ou valores;
• Os nós rotulados por uma seta são chamados nós-resultado. A seta indica
que o nó correspondente é parte do resultado da consulta;
• Os elementos que possuem nós-resultados como descendentes são rotulados

pelo símbolo *.
Template de TArtigo Template de TAutor

artigo* autor*
SELECT XMLELEMENT("artigo", %content%) FROM ARTIGOS AR (SELECT XMLAGG( XMLELEMENT("autor", %content% ) )
reference
FROM AUTORES AU, AUTORIAS AT
@data
WHERE AT.ARTIGO = AR.ID AND AT.AUTOR = AU.ID)
XMLATTRIBUTES( AR.DATA AS "data" )
nome
autor
XMLFOREST(AU.NOME AS "nome")
(SELECT XMLAGG( XMLELEMENT("autor",
XMLFOREST(AU.NOME AS "nome"), instituicao
XMLELEMENT("endereco", XMLFOREST(AU.INSTITUICAO AS "instituicao")
XMLFOREST(AU.RUA AS "rua", AU.CIDADE AS "cidade",
AU.PAIS AS "pais", AU.EMAIL AS "email") ) ) endereco
WHERE AT.ARTIGO = AR.ID AND AT.AUTOR = AU.ID) XMLELEMENT("endereco",
XMLFOREST(AU.RUA AS "rua", AU.CIDADE AS "cidade",
nome AU.PAIS AS "pais", AU.EMAIL AS "email") )
(SELECT XMLAGG( XMLELEMENT("nome", AU.NOME) )
FROM AUTORES AU, AUTORIAS AT rua
WHERE AT.ARTIGO = AR.ID AND AT.AUTOR = AU.ID) XMLFOREST(C.STREET AS "Street")
reference
endereco cidade
(SELECT XMLAGG( XMLELEMENT("endereco", ... ) )
pais
WHERE AT.ARTIGO = AR.ID AND AT.AUTOR = AU.ID) email
rua
(SELECT XMLAGG( XMLFOREST(AU.RUA AS "rua") ) Template de TEndereco
reference
FROM AUTORES AU, AUTORIAS AT endereco*

WHERE AT.ARTIGO = AR.ID AND AT.AUTOR = AU.ID)
(SELECT XMLELEMENT("endereco", %content% )
cidade FROM AUTORES AU, AUTORIAS AT
pais WHERE AT.ARTIGO = AR.ID AND AT.AUTOR = AU.ID)
XMLELEMENT("endereco", %content% )
email
titulo rua
XMLFOREST( AR.TITULO AS "titulo" ) XMLFOREST(AU.RUA AS "rua")
resumo cidade
referencia pais
(SELECT XMLAGG( XMLFOREST("referencia", email
XMLATTRIBUTES( AR2.ID AD "id" ), XMLFOREST( AR2.TITULO AS "titulo" ),
(SELECT XMLAGG( XMLELEMENT( "nome" AS AU.NAME ) )
FROM AUTORES AU, AUTORIAS AT Template de TReferencia
WHERE AT.ARTIGO = AR.ID AND AT.AUTOR = AU.ID), referencia*
XMLFOREST(AR2.ANO AS "ano"), XMLFOREST(AR2.LOCAL AS "local") )
FROM REFERENCIAS RE, ARTIGOS AR2 (SELECT XMLAGG( XMLELEMENT("referencia", %content%)
reference
WHERE RE.ARTIGO = AR.ID AND RE.REFERENCIA = AR2.ID ) FROM REFERENCIAS RE, ARTIGOS AR2
WHERE RE.ARTIGO = AR.ID AND RE.REFERENCIA = AR2.ID )
@id
@id
(SELECT XMLAGG( XMLFOREST("referencia",
XMLATTRIBUTES( AR2.ID AD "id" ) ) XMLATTRIBUTES(AR2.ID AS "id")
FROM REFERENCIAS RE, ARTIGOS AR2
WHERE RE.ARTIGO = AR.ID AND RE.REFERENCIA = AR2.ID ) titulo
XMLFOREST(AR2.TITULO AS "titulo")
titulo
autor autor
ano ano
local local
Figura 1.5.9: Templates de Consulta da visão Artigos_XML.

Considere, por exemplo, a seguinte consulta XQuery Q:

for
$ar in view("Artigos_XML")/artigo
where
$ar/@data > "2002-01-01"
return
<artigo>
{$ar/titulo,
for $au in $ar/autor
return
<autor>{$au/nome, $au/instituicao}</autor>}
</artigo>
A Figura 1.5.10 apresenta a definição da consulta Q através da Ferramenta

de Consulta de Visões. Na ferramenta, (i) o usuário carrega o esquema da visão
XML sobre a qual ele deseja realizar a consulta. Em seguida, (ii) o usuário
seleciona os elementos que deseja retornar (nós-resultado) e define os filtros da
consulta. Por fim, (iii) o usuário envia a consulta ao RelP (botão Executar) e
o resultado é mostrado.
Quando o usuário envia uma consulta XQuery ao RelP, o Tradutor de
Consulta gera a TPQ correspondente, como ilustra a Figura 1.5.11. Em seguida,
o tradutor faz o matching entre a TPQ e os templates de consulta da visão. No
exemplo, a raiz artigo* da TPQ P é associada à raiz do template do tipo
TArtigo. O elemento titulo da TPQ é associado ao elemento titulo do
template do tipo TArtigo. O elemento autor* da TPQ é associado ao elemento
do caminho artigo*/autor/reference. Em seguida, os dois subelementos
nome e instituicao da TPQ são associados aos elementos nome e instituicao
do template do tipo TAutor, respectivamente. A consulta final é dada pela
composição dos fragmentos mais a cláusula de filtro definida para o atributo
data:
SELECT XMLELEMENT(NAME "artigo",
XMLFOREST(AR.TITULO AS "titulo"),
(SELECT XMLAGG(XMLELEMENT(NAME "autor",
XMLFOREST(AU.NOME AS "nome"),
XMLFOREST(AU.INSTITUICAO AS "instituicao")))
WHERE AT.ARTIGO = AR.ID AND AT.AUTOR = AU.ID))
FROM ARTIGOS AR
WHERE AR.DATA > ’2002-01-01’
1.6 Consultando dados XML armazenados em SGB-

DRs
Uma vez que os dados estão disponibilizados no formato XML, o passo seguinte é
recuperar fragmentos específicos desses dados através de consultas XML. Como
Figura 1.5.10: Ferramenta de Consulta de Visões do RelP.
artigo*
@data titulo autor*
>
"2002-01-01" nome instituicao
Figura 1.5.11: Tree Pattern Query P correspondente à consulta XQuery Q.

visto, este cenário é bem comum em aplicações que armazenam seus dados em
bancos relacionais, mas realizam a troca de informações com outras aplicações
usando o formato XML. Em geral, o projetista da aplicação publica os dados
relacionais relevantes no formato XML de modo a definir uma camada lógica
sobre a qual outros desenvolvedores podem definir facilmente consultas XML
particulares.
No sentido inverso, considera-se o cenário no qual o usuário precisa repre-
sentar esses dados no formato relacional com o intuito de armazená-los, por
exemplo. Deste modo, os dados XML precisam ser convertidos em um formato
tabular para serem manipulados mais facilmente no momento de sua consoli-
dação na base relacional.
Pensando em preencher essa lacuna, o padrão SQL/XML definiu duas funções:
XMLQUERY, para a recuperação de dados XML através de consultas XML
(XQuery e XPath); e XMLTABLE, para a geração de estruturas tabulares a
partir de dados XML. A seguir, descrevemos os detalhes essas funções e apre-
sentamos alguns exemplos.
XMLQUERY A função XMLQUERY permite a definição de consultas XQuery

sobre instâncias do tipo de dados XML. Ela é utilizada em conjunto com uma
consulta SQL, a qual deve selecionar as instâncias XML sobre as quais a consulta
XQuery será aplicada, como mostra o Exemplo 9.
SELECT XMLQUERY(
’for $ar in $xml/artigo
return
<artigo titulo="{$ar/titulo}">{ $ar/@data }</artigo>’
PASSING AR.XML AS "xml"
RETURNING CONTENT
NULL ON EMPTY ) AS "ARTIGOS"
FROM ARTIGOS_XML AR
Resultado:
ARTIGOS
-----------------------------------------------------------------
<artigo titulo="Um Mediador para o Processamento de Consultas so
bre Bases XML Distribuídas" data="2007-08-01"/>
<artigo titulo="Automatic Generation of SQL/XML Views" data="200
6-02-22"/>
(2 linhas)
O argumento da função XMLQUERY é a consulta XQuery que se deseja

executar. No Exemplo 9, a consulta XQuery embutida retorna um elemento
artigo com dois atributos (titulo e data). A consulta faz referência à variável
xml, a qual é passada através da expressão PASSING AR.XML AS "xml". Deste
modo, a consulta XQuery é executada para cada tupla da visão Artigos_XML. A
expressão RETURNING CONTENT especifica que o resultado é do subtipo CONTENT

do tipo XML, enquanto a expressão NULL ON EMPTY especifica que o valor nulo
deve ser retornado quando o resultado da consulta for vazio.
O Exemplo 10 mostra como executar consultas XQuery sobre a representação
XML de uma tabela relacional.
SELECT XMLQUERY(
’for $ar in ora:view("artigos")/ROW
return
<artigo titulo="{$ar/TITULO}"
data="{$ar/DATA/text() }"/>’
RETURNING CONTENT
NULL ON EMPTY ) AS "ARTIGOS"
FROM ARTIGOS_XML AR
Resultado:
ARTIGOS
-----------------------------------------------------------------
<artigo titulo="Um Mediador para o Processamento de Consultas so
bre Bases XML Distribuídas" data="2007-08-01"/>
<artigo titulo="Automatic Generation of SQL/XML Views" data="200
6-02-22"/>
(2 linhas)
No Exemplo 10, usamos a função ora:view do Oracle, a qual gera uma

representação XML de uma tabela relacional. Como visto na Seção 1.4.3, cada
linha da tabela é mapeada em um elemento ROW contendo os atributos da tabela
como sub-elementos.
XMLTABLE A função XMLTABLE permite gerar uma estrutura tabular a

partir de dados XML. Ela também é utilizada em uma consulta SQL. Para o
exemplo a seguir, considere a tabela INSTITUICOES_XML (Tabela 1.4), a qual
armazena dados XML de instituições de ensino e seus autores. O Exemplo 11
apresenta uma consulta SQL usando a função XMLTABLE.
SELECT IT.NOME, AU.NOME, AU.EMAIL

FROM INSTITUICOES_XML IT_XML,
XMLTABLE(’for $in in $xml/instituicao
return $in’
PASSING IT_XML.SYS_NC_ROWINFO$ AS "xml"
COLUMNS
"ID" NUMBER PATH ’@id’,
"NOME" VARCHAR2(150) PATH ’nome’,
"AUTORES_XML" XMLTYPE PATH ’autor’) IT,
XMLTABLE(’for $au in $xml/autor
INSTITUICOES_XML
XML
<instituicao id="120">
<nome>PUC-Rio</nome>
<autor>
<nome>Marco Antonio Casanova</nome>
<email>casanova@inf.puc-rio.br</email>
</autor>
</instituicao>
<nome>UFC</nome>
<autor>
<nome>Vânia Vidal</nome>
<email>vvidal@lia.ufc.br</email>
</autor>
<autor>
<nome>Fernando Lemos</nome>
<email>fernandocl@lia.ufc.br</email>
</autor>
</instituicao>
<nome>COPPE/UFRJ</nome>
<autor>
<nome>Guilherme Figueiredo</nome>
<email>g.coelho@cos.ufrj.br</email>
</autor>
<autor>
<nome>Marta Mattoso</nome>
<email>marta@cos.ufrj.br</email>
</autor>
</instituicao>
<nome>IM/UFRJ</nome>
<autor>
<nome>Vanessa Braganholo</nome>
<email>braganholo@dcc.ufrj.br</email>
</autor>
</instituicao>
Tabela 1.4: Instância da tabela INSTITUICOES_XML, a qual armazena dados

XML de instituições de ensino e seus autores.
return $au’
PASSING IT.AUTORES_XML AS "xml"
COLUMNS
"NOME" VARCHAR2(150) PATH ’nome’,
"EMAIL" VARCHAR2(150) PATH ’email’) AU
Resultado:
DATA | TITULO | RESUMO
-----------------------------------------------------------------
PUC-Rio | Marco Antonio Casanova | casanova@inf.puc-rio.br
UFC | Vânia Vidal | vvidal@lia.ufc.br
UFC | Fernando Lemos | fernandocl@lia.ufc.br
COPPE/UFRJ | Guilherme Figueiredo | g.coelho@cos.ufrj.br
COPPE/UFRJ | Marta Mattoso | marta@cos.ufrj.br
IM/UFRJ | Vanessa Braganholo | braganholo@dcc.ufrj.br
(6 linhas)
A consulta XQuery do Exemplo 11 constrói duas tabelas relacionais tem-
porárias (IT e AU). A tabela IT é gerada a partir dos elementos instituição da
tabela INSTITUICOES_XML e possui três colunas (ID, NOME e AUTORES), as quais
são definidas pela cláusula COLUMNS. A coluna ID, por exemplo, contém os val-
ores do atributo id do elemento instituicao, enquanto a coluna AUTORES_XML
contém os elementos XML autor do elemento instituicao. A tabela AU é ger-
ada a partir dos autores da instituição em questão e possui duas colunas (NOME
e EMAIL).
1.7 Conclusões
Neste capítulo, discutimos o padrão SQL/XML, uma extensão do SQL que provê
suporte a XML no contexto de um SGBD relacional. Primeiro, introduzimos
um breve histórico sobre o surgimento do padrão SQL/XML. Em seguida, ap-
resentamos o tipo de dados XML, o qual permite gerenciar e manipular dados
XML de forma nativa em SGBDs relacionais. Em outro momento, discutimos
as funções de publicação do padrão SQL/XML, as quais contituem a parte do
padrão que provê a publicação de dados relacionais em um formato XML. Vi-
mos que tais funções são usadas diretamente na consulta SQL e que permitem
criar qualquer estrutura XML a partir do esquema relacional. Apresentamos
também o mapeamento definido pelo padrão para transformar tabelas rela-
cionais em um documento XML canônico. Em seguida, discutimos o uso de
visões SQL/XML. Neste caso, foi apresentada uma metodologia para a criação
de visões SQL/XML em bancos de dados que possuem tal mecanismo de visão.
Também abordamos um framework que permite a criação de visões SQL/XML
em bancos relacionais que não possuem mecanismo de visão SQL/XML. Por
fim, apresentamos a função XMLQUERY, a qual permite, através de consultas
XQuery, recuperar fragmentos de dados XML armazenados em SGBDs rela-
cionais. Também apresentamos a função XMLTABLE, a qual permite gerar
estruturas tabulares a partir de dados XML.
Como vimos, o padrão SQL/XML se mostra uma solução natural no cenário

de integração de dados XML e relacionais usando a linguagem SQL. Ele permite
armazenar documentos XML em SGBDRs, consultar tais documentos usando
XPath e XQuery, e publicar dados relacionais no formato XML. Vimos também
que o padrão SQL/XML é de fácil aprendizagem, pois envolve um grupo pequeno
de adições à linguagem SQL existente.
Exercícios
Considere o esquema relacional AVIACAO mostrado abaixo:
VOOS (VCODIGO: INTEGER, ORIGEM:STRING, DESTINO:STRING, PREÇO:REAL)
ALOCACAO (VCODIGO:INTEGER, ACODIGO:INTEGER)
AVIOES (ACODIGO:INTEGER, MODELO:STRING, FABRICANTE:STRING, AUTONOMIA_VOO:INTEGER)
CERTIFICADOS (ACODIGO:INTEGER, PCODIGO:INTEGER)
PILOTOS (PCODIGO:INTEGER, NOME:STRING, SALARIO:INTEGER, HORASVOO:INTEGER)
Considere o seguinte esquema XML:
<schema>
<element name="aviao" type="TAviao"/>
<complexType name="TAviao">
<sequence>
<element name="modelo" type="string"/>
<element name="fabricante" type="string"/>
<element name="autonomia" type="int"/>
<element name="voo" type="TVoo" maxOccurs="unbounded"/>
<element name="pilotoCertificado" type="TPilotoCertificado"
maxOccurs="unbounded"/>
</sequence>
<attribute name="codigo" type="int"/>
</complexType>
<complexType name="TVoo">
<sequence>
<element name="origem" type="string"/>
<element name="destino" type="short"/>
</sequence>
<attribute name="codigo" type="int"/>
</complexType>
<complexType name="TPilotoCertificado">
<sequence>
<element name="nome" type="string"/>
<element name="salario" type="float"/>
</sequence>
</complexType>
</schema>
Exercise 12. Suponha a visão AVIOES cujos elementos são instâncias do es-
quema XML acima. Escreva a consulta SQL/XML que define a visão AVIOES
sobre o esquema relacional AVIACAO.
Exercise 13. Escreva as consultas a seguir (i) em XQuery sobre a visão AVIOES
e (ii) em SQL/XML sobre o esquema relacional AVIACAO.
1. Obtenha os aviões que fizeram vôo partindo de São Paulo.

2. Obtenha os pilotos certificados a pilotar aviões 747 da BOEING.
3. Obtenha os vôos de cada avião onde todos os pilotos certificados a pilotá-lo
têm salário maior que 5 mil.
4. Obtenha os aviões que tem mais de 15 pilotos certificados a pilotá-los.

5. Obtenha os aviões que não têm nenhum vôo realizado.
Referências Bibliográficas
[1] J. Shanmugasundaram, E. Shekita, R. Barr, M. Carey, B. Lindsay, H. Pi-

rahesh, and B. Reinwald, Efficiently publishing relational data as XML
documents, The VLDB Journal 10(2-3), 133–154 (2001).
[2] H. Jiang, H. Ho, L. Popa, and W.-S. Han, Mapping-driven XML transfor-
mation, pages 1063–1072 (2007).
[3] C. Re, J. F. Brinkley, and D. Suciu, A performant XQuery to SQL trans-
lator, Technical report, Computer Science and Engineering, University of
Washington, 2006.
[4] M. Fernández, Y. Kadiyska, D. Suciu, A. Morishima, and W.-C. Tan,
SilkRoute: A framework for publishing relational data in XML, ACM
Trans. Database Syst. 27(4), 438–493 (2002).
[5] S. Melnik, P. A. Bernstein, A. Halevy, and E. Rahm, Supporting executable

mappings in model management, in SIGMOD ’05: Proceedings of the 2005
ACM SIGMOD international conference on Management of data, pages
167–178, New York, NY, USA, 2005, ACM.
[6] L. A. d. L. Santos, XML Publisher: Um Framework para Publicar Da-
dos Objeto Relacionais em XML, Master’s thesis, Departamento de Com-
putação, Universidade Federal do Ceará, 2004.
[7] J. E. Funderburk, G. Kiernan, J. Shanmugasundaram, E. Shekita, and
C. Wei, XTABLES: Bridging relational technology and XML, IBM Syst.
J. 41(4), 616–641 (2002).
[8] L. Popa, Y. Velegrakis, M. A. Hernández, R. J. Miller, and R. Fagin, Trans-

lating web data, in VLDB ’02: Proceedings of the 28th international confer-
ence on Very Large Data Bases, pages 598–609, VLDB Endowment, 2002.
[9] R. Krishnamurthy, R. Kaushik, and J. F. Naughton, XML-to-SQL Query
Translation Literature: The State of the Art and Open Problems, in In
XSym, pages 1–18, 2003.
[10] SQL/XML, http://www.sqlx.org.
39
REFERÊNCIAS BIBLIOGRÁFICAS 40
[11] A. Eisenberg and J. Melton, SQL/XML is making good progress, SIGMOD

Rec. 31(2), 101–108 (2002).
[12] A. Eisenberg, J. Melton, K. Kulkarni, J.-E. Michels, and F. Zemke,
SQL:2003 has been published, SIGMOD Rec. 33(1), 119–126 (2004).
[13] ISO/IEC 9075-14:2003 Information technology – Database languages – SQL
– Part 14: XML-Related Specifications, (SQL/XML), 2003.
[14] A. Eisenberg and J. Melton, Advancements in SQL/XML, SIGMOD Rec.
33(3), 79–86 (2004).
[15] ISO/IEC 9075-14:2006 Information technology – Database languages – SQL
– Part 14: XML-Related Specifications, (SQL/XML), 2006.
[16] Presentation - SQL Standard - SQL/XML Functionality,
http://jtc1sc32.org/doc/N1251-1300/32N1293-WG3-Presentation-for-
SC32-20050418.pdf, 2005.
[17] S. Pal, M. Fussell, and I. Dolobowsky, XML Support in Microsoft SQL
Server 2005, Technical report, Microsoft Corporation, 2005.
[18] D. Adams, Oracle XML DB Developer’s Guide, 11g Release 2,
http://download.oracle.com/docs/cd/E11882_01/appdev.112/e10492.pdf,
2009.
[19] PostgreSQL, XML Functions, http://www.postgresql.org/docs/8.4/static/functions-
xml.html, 2009.
[20] I. C. DB2, pureXML Guide, ftp://ftp.software.ibm.com/ps/products/db2/info/vr97/pdf/en_US/DB2pure
db2xge970.pdf, 2009.
[21] V. M. P. Vidal, M. A. Casanova, and F. Lemos, Automatic Generation of
SQL/XML Views, 21st Brazilian Symposium on Databases (SBBD’06) ,
221–235 (2006).
[22] V. Vidal, V. Araujo, and M. A. Casanova, Towards Automatic Generation
of Rules for Incremental Maintenance of XML Views of Relational Data,
Web Information Systems Engineering – WISE 2005 , 189 – 202 (2005).
[23] F. Lemos and V. M. P. Vidal, XVBA: Uma Ferramenta para Criação de
Visões XML, Technical report, Grupo ARiDa – Universidade Federal do
Ceará, 2006.
[24] L. M. Haas, M. A. Hernández, H. Ho, L. Popa, and M. Roth, Clio grows up:
from research prototype to industrial tool, in SIGMOD ’05: Proceedings of
the 2005 ACM SIGMOD international conference on Management of data,
pages 805–810, New York, NY, USA, 2005, ACM.
[25] F. Lemos, C. Maciel, and V. M. P. Vidal, Using SQL/XML for Efficiently
Translating Queries over XML View of Relational Data, Technical report,
Grupo ARiDa, Universidade Federal do Ceará, 2009.

SQLXML

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

SQLXML

Enviado por

Direitos autorais:

Formatos disponíveis

Capítulo 1

Vânia Maria Ponte Vidal, Fernando Lemos

padrão SQL/XML é uma solução natural para a necessidade de integrar dados

várias outras tecnologias como JDBC3 , SQLJ4 , SQL-19995 e ODMG OQL6 . A

Object Language Bindings (SQL/OLB)

Tabela 1.1: Exemplos de instâncias do tipo de dados XML.

• Novas funções de publicação e novos predicados (suporte à XQuery);

• Mapeamento de dados XML em estruturas relacionais.

1.3 Tipo de dados XML

1.3.1 Refinamentos do Tipo XML

Figura 1.3.1: Relação entre os subtipos XML [16].

SEQUENCE não determina nenhuma restrição; qualquer sequência XQuery é

1.4 Publicando Dados Relacionais como XML

REFERENCIAS ARTIGOS AUTORIAS AUTORES

Figura 1.4.1: Esquema relacional ARTIGOS_REL.

1.4.2 Funções de Publicação SQL/XML

XMLELEMENT A função XMLELEMENT constrói um elemento XML. A

Figura 1.4.2: Instância do esquema relacional ARTIGOS_REL.

O primeiro argumento da função XMLELEMENT é o nome do elemento

XMLFOREST A função XMLFOREST gera uma floresta de elementos XML

Cada expressão é convertida em um elemento XML e, caso um alias tenha

XMLAGG A função XMLAGG é uma função de agregação no mesmo sentido

Example 4. Consulta SQL/XML:

SELECT XMLELEMENT(NAME "autor",

A consulta do Exemplo 5 retorna o nome, o email e a lista de artigos de

XMLCONCAT A função XMLCONCAT recebe como parâmetros instâncias

SELECT AU.ID AS "autor",

No Exemplo 6, a função XMLCONCAT concatena os resultados das duas

XMLCOMMENT A função XMLCOMMENT permite criar comentários.

XMLPI A função XMLCOMMENT permite criar instruções de processa-

Example 8. Consulta SQL/XML:

As instruções de processamento sempre começam com "<?" e terminam

1.4.3 Mapeamento de tabelas relacionais em documentos

Figura 1.4.3: Documento XML gerado a partir da tabela ARTIGOS usando a

padrão SQL/XML também define mapeamentos de identificadores, dados e val-

Figura 1.4.5: Documento XML gerado a partir da tabela ARTIGOS usando a

mos na Seção 1.6. Já o SGBD PostgreSQL [19] possui as funções table_to_xml

1.5 Consultando dados relacionais através de Visões

Figura 1.5.1: Tipo XML TArtigo.

• A coleção de sub-elementos autor é gerada pela subconsulta nas linhas

1.5.1 Geração de Visões SQL/XML

Passo 1 Definição do esquema XML da visão

1. CREATE VIEW Artigos_XML AS SELECT XMLELEMENT(NAME "artigo",

Figura 1.5.2: Consulta SQL/XML que define a visão Artigos_XML.

Figura 1.5.3: Estado da visão Artigos_XML.

com as tuplas de uma tabela relacional, denominada tabela pivô. No caso

Passo 2 Definição dos mapeamentos da visão

autor* TArtigo/autor º ARTIGOS/FK3-1/FK4 TITULO

elementos/atributos da visão de acordo com a sua cardinalidade e tipo. A

Passo 3 Geração da consulta SQL/XML que define a visão

CONTEXTO XML CONTEXTO RELACIONAL ASSERTIVA CORRESPONDENTE

a : atributo da tabela R T/e  R/a

OCORRÊNCIA : atributo de uma tabela R' T/e  R//a

Tabela 1.2: Definição de uma assertiva entre um atributo/elemento e de um

(SELECT XMLFOREST( r'.a1 AS "e", ..., r'.an AS "e")

Tabela 1.3: Geração da sub-consulta SQL/XML para uma assertiva da forma

o caso que gerou cada subconsulta. A seguir, detalhamos os passos da Figura

4. O elemento endereço também é complexo e, logo, são geradas também as

XMLFOREST(NAME "local", AR2.LOCAL) caso 3

Figura 1.5.5: Passos para a geração da consulta SQL/XML da visão

1.5.2 Ferramenta XML View by Assertion (XVBA)

1.5.3 Middlewares que Implementam Visões XML

BDR consulta SQL/XML

Figura 1.5.6: Arquitetura do XVBA.