XMLy BD

XML y las BD
Fundamentos de bases de datos, 4ª Edición

Silberschatz, Korth y Sudarshan
Capitulo 10
Mc Graw-Hill
Introducción
XML (eXtensible Markup Language), al igual que HTML
(HyperText Markup Language), tiene su origen en la gestión de
documentos (NO se concibió como tecnología de BD).
Ambos lenguajes derivan del SGML (Standard Generalized
Markup Language), lenguaje para estructurar documentos
grandes.
XML permita la representación de datos estructurados (BD) o
semi-estructurados (aplicaciones de negocios).
Útil como formato de datos cuando las aplicaciones necesitan
comunicarse y facilita la integración de información procedente
de varias aplicaciones.
¿Cómo organizar, manipular, gestionar y consultar datos XML?
©Silberschatz et al. ©Grupo Kybele

Fundamentos de bases de datos 2
Índice de contenidos
1. Motivación: ¿Por qué XML?

2. Estructura de los Datos XML
2.1. DTDs
2.2. Esquemas XML
3. Almacenamiento de Datos XML
4. Consulta a Documentos XML
5. La Interfaz de Programación de Aplicaciones
6. Aplicaciones

1
XML (eXtensible Markup Language): Lenguaje de marcas extensible

Versión actual: 1.0 (tercera edición) 4 de febrero de 2004
Definido por el Consorcio WWW (W3C) http://www.w3.org/XML/
En sus orígenes proyectado como un lenguaje de marcas de
documentos, no como un lenguaje de bases de datos.
Marca: elemento de un documento que no formará parte de la salida
impresa (p. ej.: notas de un escritor para una revista ”no romper párrafo” ).
Lenguaje de marcas: descripción formal de qué parte del documento es
contenido, qué parte es marca y significado de la marca.
Los documentos tienen etiquetas que dan información adicional sobre
secciones del documento (en XML no están preescritas).
Por ejemplo <title>XML y las BD</title> <slide>1. Motivación …</slide>
Derivado de SGML (Lenguaje estándar generalizado de marcas), pero
más sencillo de utilizar que SGML.


Permite separar la especificación del contenido de la de su visualización.
XML, a diferencia de HTML, es un metalenguaje Extensible
Se pueden añadir nuevas etiquetas.
El objetivo era (¿es?) sustituir a HTML como lenguaje para la publicación
de documentos en la Web.
La capacidad para especificar etiquetas nuevas, y para crear estructuras

de etiquetas anidadas hace de XML una buena forma de intercambiar
datos, y no sólo documentos.
El uso mayor de XML ha estado en las aplicaciones de intercambio de
datos, y no en una sustitución de HTML.
HTML se usa principalmente para el formato de documentos.


Ejemplo: Aplicación bancaria
<banco>
<cuenta>
<número-cuenta> C-101</número-cuenta>
<nombre-sucursal>Centro </nombre-sucursal>
<saldo>500</saldo>
</cuenta>
<impositor>
<número-cuenta>C-101</número-cuenta>
<nombre-cliente>González</nombre-cliente>
</impositor>
</banco>
Las etiquetas:
Proporcionan el contexto de cada valor
Permiten especificar la semántica del valor
2
El intercambio de datos es crítico en el mundo de Internet hoy en
día
Ejemplos:
Banca: transferencias de fondos
Procesamiento de órdenes (especialmente las órdenes entre
compañías)
Datos científicos
– Química: ChemML (Lenguaje de marcas químicas), ...
– Genética: BSML (Lenguaje de marcas de bio-secuencias), …
El flujo de documentos entre organizaciones se ha sustituido por el flujo
electrónico de información.
Cada área de aplicación tiene su propio conjunto de estándares para
representar la información.
XML base de todos los formatos de intercambio de

datos de nueva generación

Desventajas para el almacenamiento de los datos:
Poca eficiencia de la representación XML: las etiquetas se
repiten por todo el documento (REDUNDANCIA).
Ventajas para el intercambio de datos:

Las etiquetas hacen que los datos estén autodocumentados:
No hay que leer el esquema para entender el significado del texto
Formato no rígido:
Si un remitente agrega información adicional, el receptor puede ignorarla
La facilidad de reconocer e ignorar etiquetas facilita la evolución
Permite evolucionar los datos sin invalidar las aplicaciones
Existe una amplia variedad de herramientas disponibles para
analizar, rastrear y consultar los documentos/datos de XML:
Incluidas herramientas de BD


