Esquema de un documento XML
 Los esquemas de BDs restringen que información puede ser
almacenada
 Los documentos XML no requieren tener un esquema
asociado
 No obstante, los esquemas son muy importantes para el
intercambio de datos XML

De otro modo, un sitio no puede interpretar
automaticamente los datos recibidos de otro sitio

Dos mecanismos se usan en XML para especificar
esquemas

Document Type Definition (DTD)


Un DTD Impone estructura a un documento XML.
XML Schema
 Más
reciente, su uso está en pleno crecimiento
Definición de Tipo de Documento (DTD)
 El tipo de un documento XML puede ser especificado usando un
DTD
 DTD condiciona o restringe la estructura de los datos XML

Que elementos pueden ocurrir

Que atributos puede/debe tener un elemento

Que subelementos pueden/deben ocurrir dentro de cada
elemento y cuantas veces.
 DTD no restringe los tipos de datos

Todos los valores se representan como strings en XML
 Sintaxis DTD (luego en detalle)

<!ELEMENT elemento (especificación de subelementos) >

<!ATTLIST NombreElemento NombreAtributo Tipo atr. Restr.>
Especificación de Elementos en DTD
 La especificación de un elemento puede contener:
Nombres de sub-elementos
 #PCDATA (Parsed Character Data), i.e., strings de caracteres
 EMPTY (el elemento no tiene contenido o subelementos)
 ANY (el contenido puede ser cq. Mezcla de PCDATA y elementos)
 Expresiones regulares
 Ejemplo
