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 attType Const >

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 Un círculo doble denota un estado admisible nombre dir email

nombre,dir*,(tel | fax)*,email* Otro ejemplo nombre,dir*,(tel | fax)*,email* nombre dir tel 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 <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> <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> <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> (321) 786 2544 </tel> <email> jp@tutopia.com </email> </persona> Teléfonos y faxes mezclados Tantas como se necesiten Tantas líneas de dirección como sean necesarias A lo sumo una presentación Exactamente un nombre

El resto del documento XML para libreta de direcciones es: <libreta-direcciones> <persona> <nombre> Juan Perez </nombre> <presentación> Ing. J. Perez </presentación> …. <email> jp@tutopia.com </email> </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*

Definición de contenido mixto (mixed content ) Se describe mediante un grupo OR repetible (#PCDATA | nombre-de –elemento | …)* Dentro del grupo no hay expresiones regulares, sólo nombres de elementos #PCDATA debe ir primero seguido de 0 o más nombres de elementos, separados por | El grupo puede ser repetido 0 o más veces volver

Documento XML con DTD interno para libreta de direcciones “Interno” significa que el DTD y el documento XML están en el mismo archivo <?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 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) es un formato de codificación de caracteres Unicode de longitud variable

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 #FIXED “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 Ejemplos <!ATTLIST cuenta tipodecuenta CDATA “checking”> <!ATTLIST cliente id_cliente ID #REQUIRED cuentas IDREFS#REQUIRED> elemento valor x defecto tipo atributo

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 <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> </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> … </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 idrefCiudad IDREF #REQUIRED> <!ELEMENT ciudades-en EMPTY> <!ATTLIST ciudades-en idrefCiudad IDREF #REQUIRED> <!ELEMENT ciudad (codCiudad, nombreCiudad,deprovincia)> <!ATTLIST ciudad idCiudad ID #REQUIRED > <!ELEMENT codCiudad (#PCDATA)> <!ELEMENT nombreCiudad (#PCDATA)> <!ELEMENT deprovincia EMPTY> <!ATTLIST deprovincia idrefprov 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> ]> 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 id=“marge” hijos=“bart lisa”> <nombre> Marge Simpson </nombre> <persona id=“homero” hijos=“bart lisa”> <nombre> Homero Simpson </nombre> </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 <!ELEMENT persona (nombre, madre?, padre?, hijos?)> …… <familia> <persona id="marge"> <nombre> Marge Simpson </nombre> <hijos h_idrefs="bart lisa"/> </persona> <persona id="homero"> <nombre> Homero Simpson </nombre> <persona id="bart"> <nombre> Bart Simpson </nombre> <madre m_idref="marge"/> <padre p_idref="homero"/> <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: 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> <banco Xmlns:FB=‘http://www.FirstBank.com’> … <FB:sucursal> <FB:nombresucursal>Downtown</FB:nombresucursal> <FB:ciudadsucursal> Brooklyn </FB:ciudadsucursal> </FB:sucursal> … </banco> Veamos esto en más detalle... o alias o prefijo

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> <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 <?xml version=1.0" encoding="iso-8859-1"?> 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> Los espacios de nombres permiten combinar en un mismo documento varios vocabularios 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).

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: . . . <“http://www.bolsa.es”:inversiones xmlns=“http://www.bolsa.com” xmlns=“http://www.geog.es”> <“http://www.geog.com”:país http://www.geog.com”:nombre =“España”> <“http://www.geog.com”:capital>Madrid</“http://www.geog.com”:capital> <“http://www.bolsa.es”:capital>20000€ </“http://www.bolsa.es”:capital> </“http://www.geog.com”:país> </“http://www.bolsa.es”:inversiones> Aquí no se usaron alias o prefijos

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: <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> 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. Se pueden declarar varios 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

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 <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. No tiene prefijo

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 > ]> <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> Documento XML

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

ejemplo “orden de compra” en archivo ‘po.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> <state>CA</state> <zip>90952</zip> </shipTo> <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> <USPrice>39.98</USPrice> <shipDate>2004-12-21</shipDate> </items> </purchaseOrder> documento para el ejemplo “orden de compra” en archivo ‘po.xml’

(cualquier otro prefijo para el espacio de nombres puede ser usado) <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:annotation> <xsd:documentation xml:lang="en"> Purchase order schema for Example.com. Copyright 2000 Example.com. All rights reserved. </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"/> <xsd:element ref="comment" minOccurs="0"/> <xsd:element name="items" type="Items"/> </xsd:sequence> <xsd:attribute name="orderDate" type="xsd:date"/> </xsd:complexType> <xsd:complexType name="USAddress"> <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:attribute name="country" type="xsd:NMTOKEN"/> (cualquier otro prefijo para el espacio de nombres puede ser usado) documento-esquema para el ejemplo anterios en archivo ‘po.xsd’ xmlschemedocument