2.1. DTDs
2.2. Esquemas XML
6. Aplicaciones

3
Etiqueta: marca de una sección de datos
Marca: elemento que no formará parte de la salida impresa
Elemento:
Constructor básico de un documento XML.
Sección de datos que comienza con <nombredeetiqueta> y termina
con la coincidencia </nombredeetiqueta>, incluyendo el texto que
aparece entre las dos etiquetas.
Cada documento debe tener un único elemento de raíz.
Los elementos deben estar anidados adecuadamente.
Contexto de un elemento: texto incluido entre la etiqueta de
comienzo y la etiqueta de fin de dicho elemento.
Etiquetas anidadas adecuadamente: si toda etiqueta de inicio tiene
una única etiqueta de fin en el contexto del mismo elemento padre.
Anidamiento adecuado: <cuenta> … <saldo> …. </saldo> </cuenta>
Anidamiento inadecuado: <cuenta> … <saldo> …. </cuenta> </saldo>

Se permite la combinación de texto con subelementos

Ejemplo:
<cuenta>
Esta cuenta se usa muy rara vez, por no decir nunca.
<número-cuenta> C-102 </número-cuenta>
<nombre-sucursal> Navacerrada </nombre-sucursal>
<saldo> 400 </saldo>
</cuenta>
Útil para marcar documentos, pero no recomendada para la

representación de datos estructurados.


Ejemplo de anidamiento
<banco-1>
<cliente>
<nombre-cliente>Federico</nombre-cliente>
<calle-cliente> Arenal</calle-cliente>
<ciudad-cliente>La Granja</ciudad-cliente>
<cuenta>
<saldo>400</saldo>
</cuenta>
<cuenta>….</cuenta>
</cliente>
<cliente>
Problema:
<nombre-cliente>Federica</nombre-cliente>
<calle-cliente> Arenal</calle-cliente> Redundancia
<ciudad-cliente>La Granja</ciudad-cliente>
<cuenta>
<saldo>400</saldo>
</cuenta>
</cliente>
….
</banco-1>

4
El anidamiento de datos es útil en las aplicaciones de
transferencia de datos: evitan la necesidad de joins.
Ejemplo: los elementos que representan la cuenta (número-cuenta,
nombre-sucursal, saldo), anidados en cada cliente de la cuenta.
No se soporta la anidación en las BD relacionales:
Con varios clientes titulares de una cuenta, se almacenarían
repetidamente los datos de la cuenta.
La normalización sustituye las estructuras anidadas: en cada cliente
se incluye una clave ajena a la tabla que almacena las datos de la
cuenta.
Se soporta anidación en BD Objeto-Relacionales (Nested Tables).
La anidación sólo es apropiada cuando se transfieren datos:
La aplicación externa no tiene acceso directo a los datos
referenciados por una clave ajena.


Los elementos pueden tener atributos.
Los atributos son cadenas, no contienen marcas.
Se especifican por medio de pares nombre=valor dentro de la
etiqueta de inicio de un elemento:
<cuenta tipo-cuenta = “corriente” >
<número-cuenta> C-102 </número-cuenta>
<nombre-sucursal>Navacerrada</nombre-sucursal>
<saldo> 400 </saldo>
</cuenta>
Un elemento puede tener varios atributos, pero cada nombre de

atributo sólo puede producirse una vez:
<cuenta tipo-cuenta = “corriente” cuota mensual=“5”>

Distinción entre subelemento y atributo

En el contexto de los documentos, los atributos son texto
que no aparecen en el documento impreso o visualizado
(forman parte de las marcas y no del contenido). Los
subelementos son parte del contenido del documento.
En el contexto de la representación de datos (BD e
intercambio de datos), la diferencia es menos relevante. La
misma información se puede representar de dos maneras; y
la elección de utilizar una u otra es frecuentemente arbitraria:
– <cuenta número-cuenta = “C-101”> …. </cuenta>
– <cuenta>
<número-cuenta>C-101</número-cuenta> …
</cuenta>
Cuidado en el caso de atributos multivaluados:
subelementos!!!

5
Los elementos sin subelementos o contenido de texto

se pueden abreviar finalizando la etiqueta de inicio con un
/> y borrando la etiqueta final:
<número cuenta=“C-101” sucursal=“Navacerrada” saldo=“200 />
Los elementos abreviados sí pueden contener atributos.
Para almacenar datos de cadenas que pueden contener

