Bases-de-datos-nativas-en-XML-sus-usos-y-aplicaciones-en-el-Web

Vista previa del material en texto

UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO
Facultad de Ciencias
“Bases de Datos Nativas en XML sus usos y
aplicaciones en el Web”
Tesis profesional presentada por
Carlos Ricardo Cruz Mendoza
para obtener el t́ıtulo de Licenciado
en Ciencias de la Computación
Dra. Amparo López Gaona
Directora de Tesis
México, D.F. Enero de 2007
 
UNAM – Dirección General de Bibliotecas 
Tesis Digitales 
Restricciones de uso 
 
DERECHOS RESERVADOS © 
PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL 
 
Todo el material contenido en esta tesis esta protegido por la Ley Federal 
del Derecho de Autor (LFDA) de los Estados Unidos Mexicanos (México). 
El uso de imágenes, fragmentos de videos, y demás material que sea 
objeto de protección de los derechos de autor, será exclusivamente para 
fines educativos e informativos y deberá citar la fuente donde la obtuvo 
mencionando el autor o autores. Cualquier uso distinto como el lucro, 
reproducción, edición o modificación, será perseguido y sancionado por el 
respectivo titular de los Derechos de Autor. 
 
 
 
Gracias a todos los que hicieron esto
posible.
Índice general
1. XML 3
1.1. Conceptos generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Documentos XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. DTD y Esquema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Documentos Válidos y Bien Formados . . . . . . . . . . . . . . . . . . 10
1.5. Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6. XSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7. Datos estructurados, no estructurados y semiestructurados . . . . . . . 13
1.8. Bases de Datos con XML . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2. Bases de Datos Nativas en XML 17
2.1. XPATH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2. XQUERY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3. XPOINTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4. DOM (Document Object Model) . . . . . . . . . . . . . . . . . . . . . 25
2.5. Xindice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5.1. Almacenamiento de Datos . . . . . . . . . . . . . . . . . . . . . 30
2.5.2. Paginación en Xindice . . . . . . . . . . . . . . . . . . . . . . . 30
2.5.3. Árboles B y B+ . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
i
ÍNDICE GENERAL ii
2.5.4. Árboles en Xindice . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.6. eXist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.7. Indexación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.7.1. Organización de los Datos e Indexamiento . . . . . . . . . . . . 44
2.8. Comparativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3. Diseño e Implementación 48
3.1. Requerimientos y Análisis . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2. Modelado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4. Casos de Uso y Diagramas de Actividad . . . . . . . . . . . . . . . . . 53
3.5. Diagramas de Secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.6. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.7. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A. Bases de Datos en XML (Habilitadas y Nativas) 70
B. Diagrama de Clases 72
Bibliograf́ıa 74
Introduccion
Antecedentes
Siempre ha habido la necesidad de comunicación entre las personas pero en el ámbi-
to de la computación ha existido un grave problema al tratar de homogenizar la manera
de intercambiar información entre sistemas. Este problema se complicó con la aparición
de Internet, donde era casi imposible intercambiar información ya que no exist́ıa un
estándar para el uso de ésta. Uno de los primeros acercamientos para solucionar esto
fue GML1 el cual trataba de solucionar el problema de transporte, modelaje y almace-
namiento de información geográfica, a través de estructuras de datos descriptivas. GML
no tuvo mucha aceptación ya que solamente resolv́ıa un problema en particular pero
sentó las bases para SGML2 , el cual como su nombre lo indica es una generalización
del GML que amplia las capacidades de este. Aunque SGML es actualmente utilizado
por ser un lenguaje de marcación muy poderoso (basta abrir una navegador para darse
cuenta de esto, ya que HTML es una derivación de SGML), no tuvo tanto auge debido
a que su forma es compleja y dif́ıcil de desarrollar.
Es por todo esto que surge XML 3 el cual es una derivación del SGML, conviertiéndolo
en una versión más ligera pero igualmente poderosa, permitiendo el almacenamiento e
1 Acrónimo de Geography Markup Language
2 Acrónimo de Standard Generalized Markup Language
3 Acrónimo de eXtensible Markup Language
1
ÍNDICE GENERAL 2
intercambio de una manera mas rápida y eficiente pero sobre todo estandarizada. Con
el auge de XML, rápidamente las bases de datos relacionales adoptaron modificaciones
para poder utilizar y almacenar este tipo de datos, obteniendo aśı las primeras exten-
siones para bases de datos relacionales, pero al no ser totalmente orientadas a XML
exist́ıan problemas para representar estructuras de tipo jerárquico.
Es por esto que surgen las bases de datos nativas en XML las cuales pueden manejar
eficientemente todas las tareas de una base de datos relacional, mas el almacenamiento
de datos en forma jerárquica de una manera más rápida y eficiente [34, 16].
Objetivos
Conocer a fondo las facilidades y ventajas que ofrecen las bases de datos nativas
en XML y aplicarlas en el desarrollo de un sistema para generar y mantener prácticas,
tareas y exámenes para el curso de bases de datos impartido en la Facultad de Ciencias,
el cual sentará las bases para futuras aplicaciones que utilicen esta tecnoloǵıa. Este
sistema será desarrollado como una aplicación web debido a las ventajas que conlleva
una aplicación de este tipo, tales como: conectividad, acceso, costo, etc.
Organización
En el Primer caṕıtulo se explicará, que es XML, sus tecnoloǵıas, usos y aplicaciones.
En el Caṕıtulo 2 se hará una revisión acerca de las tecnoloǵıas usadas, datos existentes,
algoritmos e información referente a las bases de datos nativas en XML. En el Caṕıtulo
3 se explicará el análisis, diseño, implementación y pruebas del sistema. Por último en
el Caṕıtulo 4 se resumen los conceptos de esta investigación aśı como posibles usos y
aplicaciones a un nivel superior.
Caṕıtulo 1
XML
1.1. Conceptos generales
El World Wide Consortium (W3C) define XML [1] como un lenguaje sencillo pero
muy flexible basado en “marcas o etiquetas” el cual fue definido a partir del anterior
estándar SGML, el cual al igual que XML estaba basado en marcas, pero era demasiado
extenso y poco utilizado debido a su complejidad [20].
En un principio XML surgió en base a la necesidad de solucionar los siguientes proble-
mas:
Crear un lenguaje para ser usado en Internet.
Crear un metalenguaje el cual pueda ser usado para describir otros lenguajes los
cuales resuelven otros problemas particulares (SOAP, XSL, SAX, DOM).
Ser más flexible y fácil que SGML pero a la vez ser compatible con él.
Además de que debe de cumplir con las siguientes caracteŕısticas:
Facilidad en la creación de programas que procesen documentos.
Facilidad en su lectura además de ser claros.
3
CAPÍTULO 1. XML 4
Diseño razonablemente rápido.
Diseño formal y conciso[15, 20].
1.2. Documentos XML
Los documentos XML deben tener estructura f́ısica y lógica [22, 14]. Es decir, los
documentos deben ser válidos o al menos estar bien formados (más adelante se explicaránestos conceptos).
Para que un documento XML pueda tener una estructura correcta, a su vez debe tener
una lógica en la declaración, esto es con el fin de tener coherencia al momento de
interpretar. Pero, ¿Qué significa que un documento XML esté bien formado?. Según la
especificación del W3C [2], un documento XML está bien formado si cumple con:
La regla Document, la cual consiste en que:
• Debe contener uno o más elementos. Un elemento es la unidad de creación
básica de un documento XML, la cual contiene al menos una etiqueta que
define un dato. Ejemplo de un elemento es el siguiente:
<raiz>Texto de la raiz del Documento</raiz>
• Hay exactamente un elemento, llamado ráız, el cual en ninguna otra parte
aparece en el contenido de algún otro elemento. Un ejemplo puede ser el
siguiente:
<raiz>
<etiqueta>Primer Texto de la Etiqueta</etiqueta>
<etiqueta>Segundo Texto de la Etiqueta</etiqueta>
</raiz>
Se puede notar que la etiqueta <raiz> no aparece en el contenido de las
demás sino una única vez englobandolas.
CAPÍTULO 1. XML 5
• Para el resto de elementos, si la etiqueta de comienzo está en el contenido
de algún otro elemento, la etiqueta de fin está en el contenido del mismo
elemento. Es decir, los elementos delimitados por etiquetas de principio y
final se anidan adecuadamente. Ejemplo:
<raiz>
<etiqueta>
<otraetiqueta>Texto anidado</otraetiqueta>
</etiqueta>
</raiz>
Un ejemplo sencillo de un documento XML que cumpla con la regla Document puede
ser el siguiente:
<?xml version="1.0"?>
<libro>
<autor>Rusty, E., Scout</autor>
<nombre>XML in a nutshell</nombre>
<precio tipo="pesos">200 pesos</precio>
<editorial>O’Reilly</editorial>
</libro>
Explicando el ejemplo tenemos que la etiqueta <?xml version="1.0"?> indica
que el texto es un documento XML. En la siguiente ĺınea se puede observar la etiqueta
<libro>, hay que resaltar algunos detalles importantes respecto a esta etiqueta:
Los nombres son sensibles a mayúsculas y minúsculas. Aśı un elemento denominado
“Libro” es diferente de un elemento denominado “libro”.
No se pueden utilizar caracteres como “$”, “<”, si se desea usarlos se deben escribir
como $amp, $lt, respectivamente ya que estos causaŕıan conflictos en la sintaxis
del documento; este tipo de caracteres se conocen como entidades, las cuales se
explicarán posteriormente.
Un atributo es una caracteŕıstica especial de un elemento XML. El valor del atri-
buto debe estar entrecomillado y no puede ser repetido por un elemento. Ejemplo:
CAPÍTULO 1. XML 6
<precio tipo="pesos">200</precio>
En el ejemplo tipo es un atributo del elemento precio con un valor pesos. El uso
del atributo tipo tienen sentido en el elemento precio ya que un precio puede ser
en pesos o dólares. Los atributos son opcionales.
Los nombres de elementos no pueden empezar por un número o un signo de sub-
rayado, ni por la cadena “XML”.
Los nombres de elementos no pueden contener espacios.
Respecto a la correctez del documento se debe tener en cuenta varias cosas:
• Toda etiqueta no vaćıa debe tener una etiqueta de cerrado.
• Los elementos vaćıos son aquellos que no tienen contenido dentro del docu-
mento. Ejemplo:
<imagen archivo="logo.jpg"/>
Un documento XML tiene las siguientes ventajas y desventajas:
Ventajas
Es fácil de entender y editar.
Es flexible, pues cada persona puede utilizar y crear etiquetas que necesite.
Es independiente de aplicaciones, software o formatos propietarios.
Desventajas
Falta más difusión, de hecho algunos navegadores aún no tienen soporte para
documentos XML.
CAPÍTULO 1. XML 7
1.3. DTD y Esquema
Una definición de documentos tipo, DTD1 es como su nombre lo indica una es-
pecificación de restricciones para la estructura del documento XML [3]. Es decir es la
definición para futuros documentos XML.
Una DTD describirá cada elemento dentro del documento XML, aśı como sus posibles
atributos y opcionalmente los valores de los atributos permitidos. Veamos el siguiente
ejemplo:
<?xml version="1.0"?>
<!DOCTYPE libro [
<!ELEMENT libro (autor+, nombre+ ,precio+, editorial+)>
<!ELEMENT autor (#PCDATA)>
<!ELEMENT nombre (#PCDATA)>
<!ELEMENT precio (#PCDATA)>
<!ATTLIST precio tipo NMTOKEN #REQUIRED>
<!ELEMENT editorial (#PCDATA)>
]>
La etiqueta <!DOCTYPE> especifica que debe haber al menos un elemento llamado
libro, la siguiente etiqueta <!ELEMENT> indica que libro contiene cuatro elementos:
autor+, nombre+, precio+ y editorial+, los cuales son obligatorios. El nombre del
elemento seguido de un śımbolo “+” indica que puede haber más de una ocurrencia
del elemento en cuestión; existen otros signos tales como el śımbolo “?”, significa que
puede haber al menos una ocurrencia; el śımbolo “*” indica que puede haber una,
muchas ó ninguna ocurrencia.
Las etiquetas <!ELEMENT> indican que cada uno de estos elementos son de tipo PCDATA,
por último la etiqueta <ATTLIST> indica que el elemento precio contiene un atributo
llamado tipo.
A continuación se listan algunas ventajas y desventajas de la DTD:
1 Acrónimo de Document Type Definition.
CAPÍTULO 1. XML 8
Ventajas
Facilita la validación de documentos XML.
Muestra la estructura de un documento XML.
Desventajas
No siempre es necesario validar un documento XML.
No maneja tipos de datos.
No utiliza el lenguaje propio de XML.
Para resolver estos problemas la organización W3C creó otro tipo de validación mediante
Esquemas [4]. Los cuales son definiciones para validar documentos XML, mediante la
sintaxis de XML. Ejemplo de Esquema.
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns:xs="http://www.w3org/2001/XMLSchema">
<xs:element name="libro">
<xs:sequence>
<xs:element ref="autor" />
<xs:element ref="nombre" />
<xs:element ref="precio" />
<xs:element ref="editorial" />
</xs:sequence>
</xs:element>
<xs:element name="autor" type="xs:string">
</xs:element>
<xs:element name="nombre" type="xs:string">
</xs:element>
<xs:element name="precio" type="xs:integer">
<xs:attribute name="tipo" type="xs:NMTOKEN" use="required" />
</xs:element>
<xs:element name="editorial" type="xs:string">
</xs:element>
</xs:schema>
Este Esquema define el siguiente documento XML, aunque también podŕıa definir
otros documentos XML.
CAPÍTULO 1. XML 9
<?xml version="1.0"?>
<libro>
<autor>A.S. Tanenbaum</autor>
<nombre>Operating Systems: Design And Implementation</nombre>
<precio tipo="pesos">400</precio>
<editorial>Pretince Hall</editorial>
</libro>
En el ejemplo la etiqueta <xs:schema ...> indica que se creó un Esquema siguiendo
las especificaciones de la organización W3C para el documento XML, la siguiente ĺınea
muestra la etiqueta <xs:element ..> la cual indica que va a existir un elemento
llamado libro el cual mediante la etiqueta <xs:sequence> indicará que dentro de
libro van a existir otros elementos (autor, nombre, precio y editorial), y estas
a su vez hacen referencia a sus definiciones que, al contrario de una DTD, muestran el
tipo de datos que van a contener, ya sea una cadena, un entero u otro tipo de dato.
Los Esquemas son superiores a los DTD por las siguientes razones:
Permiten la validación de documentos XML.
Tienen la sintaxis de un documento XML.
Son más intuitivos que una DTD.
Manejan tipos de datos.
Pero el problema actual con los Esquemas, es que aunque sean superiores a las DTD,
su uso no es popular.
CAPÍTULO 1. XML 10
1.4. Documentos Válidos y Bien Formados
Un documento Válido y Bien Formado debe cumplir la regla Document, pero ¿Qué sig-
nifica que un documento sea Válido?.
Para que un documento sea Válido necesita tener una DTD o Esquema asociado al
documento para que éste valide el documento XML.
Se pueden diferenciar dos tipos de documentos XML.
Bien Formados, son aquellos que no tiene una DTD o esquema asociado, pero que
siguen la regla Document.
Válidos, aquellos documentos que siguen las reglas de una DTD ó Esquema.
Se puede afirmar que todos los documentosVálidos están Bien Formados debido a que
una DTD o Esquema sigue la regla Document.
1.5. Entidades
Las entidades sirven para incluir cualquier documento u objeto externo en un do-
cumento XML. Ejemplo:
<!ENTITY CAD "Cadena a usar en repetidas ocasiones">
Con esto se tiene una referencia a una cadena la cual cada vez que es necesitada, bas-
taŕıa con escribir &CAD para obtenerla. Otro ejemplo de entidades son los caracteres
como “&” y “<”, ya que para escribirlos en un documento XML se necesita asignarles
un “alias” como es &amp y &lt, respectivamente.
CAPÍTULO 1. XML 11
1.6. XSL
Un documento XML puede ser comprensible para gente acostumbrada a su uso,
pero para una persona sin conocimientos de XML resultaŕıa poco o nada comprensible,
además de que el usuario final de una aplicación realizada con XML no tiene porque
saber nada de XML, es por esto que se creó XSL 2 .
El World Web Consortiom (W3C) define a XSL [5] como un lenguaje para expresar
hojas de estilo, las cuales transforman un documento XML en algún formato como
HTML, PDF, etc. Debido a que XSL es un lenguaje construido especialmente para dar
formato a documentos XML con la sintaxis de los documentos XML, si bien es cierto
que existen otros lenguajes para dar formato, como por ejemplo CSS 3 [6, 21]. El cual es
un simple mecanismo para añadir estilos a documentos web, tales como fuentes, colores,
espacios. no tienen el poder de XSL, ya que XSL no solamente puede dar formato sino
realizar instrucciones para realizar operaciones mas complejas.
Documento XML al cual se le aplicará la transformación XSL.
<?xml version="1.0"?>
<libro>
<autor>Rusty, E., Scout</autor>
<nombre>XML in a nutshell</nombre>
<precio tipo="pesos">200</precio>
<editorial>O’Reilly</editorial>
</libro>
<libro>
<autor>A.S. Tanenbaum</autor>
<nombre>Operating Systems</nombre>
<precio tipo="pesos">400</precio>
<editorial>Pretince Hall</editorial>
</libro>
Documento XSL asociado al documento XML anterior:
2 Acrónimo de eXtensible Stylesheet Language.
3 Acrónimo de Cascading Style Sheets.
CAPÍTULO 1. XML 12
<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="1.0"
xmlns="http://www.w3.org"/1999/XSL/Transform">
<xsl:output method="html"/>
<xsl:template match="/">
<html>
<head>
<title>Ejemplo de una transformacion XML a HTML</title>
</head>
<body>
<table border="1" width="600" align"center">
<td><b>Autor</b></td>
<td><b>Nombre</b></td>
<td><b>Precio</b></td>
<td><b>Editorial</b></td>
<xsl:for-each select="//libro">
<tr>
<td><xsl:value-of select="autor"/></td>
<td><xsl:value-of select="nombre"/></td>
<td><xsl:value-of select="precio"/></td>
<td><xsl:value-of select="editorial"/></td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
A continuación se desglosará el ejemplo. La primera ĺınea declara que el texto será un
documento XML. En la siguiente ĺınea se especifica que se trata de un documento XSL
que sigue los estándares del W3C, además de que producirá un documento HTML como
salida después de la transformación XSL.
En la ĺınea <xsl:template match="/"> se especifica a partir de donde vamos a apli-
car la transformación al documento XML, en este caso se empezó a partir del primer
elemento del documento XML.
En las siguientes ĺıneas se especifican algunos elementos necesarios para la construcción
CAPÍTULO 1. XML 13
de un documento HTML tal es el caso de la etiqueta <head> y la etiqueta <body>
las cuales crearán el encabezado y cuerpo de nuestro documento HTML final, además
de crear una tabla con 4 columnas las cuales serán llenadas con los elementos autor,
nombre, precio y editorial del documento XML.
La etiqueta <xsl:for-each select="//libro"> indica que por cada etiqueta libro
que veamos en el documento XML se realizarán las instrucciones dentro del alcan-
ce de este elemento. En este caso dentro del alcance de la etiqueta <xsl:for-each
select="//libro"> se encuentran las etiquetas <xsl:value-of select="autor"/>,
<xsl:value-of select="nombre"/>, <xsl:value-of select="precio"/> y <xsl:
value-of select="editorial"/>, las cuales colocarán el valor de estas etiquetas den-
tro del documento HTML final.
Al aplicar el documento XSL al documento XML se obtiene la siguiente tabla vista con
un interprete de HTML (por ejemplo un navegador Web).
Autor Nombre Precio Editorial
Rusty, E., Scout XML in a nutshell 200 O’Reilly
A.S. Tanenbaum Operating Systems 400 Pretince Hall
Existen más cosas relacionadas a un documento XML pero estos temas están fuera
del alcance de este trabajo [19].
1.7. Datos estructurados, no estructurados y semi-
estructurados
Una de las principales razones para utilizar una base de datos que pueda manejar
documentos XML es el poder utilizar datos semiestructurados, a diferencia de las bases
de datos relacionales que sólo usan datos estructurados.
CAPÍTULO 1. XML 14
Datos Estructurados
Son aquellos datos que tienen una estructura definida, los cuales pueden estar fuer-
temente tipificados (un dato es fuertemente tipificado si mantiene un tipo de dato,
por ejemplo al definir un número entero no se puede guardar una cadena u otro tipo
de dato en vez del número entero). Una razón por la que este tipo de datos son uti-
lizados en bases de datos relacionales es porque, pueden ser representados en forma
de registros que posteriormente formarán tablas. Ejemplo:
Nombre char(20) Precio int Editorial char(20)
Operating Systems 400 Pretince Hall
Datos no-estructurados
Son aquellos datos los cuales carecen de alguna organización, además de no estar
tipificados. Ejemplos: Texto plano, e-mails.
Datos semiestructurados
Son aquellos datos que tienen una estructura intermedia, es decir respetan una es-
tructura pero no necesariamente tienen porque estar tipificados, ejemplo: x=“1” y
x=“cadena” son válidos, sus elementos no necesariamente tiene que estar bien defi-
nidos, además de que son mas descriptivos y generales.
Los datos semiestructurados pueden ser representados como:
• Árboles
• Texto Identado
• XML
CAPÍTULO 1. XML 15
Otra observación muy importante es que cuando se tiene datos estructurados se
tienen sólo datos, cuando se tienen datos no estructurados se tiene información pero
cuando se tienen datos-semiestructurados se obtiene los mejor de ambas categorias es
decir información y datos, es por esto que al utilizar bases de datos que manejen este
tipo de datos se tiene otra ventaja sobre las bases de datos relacionales.
1.8. Bases de Datos con XML
Debido a la llegada del World Wide Web (www) a mediados de los 90′s comenzó a
existir una gran demanda para el mantenimiento de datos, información y conocimiento.
Esto ocasionó que los datos manejados en la Web con herramientas convencionales cada
vez se hiciera más dif́ıcil. Es aśı que han surgido nuevas herramientas y técnicas para el
manejo de datos [34, 23]. Unas de estas herramientas fueron los sistemas manejadores
de bases de datos con XML. De forma muy general las bases de datos con XML se
podŕıan agrupar en dos tipos.
XML Enabled Databases (Bases de Datos habilitadas para XML)
Las bases de datos habilitadas para XML desglosan la información de un documento
XML en su correspondiente esquema relacional o de objetos. Contienen extensiones
para transferir datos entre documentos XML y sus propias estructuras. Ejemplos de
este tipo de manejadores de bases de datos son: Access, FoxPro, SQL Server, Sybase
ASE.
En el Apéndice A.1. se encuentra un listado de bases de datos habilitadas para XML
[7].
XML Native Databases (Bases de Datos nativas en XML)
La Organización XML:DB Initiative for XML Databases [8] define a las bases de
CAPÍTULO 1. XML 16
datos nativas en XML como modelos lógicos para documentos XML los cuales alma-
cenan y recuperan documentos de acuerdo a dicho modelo. Como mı́nimo los modelos
deben incluir elementos, atributos y un orden en los datos. Ejemplosde estos modelos
lógicos son XQUERY, XPATH, XML de Infoset.
Deben de tener un documento XML como su unidad fundamental de almacenamiento
lógico, justo como una base de datos relacional tiene un registro en una tabla como
principal unidad de almacenamiento lógico.
En otras palabras son aquellas bases de datos que pueden hacer consultas sobre do-
cumentos XML usando modelos como XQUERY, XPATH, XQL, XML-QL, QUILT;
realizar actualizaciones con XUPDATE; además de proveer interfaces de programa-
ción tal es el caso de SAX, DOM, JDOM todo esto respetando la integridad del
documento XML. Ejemplos de este tipo de manejadores de bases de datos son: eXist,
Xindice, Berkeley DB XML, dbXML.
En el Apéndice A.2.se encuentra un listado de bases de datos nativas en XML [9].
En el siguiente caṕıtulo se explica con detalle qué es una base de datos nativa en XML,
las ventajas y desventajas de su uso, cuales son las opciones al escoger alguna, aśı como
la manera en la cual funcionan y administran.
Caṕıtulo 2
Bases de Datos Nativas en XML
Cuando se desarrolla una aplicación con una base de datos nativa en XML se ob-
tienen grandes beneficios, sobre todo en rendimiento y escalabilidad, esto se puede
justificar debido a que las operaciones básicas realizadas sobre una base de datos (rea-
lizar búsquedas, guardar datos y mantener resultados) pueden ser realizadas de una
manera eficiente debido a la forma en que las bases de datos nativas en XML están
implementadas, con respecto a las bases de datos relacionales.
Las bases de datos en XML organizan sus datos en estructuras de árboles. Mientras
que las bases de datos relacionales organizan sus datos en forma tabular; lo cual presenta
el inconveniente de no ser claras al momento de visualizar las relaciones que existen entre
los datos, además de perder rendimiento en las consultas a la base de datos.
Cuando se desarrolla un sistema utilizando bases de datos relacionales se puede
encontrar su equivalente en una base de datos nativa en XML. En una base de datos
relacional se usa SQL 1 para realizar consultas y guardar datos, su equivalente en una
base de datos nativa en XML es XPATH o XQUERY y XUPDATE para agregar datos
a los documentos, por lo tanto hay equivalencia entre ambas formas de desarrollar un
1 Acrónimo de Structured Query Language.
17
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 18
sistema, ya que es posible al menos realizar las operaciones básicas y más comunmente
usadas en un sistema manejador de bases de datos, pero aún carecen de muchas opcio-
nes que un sistema manejador de bases de datos relacionales brinda, como por ejemplo
transacciones, triggers, busquedas sobre multiples documentos, aunque en un futuro se
podrán utilizar estas caracteŕısticas en las bases de datos nativas en XML.
Tanto las bases de datos relacionales como las nativas en XML permiten almacenar
datos, mantener datos, realizar búsquedas, pero la diferencia está en la forma de alma-
cenamiento e indexación de los datos.
Como se mencionó anteriormente, una base de datos nativa en XML almacena datos
en estructuras llamadas árboles y su indexación es el factor clave para su rendimiento,
por lo cual el sistema manejador de datos que se escoja determinará los beneficios y
desventajas del sistema. En este caṕıtulo se explicarán dos de los principales sistemas
manejadores de bases nativas en XML, Xindice y eXist, el motivo de la utilización
de eXist para la implementación de la aplicación manejadora de prácticas, tareas y
exámenes, pero antes de esto se explicarán algunos conceptos necesarios para entender
el funcionamiento de las bases nativas en XML, tal es el caso de XPATH, XQUERY,
XPOINTER y DOM.
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 19
2.1. XPATH
XPATH 2 [10, 24] es definido como un lenguaje para obtener partes del documento
XML, esta diseñado para ser usado por XSL y XPOINTER (el cual se explicará mas
adelante). De manera rápida se puede decir que XPATH y XQUERY es a las bases de
datos nativas en XML lo que SQL es a las bases relacionales.
Para estos propósitos XPATH provee manejo de cadenas, números y valores lógicos, su
sintaxis es diferente de la usada en XML, esto debido a que es más fácil la manipulación
de elementos, texto y atributos de documentos XML.
La forma en que XPath manipula los datos es a través de un parser el cual construye
un árbol de nodos. Este árbol presenta las caracteŕısticas de cualquier árbol de datos
es decir tiene, ráız, hijos, ancestros, descendientes, etc.
Existen distintos tipos de nodos en un árbol generado a partir de un documento XML:
nodo ráız, nodos elemento, nodos atributo, nodos texto, nodos comentario y nodos de
instrucciones de procesamiento (root, node elements, node attributes, node texts, node
comments y processing node instructions). El caracter “/” hace referencia al nodo ráız
del árbol generado, pero no al elemento ráız del documento XML. Cualquier elemento
de un documento XML se convierte en un nodo elemento dentro del árbol.
Cada elemento tiene su nodo padre. El nodo padre de cualquier elemento es, a su vez,
un elemento, excepto el elemento ráız, cuyo padre es el nodo ráız. Los nodos elemento
tienen a su vez hijos, que son: nodos elemento, nodos texto, nodos comentario y nodos
de intrucciones de proceso. Los nodos elemento también tienen propiedades tales como
su nombre y atributos.
Los nodos atributo no son hijos de los nodos elemento sino que los contiene como
etiquetas añadidas a dicho nodo elemento. Cada nodo atributo consta de un nombre y
2 Acrónimo de XML Path Language.
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 20
un valor.
En el árbol también se generan nodos para cada nodo comentario y nodo de instruccion
de proceso.
Ejemplo de transformación de un documento XML en su representación de árbol.
<libro>
<titulo>MOMO</titulo>
<autor id="1">Michael Ende</autor>
</libro>
---/
|
+---libro
|
+---titulo
| |
| +---(texto)MOMO
|
+---autor[id="1"]
| |
| +---(texto)Michael Ende
Una consulta es definida como una expresión (path expression) que lee una secuencia
de datos en XML y devuelve otra secuencia como resultado.
Ejemplo de una consulta en XPATH
/Libro//Capitulo/Seccion
Indica que se desea seleccionar todos los elementos Sección que sean hijos de Capı́tulo
los cuales tengan un antecesor llamado Libro. La doble diagonal en la subexpresión
Libro//Capı́tulo nos indica que debe de haber un camino de un elemento Libro a
un elemento Capı́tulo. Esto corresponde a una relación antecesor-descendiente, es de-
cir, sólo los elementos que son descendientes de Libro serán seleccionados. La diagonal
en Capı́tulo/Sección indica una relación padre-hijo. En ésta se seleccionarán aque-
llas secciones cuyo padre es un elemento Capı́tulo. Resumiendo, cuando se tiene una
relación antecesor-descendiente se seleccionarán TODOS los nodos que descendiendan
del conjunto de nodos contexto. Es decir, no sólo los hijos de los nodos contexto, sino
también los hijos de los hijos y los hijos de éstos y aśı hasta llegar al final. Mientras que
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 21
en una relación padre-hijo sólo se seleccionan los nodos hijo o nodos padre.
Los Axes son abreviaturas de las expresiones completas de XPATH, el ejemplo anterior
se podŕıa reescribir como: descendant::Libro::child::*, pero se perdeŕıa facilidad en
el uso de XPATH. Ejemplos de Axes son descendant (//), child (/), attribute (@), self
(.) , parent (..).
Se pueden realizar consultas mucho mas complejas usando predicados. Un predicado
básicamente restringe el conjunto de nodos seleccionados por un Axe el cual cumple
cierta condición. Por ejemplo la consulta:
/Libro/Capitulo/Seccion[@id = "10"]
Devuelve todos los elementos hijos de Sección cuyo atributo id sea igual a 10.
2.2. XQUERY
XQUERY 3 [11, 27] es un lenguaje de consulta que contiene a la especificación de
XPATH 2.0, por lo queambos lenguajes son compatibles a cierto nivel entre ellos, pero
a diferencia de XPATH, XQUERY regresa un consulta como nodos ordenados y sin
repetir datos.
Otra diferencia entre XPATH y XQUERY es la forma en que pueden utilizar las hojas
de estilo ya que con XPATH es muy fácil el uso de éstas 4 mientras que con XQUERY se
pueden utilizar hojas de estilos más complicadas utilizando menos código y haciéndolo
mas legible.
XQUERY abarca desde archivos XML hasta bases de datos relacionales con funciones
de conversión de registros.
3 Acrónimo de XML Query Languaje.
4 Siempre y cuando estas resuelvan tareas pequeñas.
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 22
En XQUERY las expresiones pueden estar compuestas por cláusulas de hasta cinco
tipos distintos. Estas cláusulas siguen la norma FLWOR ( For, Let, Where, Order by
y Return).
Tabla que explica cada cláusula.
For Vincula una o mas variables o expresiones escritas en XPATH.
Let Vincula una variable al resultado completo de una expresión, añadiendo
esos v́ınculos a los elementos generados por una cláusula For ó, si no
existe una cláusula For, creando un único elemento que contenga esos
v́ınculos.
Where Filtra los elementos eliminando todos los valores que no cumplan las
condiciones.
Order by Ordena los elmentos según el criterio dado.
Return Construye el resultado de la consulta para un elemento dado, después de
haber sido procesado.
En el siguiente ejemplo se ilustra el uso de XQUERY.
-------- libros.xml ------------
<libros>
<libro>
<titulo>MOMO</titulo>
<autor id="1">Michael Ende</autor>
</libro>
<libro>
<titulo>Ensayo sobre la Ceguera</titulo>
<autor id="2">Jose Saramago</autor>
</libro>
<libro>
<titulo>El Evangelio segun Jesucristo</titulo>
<autor id="2">Jose Saramago</autor>
</libro>
</libros>
-------- CONSULTA --------------
for $b in doc("libros.xml")//libro
let $c := $b//autor
where $c/@id = "2"
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 23
order by $b/titulo
return $b/ titulo
El resultado de la consulta se muestra a continuación.
<titulo>Ensayo sobre la Ceguera</titulo>
<titulo>El Evangelio segun Jesucristo</titulo>
En la primera ĺınea de la consulta se asignan todos los libros existentes en el documento
libros.xml a la variable $b, en la siguiente ĺınea se asocian a la variable $c todos los
autores de los libros que seleccionamos en la variable $b, en la siguiente ĺınea se pone la
condicion en la cual solamente se seleccionará como válidos los elementos en los cuales
el atributo id de algún autor sea 2, en la siguiente ĺınea se ordena por titulo y para
finalizar se regresan únicamente las tuplas titulo.
En la siguiente tabla se especifica las etapas en las cuales se ejecutaŕıa la consulta.
#Libros que se asignaron a la variable b.
For <libro><titulo>MOMO</titulo><autor id=’1’>Michael
Ende</autor></libro> <libro><titulo>Ensayo
sobre la Ceguera</titulo><autor id=’2’>Lewis
Carroll</autor></libro> <libro><titulo>El
Evangelio segun Jesucristo</titulo><autor id=’2’>Jose
Saramago</autor></libro>
#Autores que se seleccionaron en la variable c.
Let <libro><autor id=’1’>Michael Ende</autor></libro>
<libro><autor id=’2’>Jose Saramago</autor></libro>
#Condicion en la cual solo se seleccionaron los autores
#que tenian un atributo = 2
Where <libro> <autor id=’2’>Jose Saramago</autor></libro>
#Ordenados por titulo.
Order by <titulo>El Evangelio segun Jesucristo</titulo><autor
id=’2’>Jose Saramago</autor> <titulo>Ensayo sobre la
Ceguera</titulo><autor id=’2’>Jose Saramago</autor>
#Regresa solamente los titulos.
Return <titulo>El Evangelio segun Jesucristo</titulo>
<titulo>Ensayo sobre la Ceguera</titulo>
Un detalle muy importante respecto a XQUERY es que ninguna de las cláusu-
las FLWOR es obligatoria en una consulta XQUERY. Por ejemplo una expresión en
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 24
XPATH es totalmente válida y puede no tener ninguna de las cláusulas FLWOR.
Escoǵı utilizar XPATH para realizar el sistema manejador de prácticas debido a que su
especificación, al ser menos amplia que la especificación de XQUERY, es mas fácil de
ser implementada por distintos sistemas manejadores de bases de datos, con lo cual es
mas fácil migrar el sistema de un sistema manejador a otro. De hecho Xindice solamente
implementa XPATH, a diferencia de eXist que implementa casi en su totalidad tanto
XPATH 2.0 como XQUERY.
2.3. XPOINTER
XPOINTER 5 es una extensión de XPATH que permite obtener partes del docu-
mento XML.
El equivalente en HTML es lo que se consigue con la etiqueta <A NAME="seccion">,
la cual permite obtener una parte del documento html. Para utilizar esta instrucción se
agrega al final de un URI6 un signo de # seguido de la sección que deseamos obtener,
ejemplo:
http://www.w3.org/TR/xpath#seccion
La idea que sigue XPOINTER es parecida. XPOINTER permite añadir a un URI una
#expresión donde expresión es una sentencia XPATH, con algunas propiedades ex-
tra. Ejemplo:
http://wwww.w3.org/xpath.xml#xpointer(/xpath/axes)
Explicando el ejemplo se observa que la sentencia XPOINTER buscaŕıan el conjunto
de nodos delimitado por /xpath/axes, dentro de xpath.xml tal y como se buscaŕıa con
una sentencia XPATH.
5 Acrónimo de XML Pointer Language.
6 Acrónimo de Uniform Resource Identifier el cual puede ser un URL (Acrónimo de Uniform Re-
source Locator) o un URN (Acrónimo de Uniform Resource Name).
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 25
Actualmente no hay muchas herramientas que soporten XPOINTER 7 , pero una vez
que se difunda su uso se podrán utilizar todas las mejoras y extensiones que hace a
XPATH sobre todo en el web.
2.4. DOM (Document Object Model)
DOM 8 [12] acorde a la especificación del W3 se define como una plataforma e
interfaz para algún lenguaje neutral con el cual se puede acceder al contenido, cambiar
estructura y estilo de algún documento (HTML ó XML). En otras palabras es un API 9
para acceder y manipular datos estructurados dinámicamente no importando el lenguaje
en que se implemente.
Guarda una gran similitud con la estructura del documento al que modela. Por ejemplo:
<!-- PARTE DE UN DOCUMENTO HTML -->
<TABLE>
<BODY>
<TR>
<TD>Libro 1</TD>
<TD>--</TD>
</TR>
<TR>
<TD>Libro 3</TD>
<TD>Libro 4</TD>
</TR>
<TBODY>
</TABLE>
El DOM que representa este documento es el siguiente:
7 De hecho tanto IExplorer como Firefox aun no tienen soporte.
8 Acrónimo de Document Object Model.
9 Conjunto de especificaciones de comunicación entre componentes de software.
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 26
Algo muy importante por enfatizar es que los nodos del diagrama anterior no repre-
sentan una estructura de datos, sino que representan objetos, los cuales pueden tener
funciones e identidad. Como modelo de objetos, el DOM identifica:
Las interfaces y objetos usados para representar y manipular un documento
La semántica de estas interfaces y objetos, incluyendo comportamiento y atributos
Las relaciones y colaboraciones entre estas interfaces y objetos
Sin embargo, el DOM no especifica que los documentos deban ser implementados
como una estructura de árboles, ni tampoco especifica cómo deben implementarse las
relaciones entre objetos. El DOM es un modelo lógico que puede implementarse de la
manera que sea conveniente.
Una propiedad importante de los modelos de estructura del DOM es su isomorfismo
estructural, es decir, si dos implementaciones cualesquiera del DOM se usan para crear
una representación del mismo documento, ambas crearán el mismo modelo de estruc-
tura, con exactamente los mismos objetos y relaciones.
El Modelo de Objetos del Documento consiste actualmente de dos partes, el Núcleo del
DOM y el DOM HTML.
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 27
El Núcleo del DOM representa la funcionalidad usada para los documentos XML y
también sirve de base para el DOM HTML. El DOM HTML es un conjuto de recursos
que facilita las tareas más comunes que se puedenrealizar en un documento HTML.
Ejemplos del Núcleo de DOM y DOM HTML:
getElementById(Identificador) (Núcleo de DOM: Método de Document)
Devuelve el nodo Elemento cuyo Id es Identificador.
images (DOM HTML: Atributo de HTMLDocument)
Devuelve el conjunto ordenado de elementos HTMLImageElement del documento.
2.5. Xindice
Xindice [25] es un sistema manejador de bases de datos escrito enteramente en Java,
por lo tanto se tiene portabilidad y seguridad, pero depende de la Máquina Virtual de
Java (JVM).
Xindice guarda datos en objetos de Java dentro de la JVM tales como :
Objetos que representan la jerarqúıa de las colecciones. Una colección como su nombre
lo indica contiene varios documentos XML y a su vez puede contener subcolecciones,
obteniendo aśı una jerarqúıa de datos.
Información del estado de la conexión con el cliente.
Varios datos guardados en memoria.
Es por esto que Xindice necesita acceso a los archivos en el disco duro u otro dispositivo
de almacenamiento que contenga los documentos XML. Estos archivos son guardados
dentro de una jeraqúıa de directorios, que comienza en la raı́z10 .
10 También es llamada database root ó dbroot.
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 28
Xindice puede ser utilizado de dos diferentes maneras, dependiendo de como se quiera
usar. La primera forma es como una aplicación Stand Alone en donde el cliente y la
base de datos funcionan bajo la misma máquina virtual11 . La segunda es dentro de
un contenedor de aplicaciones web, como Apache Tomcat. El cual permite a Xindice
recibir peticiones de diferentes clientes sin perder integridad y asegurando concurrencia.
La comunicación entre los clientes y el manejador de bases de datos se realiza mediante
XML-RPC12 , o através del api XML:DB, el cual al ser implementado en Java es la op-
ción ideal para el desarrollo y comunicación con el sistema manejador de bases de datos.
Cada colección en Xindice es representada por una instancia de la clase:
org.apache.xindice.core.Collection, la cual toma valores iniciales usando un ar-
chivo XML que describe el comportamiento de la colección.
La colección principal de esta jerarqúıa de colecciones es llamada raı́z la cual no tiene
padre13 ádemas de que no contiene documentos XML sino solamente subcolecciones.
Esta raı́z provee enlaces a cualquier objeto utilizado en una instancia de Xindice. La
colección principal es inicializada como se mencionó anteriormente por un archivo XML,
el cual luce de la siguiente forma:
<xindice>
<root-collection dbroot="./db/" name="db">
<queryengine>
<resolver autoindex="false"
class="org.apache.xindice.core.query.XPathQueryResolver" />
<resolver class="org.apache.xindice.core.xupdate.XUpdateQueryResolver" />
</queryengine>
</root-collection>
</xindice>
Los elementos importantes en este documento son:
11 Embedded mode.
12 Acrónimo de XML-Remote Procedure Call.
13 Es decir, una colección con una jeraqúıa mayor a la suya.
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 29
El atributo dbroot, es una dirección que puede ser absoluta o relativa para encon-
trar la colección principal, si la ruta es absoluta usa esa ruta y si es relativa Xindice
tratará de encontrar una variable global llamada XINDICE HOME y la concate-
nará con el valor del atributo dbrooot (esto sólo si la aplicación no se encuentra
dentro de un contenedor de aplicaciones Web). Si la variable global no es encontrada
Xindice tratará de usar el directorio webapps/xindice/WEB-INF como la dirección
principal.
El atributo name, es el nombre de la colección principal.
Los elementos resolver, son apuntadores a los motores de busqueda que Xindice
soporta. Por default se utilizan tanto XPATH como XUPDATE.
El atributo autoindex, nos indica que la colección principal puede o no tener un
ı́ndice, por default la colección principal no se encuentra indexada.
Otro punto muy importante respecto a las colecciones es que cada colección contiene al
menos un archivo con terminación tbl, que contiene todos los documentos XML guar-
dados en ella, este archivo se explicará con más detalle más adelante.
Una colección especial es system, la cual siempre es creada cuando se instancia la base
de datos, esta colección no contiene documentos pero si dos colecciones: SysConfig y
SysSymbols.
La Colección SysConfig contiene un archivo llamado database.xml. Mientras que
SysSymbols contiene varios documentos que en conjunto son la llamada tabla de śımbo-
los 14 usada para guardar los nombres de elementos y atributos de todos los documentos
XML guardados en la base. El archivo database.xml es un archivo en XML que es usa-
do para crear cualquier colección en la base de datos.
14 Tambien llamada symbol tables.
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 30
2.5.1. Almacenamiento de Datos
Como se mencionó anteriormente los datos de un documento XML son almacenados
en un solo archivo con extensión tbl el cual es localizado en el directorio de las coleccio-
nes en algun lugar en el database root directory. Una clase de Java llamada filer
es la responsable de leer y escribir XML a ese archivo. El más común filer en Xindice
es implementado por org.apache.xindice.core.file.BtreeFiler.
La clase org.apache.xindice.core.file.BtreeFiler divide el almacenamiento
de datos en dos capas. La capa inferior provee un archivo de paginación 15 . El código
para esta capa es implementado por la clase: org.apache.xindice.core.file.Paged.
La capa superior contiene una implementación de un Árbol B 16 (el cual es una estruc-
tura de datos que permite el almacenamiento de duplas de llaves y valores).
2.5.2. Paginación en Xindice
La paginación es usada en las bases de datos nativas en XML debido a que es un
algoritmo de almacenamiento muy utilizado y eficiente, pero sobre todo facilita el ac-
ceso aleatorio a los datos. A continuación se explicará de qué se trata la paginación y
cómo es usada en las bases de datos en XML.
La paginación provee un acceso eficiente a un archivo permitiendo que varias partes
del archivo (páginas) sean mapeadas a la memoria principal para fácil acceso. Estas
páginas tienen un tamaño predefinido, si el dato que requiere ser guardado es mayor que
el de una página, las siguientes páginas creadas deben ser enlazadas a la pagina anterior.
15 Paged file.
16 B-tree filer
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 31
Encabezado de Archivo
Encabezado de Página
Página 1
Página 2
Página 3
Encabezado de Página
Encabezado de Página
Figura 2.4.2. Estructura de un archivo paginado
Como se muestra en la Figura 2.4.2 un archivo paginado contiene un encabezado
de archivo17 seguido de páginas con un tamaño predefinido. En el caso de Xindice
las páginas y el encabezado de archivo tienen un tamaño de 4kb, pero el tamaño puede
ser cambiado.
Cada página contiene un encabezado de página18 de 64 bytes seguidos de datos.
Estas páginas son numeradas. Ahora si se necesita cierta página y ésta no se encuentra
en la memoria principal la manera de obtener la página seŕıa la siguiente:
direcciónpágina = tama~no encabezado archivo + (n página * tama~no página)
Ejemplo: Obtener la direccion de la página 5
direcciónpágina = 4 kb + ( 5 * 4kb)
Con esta fórmula se puede encontrar la direccion de la página que se busca y 64 bytes
después (los 64 bytes del encabezado de página) se obtendŕıa el comienzo de los datos.
17 File header.
18 Page header.
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 32
El encabezado de archivo contiene una serie de campos arreglados para cierto
propósito. Estos campos si son mas grandes de un byte son guardados en Big En-
dian Format, lo cual significa que el byte mas significativo siempre es guardadado en la
dirección de memoria mas pequeña. Con esto se asegura que los datos sean correctos
no importando la arquitectura.
El encabezado de archivo contiene los siguiente campos:
header_size
0 2
page_size
page_count
total_countfirts_free_page
last_free_page
6
14
22
30
38 39
pag_hd_size max_key_size
40
record_count
header size (2 bytes) - Contiene el tamaño del encabezado de archivo.
page size (4 bytes) - Contiene el tamaño de las páginas.
page count (8 bytes) - En versiones recientes de Xindice este campo es remplazado
por el campo de total count.
total count (8 bytes) - Número total de páginas presentes en ese archivo.
first free page (8 bytes) - Número de página de la primera página sin usar.
last free page (8 bytes) - Número de página de la última página sin usar.
pag hd size (1 byte)- Tamaño del encabezado de página. En este caso son 512 bits
(64 bytes).
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 33
max key size (2 bytes) - Tamaño máximo de cada llave.
record count (8 bytes) - Número de expedientes19 guardados en el archivo.
Además de todos estos campos otros pueden ser creados posteriormente.
Clases como org.apache.xindice.core.file.Btree, la cual extiende a la clase
org.apache.xindice.core.file.Paged pueden añadir campos a este archivo.
Un expediente es un dato guardado en una página. Si este dato cabe en una sola pági-
na nada especial pasa, es decir se guarda en la página, pero si el dato no cabe en ésta,
es guardado en la primera página y subsecuentes páginas guardan el resto del dato. Es
por esto que cada página tiene su propio encabezado de página el cual contiene ciertos
campos necesarios para enlazar los datos entre páginas.
Las páginas sin usar que existan en el archivo de datos 20 y que puedan ser usadas
para guardar datos son almacenadas en la lista de páginas sin usar usando el campo
first free page y last free page del encabezado de archivo.
El encabezado de página contiene los siguiente campos:
status
0 3
key_hash
record_len
total_count
7
15
key_len
data_len
1
11
status (1 byte) - Este estatus es un valor en hexadecimal que representa los valores
de: Usado, Sin Usar o Sobrecarga.
Si la página está usada el estatus cambia a Usado.
Si una página esta sin usar su estado es Sin Usar.
Si esta página contiene la primera parte de un expediente su estado cambia a un valor
19 Records.
20 Archivo con extención tbl.
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 34
en hexadecimal que es usado por el algoritmo de Árboles B. El cual será descrito
detalladamente mas adelante.
Si la página contiene el sobrante de algún expediente su estado cambia a Sobrecarga.
página 0x42
estatus ?
datos, parte 1
página 0x62
estatus Sobrecarga 
datos, parte 2
página 0x3C
estatus Sobrecarga
datos, parte 3
página 0x5E
estatus Sobrecarga
datos, parte 4
apuntador vacio
Ejemplo de un expediente guardado en 4 páginas
key len (2 bytes) - Las páginas tienen la posiblidad de guardar una llave21 justo
antes de los datos que contiene la pagina. El tamaño máximo de ésta llave es puesto
en el campo de max key size del encabezado de archivo a 256 (0X0100) pero, puede
ser redefinido en ésta página si se cambia el tamaño en este campo. Posteriorme este
campo sirve para crear la llave hash utilizada en busquedas de datos. Si no hay llave
en esta página el valor es 0 y no se creará ninguna llave hash.
key hash (4 bytes) - Se guarda una llave hash22 calculada utilizando el campo
key len.
data len (4 bytes) - El tamaño del expediente guardado en ésta página. Si el expe-
21 Key.
22 Key Hash.
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 35
diente continua en otra página en éste campo solo se guarda el tamaño del pedazo
de expediente guardado en ésta página.
record len (4 bytes) - El tamaño total del expediente.
next page (8 bytes) - El número de la página que contiene la siguiente parte del
expediente, si esta página es la última que contiene el expediente su valor pasa a -1.
2.5.3. Árboles B y B+
Un árbol es una estructura de datos que permite ordenar listas de valores, minimi-
zando el número de lecturas.
Esta estructura contiene nodos, en los cuales se almacenan llaves, éstos tienen apun-
tadores a otros nodos (llamados nodos hijo). Los nodos hoja son nodos que no tienen
nodos hijo. Solo puede haber un único nodo sin padre llamado ráız.
Un árbol B tiene las siguientes caracteŕısticas:
Cada nodo, excepto la ráız tiene un número acotado de llaves; tal cota está dada
por superior, que es una función que toma el órden del árbol, m, lo divide entre 2 y
regresa el valor entero de tal operación.
Un árbol B de orden m contiene a lo mas m llaves y m+1 apuntadores.
Mientras que otros tipos de árboles pueden perder su balance, los árboles B garantizan
balanceo de datos y un número de niveles menor. Esto permite que las operaciones
mas comunes en árboles B se realicen de una manera mas eficiente, por ejemplo las
busquedas en los árboles B en el peor de los casos se realizan en tiempo logaŕıtmico
mientras que en los árboles no balanceados en el peor de los casos el tiempo es lineal.
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 36
6
1 4
10 15
 
 
 
Nodo
Nodo hojaLlave
Ejemplo de un árbol B de orden 4
Cuando un nodo es insertado o removido, el número de nodos vaŕıa y en algunos casos
se requieren realizar operaciones especiales para mantener la estructura.
Un árbol B+ es una variación de un árbol B. En un árbol B+, en contraste respecto
a un árbol B, toda la información se guarda en las hojas. Los nodos internos sólo con-
tienen claves y punteros. Los nodos hoja se encuentran unidos entre śı como una lista
enlazada para permitir búsqueda secuencial.
No es el objetivo de ésta tesis explicar toda la teoria detras de los árboles B y B+ pero
un buen libro de algoritmos [13, 18] puede dar una explicación mas amplia.
2.5.4. Árboles en Xindice
En el caso de Xindice existe una variación en el árbol B ya que todas las llaves que
Xindice necesita termina en los nodos hojas del árbol B, pero a diferencia de los árboles
B+ no se tienen apuntadores entre hojas.
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 37
Fig 2.5.4 - Ejemplo de un árbol B en Xindice
Xindice implementa estos árboles usando el archivo paginado. Cada nodo en el árbol
es guardado en un expediente el cual puede estar en una o mas páginas.
Además de los nodos del árbol B. El B-tree filer23 almacena los datos que estan
asociados a alguna llave. Estos datos son guardados en expedientes separados (también
separados en una o más páginas). Los nodos hoja en el árbol B24 contienen apuntadores
a los expedientes que contienen los datos asociados a las llaves.
El archivo B-Tree Filer mantiene tres tipos de expedientes dentro del archivo pagi-
nado.
nodos hoja25 - Estos nodos contienen una lista de llaves y apuntadores a expedientes
de datos, los cuales contienen el dato asociado a cada llave.
23 Implementado por las clases org.apache.xindice.core.filer.BTree y
org.apache.xindice.core.filer.BTreeFiler.
24 Recordar que el conjunto de todos los nodos hoja en el árbol contienen todas las llaves usadas.
25 Leaf Nodes.
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 38
nodos de las ramas26 - Estos nodos contienen parejas de llaves y apuntadores a
otros nodos.
expedientes de datos27 - No son parte del árbol B pero los nodos hoja apuntan
a estos datos.
La implementación del árbol B necesita de ciertos campos extra que son agregados al
encabezado de archivo y a los encabezados de página para su organización interna.
Los campos agregados al encabezado de archivo son:
root_node_page_number total_bytes
Encabezado de Archivo Original
root node page number (8 bytes) - El número de página de la página que mantiene
el nodo ráız del árbol B.
total bytes (8 bytes) - El tamaño en bytes del archivo que matiene los nodos de los
árboles y los expedientes de datos.
Los campos agregados en la cabecera de la página del archivo son:
val_count modified
Encabezado de Página Original
created
status
26 Branch Nodes.
27 Data Records
CAPÍTULO 2. BASES DE DATOS NATIVAS ENXML 39
status (1 byte) - Este campo es usado para indicar que clase de expediente es:
• Un expediente que es usado como un nodo rama del árbol B tendrá un estatus
0X01.
• Un expediente que es usado como un nodo hoja del árbol B tendrá un estatus
0X02.
• Un expediente que es usado como un expediente de datos tendrá un estatus 0X14.
val count (2 bytes) -Si el expediente es usado para guardar un nodo del árbol B,
entonces éste campo indica cuantas llaves hay en el nodo.
created (8 bytes) - Si el expediente es usado para guardar datos, en este campo se
guarda la hora en que fue guardado.
modified (8 bytes) - Si el expediente es usado para guardar datos y fue modificado,
en éste campo se guarda la hora en que fue modificado.
Pero, ¿Cómo es codificado un nodo del árbol B en un expediente dentro del archivo
paginado?.
En el caso de los nodos rama, hay un apuntador más que el número de llaves; estos
apuntadores apuntan a otros nodos en el árbol B. En el caso de los nodos hoja hay
exactamente tantos apuntadores como llaves y cada apuntador apunta al expediente
de datos asociado a alguno de los valores de las llaves. En caualquier caso el nodo es
codificado de la siguiente manera.
Para cada llave, dos campos son escritos28 :
28 Las llaves en Xindice no son números como se muestra en la Figura 2.5.4, sino cadenas de caracteres
codificados en UTF-8, dentro de un arreglo de bytes.
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 40
• El tamaño del arreglo de bytes.
• Los bytes que representan el valor de la llave29 .
El número de llaves se obtiene del encabezado de página.
Inmediatamente de la llave siguen los apuntadores, uno tras otro cada uno ocupando
8 bytes.
El número de apuntadores se obtiene del número de llaves y del campo status el
cual indica si es un nodo hoja o nodo rama.
2.6. eXist
eXist es sistema manejador de bases nativas en XML bajo código abierto escrito to-
talmente en Java, su creador es Wolfgang M. Meier[30] de la Universidad de Tecnoloǵıa
de Darmstadt. Al igual que Xindice, eXist cubre las expresiones que define el lenguaje
XPATH 1.0 y a diferencia de Xindice, implementa casi en su totalidad XPATH 2.0 y
XQuery 1.0, además de búsquedas por medio de expresiones regulares, búsquedas por
palabras clave en textos, etc.
Este manejador de bases nativas en XML puede ser utilizado de dos maneras distintas.
La primera de estas es como una aplicación 30 y la segunda es dentro de un servidor
de aplicaciones web como Apache Tomcat. Cualquiera de estas dos formas de utilizar
eXist soportan operaciones concurrentes realizadas por diferentes usuarios.
Una mejora respecto a Xindice es el aumento de operadores y funciones. Un ejemplo
de esto es la siguiente sentencia de XPATH:
/libro[ near (., ’Datos XML’, 50)]
29 una cadena, en UTF-8
30 Stand Alone.
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 41
En el ejemplo anterior, la sentencia XPATH buscaŕıa todas las incidencias de la cadena
Datos XML que estén a una distancia una de otra de cincuenta o menos letras dentro
del documento XML.
La forma en la cual eXist realiza el almacenamiento es muy similar a Xindice ya que
utiliza paginación y árboles B. El manejador eXist tiene sus busquedas propias y opti-
mizadas basadas en ı́ndices. Soporta concurrencia pero no transacciones. La diferencia
principal entre una base de datos y otra se centra principalmente en la forma de realizar
busquedas; ya que eXist utiliza una forma de indexamiento por cada elemento, texto y
atributos, además de que genera automáticamente este indexamiento.
2.7. Indexación
El esquema de indexación representa una mejora en la forma en la cual se procesan
búsquedas dentro de la base de datos. El objetivo principal del esquema de indexación
en eXist es encontrar relaciones estructurales entre nodos.
Por ejemplo la expresión /libro//figura/titulo denota una selección estructural. Es
decir tienen relaciones entre nodos, como son antecesor-descendiente ó padre-hijo. En
una consulta normalmente se utilizaŕıa un enfoque top-down para evaluar las expresio-
nes; es decir buscaŕıamos en todos los nodos que comiencen con libro para encontrar
posibles elementos figura. Esto implica que un gran número de nodos que no conten-
gan figura serán accesados para probar si el nodo es un descendiente de libro y si
el nombre concuerda con figura. Es por esto que para acelerar las consultas se imple-
mentó un esquema de indexación que identificara relaciones entre nodos.
Varios esquemas de indexación han sido propuestos [17, 29, 33]. En particular el sistema
de indexamiento de eXist usa un esquema numérico para identificar nodos en un docu-
mento XML y determinar relaciones entre nodos en el árbol del documento. Lee Yong
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 42
Kyu[28] propone una forma de númeración en la cual se modela el árbol del documento
como un árbol k-enario, en donde k es igual al máximo número de nodos hijos en el
árbol. A cada nodo de este árbol se le agrega un único identificador por medio de un
recorrido en level-order es decir, un recorrido por niveles. Ejemplo de un árbol con a lo
más dos nodos hijo:
<libro>
 <nombre>XML Data Management</nombre>
 <datos>
 <editorial>Addison</editorial>
 <autor>Akmal Chaudhri</autor>
 </datos>
</libro>
1 libro
2 nombre 3 datos
4 XML Data Management 5
6 editorial
7 autor
8 9 10 11 12 Addison
13 14 Akmal Chaudhri
15
Este árbol posee ciertas peculiaridades, por ejemplo se puede obtener el identificador
del nodo padre de un nodo i mediante la siguiente función.
parenti =
[
(i − 2)
k
+ 1
]
Este algoritmo tiene ciertas fallas ya que podemos tener en un documento relativamente
pequeño algún nodo que tenga un gran número de nodos hijos, con lo cual para poder
mantener balanceado nuestro árbol k-enario tendŕıamos que insertar muchos mas nodos
en todos los niveles del árbol para mantenerlo balanceado.
Por esto es que eXist implementó una extensión a este algoritmo, en el cual para superar
los problemas de ĺımite de tamaño se decidió desechar la idea de tener forzosamente un
árbol k-enario. En vez de eso el número de hijos de un nodo es asignado para cada nivel
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 43
del árbol, se tiene que para dos nodos x o y de un árbol, el tamaño(x ) = tamaño(y)
y el nivel(x )=nivel(y), donde el tamaño(n) es el número de hijos de un nodo n y el
nivel(m) el tamaño del camino de la ráız al nodo m.
Ejemplo:
<libro>
 <nombre>XML Data Management</nombre>
 <datos>
 <editorial>Addison</editorial>
 <autor>Akmal Chaudhri</autor>
 </datos>
</libro>
1 libro
2 nombre 3 datos
4 XML Data Management 5 6 editorial
7 autor
8 9 10 Addison 11 Akmal Chaudhri
Con esto se pueden tener documentos con grandes cantidades de nodos en niveles bajos
y con pocos nodos en los primeros niveles de la jeraqúıa de elementos, aśı mismo se incre-
menta el nivel de indexamiento al poder tener documentos mas grandes. Comparándolo
con el esquema original de numeración, se tienen que insertar menos identificadores y al
insertar un nodo en los niveles mas bajos no se afecta a los nodos de niveles superiores.
Con esto se puede observar que eXist ha sido diseñado para proveer una implementa-
ción mas completa de XPATH y para los casos de uso mas requeridos.
Considere la siguiente expresión.
/libro[contains(.,"XPATH"]//titulo
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 44
En esta expresión se seleccionan todos los nodos relacionados que cumplan la condición
de tener la frase XPATH en algún t́ıtulo. Con la manera de indexamiento de eXist se
obtiene el identificador del nodo padre para cada nodo que se evalue en la expresión.
Otro beneficio adicional es la reducción en el tamaño de almacenaje de un nodo ya que
no se tiene que guardar referencias extra a padres, hermanos, hijos o atributos; además
de que cualquier nodo enel documento XML puede ser utilizado como el comienzo para
una expresión en XPATH.
Esta es la principal diferencia respecto a Xindice en cuanto a indexación; esto es,
como Xindice no mantiene un ı́ndice entre nodos solamente puede realizar una con-
sulta XPATH mediante un recorido top-down.
2.7.1. Organización de los Datos e Indexamiento
eXist utiliza cuatro archivos de indexación para mantener el funcionamiento del
sistema manejador de bases de datos.
Collections.dbx- este archivo mantiene la jerarqúıa de las colecciones.
dom.dbx- colecta nodos en una página y asocia los identificadores únicos a los nodos
actuales (necesarios para el indexamiento).
elements.dbx- indexa elementos y atributos.
words.dbx- mantiene referencias a ocurrencias de palabras en el texto y es usada
para búsquedas globales.
Todos los ı́ndices están basados en árboles B+. Los ı́ndices para los elementos, atri-
butos y palabras son guardados por colecciones y no por documentos. Esto es mejor
en rendimiento ya que usualmente buscamos a través de colecciones y no en un sim-
ple documento; por ejemplo buscamos todos los libros con la palabra “XPATH” en la
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 45
colección de libros de computación.
El archivo Collections.dbx mantiene la jerarqúıa de colecciones y algo muy importan-
te es que mapea los nombres de las colecciones con los objetos colección. Un identicador
único es asignado a cada colección y documento durante la indexación.
El archivo dom.dbx31 es el principal componente de la arquitectura nativa de eXist.
Consiste de un archivo paginado en el cual todos los nodos del documento son guar-
dados de acuerdo al Document Object Model32 y de un árbol B+ multi-ráız para ir
asociando los identificadores únicos de los nodos de un nivel superior con las direcciones
de los nodos en la sección de datos (similar a Xindice).
Solo los elementos de un nivel superior son indexados en el árbol B+. Atributos, texto,
y elementos de niveles inferiores son escritos a las páginas de datos sin añadir una llave
en el árbol B+.
Documento D1
Documento D2
ID del Nodo
ID del Nodo
Dirección
Dirección
Páginas de Datos
Nodos DOM
Nodo N1 Nodo N2 Nodo N3
Árbol B+ Multiraíz
Figura 2.7.1 Organización de documentos XML en eXist
En la Figura 2.7.1 se puede observar que eXist no guarda enlaces entre sus nodos. La
implementación de DOM conf́ıa en el esquema de numeración de nodos para determinar
las relaciones. Por ejemplo para obtener el padre de un nodo, el identificador único del
31 También llamado XML data store.
32 DOM
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 46
padre es calculado del identificador único del nodo actual.
Elementos y atributos son mapeados a identificadores únicos de los nodos en el archivo
elements.dbx. Cada entrada consiste de una llave que consiste de <collection-id,
name-id> y un arreglo de valores que contiene una lista ordenada de identificadores de
documentos e identificadores de nodos, los cuales corresponden a los elementos y atri-
butos que concuerdan con el name-id. Por ejemplo, para encontrar todos los caṕıtulos
en una colección de libros se requiere de un simple ciclo para encontrar todos los iden-
tificadores únicos de los nodos que apunten a caṕıtulos.
<collection-id,
 name-id>
Llaves del Árbol B+
doc-id node-id doc-id ...... doc-id ......
Valor del Árbol B+: Arreglo de identificadores de
nodos separadolos por identificadores de documentos.
Figura 2.7.2 Organización para elementos y atributos.
Finalmente, el archivo words.dbx es similar al archivo elements.dbx pero a diferencia
de éste las llaves son compuestas de la siguiente manera <collection-id, keyword>. En
el cual cada entrada tiene una lista de valores que apunta a un texto o atributo donde
la palabra apareció.
CAPÍTULO 2. BASES DE DATOS NATIVAS EN XML 47
2.8. Comparativas
En la siguiente tabla se hace una comparación entre eXist y Xindice:
La gran diferencia entre Xindice y eXist se centra principalmente en la forma de in-
dexamiento ya que de esto depende el rendimiento y velocidad cuando se ejecutan las
consultas.
Caṕıtulo 3
Diseño e Implementación
En los caṕıtulos anteriores se analizaron las distintas opciones para la implementa-
ción del sistema, se explicó el por qué de utilizar XML, herramientas necesarias para
su manipulación, aśı como la forma en la cual funcionan los dos principales sistemas
manejadores de bases nativas en XML aśı como sus ventajas y desventajas. Es por eso
que éste caṕıtulo se enfoca en la forma en la cual se diseñó e implementó la aplicación.
3.1. Requerimientos y Análisis
El sistema manejador de prácticas y ejercicios permite consultar prácticas y ejer-
cicios relacionados con bases de datos aśı como almacenar este tipo de información
mediante XML. Tiene los siguientes requerimientos.
1. Modelar las prácticas y ejercicios de la material “Bases de Datos”[26].
2. Estructurar de una manera clara y eficiente la forma de consultar las diferentes prácti-
cas y ejercicios.
3. Facilitar la tarea de crear prácticas y ejercicios para los diferentes temas relacionados
con Bases de Datos.
48
CAPÍTULO 3. DISEÑO E IMPLEMENTACIÓN 49
Con respecto al primer y segundo punto, los ejercicios se modelarán para que pue-
dan ser utilizados por las bases nativas en XML, un punto cŕıtico a analizar, es tener
en cuenta la estructura óptima para el uso de éstas.
La forma en la cual se consultarán las prácticas y ejercicios será por medio de temas y
dificultad. Teniendo los siguientes temas: Modelo Entidad-Relación, Modelo Relacional,
Álgebra Relacional y Normalización; aśı como las siguientes dificultades: fácil, media y
dif́ıcil.
Con respecto al tercer punto el sistema contará con un módulo para agregar nuevas
preguntas y ejercicios a través de una sencilla interfaz de captura.
3.2. Modelado
Tomando en cuenta que las prácticas y ejercicios de la materia de Sistemas de Bases
de Datos se encontraban como datos no-estructurados se procedió a convertir a éstos
datos en datos semi-estructurados para después modelarlos en XML y utilizarlos en una
base de datos nativa en XML.
Se siguieron los siguientes pasos:
Diseñar la estuctura de los documentos XML.
Crear la DTD aśı como el Esquema asociado al archivo XML, con el fin de validar
nuestros documentos y ejemplicar el uso de ambos.
Una vez creado el modelo, el esquema y DTD asociado a éste, se convirtieron los
ejercicios y prácticas de la materia Sistemas de Bases de Datos.
En el siguiente ejemplo de un ejercicio de Bases de Datos en XML se muestra la for-
ma en la cual se manejaron las preguntas, respuestas y tips del sistema. Como punto
CAPÍTULO 3. DISEÑO E IMPLEMENTACIÓN 50
importante se observa que con ésta forma de modelado se puede saber si la pregunta
pertence a un tema en espećıfico; aśı como saber que requisitos son necesarios antes de
contestar el ejercicio. Ejemplo:
<?xml version="1.0" encoding="UTF-8"?>
<tema titulo="normalizacion">
<requisitos>Algebra Relacional</requisitos>
<pregunta dificultad="baja" id="0">
a) Muestra que la siguiente regla es una regla
valida de dependencias funcionales, sino da
un ejemplo donde no se satisfaga.
Si A->B entonces B->A
</pregunta>
<respuesta dificultad="baja" id="0">normalizacion_baja_0.txt</respuesta>
<tips dificultad="baja" id="0">
Puedes utilizar un tabla para ejemplificar.
</tips>
<pregunta dificultad="media" id="0">
a) Sea: R(A,B,C,D) con F={AB->C, C->D, D->A}
a.1)Encontrar la cerradura de todos los posibles
conjuntos de atributos de R y las dependencias
funcionales que se obtienen usando las reglas
de inferencia.
a.2)Decir cual o cuales son el conjunto de
atributos clave.
a.3)Decir cual o cuales son el conjunto de
atributos superclaves.
a.4)Encontrar las dependencias funcionales que
violan BCNF.
a.5)Normalizar usando BCNF
</pregunta>
<respuesta dificultad="media" id="0">normalizacion_media_0.txt</respuesta><tips dificultad="media" id="0">
No hay tips que mostrar
</tips>
<pregunta dificultad="alta" id="0">
a) Sea: R(A,B,C,D,E) con F={AB->C, DE->C, B->D}
a.1)Encontrar la cerradura de todos los posibles
conjuntos de atributos de R y las dependencias
funcionales que se obtienen usando las reglas
de inferencia.
a.2)Encontrar las dependencias funcionales que
violan BCNF.
a.3)Normalizar usando BCNF
a.4)Encuentra las violaciones a la 3NF
a.5)Normaliza usando la 3NF
</pregunta>
<respuesta dificultad="alta" id="0">normalizacion_alta_0.txt</respuesta>
<tips dificultad="alta" id="0">
No hay tips que mostrar
</tips>
</tema>
CAPÍTULO 3. DISEÑO E IMPLEMENTACIÓN 51
La DTD para el documento XML quedó de la siguiente manera:
<?xml version=’1.0’ encoding=’UTF-8’?>
<!--- Elementos necesarios para nuestro documento XML -->
<!ELEMENT tema (requisitos|pregunta|respuesta|tips)*>
<!ATTLIST tema
titulo CDATA #REQUIRED
>
<!--- Elemento Requisitos -->
<!ELEMENT requisitos (#PCDATA)>
<!--- Elemento Pregunta -->
<!ELEMENT pregunta (#PCDATA)>
<!ATTLIST pregunta
id CDATA #REQUIRED
dificultad CDATA #REQUIRED
>
<!--- Elemento Respuesta -->
<!ELEMENT respuesta (#PCDATA)>
<!ATTLIST respuesta
id CDATA #REQUIRED
dificultad CDATA #REQUIRED
>
<!--- Elemento Tips -->
<!ELEMENT tips (#PCDATA)>
<!ATTLIST tips
id CDATA #REQUIRED
dificultad CDATA #REQUIRED
>
El esquema para el documento XML quedó de la siguiente manera:
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns:xs="http://www.w3org/2001/XMLSchema">
<xs:element name="tema" type="xs:mixed">
<xs:attribute name="titulo" type="xs:string" required="yes" />
</xs:element>
<xs:element name="requisitos" type="xs:string">
</xs:element>
<xs:element name="pregunta" type="xs:text">
<xs:attribute name="dificultad" type="xs:string" required="yes" />
<xs:attribute name="id" type="xs:string" required="yes" />
</xs:element>
<xs:element name="respuesta" type="xs:text">
<xs:attribute name="dificultad" type="xs:string" required="yes" />
<xs:attribute name="id" type="xs:string" required="yes" />
</xs:element>
<xs:element name="tips" type="xs:text">
<xs:attribute name="dificultad" type="xs:string" required="yes" />
<xs:attribute name="id" type="xs:string" required="yes" />
</xs:element>
</xs:schema>
CAPÍTULO 3. DISEÑO E IMPLEMENTACIÓN 52
3.3. Arquitectura
El sistema tiene una arquitectura Cliente-Servidor[31] tal y como se muestra en el
siguiente esquema.
SMBD
eXist
Servidor de Aplicaciones
Interfaz del Usuario
Esta aquitectura consta de tres capas o niveles.
Nivel de Almacenamiento. Utiliza un Sistema Manejador de Bases de Datos, el cual
almacena los archivos XML.
Nivel Lógico. El cual consta de las reglas del negocio es decir, la lógica del programa
en la cual se utiliza un servidor de aplicaciones.
Nivel de Presentación. Interfaz del usuario.
CAPÍTULO 3. DISEÑO E IMPLEMENTACIÓN 53
Cada capa o nivel tiene un cometido espećıfico, esto con el fin de que cada tarea se
realice con mayor eficiencia, además de simplicar la lógica de la aplicación.
Caracteŕısticas del modelo cliente-servidor.
Ventajas
El servidor atiende a múltiples clientes en forma concurrente.
El cliente y el servidor pueden estar en diferentes plataformas.
El cliente y el servidor pueden actuar como una sola entidad o como entidades sepa-
radas.
En general no se necesitan muchos recursos (hardware) para ejecutar la aplicación.
Desventajas
Puede ser que el servidor tenga una excesiva carga de trabajo.
Se puede tener la carga de trabajo en una sola capa del sistema.
3.4. Casos de Uso y Diagramas de Actividad
En el siguiente caso de uso se muestra la funcionalidad del sistema, el cual es capaz
de consultar ejercicios aśı como agregar preguntas a nuestra base de datos en XML.
Cualquier usuario puede consultar y aportar nuevos ejercicios al sistema con el fin de
tener un acervo de preguntas y ejercicios mas completo[32].
CAPÍTULO 3. DISEÑO E IMPLEMENTACIÓN 54
Usuario
Consultar Ejercicios y Prácticas
Agregar Ejercicios y Prácticas
Sistema
Figura 3.4.1 Casos de uso del sistema.
En la siguiente tabla se muestran el flujo del sistema para realizar las consultas al sis-
tema.
Tabla 3.4.2 Caso de uso para consultar ejercicios y prácticas.
CAPÍTULO 3. DISEÑO E IMPLEMENTACIÓN 55
En la siguiente tabla se muestran el flujo del sistema para agregar ejercicios al sistema.
Tabla 3.4.3 Caso de uso para agregar ejercicios y prácticas.
CAPÍTULO 3. DISEÑO E IMPLEMENTACIÓN 56
Consultar ejercicios y prácticas
El usuario selecciona el tema 
El usuario selecciona dificultad El usuario selecciona 
el número de
 preguntas
[No se pudo conectar a la base de datos]
Mensaje de Error
[Todo es correcto]
Seleccionar números 
aleatorios dependiendo
del número de preguntas. 
Obtener las preguntas
respuestas y tips seleccionados
Figura 3.4.4 Diagrama de actividad correspondiente al caso de uso para consultar
ejercicios y prácticas.
Agregar ejercicios y prácticas
El usuario selecciona 
el tema 
El usuario contesta la
pregunta
El usuario contesta la 
respuesta 
[Campo Inválido]
Mensaje de error
"Campo Inválido"
Mensaje de error 
Monstrar los datos
de la pregunta agregada
El usuario contesta
 los tips
[No se pudo conectar a la base de datos]
El usuario selecciona 
la dificultad
Agregar la pregunta
a la base de datos
Figura 3.4.5 Diagrama de actividad correspondiente al caso de uso para agregar
ejercicios y prácticas.
CAPÍTULO 3. DISEÑO E IMPLEMENTACIÓN 57
3.5. Diagramas de Secuencia
Usuario
setTema(String temas)
Consultas JavaBeanConsultas
setDificultad(String dificultad)
setNumPreguntas(int cantidad)
doPost()
hasConsulta()
escogeNumeros()
getColeccion()
getNumPreguntasBasedeDatos()
setRespuesta()
devolverPagina(XML Respuesta)
Figura 3.5.1 Diagrama de secuencia para el caso de uso para consultar el sistema.
En la Figura 3.5.1 se muestra la secuencia del programa para consultar el sistema,
esta secuencia comienza con una petición del usuario, la cual es recibida por la clase
Consultas, la cual se encarga de mandar el tema, dificultad y cantidad de preguntas a
la clase JavaBeanConsultas aśı como llamar al método hasConsulta()1 .
El sistema al ser también un generador de prácticas siempre trae preguntas, respuestas
y tips distintos en cada consulta, esto se hace mediante generar número aleatorios2 los
cuales concuerdan con los identificadores de las preguntas, respuestas y tips en la base
1 El cual es el encargado de realizar la consulta a la base de datos.
2 Mediante el método escogeNumeros().
CAPÍTULO 3. DISEÑO E IMPLEMENTACIÓN 58
de datos. El método setRespuesta() es el método encargado de darle formato a las pre-
guntas, respuestas y tips para que finalmente mediante el método devolverPagina(XML
Respuesta) se presenten los resultados de la consulta al usuario.
Usuario
setTema(String temas)
Actualizar JavaBeanActualizar
setPregunta(String pregunta)
setRespuesta(String respuesta)
doPost()
actualizarColeccion()
devolverPagina()
setTips(String Tips)
setDificultad(String dificultad)
getTema()
getPregunta()
getRespuesta()
formatea()
getTips()
getDificultad()
getColeccion()
Figura 3.5.2 Diagrama de secuencia para el caso de uso para agregar datos al sistema.
En la Figura 3.5.2 se muestra la secuencia del programa para agregar ejercicios, es-
ta secuencia comienza con una petición del usuario, la cual es recibida por la cla-
se Actualizar, la cual se encarga de mandar el tema, pregunta, respuesta, tip y
dificultad del ejercicio a la clase JavaBeanActualizar, aśı como llamar al método
CAPÍTULO 3. DISEÑO E IMPLEMENTACIÓN 59
actualizarColección()3 .
La clase JavaBeanActualizar manda llamar al método formatea() el cual es el en-
cargado de darle formato a nuestro ejercicio para que pueda ser actualizado en la base
de datos, finalmente el método devolverPágina() devuelve un mensaje de error si
surgió algún problema al momento de actualizar la colección o un mensaje