<xsd:complexType name="Items"> <xsd:sequence> <xsd:element name=“Item" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <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> <!-- 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:schema>

ejemplo de tipo complejo: 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: <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> 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’ el tipo NMTOKEN sólo puede contener letras, dígitos, punto [ . ], guión [ - ], subrayado [ _ ] y dos puntos [ : ] . Los del tipo NMTOKENS pueden contener los mismos caracteres que NMTOKEN más espacios en blanco.

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}"/>

Ejemplo banco: datos XML <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> <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: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 Lenguaje simple consistente en expresiones de camino XQuery “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 atributos o subelementos 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

Modelo de Datos Tipos de Nodos Documento Elemento Texto atributo Raiz Estudiantes Curso Estudiante Nombre Npila Apell StudId CódigoCr “dr ” “Juan” “Perez” “Esp1” Semestre CódigoCr “…” “…” “…” “…” <Estudiantes> <Estudiante StudId=“dr”> <Nombre> <Npila> Juan </Npila> <Apell> Perez </Apell> </Nombre> Esp1 <Curso Semestre=“…” CódigoCr=“…”/> </Estudiante> <Estudiante> … </Estudiantes> Tipos de Nodos Documento Elemento Texto atributo Raiz Estudiantes Semestre

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 return  SQL select let permite el uso de variables temporales, y no tiene equivalente en SQL F L W O R (Se pronuncia flower)

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 bib/book/@price 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 /@numero_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> { $x/@numero_cuenta } </número_cuenta>

XQuery : Constructores de elementos XQuery permite trabajar directamente con estructuras XML. Los constructores de elementos permiten embeber estructuras XML directamente 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. <itemno>{ $i }</itemno> <userid>{ $u }</userid> <bid_amount>{ $a }</bid_amount> Cualquier expresión XQuery 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>

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> ..... Buscar todos los títulos de libros y el año en que fueron publicados:

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> <resultado> <author>Jones</author> <title> abc </title> <title> ...... </title> </resultado> <author> Smith </author> <title> ghi </title> XML

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> … </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

RETURN <resultado> { $x } </resultado> Xquery: FOR v.s. LET FOR $x IN /bib/book RETURN <resultado> { $x } </resultado> Liga con variables nodo  iteración <resultado> <book>...</book></resultado> ... LET $x := /bib/book RETURN <resultado> { $x } </resultado> Liga con 1 variable de colección <resultado> <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 nombre_cliente = $c/nombre_cliente] Elem.de depositante

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> 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> Toda los datos XML de los clientes ordenada por nombre de cliente

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 XQuery también soporta cláusulas If-then-else for $a in /banco-1/cliente where some $c in $a/cuenta satisfies [balance>400] return<cliente> $a </cliente>

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 FOR $x in doc(“db.xml”)/db/Producto/row ORDER BY $x/precio/text() RETURN <resultado> { $x/nombrep, $x/precio } </resultado> XQuery

Resultado XQuery para.... Buscar todos los nombres de producto y precios, ordenados por precio: FOR $x in doc(“db.xml”)/db/Producto/row ORDER BY $x/precio/text() RETURN <resultado> { $x/nombrep, $x/precio } </resultado> XQuery <resultado> <nombrep> abc </nombrep> <precio> 7 </precio> </resultado> <resultado> <nombrep> def </nombrep> <precio> 12 </precio> </resultado> . . . . Notar que esto no es un documento bien formado!

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.idce HAVING count(*) > 30 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> collection element

Almacenamiento de datos XML Almacenes no relacionales Archivos planos Dado que XML es un formato de archivo, es natural almacenar datos XML como un archivo plano. 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) 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 se genera 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 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) ◦ 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: con nombre de la etiqueta del elemento o el 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 un atributo más (posición) a hijo, con el orden de cada hijo banco (id:1) cliente (id:2) cuenta (id: 5) nombre_cliente (id:3) número_cuenta (id:7) Nota la

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: student: course: enroll: (inscripto) grade point average

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> <course cno=“331”> <title> DB </title> <credit> 3.0 </credit> </course> <course cno=“350”> <title> Web </title> <credit> 3.0 </credit> <enroll> <id> 001 </id> <cno> 331 </cno> </enroll> <id> 001 </id> <cno> 350 </cno> <id> 002 </id> <cno> 331 </cno> </school> grade point average inscripto

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 <xsl:value-of select=“nombre_cliente”/> 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