etiquetas, sin que dichas etiquetas se interpreten como
subelementos, utilizar CDATA como se puede ver a
continuación:
<![CDATA[<cuenta> … </cuenta>]]>
Aquí, <cuenta> y </cuenta> se tratan como simples cadenas.


Los datos XML se pueden que intercambiar entre organizaciones.
El mismo nombre de etiqueta puede tener diferentes significados
en diferentes organizaciones.
SOLUCIÓN: especificar una cadena única como un nombre
global de elementos: anteponer a cada etiqueta o atributo un
identificador de recursos universal:
nombre-único:nombre-elemento
Para evitar utilizar nombres únicos largos se definen abreviaturas
en el espacio de nombres (namespace) estándar.
<banco Xmlns:FB=‘http://www.BancoPrincipal.com’>
…
<FB:sucursal>
<FB:nombresucursal>Centro</FB:nombresucursal>
<FB:ciudadsucursal> Brooklyn</FB:ciudadsucursal>
</FB:sucursal>
…
</banco>

Los esquemas de las bases de datos restringen qué
información se puede almacenar, y los tipos de datos de los
valores almacenados.
Los documentos XML no precisan tener un esquema asociado.
Sin embargo, los esquemas son muy importantes para el
intercambio de datos XML.
De lo contrario, un sitio no puede interpretar automáticamente los
datos recibidos de otro sitio.
Dos mecanismos para especificar el esquema XML
Document Type Definition (DTD) (Definición de Tipos de
Documento)
Ampliamente utilizado
Parte del estándar XML
Esquema XML
Más novedoso, no utilizado aún extensamente
6

2.1. DTDs
2.2. Esquemas XML
6. Aplicaciones

2.1. Estructura de los Datos XML: DTDs
El tipo de un documento XML se puede especificar utilizando

una DTD; la DTD es opcional
DTD restringe la estructura de los datos de XML
Qué elementos pueden producirse
Qué atributos puede/debe tener un elemento
Qué subelementos pueden/deben producirse dentro de cada
elemento, y cuántas veces.
DTD no restringe los tipos de datos
Todos los valores se representan como cadenas de XML
Sintaxis de DTD
<!ELEMENT elemento (especificación-subelementos) >
<!ATTLIST elemento (atributos) > orden irrelevante

2.1. DTD: ELEMENTOS