<! ELEMENT depositante (nombre cliente,número cuenta)>
<! ELEMENT nombre cliente (#PCDATA)>
<! ELEMENT número cuenta (#PCDATA)>
 Ejemplo del uso de expresiones regulares

<!ELEMENT banco (( cuenta | cliente | depositante)+)>
A continuación veremos esto más formalmente:
Definicion del tipo de un elemento
 Un elemento E se declara como:
<!ELEMENT E (P)>
Donde P es una expresión regular, i.e.,

P ::= EMPTY | ANY | #PCDATA | E’ | P1, P2 |






P1 | P2
| P? | P+ | P*
E’: tipo elemento
P1 , P2: concatenación
P1 | P2: disjunción
P?: opcional
P+: una o más ocurrencias
P*: cero o más ocurrencias (clausura de Kleene)
Nota: Clausura de Kleene {'a', 'b', 'c'}* = {ε, "a", "b", "c", "aa", "ab", "ac", "ba", "bb", "bc",...}
Notación DTD…
“|” - alternativas.
( e1 | e2 ) especifica que puede aparecer en el
documento e1 o e2 (disjunción)
“+” - 1 o más ocurrencias. Un “+” siguiendo al nombre de un elemento
significa que el elemento puede aparecer una o más veces en el
documento (elemento multivaluado).
“*” - cero o más ocurrencias. Un “*” siguiendo al nombre de un elemento
significa que el elemento puede aparecer cero o más veces en el
documento (elemento opcionalmente multivaluado).
“?” – cero o una ocurrencia. Un “?” siguiendo al nombre de un elemento
significa que el elemento puede aparecer cero o una vez en el
documento (optional single-valued element).
Todo elemento que aparezca sin ninguno de estos 3 símbolos debe
aparecer sólo una vez en el documento (single-valued element).
El tipo de un elemento es especificado entre paréntesis siguiendo al
elemento. Si el paréntesis incluye nombres de otros elementos estos
serán hijos en la estructura de árbol. Si los paréntesis incluyen la
palabra clave #PCDATA el elemento es un nodo hoja.
Los paréntesis pueden anidarse al especificar elementos.
Expresiones Regulares: ejemplos
nombre, dir*, email
dir
nombre
email
Un círculo
doble denota
un estado
admisible
Otro ejemplo
nombre,dir*,(tel | fax)*,email*
dir
nombre
email
tel
tel
email
fax
fax
email
Algunas cosas son difíciles de especificar
Cada empleado debe contener elementos nombre, edad y dni en
algun orden:
<!ELEMENT empleado
( (nombre, edad, dni) | (edad, dni, nombre) | (dni, nombre, edad)
| ... )>
Suponga que hay muchos más elementos involucrados!
Existen n! ordenamientos diferentes para n elementos
Ejemplo banco: datos XML
<banco>
<cuenta>
<número_cuenta> A-101 </número_cuenta>
<nombre_sucursal> caucete </nombre_sucursal>
<balance> 500 </balance>
</cuenta>
....
<cliente>
<nombre_cliente> Pérez </nombre_cliente>
<calle_cliente> el sauce 123 </calle_cliente>
<ciudad_cliente> angaco </ciudad_cliente>
</cliente>
....
<depositante>
<número_cuenta> A-101 </número_cuenta>
<nombre_cliente> Pérez </nombre_cliente>
</depositante>
....
</banco>
Ejemplo Banco: DTD
<!DOCTYPE banco [
<!ELEMENT banco (( cuenta | cliente | depositante)+)>
<!ELEMENT cuenta (numero_cuenta, nombre_sucursal, balance)>
<! ELEMENT cliente (nombre_cliente, calle_cliente, ciudad_cliente)>
<! ELEMENT depositante (nombre_cliente, número_cuenta)>
<! ELEMENT número_cuenta (#PCDATA)>
<! ELEMENT nombre_sucursal (#PCDATA)>
<! ELEMENT balance(#PCDATA)>
<! ELEMENT nombre_cliente(#PCDATA)>
<! ELEMENT calle_cliente(#PCDATA)>
<! ELEMENT ciudad_cliente(#PCDATA)>
]>
volver
Ejemplo libreta de Direcciones: datos XML
....
<persona>
<nombre> Juan Perez </nombre>
Exactamente un nombre
<presentación> Ing. J. Perez </presentación>
<dirección>calle Las Flores 1234 ... </dirección>
<dirección> calle Las Rosas 567... </dirección>
<tel> (321) 786 2543 </tel>
<fax> (321) 786 2544 </fax>
Teléfonos y
faxes
mezclados
<tel> (321) 786 2544 </tel>
<email> [email protected] </email>
</persona>
Tantas como
se necesiten
A lo sumo una
presentación
Tantas líneas de
dirección como sean
necesarias
Una vista más integral del documento XML para
libreta de direcciones es:
<libreta-direcciones>
<persona>
<nombre> Juan Perez </nombre>
<presentación> Ing. J. Perez </presentación>
….
<email> [email protected] </email>
</persona>
<persona>
....
</persona>
</ libreta-direcciones >
Ej. Libreta direcciones: especificando la estructura c/ DTD
 nombre
para especificar 1 elemento nombre
 presentación? para especificar un elemento presentación opcional (0o1)
 Nombre, presentación? para especificar 1 nombre seguido de una
presentación opcional
 dirección*
para especificar 0 o más lineas de dirección
 tel | fax
un elemento tel o un elemento fax
 (tel | fax)*
0 o más repeticiones de tel o fax contenido mixto
 email*
0 or más elementos email
 De modo que la estructura completa para persona está dada por la
expresión regular:
nombre, presentación?, dirección*, (tel | fax)*, email*
Documento XML con DTD interno para libreta de direcciones
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE libreta-direcciones [
<!ELEMENT libreta-direcciones (persona*)>
<!ELEMENT persona (nombre, presentación?, dirección*, (fax | tel)*, email*)>
<!ELEMENT nombre (#PCDATA)>
<!ELEMENT presentación (#PCDATA)>
<!ELEMENT dirección (#PCDATA)>
<!ELEMENT tel (#PCDATA)>
<!ELEMENT fax (#PCDATA)>
<!ELEMENT email (#PCDATA)>
]>
La sintaxis de
un DTD no es
sintaxis XML
“Interno” significa que el DTD y el documento
XML están en el mismo archivo
Ampliaremos a continuación…
Asociando un DTD con un documento
 Un DTD puede ser interno

El DTD es parte del archivo del documento
 o externo
 El DTD y el documento están en archivos separados, un DTD
externo puede residir:
 En el sistema de archivos local
(en el que está el documento)
 En un sistema de archivos remoto
Etiqueta de encabezamiento
 <?xml version="1.0" standalone="yes/no" encoding="UTF-8"?>

Standalone=“yes” significa que se trata de un DTD externo

Si se omite el atributo de codificación el procesador usará UTF-8
(default)
Nota: UTF-8 (8-bit Unicode Transformation Format) Formato de codificación de caracteres
Unicode de longitud variable (1 a 4 bytes por carácter Unicode, con un byte se codifican
los incluidos en US-ASCII)
Asociando un DTD con un documento...
 Con DTD interno:
<?xml version="1.0"?>
<!DOCTYPE libreta-direcciones [<!ELEMENT ...> … ]>
< libreta-direcciones> ... </ libreta-direcciones>
 Con DTD en el sistema de archivos local:
<!DOCTYPE libreta-direcciones SYSTEM "schema.dtd">
 Con DTD en un sistema de archivos remoto:
<!DOCTYPE db SYSTEM "http://www.schemaauthority.com/schema.dtd">
Especificación de Atributos en DTD
 Especificación de Atributos: para c/atributo de un elemento especificar:

Nombre
 Tipo de atributo
 CDATA
 ID
(identificador) o IDREF (ID reference) o IDREFS (múltiples IDREFs)
– luego ampliaremos
 Alguna de las siguientes cláusulas
 #REQUIRED: significa que el atributo debe ser incluido en el elemento
 #IMPLIED: significa que el atributo es opcional en el elemento
“valor”: el valor entre comillas es el único posible para el atributo
 “valor” :Valor por defecto que toma el atributo si no se dá ninguno
 #FIXED
 Ejemplos
elemento
atributo
tipo
valor x defecto
<!ATTLIST cuenta tipodecuenta CDATA “checking”>
 <!ATTLIST cliente id_cliente ID #REQUIRED cuentas IDREFS#REQUIRED>

IDs e IDREFs
 Un elemento puede tener a lo sumo un atributo de tipo ID
 El valor del atributo ID debe ser distinto para cada elemento del
documento XML (valor único en todo el documento)

Así el valor de un ID es un identificador de objeto
 Un atributo de tipo IDREF debe contener el valor de un ID de un
elemento del mismo documento
 Un atributo del tipo IDREFS contiene un conjunto de (0 o más)
valores ID. Cada uno de los IDREFS debe contener el valor de
un ID de otro elemento del mismo documento
<persona id=“898” padre=“332” madre=“336” hijos=“982 984 986”>
Ejemplo banco-2: datos XML con ID e IDREF
<banco-2>
<cuenta número_cuenta=“A-401” propietarios=“C100 C102”>
<nombre_sucursal> central </nombre_sucursal>
<balance> 500 </balance>
</cuenta>
…..
<cliente id_cliente=“C100” cuentas=“A-401”>
<nombre_cliente> Pepe </nombre_cliente>
<calle_cliente> camino </calle_cliente>
<ciudad_cliente> San Juan </ciudad_cliente>
</cliente>
<cliente id_cliente=“C102” cuentas=“A-401 A402”>
<nombre_cliente> Mary </nombre_cliente>
<calle_cliente> Las piedras </calle_cliente>
<ciudad_cliente> San Juan </ciudad_cliente>
</cliente>
…..
</banco-2>
 Notar que, a diferencia del ej. Banco, aquí no se usa un elemento depositante.
 Lo mismo ocurre si usamos anidamiento (ver a cont. ejemplo Banco-1)
Ejemplo banco-1: datos XML con anidamiento
<banco-1>
<cliente>
<nombre_cliente> Huerta </nombre_cliente>
<domicilio_cliente> Piedras 2020 </domicilio_cliente>
<ciudad_cliente> San Juan </ciudad_cliente>
<cuenta>
<número_cuenta> A-102 </número_cuenta>
<nombre_sucursal> jachal </nombre_sucursal>
<balance> 400 </balance>
</cuenta>
<cuenta>
…
…
…
</cuenta>
</cliente>
...
...
</banco-1>
Ejemplo Banco-2: DTD

DTD del Banco con atributos ID e IDREF
<!DOCTYPE banco-2[
<!ELEMENT banco (( cuenta | cliente)+)>
<!ELEMENT cuenta (sucursal, balance)>
<!ATTLIST cuenta
número_cuenta ID # REQUIRED
propietarios IDREFS # REQUIRED>
<!ELEMENT cliente (nombre_cliente, calle_cliente, ciudad_cliente)>
<!ATTLIST cliente
id_cliente ID # REQUIRED
cuentas IDREFS # REQUIRED>
… faltan declaraciones para sucursal, balance, nombre_cliente,
calle_cliente y ciudad_cliente
]>
ir DTD del ejemplo Banco
DTD: OtroEjemplo…
<!DOCTYPE pais [
<!ELEMENT pais ((provincia, ciudad)*)>
<!ELEMENT provincia (codProv, nombreProv, capital, ciudades-en*)>
<!ATTLIST provincia idProv ID #REQUIRED>
<!ELEMENT codProv (#PCDATA)>
<!ELEMENT nombreprov (#PCDATA)>
<!ELEMENT capital EMPTY>
<!ATTLIST capital refCiudad IDREF #REQUIRED>
<!ELEMENT ciudades-en EMPTY>
<!ATTLIST ciudades-en refCiudad IDREF #REQUIRED>
<!ELEMENT ciudad (codCiudad, nombreCiudad,deprovincia)>
<!ATTLIST ciudad idCiudad ID #REQUIRED >
<!ELEMENT codCiudad (#PCDATA)>
<!ELEMENT nombreCiudad (#PCDATA)>
<!ELEMENT deprovincia EMPTY>
<!ATTLIST deprovincia refprov IDREF #REQUIRED> ]>
DTDs Recursivos
<DOCTYPE genealogía [
<!ELEMENT genealogía (persona*)>
<!ELEMENT persona (
nombre,
fechadeNac,
persona,
 la madre
persona )>  el Padre
...
]>
Cual es el problema con esto?
Cada persona
deberá tener
padre y madre.
Esto lleva a
tener infinitos
datos o a que
una persona sea
descendiente
de si mismo.
DTDs Recursivos, cont.
<DOCTYPE genealogía [
<!ELEMENT genealogía (persona*)>
<!ELEMENT persona (
nombre,
fechadeNac,
persona?,
 madre
persona? )>  Padre
...
]>
Que problema subsiste todavía?
No podemos distinguir
entre padre y madre.
Por ejemplo:
Si una persona tiene
solamente padre,
¿ como saber que se
trata del padre y no de
la madre?
Solución usando atributos ID e IDREF
<!DOCTYPE familia [
<!ELEMENT familia (persona)*>
<!ELEMENT persona (nombre)>
<!ELEMENT nombre (#PCDATA)>
<!ATTLIST persona id ID#REQUIRED
madre IDREF#IMPLIED
padre IDREF#IMPLIED
hijos IDREFS#IMPLIED>
]>
Este atributo es
opcional en el
elemento persona
Los IDREFs no tienen tipo
 Los atributos madre y padre son referencias a IDs de otros elementos
 Sin embargo no serán obligatoriamente elementos persona !
 El atributo madre no necesariamente será una referencia a una
persona del sexo femenino, y viceversa para el padre.
Datos XML compatibles con el DTD anterior
<familia>
<persona id=“lisa” madre=“marge” padre=“homero”>
<nombre> Lisa Simpson </nombre>
</persona>
<persona id=“bart” madre=“marge” padre=“homero”>
<nombre> Bart Simpson </nombre>
</persona>
<persona id=“marge” hijos=“bart lisa”>
<nombre> Marge Simpson </nombre>
</persona>
<persona id=“homero” hijos=“bart lisa”>
<nombre> Homero Simpson </nombre>
</persona>
</familia>
Una especificación alternativa para el DTD del
ejemplo anterior...
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE familia [
<!ELEMENT familia (persona)*>
<!ELEMENT persona (nombre, madre?, padre?, hijos?)>
<!ATTLIST persona id ID #REQUIRED>
<!ELEMENT nombre (#PCDATA)>
<!ELEMENT madre EMPTY>
<!ATTLIST madre m_idref IDREF #REQUIRED>
<!ELEMENT padre EMPTY>
<!ATTLIST padre p_idref IDREF #REQUIRED>
<!ELEMENT hijos EMPTY>
<!ATTLIST hijos h_idrefs IDREFS #REQUIRED>
]>
Datos XML compatibles con el DTD anterior
<familia>
<!ELEMENT persona (nombre, madre?, padre?, hijos?)>
……
<persona id="marge">
<nombre> Marge Simpson </nombre>
<hijos h_idrefs="bart lisa"/>
</persona>
<persona id="homero">
<nombre> Homero Simpson </nombre>
<hijos h_idrefs="bart lisa"/>
</persona>
<persona id="bart">
<nombre> Bart Simpson </nombre>
<madre m_idref="marge"/>
<padre p_idref="homero"/>
</persona>
<persona id="lisa">
<nombre> Lisa Simpson </nombre>
<madre m_idref="marge"/>
<padre p_idref="homero"/>
</persona>
</familia>
Limitaciones de los DTDs
 Tipos de elementos y atributos

Todos los valores son strings, no hay enteros, reales, etc.
 Dificultad para especificar conjuntos desordenados de
subelementos

(A | B)* permite especificar un conjunto desordenado, pero
No puede asegurar que cada A y B ocurra sólo una vez
 IDs e IDREFs son “untyped”

El atributo “propietario” de una cuenta puede contener una
referencia a otra cuenta, lo cual no tiene sentido
 El
atributo propietario debería estar restringido para
hacer referencia sólo a elementos cliente
Espacio de nombres
 Los datos XML tienen que ser intercambiados entre organizaciones
 Un mismo nombre de tag puede tener diferentes significados en diferentes
organizaciones, causando confusión sobre documentos intercambiados
 Especificar un string único como nombre de un elemento evita confusiones
 La mejor solución es usar nombre-único:nombre-de-elemento
 Se usa XML Namespaces (espacio de nombres)
 El espacio de nombres por defecto se declara con el atributo xmlns
 Los otros espacio de nombres son declarados con xmlns:<synonym>
o alias o
<banco Xmlns:FB=‘http://www.FirstBank.com’>
prefijo
…
<FB:sucursal>
<FB:nombresucursal>Downtown</FB:nombresucursal>
<FB:ciudadsucursal> Brooklyn </FB:ciudadsucursal>
</FB:sucursal>
…
</banco>
 Veamos esto en más detalle...
Espacio de nombres
Otro ejemplo de nombres que pueden generar confusión:
<?xml version=1.0" encoding="iso-8859-1"?>
<direccion>
<calle>Avd. Diagonal 8</calle>
<ciudad>Barcelona</ciudad>
<provincia>Barcelona</provincia>
<pais>España</pais>
</direccion>
<?xml version=1.0" encoding="iso-8859-1"?>
<servidor>
<url> http://www.palotes.com </url>
<direccion>123.45.67.8 </direccion>
</servidor>
Los dos documentos XML anteriores tienen en común el elemento direccion.
Son dos vocabularios diferentes pero puede ser que en algún momento
tengamos que integrarlos en un mismo documento XML.
Supongamos que juntos ambos documentos nos ofrecen información sobre la
localización de una empresa: su dirección física y su dirección en Internet.
Está claro que el elemento dirección va a provocar problemas.
Una posible solución es ponerlo de la siguiente manera:
Espacio de nombres
Ej: localización de una empresa con dirección física y dirección en Internet
<?xml version=1.0" encoding="iso-8859-1"?>
<empresa>
<nombre>Palotes S.A.</nombre>
<dirfis:direccion xmlns:dirfis="http://www.palotes.com/direccionfisica">
<dirfis:calle>Avd. Diagonal 8</dirfis:calle>
<dirfis:ciudad>Barcelona</dirfis:ciudad>
<dirfis:provincia>Barcelona</dirfis:provincia>
<dirfis:pais>España</dirfis:pais>
</dirfis:direccion>
<dirserv:servidor xmlns:dirserv="http://www.palotes.com/direccionservidor">
<dirserv:url>http://www.palotes.com</dirserv:url>
<dirserv:direccion>123.45.67.8</dirserv:direccion>
</dirserv:servidor></empresa>
Espacio de Nombres
Los espacios de nombres son una solución a los problemas de
homonímia. Permiten eliminar ambigüedades calificando los nombres
que se usan en los documentos XML.
Veamos un ejemplo en que, en un mismo documento, aparecerían
nombres idénticos (p.e. "capital"), para elementos diferentes:
<inversiones>
<pais nombre=“España”>
<capital> Madrid </capital>
<capital> 200000€ </capital>
</pais>
</inversiones>
capital de un pais y
capital de una transacción tienen
diferentes significados y espacios
semánticos (término geográfico vs.
término económico-financiero).
Los espacios de nombres permiten combinar en un mismo
documento varios vocabularios
Espacio de Nombres
Solucion1:
Recurrir a una autoridad mundial que asigne nombres…. complicado!!!!
Solucion2:
Otra solución es utilizar un mecanismo ya existente, por eso se pensó en
los URIs (Uniform Resource Identifiers), si bien un URI es una cadena
de caracteres que identifica unívocamente un recurso en una red o
sistema, aquí no se trata de utilizar un URI como enlace, ni tiene por
qué tener contenido, los URI sólo se utilizan para que el nombre
sea único. Ejemplo:“http://www.hipertexto.info”
 Aquí definimos un espacio de nombres XML como: una colección de
nombres, identificados por una referencia URI que se utiliza en los
documentos XML para identificar elementos y atributos.
 Para definir el espacio de nombres al que pertenece un elemento, es
necesario añadir un atributo a la definición de dicho elemento,
donde el nombre del atributo sea xmlns y el valor puede ser una
cadena cualquiera, aunque por convención suelen ser URLs.
Espacio de Nombres
Solucion2…
Asociamos entonces a cada etiqueta un espacio de nombres.
Para el ejemplo visto usaremos:
http://www.bolsa.com y http://www.geog.es
Asi, sin ambiguedades, el ejemplo queda:
Aquí no se usaron
alias o prefijos
...
<“http://www.bolsa.com”:inversiones xmlns=“http://www.bolsa.com”
xmlns=“http://www.geog.es”>
<“http://www.geog.es”:país http://www.geog.es”:nombre =“España”>
<“http://www.geog.es”:capital>Madrid</“http://www.geog.es”:capital>
<“http://www.bolsa.com”:capital>20000€ </“http://www.bolsa.com”:capital>
</“http://www.geog.es”:país>
...
</“http://www.bolsa.com”:inversiones>
Espacio de Nombres
Solucion3: para no escribir toda la URI, se usan alias o prefijos más cortos.
xmlns:alias define un alias en el ámbito de un elemento
Apliquemos esto al ejemplo:
Se pueden declarar varios
<bolsa:inversiones
xmlns:bolsa=“http://www.bolsa.com”
xmlns:geo=“http://www.geog.es”>
<geo:pais geo:nombre=“España”>
<geo:capital> Madrid </geo:capital>
<bolsa:capital> 200000 </bolsa:capital>
</geo:pais>
</bolsa:inversiones>
espacios de nombres como
atributos de un único elemento
(en este caso del elemento
inversiones)
bolsa y geo son
los alias usados
en este ejemplo
 El alcance de un prefijo de un espacio de nombres comprende desde la
etiqueta de inicio de un elemento XML, en la que se declara, hasta la
etiqueta final de dicho elemento XML.
Espacio de Nombres
Solucion3…
Idem anterior pero con asignación dinámica, esto es, se van asociando
espacios de nombre a los elementos según van apareciendo:
<bolsa:inversiones xmlns:bolsa=“http://www.bolsa.es”>
<geo:país xmlns:geo=“http://www.geog.com” geo:nombre=“España”>
<geo:capital>Madrid</geo:capital>
<bolsa:capital>2000€</bolsa:capital>
</geo:país>
...
</bolsa:inversiones
Espacio de Nombres
Variante de la solución 3: usar un espacio de nombres por defecto
No tiene prefijo
<inversiones xmlns=“http://www.bolsa.com” xmlns:geo=“http://www.geog.es”>
<geo:pais geo:nombre=“España”>
<geo:capital> Madrid </geo:capital>
<capital> 200000 </capital>
</geo:pais>
</inversiones>
En este caso las etiquetas sin prefijo corresponden al espacio de nombres
por defecto que es http://www.bolsa.com
Un espacio de nombres por defecto, definido en la etiqueta de inicio de un
elemento XML, se aplica a todos elementos sin prefijo del ámbito del
elemento, pero no a los atributos.
Espacio de Nombres
Resumiendo:
Los espacios de nombres se crearon para evitar las colisiones en los
diferentes módulos de software capaces de reconocer las marcaciones del
lenguaje XML.
También puede ocurrir que aunque los nombres en un documento sean
diferentes, el software que trabaja con ellos (por ejemplo un buscador)
necesite diferenciarlos claramente para darles un tratamiento diferente.
Los identificadores de los espacios de nombres no necesitan seguir las
convenciones de las direcciones de internet, aunque esto es
recomendable para reducir la posibilidad de que diferentes espacios de
nombres usen identificadores iguales.
Otra motivación para esta modularidad es que, si se dispone de un
conjunto de marcaciones, para el que ya existe software disponible, es
mejor la reutilización de estas marcaciones que inventar nuevas. Así, se
considera que las construcciones de ciertos documentos deben usar nombres
universales, cuyo ámbito se extienda más allá del propio documento.
Espacio de Nombres
Resumiendo…
Una de las pruebas del éxito del XML es la gran cantidad de vocabularios
XML (DTDs) que están apareciendo. En algunas ocasiones al realizar
nuestros documentos XML podemos encontrarnos en la necesidad de utilizar
varios de estos vocabularios.
Por ello, aunque un espacio de nombres XML no necesita que su
vocabulario esté definido, es una buena práctica usar un DTD o un
esquema XML para definir la estructura de datos en la ubicación URI del
espacio de nombres.
Por ejemplo, es posible que estemos escribendo un artículo científico en
formato XML y que tengamos la necesidad de incorporar fórmulas
matemáticas. Podemos perfectamente desarrollar nuestras propias etiquetas,
pero ¿por qué no utilizar las que nos proporciona el vocabulario MathML?
Espacios de Nombres y DTDs
Los espacios de nombre nacieron con posterioridad a los DTDs.
Por eso para validar un documento que usa espacio de nombres es
necesario definirlo en el DTD. Por ejemplo:
<!DOCTYPE inversiones [
<!ELEMENT inversiones (geo:país*)>
<!ELEMENT geo:país (geo:capital,capital) >
<!ELEMENT geo:capital (#PCDATA)>
<!ELEMENT capital (#PCDATA)>
<!ATTLIST inversiones
xmlns CDATA #FIXED "http://www.bolsa.es"
xmlns:geo CDATA #FIXED "http://www.geog.com">
<!ATTLIST geo:país
geo:nombre CDATA #REQUIRED >
Documento XML
]>
<inversiones xmlns=“http://www.bolsa.com” xmlns:geo=“http://www.geog.es”>
<geo:pais geo:nombre=“España”>
<geo:capital> Madrid </geo:capital>
<capital> 200000 </capital>
</geo:pais>
</inversiones>
XML Schema vs DTDs
 Un esquema XML es más sofisticado que un DTD y no tiene sus
limitaciones; soporta:

Built-in types
 E.g.
integer, string, etc.
 También
soporta restricciones de valores min/max

Tipos complejos definidos por el usuario, a partir de tipos simples

Un mismo elemento puede tener diferentes tipos dependiendo de
donde ese elemento se anida

Restricciones de unicidad y de clave foránea, herencia, etc.

A diferencia de los DTDs, los esquemas usan la misma sintaxis
de los documentos XML

Mecanismos para integrar espacios de nombres

Representación más standard pero más complicada
XML Schema vs DTDs
 Al igual que en un DTD, el propósito de un esquema XML es definir los
bloques de construcción válidos para un documento XML.
 Un esquema XML define:








Elementos que pueden aparecer en un documento
Atributos que pueden aparecer en un documento
Que elementos son hijos
El orden de los elementos hijo
El número de elementos hijo
Si un elemento es vacío o puede incluir texto
Tipos de datos para elementos y atributos
Valores por defecto y valores fijos para elementos y atributos
 Ventajas sobre los DTDs:





Los esquemas XML son más ricos y potentes que los DTDs
Los esquemas XML son escritos en XML
Los esquemas XML soportan tipos de datos
Los esquemas XML soportan espacios de nombres (namespaces)
Los esquemas XML son extensibles
● Se pueden crear nuevos tipos de datos, un esquema se puede reusar en otros
esquemas, se pueden referenciar múltiples esquemas en un documento, etc.
XML Schema: otras características...

Elementos y atributos son “tipados”

Elementos que contienen sub-elementos tienen tipo
complejo

Elementos con atributos tienen tipo complejo

Los atributos son de tipo simple

los tipos tienen nombre o pueden ser anónimos

Un esquema es definido en un documento esquema-XML
<?xml version="1.0"?>
<purchaseOrder orderDate=“2004-10-20">
<shipTo country="US">
<name>Alice Smith</name>
<street>123 Maple Street</street>
<city>Mill Valley</city>
documento para el
<state>CA</state>
<zip>90952</zip>
ejemplo “orden de compra”
“Cargar a cuenta de”
</shipTo>
en archivo ‘po.xml’
<billTo country="US">
<name>Robert Smith</name>
<street>8 Oak Avenue</street>
<city>Old Town</city>
<state>PA</state>
<zip>95819</zip>
</billTo>
<comment>Hurry, my lawn is going wild!</comment>
<items>
<item partNum="872-AA">
<productName>Lawnmower</productName>
<quantity>1</quantity>
<USPrice>148.95</USPrice>
<comment>Confirm this is electric</comment>
</item>
<item partNum="926-AA">
<productName>Baby Monitor</productName>
<quantity>1</quantity>
<USPrice>39.98</USPrice>
<shipDate>2004-12-21</shipDate>
</item>
</items>
</purchaseOrder>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation xml:lang="en">
(cualquier prefijo para el
Purchase order schema for Example.com.
espacio de nombres puede ser
Copyright 2000 Example.com All rights reserved.
usado)
</xsd:documentation>
</xsd:annotation>
<xsd:element name="purchaseOrder" type="PurchaseOrderType"/>
<xsd:element name="comment" type="xsd:string"/>
<xsd:complexType name="PurchaseOrderType">
<xsd:sequence>
<xsd:element name="shipTo" type="USAddress"/>
<xsd:element name="billTo" type="USAddress"/>
documento-esquema
<xsd:element ref="comment" minOccurs="0"/>
para el ej. anterior en
<xsd:element name="items" type="Items"/>
</xsd:sequence>
archivo ‘po.xsd’
<xsd:attribute name="orderDate" type="xsd:date"/>
Xml scheme document </xsd:complexType>
<xsd:complexType name="USAddress">
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element name="street" type="xsd:string"/>
<xsd:element name="city" type="xsd:string"/>
<xsd:element name="state" type="xsd:string"/>
<xsd:element name="zip" type="xsd:decimal"/>
</xsd:sequence>
<xsd:attribute name="country" type="xsd:NMTOKEN"/>
</xsd:complexType>
<xsd:complexType name="Items">
<xsd:sequence>
<xsd:element name=“Item" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="productName" type="xsd:string"/>
<xsd:element name="quantity">
<xsd:simpleType>
<xsd:restriction base="xsd:positiveInteger">
<xsd:maxExclusive value="100"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="USPrice" type="xsd:decimal"/>
<xsd:element ref="comment" minOccurs="0"/>
<xsd:element name="shipDate" type="xsd:date" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="partNum" type="SKU" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<!-- Stock Keeping Unit, a code for identifying products -->
<xsd:simpleType name="SKU">
<xsd:restriction base="xsd:string">
<xsd:pattern value="\d{3}-[A-Z]{2}"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
•espacio de nombres del esquema
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
•annotation... brinda información a lectores humanos:
<xsd:annotation>
<xsd:documentation xml:lang="en">
Purchase order schema for Example.com.
Copyright 2000 Example.com. All rights reserved.
</xsd:documentation>
</xsd:annotation>
• ejemplo de tipo complejo:
el tipo NMTOKEN sólo
puede contener letras,
<xsd:complexType name="USAddress">
dígitos, punto [ . ], guión [ - ],
<xsd:sequence>
subrayado [ _ ] y dos puntos
<xsd:element name="name" type="xsd:string"/>
[ : ] . Los del tipo
NMTOKENS pueden
<xsd:element name="street" type="xsd:string"/>
contener los mismos
<xsd:element name="city" type="xsd:string"/>
caracteres que NMTOKEN
<xsd:element name="state" type="xsd:string"/>
más espacios en blanco.
<xsd:element name="zip" type="xsd:decimal"/>
</xsd:sequence>
<xsd:attribute name="country" type="xsd:NMTOKEN"/>
</xsd:complexType>
Este es un elemento XML con 2 subelementos (sequence y attribute). Todos los elementos
en el documento que sean del tipo “USAddress” debe satisfacer esta declaración de tipo.
• deben tener 5 subelementos en el orden especificado
• deben tener un atributo ‘country’
Tipos simples (Built-in )
•XML simple types: “string”, “byte”, “integer”, “long”, “decimal”,
“float”, “double”, “boolean”, “dateTime”, “ID”, “IDREF”, “IDREFS”,
“anyType”, …
“anyType” es el tipo universal
• Restricciones sobre los tipos simples
<xsd:simpleType name="myInteger">
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="10000"/>
<xsd:maxInclusive value="99999"/>
</xsd:restriction>
</xsd:simpleType>
El elemento “simpleType” tiene un sub-elemento “restriction” con dos
subelementos llamados facetas o facets
<xsd:simpleType name="SKU">
<xsd:restriction base="xsd:string">
<xsd:pattern value="\d{3}-[A-Z]{2}"/>
</xsd:restriction>
</xsd:simpleType>
Ejemplo banco: datos XML
<banco>
<cuenta>
<número_cuenta> A-101 </número_cuenta>
<nombre_sucursal> caucete </nombre_sucursal>
<balance> 500 </balance>
</cuenta>
....
<cliente>
<nombre_cliente> Pérez </nombre_cliente>
<calle_cliente> el sauce 123 </calle_cliente>
<ciudad_cliente> angaco </ciudad_cliente>
</cliente>
....
<depositante>
<número_cuenta> A-101 </número_cuenta>
<nombre_cliente> Pérez </nombre_cliente>
</depositante>
....
</banco>
volver
Documento de un esquema XML: ejemplo “banco”
<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema>
<xs:element name=“banco” type=“TipoBanco”/>
<xs:element name=“cuenta”>
<xs:complexType>
<xs:sequence>
<xs:element name=“número_cuenta” type=“xs:string”/>
<xs:element name=“nombre_sucursal” type=“xs:string”/>
<xs:element name=“balance” type=“xs:decimal”/>
</xs:sequence>
</xs:complexType>
</xs:element>
….. falta definición de cliente y depositante ….
<xs:complexType name=“TipoBanco”>
<xs:sequence>
<xs:element ref=“cuenta” minOccurs=“0” maxOccurs=“unbounded”/>
<xs:element ref=“cliente” minOccurs=“0” maxOccurs=“unbounded”/>
<xs:element ref=“depositante” minOccurs=“0” maxOccurs=“unbounded”/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Documento de un esquema XML: ejemplo “banco”---
 elección del prefijo “xs:”  cualquier otro prefijo para el espacio
de nombres pudo ser elegido
 El elemento “banco” es del tipo “TipoBanco”, que es definido
separadamente

xs:complexType es usado después para crear el tipo complejo
“TipoBanco” (ver <xs:complexType name=“TipoBanco”>)
 El elemento “cuenta” tiene su tipo (complex) definido “en linea”
Mas características de XML Schema
 Etiqueta attribute: para especificar atributos

xsd:attribute name="country" type="xsd:NMTOKEN"/>
 Agregar “required” significa que un valor debe ser especificado.
 Restricción key: en el ejemplo banco, los “números de cuenta” son “la
clave” para identificar a los elementos cuenta:
<xs:key name = “clave_cuenta”>
<xs:selector xpath = “/banco/cuenta”/>
<xs:field xpath = “número_cuenta”/>
<\xs:key>
* Puedo hacer una restricción “clave_cliente” para usar nombre_cliente
como clave de cliente
 Restricción keyref: clave foránea para cuenta en depositante:
<xs:keyref name = “clave_depositacuenta” refer=“clave_cuenta”>
<xs:selector xpath = “/banco/depositante”/>
<xs:field xpath = “número_cuenta”/>
<\xs:keyref>
* Puedo hacer una restricción similar con refer=“clave_cliente” en la clave
foránea para cliente en depositante.
Consultas y Transformación de datos XML
 Traslación de información de un esquema XML a otro
 Consulta de datos XML (Querying)
 Los dos temas están relacionados y se manejan con las mismas
herramientas
 Lenguajes estandar de Consultas/Transformación de datos XML

XPath


XQuery


Lenguaje simple consistente en expresiones de camino
“XML query language” lenguaje de propósito general para XML
XSLT

Lenguaje diseñado para transformar documentos XML a XML
y XML a HTML
Árboles como modelo de datos XML
 Los lenguajes de consulta y transformación están basados en el
modelo árbol de datos XML
 Un documento XML es modelado como un árbol, con nodos
correspondiendo a elementos y atributos

Los nodos Elemento tienen hijos que pueden ser subelementos
o texto

El Texto en un elemento es modelado como un nodo hijo de
dicho elemento

Los hijos de un nodo están ordenados de acuerdo a su orden en
el documento XML

Los nodos Elemento y Atributo tienen como padre a otro nodo
Elemento (excepto por el nodo raíz)

El nodo raíz tiene un sólo hijo que es el elemento raíz del
documento
Raiz
Modelo de Datos
Estudiantes
Estudiante
Estudiante
Nombre
StudId
Npila
Curso
Apell
“dr ”
“Esp1”
Semestre
“Juan”
Tipos de Nodos
Documento
Elemento
Texto
atributo
“Perez”
Curso
“…”
CódigoCr
“…”
Semestre
“…”
CódigoCr
“…”
<Estudiantes>
<Estudiante StudId=“dr”>
<Nombre>
<Npila> Juan </Npila>
<Apell> Perez </Apell>
Raiz
</Nombre>
Esp1
Estudiantes
<Curso Semestre=“…” CódigoCr=“…”/>
<Curso Semestre=“…” CódigoCr=“…”/>
</Estudiante>
<Estudiante> …
</Estudiante>
Semestre
</Estudiantes>
XQuery
 Estandarizado por World Wide Web Consortium (W3C)

Tomado de un libro de texto del 2005. La versión final del estandar
puede diferir en algunos aspectos menores.
 XQuery se deriva del lenguaje Quilt, el cual a su vez toma características de
SQL, XQL and XML-QL
 XQuery usa la sintaxis:
for … let … where … order by …return …
for
 SQL from
where  SQL where
order by  SQL order by
F L W O R
(Se pronuncia flower)
return  SQL select
let permite el uso de variables temporales, y no tiene equivalente en SQL
Breve referencia a Xpath
Expresión:
coincide (matches) con:
bib
*
un elemento bib
cualquier elemento
/
el elemento raiz
/bib
un elemento bib bajo la raiz
bib/paper
un elemento paper en bib
bib//paper
un elemento paper en bib, a cq profundidad
//paper
un elemento paper a cq profundidad
paper|book
un elemento paper o un elemento book
@price
un atributo price
[email protected]
un atributo price en book, en bib
Sintaxis FLWOR en XQuery
 La cláusula For usa expresiones XPath, y la variable en la cláusula for
asume valores del conjunto retornado por XPath
 Expresiones simples en XQuery

Encontrar todas las cuentas con balance > 400, con cada resultado
encerrado entre etiquetas <account_number> .. </account_number>
for
$x in /banco/cuenta
let
$nucta:= $x [email protected]_cuenta
where $x /balance > 400
return <account_number> { $nucta } </account_number>

Los Items en la cláusula return son texto XML a menos que estén
encerrados entre { }, en cuyo caso son items evaluados
 La clausula Let no es realmente necesaria en esta consulta, que puede
hacerse en Xpath de la siguiente manera:
for $x in /banco/cuenta[balance>400]
return <número_cuenta> { [email protected]_cuenta } </número_cuenta>
XQuery : Constructores de elementos
 XQuery permite trabajar directamente con estructuras XML.
 Los constructores de elementos permiten embeber estructuras XML en la
programación con XQuery.
 Por ejemplo, lo siguiente es perfectamente válido en una expresión XQuery:
<bid>
<itemno>47</itemno>
<userid>tsmith</userid>
<bid_amount>34.25</bid_amount>
</bid>
 Sin embargo, para poder construir estructuras XML de manera dinámica es
necesario usar expresiones XQuery embebidas en el constructor de un
elemento, colocando dicha expresión entre llaves. Esta es la forma más
frecuente en que se usan los constructores de elementos en la cláusula
Return de una expresión FLWOR.
<bid>
<itemno>{ $i }</itemno>
<userid>{ $u }</userid>
<bid_amount>{ $a }</bid_amount>
</bid>
Cualquier expresión válida puede
ser embebida, lo que significa que
los constructores de elementos
pueden hacerse tan complejos
como se requiera.
Documento a ser consultado luego con Xquery:
<bib>
<book>
<publisher> Addison-Wesley </publisher>
<author> Serge Abiteboul </author>
<author>
<first-name> Rick </first-name>
<last-name> Hull </last-name>
</author>
<author> Victor Vianu </author>
<title> Foundations of Databases </title>
<year> 1995 </year>
</book>
<book price=“55”>
<publisher> Freeman </publisher>
<author> Jeffrey D. Ullman </author>
<title> Principles of Database and Knowledge Base Systems </title>
<year> 1998 </year>
</book>
</bib>
Buscar todos los títulos de libros y el año en que fueron publicados:
FOR $x IN doc("bib.xml")/bib/book
RETURN <libro>
<título>{ $x/title/text() } </título>
<año>{ $x/year/text() } </año>
</libro>
En Xquery se puede construir el resultado XML como se desee:
<libro>
<título> Foundations of Databases </título>
<año> 1995 </año>
</libro>
<libro>
<título> Principles of Database and Knowledge Base Systems </título>
<año> 1998 </año>
</libro>
.....
Xquery: Queries Anidados
 Para cada autor de un libro de la editorial Morgan Kaufmann, listar
todos los otros libros de ese autor:
FOR $b IN doc(“bib.xml”)/bib,
$a IN $b/book[publisher /text()=“Morgan Kaufmann”]/author
RETURN <resultado>
{ $a,
FOR $t IN $b/book[author/text()=$a/text()]/title
RETURN $t
}
</resultado>
XML
<resultado>
<author>Jones</author>
<title> abc </title>
<title> ...... </title>
</resultado>
<resultado>
<author> Smith </author>
<title> ghi </title>
</resultado>
Xquery: Queries Anidados
 El siguiente query convierte datos de la estructura chata de banco (donde
cuenta, cliente y depositante están al mismo “nivel”) a la estructura anidada
de banco-1 (ver diapositiva siguiente)
<banco-1> {
for $c in /banco/cliente
return
<cliente>
{ $c/* }
{ for $d in /banco/depositante[nombre_cliente = $c/nombre_cliente],
$a in /banco/cuenta[número_cuenta=$d/número_cuenta]
return $a }
</cliente>
} </banco-1>
 $c/* denota todos los hijos del nodo $c, sin etiquetas de nivel superior
 $c/text() da el contenido texto de un elemento sin etiquetas o subelementos
Ejemplo banco-1: datos XML con anidamiento
<banco-1>
<cliente>
<nombre_cliente> Huerta </nombre_cliente>
<domicilio_cliente> Piedras 2020 </domicilio_cliente>
<ciudad_cliente> San Juan </ciudad_cliente>
<cuenta>
<número_cuenta> A-102 </número_cuenta>
<nombre_sucursal> jachal </nombre_sucursal>
<balance> 400 </balance>
</cuenta>
<cuenta>
…
…
…
</cuenta>
</cliente>
...
...
</banco-1>
Xquery: Funciones de Agregación (Aggregate function)
 Toman una colección de valores y entregan un resultado escalar
Buscar todos los libros con más de 3 autores:
FOR $x IN doc("bib.xml")/bib/book
WHERE count($x/author)>3
RETURN $x
count = función para contar
avg = para calcular promedio
sum = para calcular la suma
distinct-values = para eliminar duplicados
for $a in distinct-values(doc("bib.xml")//author)
return <autor>{ $a }</autor>
Xquery: Funciones de Agregación
Buscar libros cuyos precios sean mayores que el promedio:
<respuesta>
{
for $b in doc("bib.xml")/bib
let $a := avg($b/book/price/text())
for $x in $b/book
where ($x/price/text() > $a)
return $x
}</respuesta>
LET liga una variable a un (1) valor;
FOR itera una variable sobre una lista de valores
Xquery: FOR v.s. LET
FOR $x IN /bib/book
RETURN <resultado> { $x } </resultado>
Liga con variables
nodo  iteración
<resultado> <book>...</book></resultado>
<resultado> <book>...</book></resultado>
<resultado> <book>...</book></resultado>
...
LET $x := /bib/book
RETURN <resultado> { $x } </resultado>
Liga con 1 variable
de colección
<resultado>
<book>...</book>
<book>...</book>
<book>...</book>
...
</resultado>
Xquery: Joins
 Los Joins son especificados de manera similar a SQL

Para el ejemplo banco, obtener información de clientes y sus cuentas
for $a in /banco/cuenta,
$c in /banco/cliente,
$d in /banco/depositante
where $a/número_cuenta = $d/número_cuenta
and $c/nombre_cliente = $d/nombre_cliente
return <cli_cuenta> { $c $a } </cli_cuenta>
 La misma consulta puede ser expresada con la restricción expresada
como en XPath:
for $a in /banco/cuenta,
$c in /banco/cliente,
$d in /banco/depositante[
número_cuenta = $a/número_cuenta and
Elem.de depositante
nombre_cliente = $c/nombre_cliente]
return <cli_cuenta> { $c $a } </cli_cuenta>
Ordenamiento en XQuery
 La cláusula order by puede ser usada al final de cualquier expresión. Por
ejemplo para retornar clientes ordenados por nombre
for $c in /banco/cliente
order by $c/nombre_cliente
return <cliente> { $c/* } </cliente>
Toda los datos XML de los clientes
ordenada por nombre de cliente
 Para ordenar en múltiples niveles (por ejemplo ordenar por nombre_cliente, y por
número_cuenta, dentro de cada cliente, al convertir datos de banco a banco-1)
<banco-1> {
for $c in /banco/cliente
order by $c/nombre_cliente
return
<cliente>
{ $c/* }
{ for $d in banco/depositante[nombre_cliente=$c/nombre_cliente],
$a in banco/cuenta[número_cuenta=$d/número_cuenta] }
order by $a/número_cuenta
return <cuenta> $a/* </cuenta>}
</cliente>
} </banco-1>
Funciones y otras características de XQuery
 Funciones definidas por el usuario con el sistema de tipos de XMLSchema
ejemplo: función que retorna los balances de las cuentas de un cliente
function balances(xs:string $c) returns list(xs:decimal*) {
for $d in /banco/depositante[nombre_cliente= $c],
$a in /banco/cuenta[numero_cuenta= $d/numero_cuenta]
return $a/balance
}
 Los tipos son opcionales para los parámetros y valores de retorno
 El * (como en decimal*) indica una secuencia de valores de ese tipo
 Cuantificador universal y existencial en predicados de la cláusula where

some $e in path satisfies P

every $e in path satisfies P
for $a in /banco-1/cliente
where some $c in $a/cuenta satisfies [balance>400]
return<cliente> $a </cliente>
 XQuery también soporta cláusulas If-then-else
SQL y XQuery “lado a lado”
Buscar todos los nombres de producto y precios, ordenados por precio:
Producto(idp, nombrep, fabricante, precio)
SELECT x.nombrep, x.precio
FROM Producto x
ORDER BY x.precio
SQL
XQuery
FOR $x in doc(“db.xml”)/db/Producto/row
ORDER BY $x/precio/text()
RETURN <resultado>
{ $x/nombrep, $x/precio }
</resultado>
Resultado XQuery para....
Buscar todos los nombres de producto y precios, ordenados por precio:
XQuery
FOR $x in doc(“db.xml”)/db/Producto/row
ORDER BY $x/precio/text()
RETURN <resultado>
{ $x/nombrep, $x/precio }
</resultado>
Notar que esto no es un
documento bien formado!
<resultado>
<nombrep> abc </nombrep>
<precio> 7 </precio>
</resultado>
<resultado>
<nombrep> def </nombrep>
<precio> 12 </precio>
</resultado>
....
Documento bien formado para el ejemplo anterior:
<miconsulta>
{ for $x in doc(“db.xml”)/db/Producto/row
order by $x/precio/text()
return <resultado>
{ $x/nombrep, $x/precio }
</resultado>
}
</miconsulta>
<miconsulta>
<resultado>
<nombrep> abc </nombrep>
<precio> 7 </precio>
</resultado>
<resultado>
<nombrep> def </nombrep>
<precio> 12 </precio>
</resultado>
....
</miconsulta>
SQL y XQuery “lado a lado”
Compañias con al menos 30 productos, y el precio promedio:
SELECT y.nombre, avg(x.precio)
FROM Producto x, Compañia y
WHERE x.fabricante=y.idc
GROUP BY y.idc
HAVING count(*) > 30
collection
element
FOR $r in doc(“db.xml”)/db,
$y in $r/Compañia/row
LET $p := $r/Producto/row[fabricante/text()=$y/idc/text()]
WHERE count($p) > 30
RETURN
<theCompany>
<companyName> {$y/nombre/text() }</companyName>
<avgPrice> avg($p/precio/text()) </avgPrice>
</theCompany>
Almacenamiento de datos XML
 Almacenes no relacionales

Archivos planos
 Es natural almacenar datos XML como un archivo plano (solo
texto, sin información sobre el tipo de letra, ni tamaños, formas etc.)
 Amplia disponibilidad de herramientas para el acceso y consulta a
archivos XML: puede ser suficiente para algunas aplicaciones.
 Presentan los problemas asociados a la gestión de ficheros: falta
de concurrencia, comprobaciones de integridad, atomicidad,
recuperación, seguridad …

Base de Datos XML (pocos sistemas a nivel comercial)
 Construidas específicamente para almacenar datos XML, soportan
consultas declarativas.
 Usan XML como Modelo de almacenamiento
 Definen un modelo de datos lógico como DOM (Document Object
Model) para la estructura jerárquica de los documentos xml.
 Se almacenan de alguna de las siguientes formas:
– Traduciendo el DOM a tablas relacionales
– Traduciendo el DOM a objetos en una BDOO
– Utilizando un almacén creado especialmente con esta finalidad.
 Bases de datos Relacionales

Los datos deben ser traducidos a la forma relacional
Almacenamiento de datos XML en BD Relacionales

Ventajas:
DBMSs maduros y ampliamente usados.
 Posibilidad de utilización desde aplicaciones
existentes.


Desventajas:
Sobrecarga
en la traducción de datos y en las consultas.
Si
XML no ha sido generado a partir de un esquema relacional,
la transformación no es tan sencilla. Se producen problemas en
la conversión, especialmente con:
– Elementos anidados
– Elementos que se repiten (atributos multivaluados)

Hay tres alternativas de almacenamiento:
Representación
de XML como String
 Representación de XML como árbol

Mapeo a relaciones
Almacenamiento de datos XML en BD Relacionales
Almacenamiento de XML como String
Se almacena cada elemento hijo del elemento de nivel superior como una
tupla aparte, con un campo de tipo string, de una única relación en la BD.
◦ Ejemplo: utilizar una única relación (ELEMENTOS) con un atributo
(datos), donde cada tupla almacena un elemento XML en forma de
cadena, sean esos elementos cuenta, cliente o depositante.
Mejoras:
◦ Almacenar cada elemento de nivel superior como una relación
separada.
Por ejemplo: Tres relaciones: cuenta, cliente, depositante.
Indexación:

Valores de subelementos/atributos se usan como campos de
indexación para construir índices


Ej. Nombre_cliente o número_cuenta
Añadir atributos a las relaciones para que identifiquen cada elemento.
Algunos sistemas de BD soportan funciones de índices, estos
sistemas usan el resultado de una función como valores de clave.
Representación String (Cont.)
 Beneficios:
◦ Pueden almacenarse datos XML aún sin DTD
◦ Si los elementos de nivel superior del documento tienen gran
número de hijos, los strings serán pequeños en comparación
al tamaño del documento
 Esto permite un acceso más rápido a los elementos
individuales.
 Inconvenientes:
◦ El SGBD NO conoce el esquema de los datos almacenados; por
tanto, no es posible consultar los datos directamente.
◦ Es necesario analizar las cadenas (parsing) para acceder a los
valores dentro de los elementos: el análisis es lento.
Representación árbol
 Representación árbol: se modelan los datos XML como un árbol y se
almacenan usando las relaciones:
nodos (id, tipo, etiqueta, valor)
hijo (id_hijo, id_padre)
cliente (id:2)
banco (id:1)
cuenta (id:5)
nombre_cliente (id:3)
número_cuenta (id:7)
◦ Se inserta una tupla en la relación nodos para cada elemento y atributo,
con los campos:
Id: identificador del elemento o atributo
Tipo: especifica si se trata de un elemento o atributo
Etiqueta: nombre de la etiqueta del elemento o nombre del atributo
Valor: es el valor literal (valor texto) del elemento o atributo
◦ La relación hijo almacena el elemento padre de cada elemento o atributo.
Se puede agregar en hijo un atributo más (posición), con el orden de cada hijo
Representación árbol (Cont.)
 Beneficio: Pueden almacenarse datos XML aún sin DTD
 Inconvenientes:

Los Datos son fraccionados en muchas piezas,
incrementando la sobrecarga de espacio.

Aún las consultas simples requieren un gran número de
joins, lo cual puede resultar muy lento.
Mapeo de datos XML a Relaciones
 Se crea una relación para cada tipo de elemento cuyo esquema sea
conocido. En la relación se guarda:

Un atributo id para almacenar un id único para cada elemento
 Todos los atributos del elemento se convierten en atributos de su
relación.

Todos los subelementos que se producen una sola vez se convierten
en atributos de la relación:
 Si el valor del subelemento es texto, es almacenado como valor del
atributo en la relación.
 Para subelementos complejos, se almacena el id del subelemento,
y el subelemento se almacena en una relación aparte.

Si el subelemento puede aparecer varias veces en el elemento, será
representado en una tabla separada:
 Similar a la forma en que se manejan los atributos multivaluados
cuando se convierte un diagrama E-R a tablas.

Un atributo id_padre para mantener el camino al elemento padre
 Información de posición (ith hijo) puede ser almacenada también
Mapeo de datos XML a Relaciones...
 Beneficios:

Almacenamiento eficiente.

Poder realizar consultas en SQL, de manera eficiente, y después
trasladar los resultados de SQL de vuelta a XML.
 Inconvenientes:

Se necesita conocer DTD o esquema XML.

Las sobrecargas por transformación continúan presentes.
Procesos de conversión de datos XML a relaciones y viceversa
 Publishing: proceso de convertir datos relacionales al formato XML
 Shredding: proceso de convertir un documento XML en un conjunto de
tuplas a ser insertadas en una o más relaciones.
 Existen DBMSs que brindan publishing and shredding automatizado
 Algunos sistemas ofrecen almacenamiento nativo de datos XML y
agregan estructuras internas “especiales” de datos e índices para
mejorar la eficiencia.
Representación en BD relacional
Una BD relacional de una escuela:
grade point average
student:
id
name
gpa
001
002
…
Joe
Mary
…
3.0
4.0
…
enroll:
(inscripto)
id
cno
001
001
002
…
331
350
331
…
course:
cno
title
credit
331
350
…
DB
Web
…
3.0
3.0
…
Representación XML
<school>
grade point average
<student id=“001”>
<name> Joe </name> <gpa> 3.0 </gpa>
</student>
<student id=“002”>
<name> Mary </name> <gpa> 4.0 </gpa>
</student>
<course cno=“331”>
<title> DB </title> <credit> 3.0 </credit>
</course>
<course cno=“350”>
<title> Web </title> <credit> 3.0 </credit>
</course>
inscripto
<enroll>
<id> 001 </id> <cno> 331 </cno>
</enroll>
<enroll>
<id> 001 </id> <cno> 350 </cno>
</enroll>
<enroll>
<id> 002 </id> <cno> 331 </cno>
</enroll>
</school>
XSLT
 Un stylesheet guarda opciones de formato para un documento,
usulmente en forma separada del documento

Ej. Una hoja de estilo HTML puede especificar color de la fuente y
tamaño para encabezados, etc.
 El XML Stylesheet Language (XSL) fue diseñado originalmente para
generar HTML desde XML
 XSLT es un lenguaje de transformación de propósito general

Puede transformar XML a XML, y XML a HTML
 Las transformaciones XSLT son expresadas usando reglas llamadas
templates (plantillas)

Los Templates combinan selección usando XPath con
construcción de resultados
XSLT Templates
 Ejemplo de plantillas XSLT con match y select
<xsl:template match=“/banco-2/cliente”>
<xsl:value-of select=“nombre_cliente”/>
</xsl:template>
<xsl:template match=“*”/>
 El atributo de match de xsl:template specifica un patrón XPath
 Los elementos del documento XML que “hagan match” con el patrón son
procesados con las acciones definidas dentro del elemento xsl:template
xsl:value-of selecciona valores de salida (en este caso nombre_cliente)
 Para los elementos que no coinciden con ninguna plantilla


El contenido (Atributos y texto) son emitidos como son
Los Templates son aplicados recursivamente a los subelementos
 La plantilla <xsl:template match=“*”/> hará match con todos los elementos
que no coincidan con ninguna otra plantilla
 Cuando se usa, esos elementos no generan ninguna salida.
 Si un elemento “hace match” con varias plantillas, sólo una de ellas es
usada en base a un esquema de prioridad definido por el usuario
Creando salidas XML
 Cualquier texto o etiqueta en XSL stylesheet que no esté en el
xsl namespace va a la salida tal cual es
 Ej. Envolver resultados en nuevos elementos XML.
<xsl:template match=“/banco-2/cliente”>
<cliente>
<xsl:value-of select=“nombre_cliente”/>
</cliente>
</xsl:template>
<xsl:template match=“*”/>

Salida:
<cliente> Pepe </cliente>
<cliente> Mary </cliente>
Creando salidas XML (Cont.)
 Nota: No se puede usar xsl:value-of tag dentro de otra etiqueta

Ej. No se puede crear un atributo para <cliente> en el ejemplo previo
usando directamente xsl:value-of...

XSLT provee una construcción xsl:attribute para manejar esta
situación

xsl:attribute agrega un atributo al elemento precedente

Ej. <cliente>
<xsl:attribute name=“id_cliente=”>
<xsl:value-of select = “id_cliente”/>
</xsl:attribute>
</cliente>
esto resulta en una salida de la forma
<cliente id_cliente=“….”> ….
 xsl:element es usado para crear elementos de salida con nombres
computados
Descargar

Module 1: Introduction