Los subelementos pueden especificarse como:
Nombres de elementos, o
#PCDATA (datos de caracteres analizados): cadenas de caracteres
EMPTY (sin subelementos) o ANY (cualquiera, no hay restricción sobre los
subelementos del elemento)
Ejemplo
<! ELEMENT impositor (nombre-cliente número-cuenta)>
<! ELEMENT nombre-cliente(#PCDATA)>
<! ELEMENT número-cuenta (#PCDATA)>
La especificación de subelementos puede tener expresiones regulares
<!ELEMENT banco ( ( cuenta | cliente | impositor)+)>
Notación:
– “|” - alternativas
– “+” - 1 ó más casos
– “*” - 0 ó más casos
– “?” - 0 ó 1 caso
7
2.1. DTD: ELEMENTOS
<!DOCTYPE banco [
<!ELEMENT banco ( ( cuenta | cliente | impositor)+)>
<!ELEMENT cuenta (número-cuenta, nombre-sucursal, saldo)>
<! ELEMENT cliente (nombre-cliente, calle-cliente, ciudad-cliente)>
<! ELEMENT impositor (nombre-cliente, número-cuenta)>
<! ELEMENT número-cuenta (#PCDATA)>
<! ELEMENT nombre-sucursal (#PCDATA)>
<! ELEMENT saldo (#PCDATA)>
<! ELEMENT nombre-cliente (#PCDATA)>
<! ELEMENT calle-cliente (#PCDATA)>
<! ELEMENT ciudad-cliente (#PCDATA)>]>
<banco>
<cuenta>
<número-cuenta> C-101</número-cuenta>
<nombre-sucursal>Centro </nombre-sucursal>
<saldo>500</saldo>
</cuenta>
<impositor>
<nombre-cliente>González</nombre-cliente>
</impositor>
</banco>
2.1. DTD: ATRIBUTOS

Especificación de atributos: <!ATTLIST elemento lista_atributos>
Para cada atributo:
Nombre
Tipo de atributo
CDATA datos de tipo carácter
ID (identificador) o IDREF (referencia a ID) o IDREFS (múltiples IDREF)
Si
es obligatorio (#REQUIRED),
tiene un valor por defecto (valor),
o no se ha especificado ningún valor predeterminado (#IMPLIED)
Ejemplos
<!ATTLIST cuenta tipo-cuenta CDATA “cuenta corriente”>
<!ATTLIST cliente
cliente-id ID #REQUIRED
cuentas IDREFS #REQUIRED >

2.1. DTD: ID e IDREF
Un elemento puede tener a lo sumo un atributo de tipo ID.

El valor del atributo ID de cada elemento de un documento XML
debe ser distinto.
Así el valor del atributo ID es un identificador del objeto.
Un atributo de tipo IDREF debe contener el valor ID de un
elemento en el mismo documento.
Un atributo de tipo IDREFS contiene un conjunto de (0 o más)
valores ID separados por espacios. Cada valor ID debe contener
el valor ID de un elemento del mismo documento.
ID e IDREF Similares a los mecanismos de referencia

(OIDs y REFs) de las BDOO y BDOR

8
DTD de banco con tipos de atributos ID e IDREF
<!DOCTYPE banco-2[
<!ELEMENT cuenta (sucursal, saldo)>
<!ATTLIST cuenta
número-cuenta ID # REQUIRED
tenedores IDREFS # REQUIRED>
<!ELEMENT cliente (nombre-cliente, calle-cliente, ciudad-cliente)>
<!ATTLIST cliente
cliente-id ID # REQUIRED
cuentas IDREFS # REQUIRED>
… declaraciones para sucursal, saldo, nombre-cliente,
calle-cliente y ciudad-cliente
]>


Documento XML con atributos ID y IDREF
<banco->
<cuenta número-cuenta=“C-401” tenedores=“C100 C102”>
<sucursal> Centro </sucursal>
<saldo>500 </saldo>
</cuenta>
<cliente cliente-id=“C100” cuentas=“C-401”>
<nombre-cliente>Juncal</nombre-cliente>
<calle-cliente>Mártires</calle-cliente>
<ciudad-cliente>Melilla</ciudad-cliente>
</cliente>
<cliente cliente-id=“C102” cuentas=“C-401 C-402”>
<nombre-cliente>María</nombre-cliente>
<calle-cliente>Etreros</calle-cliente>
<ciudad-cliente>Alicante</ciudad-cliente>
</cliente >
</banco-2>
2.1. DTD: Limitaciones de las DTDs

No se pueden declarar el tipo de elementos y atributos de texto
individuales:
Todos los valores son cadenas, no son enteros, son números reales,
etc.
Es difícil especificar conjuntos desordenados de subelementos
El orden es normalmente irrelevante en las aplicaciones de
intercambio de datos (y de BD); es relevante en el diseño de
documentos.
(A | B)* permite la especificación de conjuntos desordenados, pero
es mucho más difícil asegurar que cada uno de los elementos de
A y B se produzca una sola vez.
Hay una falta de tipos en ID e IDREF
El atributo tenedores de una cuenta puede contener una referencia,
por ejemplo, de otra cuenta (en vez de un cliente), que no tiene
sentido.
El atributo tenedores idealmente debería restringirse para hacer
referencia a los elementos de cliente.

9

2.1. DTDs
2.2. Esquemas XML
6. Aplicaciones

2.2. Esquema XML

El esquema XML es un lenguaje de esquema más sofisticado.
Soluciona alguno de los inconvenientes de las DTD. Soporta:
Declaración de tipos de valores
Enteros, cadenas, etc.
Restricciones de valores mínimos/máximos
Tipos definidos por el usuario
Tipos específicos mediante la restricción de otros tipos
Extensión de tipos complejos mediante una especie de “herencia”
Es un superconjunto de DTDs
Restricciones de unicidad y claves ajenas
XML Schema se especifica en términos de XML
Está integrado por espacios de nombres: diferentes partes de un
documento pueden adaptarse a esquemas diferentes
PERO: es significativamente más complicado que las DTD

2.2. Esquema XML: Ejemplo

<xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema>
<xsd:element name=“banco” type=“TipoBanco”/>
<xsd:element name=“cuenta”>
<xsd:complexType>
<xsd:sequence>
<xsd:element name=“número-cuenta” type=“xsd:string”/>
<xsd:element name=“nombre-sucursal” type=“xsd:string”/>
<xsd:element name=“saldo” type=“xsd:decimal”/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
….. definiciones de cliente y tenedor ….
<xsd:complexType name=“TipoBanco”>
<xsd:squence>
<xsd:element ref=“cuenta” minOccurs=“0” maxOccurs=“unbounded”/>
<xsd:element ref=“cliente” minOccurs=“0” maxOccurs=“unbounded”/>
<xsd:element ref=“impositor” minOccurs=“0” maxOccurs=“unbounded”/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
10
2.2. Esquema XML: Metamodelo
Compositor
1..*
{complete,disjoint}
SEQUENCE CHOICE ALL
{ordered} {choice} {unordered}
1..*
1..* uses
0..*
complexType
ELEMENT *
name 1 is_redefined_by 0..*
Type complexContent
1..* baseType * name
minOccurs: Number = 1 {complete,disjoint}
maxOccurs: Number = 1
1 is_based_on 0..1
Restriction
1 simpleType type
redefines 1..*
satisfies
* 1..*
attribute 0..* Facet
name simpleContent {incomplete,overlapping}
baseType
use
Enumeration Pattern Length minLength

1..*
set_values expression value length
t }
oin
isj
{d
Group


2.1. DTDs
2.2. Esquemas XML
6. Aplicaciones

Bases de datos relacionales

Se deben transformar los datos al
modelo relacional
Archivos planos
Base de datos XML

11
3. Almacenamiento de Datos XML: BD relacionales
Bases de datos relacionales
Ventajas:
Sistemas de BD maduros y ampliamente usados.
Posibilidad de utilización desde aplicaciones existentes.
Desventajas:
La conversión es sencilla si los datos se generan a partir de un
esquema relacional y si se usa XML como formato de intercambio de
datos.
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:
» Elementos anidados
» Elementos que se repiten (atributos multivaluados)
– Hay diferentes alternativas para solucionarlo:
» Almacenamiento como cadenas de caracteres
» Representación en árbol
» Asignación a relaciones
Almacenamiento como cadenas de caracteres

Dos opciones:
Almacenar cada elemento hijo del elemento de nivel superior como un
campo de tipo cadena en una tupla separada en la BD.
– Utilizar una única relación (ELEMENTOS) con un atributo (datos) para
almacenar todos los elementos (por ejemplo, cada tupla almacena un
elemento XML en forma de cadena: cuenta, cliente o impositor)
Almacenar cada elemento de nivel superior como una relación
separada (por ejemplo: Tres relaciones: cuenta, cliente, impositor)
Beneficios:
Es posible almacenar cualquier dato XML, incluso sin DTD.
Inconvenientes:
El SGBD NO conoce el esquema de los datos almacenados; por tanto,
no es posible consultar los datos directamente.
Necesidad de analizar las cadenas para acceder a los valores dentro
de los elementos.
El análisis es lento.

Representación en árbol: los datos XML se modelan como un árbol y se
almacenan en las relaciones:
nodos(id, tipo, etiqueta, valor) hijo(id-hijo, id-padre))

A cada elemento y atributo se le proporciona un identificador único.
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 atributo o elemento
Etiqueta: especifica el nombre del elemento o del atributo
Valor: es el valor literal del elemento o atributo
La relación hijo almacena el elemento padre de cada elemento y atributo.
Se puede añadir un atributo más (posición) a hijo, que guarda el orden de los hijos.
Beneficio:
Puede almacenar cualquier dato XML, incluso sin DTD.
Se pueden traducir las consultas a consultas relacionales.
Inconvenientes:
Los datos se dividen en demasiadas piezas y las consultas simples requieren una gran
cantidad de combinaciones (joins).
12
Asignación a relaciones
Los elementos XML cuyo esquema es conocido, se asignan a relaciones y atributos.
Los elementos cuyo esquema es desconocido se almacenen como cadenas o árboles.
Se crea una relación para cada tipo de elemento cuyo esquema es conocido:
Un atributo id para almacenar una id única para cada elemento.
Todos los atributos de elemento se convierten en atributos de relación.
Todos los subelementos que se producen una sola vez se convierten en atributos:
– Si el valor del subelementos es texto, el atributo almacena el texto como valor.
– Para subelementos complejos, se almacena la id del subelemento.
Si el subelemento pueden parecer varias veces en el elemento, se representado en
una tabla separada:
– Similar a la conversión de atributos multivaluados del E/R en tablas.
Beneficios:
Almacenamiento eficiente.
Pueden transmitir consultas XML dentro de SQL, ejecutarlas eficientemente, 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.

Almacenamiento de datos 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
ficheros XML.
Presentan los problemas asociados a la gestión de ficheros: falta de
concurrencia, comprobaciones de integridad, atomicidad,
recuperación, seguridad …
Base de datos XML: BD construidas específicamente para almacenar
datos XML:
Modelo de almacenamiento XML puro.
Construidas como una capa de DOM (Document Object Model)
implementada sobre una BDOO + un lenguaje de consulta XML para
proporcionar consultas declarativas.
Construidas como una capa sobre BDOR:
– Ventajas de las BD relacionales.
– Desaparece el problema de la representación de estructuras
anidadas.

2.1. DTDs
2.2. Esquemas XML
6. Aplicaciones

13
El resultado de una consulta a un documento XML es otro

documento XML. Por tanto, un mismo lenguaje puede combinar:
Transformación de información de un esquema XML a otro
Consulta de datos XML
Lenguajes de consulta/transformación de XML:
XPath: consta de expresiones de rutas de acceso.
XSLT: diseñado para la transformación de XML a XML y HTML.
XQuery: lenguaje estándar de consulta de XML, con un conjunto
completo de características.
Se ha propuesto una variedad amplia de lenguajes, y algunos
han servido como base para el estándar de XQuery
XML-QL, Quilt, XQL, …

Modelo de árbol de datos XML

Los lenguajes de consulta y transformación se basan en un modelo de
árbol de datos XML.
Un documento XML se modela como un árbol con nodos que corresponde
a elementos y atributos:
Los nodos elemento tienen nodos hijo, que pueden ser atributos o
subelementos.
El texto de un elemento se modela como un nodo de texto, hijo del elemento.
Los hijos de un nodo se ordenan de acuerdo a su orden en el documento XML.
Los nodos de elementos y atributos (excepto los nodos raíz) tienen un padre
único, que es un nodo elemento.
El nodo raíz tiene un único hijo, que es el elemento raíz del documento.


3.1. DTDs
3.2. Esquemas XML
6. Aplicaciones

14
Dos modelos estándar de APIs de datos de XML
SAX (Simple API for XML (API simple para XML))
Modelo de eventos, diseñado para proporcionar una interfaz común entre analizadores y
aplicaciones.
Se basa en la noción de manejadores de eventos: funciones especificadas por el usuario
asociadas con eventos de análisis.
Eventos de análisis: reconocimiento de partes de un documento. Por ejemplo, las etiquetas
de inicio y fin de elemento, generan un evento.
SAX no es adecuado para aplicaciones de base de datos.
DOM (Document Object Model (Modelo de objetos documento))

Los datos XML se representan mediante una estructura de árbol, donde cada elemento se
representa con un nodo (DOMNode). Los programas pueden acceder a partes del
documento navegando desde la raíz.
Se proporcionan variedad en las funciones para navegar a través del árbol DOM. Por
ejemplo, el API DOM de Java proporciona una interfaz Node (interfaces hijas Element y
Attribute) con métodos:
getParentNode( ), getFirstChild( ), getNextSibling( ), getAttribute( )…
También proporciona funciones para actualizar árboles DOM.
DOM se puede usar para acceder a datos XML almacenados en BD; se puede construir una
BD XML usando DOM como interfaz de acceso y actualización de datos.
Sin embargo, DOM no soporta ninguna forma de consulta declarativa.

3.1. DTDs
3.2. Esquemas XML
6. Aplicaciones

6. Aplicaciones
Objetivo de XML:
Facilitar la comunicación de información en la Web y entre
aplicaciones permitiendo que la semántica de los datos se describa
con los mismos datos.
Aunque la gran cantidad de datos XML y su uso en aplicaciones de

negocio requerirán y se beneficiarán de las tecnologías de BD XML,
XML es principalmente un medio de comunicación.
APLICACIONES para COMUNICACIÓN:

Intercambio de datos
Mediación de datos

15
6. Aplicaciones
INTERCAMBIO DE DATOS
Estándares para representación XML de datos de aplicaciones especializadas:
química, transporte (registros de envíos, …), B2B (catálogos, …), etc.
El modelo relacional, para aplicaciones de datos tan complejas, genera un gran
número de relaciones complicadas de gestionar.
En XML, la representación explícita de nombres de atributos y sus valores, ayuda
a evitar confusiones entre atributos.
La representación de elementos anidados permite reducir el número de relaciones
a representar; también reduce el número de combinaciones en las consultas.
Los datos XML suelen proceder de BD relacionales que hay que convertirlos a
formato XML.
Los datos de entrada hay que convertirlos de XML a un formato normalizado
para almacenarlo en una BD relacional.
BD con capacidades XML Conversión automática del modelo relacional a XML

6. Aplicaciones
MEDIACIÓN DE DATOS
EJEMPLOS: aplicaciones de compra comparada; gestión centralizada de

cuentas de un cliente en distintas instituciones, etc.
Si la información no está en XML: software envolvente
Genera datos XML a partir de páginas HTML.
Estas aplicaciones necesitan un mantenimiento constante, ya que dependen de
los detalles de formato de las páginas Web.
Una vez que se tiene la información de las distintas fuentes: aplicación
mediadora
Se combina la información de las distintas fuentes en un único esquema.
El mediador debe proporcionar código para transformar los datos entre
diferentes representaciones XML.

16

XMLy BD

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

XMLy BD

Загружено:

Авторское право:

Доступные форматы

XML y las BD

Fundamentos de bases de datos, 4ª Edición

¿Cómo organizar, manipular, gestionar y consultar datos XML?

©Silberschatz et al. ©Grupo Kybele

1. Motivación: ¿Por qué XML?

©Silberschatz et al. ©Grupo Kybele

XML (eXtensible Markup Language): Lenguaje de marcas extensible

©Silberschatz et al. ©Grupo Kybele

1. Motivación: ¿Por qué XML?

La capacidad para especificar etiquetas nuevas, y para crear estructuras

©Silberschatz et al. ©Grupo Kybele

1. Motivación: ¿Por qué XML?

XML base de todos los formatos de intercambio de

1. Motivación: ¿Por qué XML?

Ventajas para el intercambio de datos:

©Silberschatz et al. ©Grupo Kybele

1. Motivación: ¿Por qué XML?

©Silberschatz et al. ©Grupo Kybele

©Silberschatz et al. ©Grupo Kybele

2. Estructura de los Datos XML

Se permite la combinación de texto con subelementos

Útil para marcar documentos, pero no recomendada para la

©Silberschatz et al. ©Grupo Kybele

2. Estructura de los Datos XML

©Silberschatz et al. ©Grupo Kybele

©Silberschatz et al. ©Grupo Kybele

2. Estructura de los Datos XML

Un elemento puede tener varios atributos, pero cada nombre de

©Silberschatz et al. ©Grupo Kybele

2. Estructura de los Datos XML

Distinción entre subelemento y atributo

©Silberschatz et al. ©Grupo Kybele

Los elementos sin subelementos o contenido de texto

Para almacenar datos de cadenas que pueden contener

©Silberschatz et al. ©Grupo Kybele

2. Estructura de los Datos XML

2. Estructura de los Datos XML

1. Motivación: ¿Por qué XML?

©Silberschatz et al. ©Grupo Kybele

2.1. Estructura de los Datos XML: DTDs

El tipo de un documento XML se puede especificar utilizando

©Silberschatz et al. ©Grupo Kybele

2.1. DTD: ELEMENTOS

2.1. DTD: ATRIBUTOS

©Silberschatz et al. ©Grupo Kybele

2.1. DTD: ID e IDREF

Un elemento puede tener a lo sumo un atributo de tipo ID.

ID e IDREF Similares a los mecanismos de referencia

©Silberschatz et al. ©Grupo Kybele

DTD de banco con tipos de atributos ID e IDREF

©Silberschatz et al. ©Grupo Kybele

2.1. DTD: ID e IDREF

2.1. DTD: Limitaciones de las DTDs

©Silberschatz et al. ©Grupo Kybele

1. Motivación: ¿Por qué XML?

©Silberschatz et al. ©Grupo Kybele

2.2. Esquema XML

PERO: es significativamente más complicado que las DTD

2.2. Esquema XML: Ejemplo

SEQUENCE CHOICE ALL

{ordered} {choice} {unordered}

Enumeration Pattern Length minLength

©Silberschatz et al. ©Grupo Kybele