1 00:00:05,870 --> 00:00:18,370 Bueno, la videoconferencia trata del almacenamiento de la información y corresponde al tema 6 del módulo. 2 00:00:19,829 --> 00:00:26,129 He intentado, como en todas las videoconferencias, cojo toda la información que hay en el aula virtual y la completo, 3 00:00:26,129 --> 00:00:30,530 incluso la pongo un poquito más clara, con más ejemplos, etc. 4 00:00:30,530 --> 00:00:39,450 Que sepáis que lo que entra en el examen será toda la parte que aparece en el aula virtual. 5 00:00:40,030 --> 00:00:48,929 Yo soy muy fiel a la aula virtual en cuanto a los contenidos que voy a reflejar aquí, en esta videoconferencia, igual que me ha pasado en todas las que os he colgado. 6 00:00:50,609 --> 00:00:54,570 Entonces, ¿cómo empieza el aula virtual? Bueno, empieza repasando XML. 7 00:00:54,570 --> 00:01:11,450 XML ya habíamos visto lo que era. Hemos visto que estaba muy aceptado y que se aceptaba con dos finalidades. Una, porque guardaba información estructurada, como la guardaba, la guardaba de manera jerárquica y podía comunicar datos entre sistemas. 8 00:01:11,450 --> 00:01:34,069 Entonces, vimos también que se podía separar la información del formato de presentación. ¿Cómo se trabajaba con XML? Si lo recordáis, pues teníamos un ficherito en el que los datos estaban como nodos, teníamos nados, atributos, había un orden y había una jerarquía. 9 00:01:34,069 --> 00:01:44,390 Realmente XML no deja de ser nada más que un árbol con una jerarquía donde hay nodos con subnodos y luego cada uno de ellos puede tener atributos. 10 00:01:44,390 --> 00:01:58,549 Para acceder a los datos se debía, lógicamente, si tú quieres acceder a los datos, esto no es como en una base de datos relacional en la que tú necesitas un dato, a través de un índice pasas a buscar ese dato, sino que aquí necesitas parsear todo el fichero. 11 00:01:58,969 --> 00:02:03,790 Tienes que pasar y comparar cada uno de los datos hasta que tienes el dato que tú necesites. 12 00:02:04,069 --> 00:02:20,210 XMLE lógicamente no tiene índices y necesitas ese parseo para poder leer e interpretar todo XMLE y hasta llegar al dato, si el dato que requieres es el de Madrid, tienes que parsear todo hasta que obtienes ese dato. 13 00:02:22,280 --> 00:02:31,699 Como XML puede actuar como base de datos. Podemos ver XML como una base de datos, pero claro, no será una base de datos, será no relacional. 14 00:02:32,740 --> 00:02:40,099 También podemos ver una colección de archivos XML como una tabla con registros y cada archivo XML sería un documento independiente. 15 00:02:41,360 --> 00:02:50,060 En cuanto a esquema y estructura, ya lo hemos visto, pueden seguir un mismo esquema a través del XSD, pero no es obligatorio. 16 00:02:50,060 --> 00:02:57,520 y nos va a otorgar mucha flexibilidad, accesibilidad individual y modularidad. 17 00:02:58,800 --> 00:03:00,939 Ventajas del almacenamiento XML. 18 00:03:02,000 --> 00:03:04,379 Como he dicho, gran flexibilidad. 19 00:03:05,259 --> 00:03:09,479 No te impone una estructura fija, sino que puedes ponerla tú como quieras. 20 00:03:09,580 --> 00:03:11,159 Tú la creas y tú la puedes poner. 21 00:03:11,360 --> 00:03:14,180 Eso sí, luego esa estructura sí va a ser jerárquica. 22 00:03:14,180 --> 00:03:28,879 Se puede compartir información y en eso pues como su formato pues es muy estándar pues se puede acoger pues muchos sistemas y entonces pueden o tecnologías que pueden utilizar o compartir esa información. 23 00:03:28,879 --> 00:03:45,780 Quizás esa sea la gran ventaja de XML. Es compatible con estándares de interoperabilidad en la industria con SOAP, con XSLT, etc. Y útil en aplicaciones que requieren estructura y libertad. 24 00:03:45,780 --> 00:04:07,520 ¿Eso qué quiere decir? Que puedes definir las reglas claras, pues lo puedes hacer de una manera clara con el ETD, con el XSD y libertad, que no estás obligado a seguir una determinada, no estás obligado a seguir una única forma, sino que tú puedes adaptar el contenido como tú lo creas. 25 00:04:07,520 --> 00:04:34,279 En ámbito de aplicación tenemos dos, que sería uno, sistema centrado en los datos y sistema centrado en documentos. Bueno, esto es en función de los datos que vas a querer recoger. En cuanto a ser centrado en los datos, pues sería una estructura bien definida, datos actualizables y, por ejemplo, en facturas, en artículos. En cambio, en un sistema centrado en documentos tendríamos un tamaño y estructura variable, contenido rico y flexible y serían ejemplos como contratos, informes, etc. 26 00:04:34,279 --> 00:04:43,779 Comparativa con base de datos relacionales. Os he puesto aquí en cajita o remarcado en cuadros rojos las diferencias. 27 00:04:44,180 --> 00:04:48,459 Veis que relacionadas en cuanto a estructura, lógicamente una base de datos relacional es rígida, 28 00:04:48,459 --> 00:04:54,600 mientras que una XML, hemos visto que una de las características que la identificaba era la flexibilidad. 29 00:04:55,399 --> 00:05:02,860 En cuanto al tipo de datos, lógicamente una relacional, lo único, tú tienes tablas y columnas en las que los datos están allí puestos de una manera plana. 30 00:05:02,860 --> 00:05:15,420 En cambio, aquí en XML no hay una estructura plana, es un árbol de nodos. Si tú quieres llegar hacia un determinado destino, tendrás que recorrer distintos nodos y subnodos de dicho árbol, lo que hablábamos del parseo. 31 00:05:16,199 --> 00:05:31,459 Ideal para datos estructurados en el caso de las relacionales, pero en el caso de XML, pues, si es verdad que tú puedes hacer ese XML lo más complejo que tú puedas hacerlo, a diferencia de los datos estructurados en una base de datos relacional. 32 00:05:31,459 --> 00:05:57,740 Entonces, hablamos de una mayoría complejidad. Y intercambio de datos, pues en uno es limitado y hemos visto que en XML, pues intercambio de datos sería favorable, sería estándar. Tenemos en cuanto a que la base de datos relacional, pues si es verdad que es actualizable, quiere decir que puedes utilizar consultas con la date, insert, delete. En cambio, en XML, pues es un poquito más estático. Tendrías que reprocesarlo. 33 00:05:58,540 --> 00:06:03,180 ¿Qué más? En cuanto a base de datos relacional, ya hemos dicho que la tabla tenía filas y columnas. 34 00:06:03,259 --> 00:06:06,379 Aquí estamos hablando de una jerarquía en la que hay nodos, hay atributos. 35 00:06:07,319 --> 00:06:15,779 Base de datos relacional se utilizan fundamentalmente con aplicaciones que tengan muchos registros. 36 00:06:16,720 --> 00:06:24,839 En cambio, XML, su peculiaridad o su gran ventaja sería que puedes utilizarlo para manejar documentos complejos. 37 00:06:24,839 --> 00:06:46,439 En cuanto a base de datos relacional, utilizamos SQL, en XML veremos que se utilizará el XPAT y el XQuery, es decir que toda esta videoconferencia converge en una dirección, en la dirección a que al final veamos XQuery y cómo podemos, esa base de datos XML, cómo podemos acceder a los datos a través de XQuery. 38 00:06:46,439 --> 00:07:01,800 Y, por último, tenemos que base de datos relacional sería una base de datos de alta eficiencia, rápida en búsquedas, tiene índices. En cambio, en XML tendría otro tipo de características, portabilidad, perfecto para compartir datos, ya lo hemos dicho una y otra vez. 39 00:07:01,800 --> 00:07:18,720 En cuanto a integración de XML y base de datos, pues tenemos que los sistemas modernos deben exponer los datos en relaciones como XML, es decir, que facilita la transferencia de datos, la importación y exportación entre sistemas y la interoperabilidad entre plataformas. 40 00:07:18,720 --> 00:07:45,560 Ya lo hemos visto en lo que he puesto antes. La verdad es que hay diferentes importantes entre la XML y las bases de datos normales o habituales. Aquí estaría todo lo que carece. Las XML, que serían sin almacenamiento eficiente, sin índices, no van a tener índices, sin control de concurrencia, sin transacciones, sin seguridad integrada, sin integridad referencial, sin triggers. 41 00:07:45,560 --> 00:07:58,220 ¿Es XML una alternativa a la base de datos? Pues no hablamos de alternativa, estaremos hablando de algo complementario. No para tareas transaccionales, ya lo hemos visto anteriormente. 42 00:07:59,040 --> 00:08:14,319 XML sería ideal para qué? Vuelvo a repetir lo mismo que he dicho antes, intercambio de datos, representación estructurada, comunicación entre sistemas. En cambio, las bases de datos son mejores para utilizar grandes volúmenes de datos, transacciones e integridad y rendimiento. 43 00:08:15,560 --> 00:08:24,620 Un ejemplo de XML tendría que ser Hubs, que es una herramienta que se conjuga XML con Java, en el que convierte objetos Java en XML y al revés. 44 00:08:25,420 --> 00:08:30,279 Aquí viene el enlace, como viene en la aula virtual, para si queréis más información sobre esto. 45 00:08:31,560 --> 00:08:37,179 Conclusión, que XML complementa la base de datos, no la sustituye y que es clave en la integración e intercambio de datos. 46 00:08:37,179 --> 00:08:44,419 Lo hemos visto anteriormente, su uso común serían estos que aparecen aquí, almacenamiento portable y legible, configuración y comunicación entre plataformas, APIs web. 47 00:08:44,419 --> 00:08:59,759 Y conoce sus ventajas y limitaciones, permite usarlo correctamente en arquitectura de software. Quiere decir, tenemos que saber concretamente cuáles son sus limitaciones, aparte de sus ventajas, para saber dónde utilizarlo, dónde va a ser útil. 48 00:08:59,759 --> 00:09:21,200 XML y bases de datos relacionales, como las bases de datos relacionales son las más habituales, una de las maneras que podemos almacenar datos sería transformar esos datos XML, por ejemplo, en tablas y, por tanto, pasarlo a bases de datos relacionales. 49 00:09:21,200 --> 00:09:40,220 Veremos que ahora no es tan fácil hacerlo, pero se puede hacer. ¿Por qué hacerlo? Porque están asociadas al lenguaje standard SQL, porque todo el mundo usa las bases de datos relacionales, pero tenemos que las estructuras de XML eran flexibles y jerárquicas. 50 00:09:40,220 --> 00:09:57,299 Hay que transformar eso en componentes de una base de datos relacional. Hay uno de los middleware que se utilizan, aunque he puesto aquí varios, pero sería el que acabo de decir antes con el JDBC en Java y el Hubs. 51 00:09:57,299 --> 00:10:11,639 ¿Es posible almacenar XML en base de datos relacionales? Pues sí, es posible, pero no siempre es eficiente. Hay que tener muy claro que el paso de XML a base de datos relacionales puede provocar una pérdida de semántica. 52 00:10:11,639 --> 00:10:37,139 En cuanto a semántica, me explico. Quiero decir que el significado que puede tener en el propio archivo XML, en esa jerarquía, en ese árbol jerárquico que tiene, puede perder su semántica cuando la pasamos a tablas y no solo a tablas, sino que tenemos que pasarlo a tablas y a las relaciones que hay entre dichas tablas, como sucede en una base de datos relacional. 53 00:10:37,139 --> 00:10:58,320 Entonces, problemas para almacenar XML en una base de datos relacional. Estructura regular frente a una estructura en XML, lógicamente es una estructura heterogénea. Estamos hablando de datos más complejos. Anidamiento profundo en XML versus datos planos en SQL. Ya lo vimos que los datos en una base de datos relacional son datos planos. 54 00:10:58,320 --> 00:11:13,120 En cambio, en XML estamos hablando de datos anidados unos dentro de otros. Estamos hablando de una jerarquía. XML tiene un orden definido, SQL no, y XML es disperso y SQL es denso. Muchos datos. 55 00:11:13,120 --> 00:11:32,659 Por demás, de mapeo jerárquico, pues tenemos que representar datos jerárquicos en estructuras planas, pues requiere todo esto que aparece aquí. Descomposición del árbol, tienes que coger el árbol y lo tienes que descomponer como puedas en varias tablas, como puedas de la mejor manera posible. 56 00:11:32,659 --> 00:11:56,259 Luego tienes que establecer las relaciones que va a haber entre esas tablas que has creado a partir de esos datos del fichero XML. Y lo que hablaba anteriormente, eso puede provocar una pérdida de semántica e incluso de orden, porque también tenemos que tener claro que un fichero XML tiene un orden, aparte de una jerarquía o una estructura arbórea, tiene un orden en cuanto a los datos, a la complejidad de esos datos. 57 00:11:57,240 --> 00:12:07,740 Esto requiere un modelo muy complejo y esto va a generar, si lo queremos automatizar, un mayor coste computacional transformarlo a una base de datos relacional. 58 00:12:08,779 --> 00:12:15,720 La razón es porque aún así aún se usa SQL para XML, ¿por qué? Porque es lo que más se utiliza. 59 00:12:16,139 --> 00:12:22,519 Entonces es bastante más fácil coger un fichero XML y transformarlo a algo que es lo que más se utiliza. 60 00:12:22,519 --> 00:12:43,240 El tema de base de datos relacionales está muy establecido, son conocidos, fiables y optimizados, alto rendimiento y escalabilidad. Los usuarios y desarrolladores ya están familiarizados con SQL. Si veis, pues hay bastantes razones por las que es una buena táctica pasar un fichero o ficheros XML a una base de datos relacional. 61 00:12:43,240 --> 00:12:55,509 Es decir que también, como hablaremos ahora a continuación, hablaremos de las bases de datos orientadas a objetos y por último hablaremos de las bases de datos XML nativas. 62 00:12:55,990 --> 00:13:01,710 Entonces, ¿por qué no usar esas bases de datos XML nativas? ¿Por qué? Porque son más recientes y menos extendidas. 63 00:13:02,909 --> 00:13:08,409 Soluciones intermedias. Existen herramientas y técnicas que permiten trabajar con XML en bases de datos relacionales. 64 00:13:08,409 --> 00:13:21,870 Y aquí tenemos almacenarlo con un campo CLOP o mapeo relacional XML. Aquí tenemos XQuery, XPath, Hubs, que ya lo he dicho, middlewares que integran esa transformación XML a SQL. 65 00:13:22,769 --> 00:13:38,330 Aquí tenemos un ejemplo de base de datos relacional a XML. Si veis, tenemos una base de datos relacional con una tabla. Tenemos la tabla clientes y veis que tiene tres campos, ID, nombre y email. 66 00:13:38,409 --> 00:14:01,210 Entonces, tenemos que hacer una traducción a XML, pero para hacerla correctamente, primero decir que a nivel semático a veces no es muy trivial. Aquí este caso es muy sencillo, pero si veis lo que ha convertido lo que es el fichero XML, lo ha convertido en una raíz de clientes y dentro me ha metido cada uno de los clientes. 67 00:14:01,210 --> 00:14:14,190 Cada cliente, lógicamente, podría haber puesto esos campos como atributos o lo podría haber puesto como ha puesto aquí, que son subcampos dentro del campo cliente, dentro de la etiqueta cliente. Y lo ha definido así. 68 00:14:14,190 --> 00:14:33,029 Y después podemos crear también o definir, de hecho es necesario definir un DTD o un XSD, aquí hay que generar un XSD para definir, por supuesto que en una tabla relacional como puede ser la tabla clientes, estos datos que aparecen aquí se les asigna un tipo a cada uno de ellos. 69 00:14:33,029 --> 00:14:46,789 Entonces, ¿cómo generamos esos tipos? Pues los generamos a través de un XSD, aquí le está dando el tipo de integer, de string, también está diciendo el número máximo de ocurrencias que pueden tener en este XSD, etc. 70 00:14:47,990 --> 00:15:02,970 No hay decir que, bueno, este es un caso muy sencillo, entonces, bueno, pues es verdad que sale bastante bien, pero cuando tenemos un fichero con unos datos mucho más complejos y cuando metemos no solo una tabla, si empezamos a meter un montón de tablas, pues la cosa se complica. 71 00:15:03,029 --> 00:15:14,889 Entonces existen muchos enfoques posibles y decir que no hay una solución única correcta. Luego tenemos que hay que definir también el problema de las claves primarias, las claves foráneas, que veremos a continuación. 72 00:15:17,809 --> 00:15:34,909 Aquí está haciendo cada uno de los pasos del mismo ejemplo que anteriormente y si veis crear el esquema XML, lo que ha hecho es aquí clientes y ahora si veis hay otra opción, podría haberlo metido como en este otro que tiene los tres campos, lo ha metido como si fueran tres atributos de cliente. 73 00:15:34,909 --> 00:15:48,070 Y le ha metido cada uno de los clientes, tendrá cada uno de los, esto sería pues cada uno de estas etiquetas clientes sería pues como si fuera una fila dentro de la tabla de base de datos relacional. 74 00:15:48,509 --> 00:15:55,990 Entonces veis que le ha metido a cada fila, lo mete como sus tres columnas, lo mete como tres atributos. 75 00:15:57,070 --> 00:16:03,750 Esta sería una buena técnica de hacer pues ese paso de la tabla clientes a la representación en XML. 76 00:16:03,750 --> 00:16:22,190 En cuanto a la XSD, igual que te he dicho antes, cada uno de los campos tendrá un tipo de dato que hay que definir a través de aquí de la attribute, le mete el tipo, el uso, si va a ser opcional o requerido y eso es lo que va a simular el caso de los not null y del label. 77 00:16:22,190 --> 00:16:37,389 El not null, que significaba que una columna no podía estar vacía, pues es como si dijéramos que tiene que ser obligatoria, con lo cual aquí le ponemos el required. En cambio, pues el no label sería, significa que una columna puede estar vacía. 78 00:16:37,389 --> 00:16:52,169 Entonces, ¿qué ponemos? Se equivaldría al campo opcional. Aquí ponemos useOptional. Esto sería en cuanto a lo más sencillo. ¿Qué sucede en cuanto a representar las claves primarias? 79 00:16:52,169 --> 00:17:03,809 Las claves primarias se representarían a través del campo ID, pero recordar que XML tiene el problema de que un ID debe ser único en todo el documento. 80 00:17:03,809 --> 00:17:23,809 Entonces, para establecer varios IDs y que sean únicos en todo el documento, pues, habría que ponerle, pues, anteponerle una palabra al mismo ID, pues, que sería, pues, en función de cada uno de los IDs que vamos proporcionando, pues, por ejemplo, en función, pues, el nombre de la etiqueta y con ello podríamos generar uno de manera distinta. 81 00:17:23,809 --> 00:17:27,549 También tenemos que simular las claves foráneas 82 00:17:27,549 --> 00:17:28,990 ¿Cómo simulamos las claves foráneas? 83 00:17:29,029 --> 00:17:31,289 Pues hay dos representaciones posibles 84 00:17:31,289 --> 00:17:32,710 Una a través de elementos anidados 85 00:17:32,710 --> 00:17:37,450 O a través de atributos de tipo IDREF que vimos 86 00:17:37,450 --> 00:17:41,630 En cuanto a como elementos anidados 87 00:17:41,630 --> 00:17:43,529 Si lo veis aquí, aquí tenemos dos tablas 88 00:17:43,529 --> 00:17:44,750 Que serían clientes y pedidos 89 00:17:44,750 --> 00:17:47,049 Si veis hay una clave foránea que indica 90 00:17:47,049 --> 00:17:51,670 Que este cliente ID hace referencia a la tabla clientes 91 00:17:51,670 --> 00:17:53,549 A la clave primaria de clientes 92 00:17:53,549 --> 00:18:16,029 Entonces, una de las maneras sería a través de elementos anidados. Los elementos anidados, si veis aquí, lo que ha hecho es clientes, le añade cada uno de los clientes, que sería con respecto al tabla pedido y la tabla dentro de clientes tendríamos aquí cada uno de los clientes, que sea cada una de las filas con su ID y con su nombre. 93 00:18:16,029 --> 00:18:31,009 Y, además, engloba allí dentro el que la tabla pedidos. Si veis, lo ha internalizado o lo ha anidado dentro del mismo para decir que pedidos depende de manera foránea con respecto a clientes. 94 00:18:31,589 --> 00:18:38,210 La otra opción sería a través del ID y IDREF. ¿Os acordáis de los temas anteriores como lo que se dedicaba al IDREF? 95 00:18:38,210 --> 00:18:43,089 La IDREF tú la creabas y haces referencia a una ID de la propia XML. 96 00:18:47,579 --> 00:18:53,500 Decir que no existe una única forma de traducir una base de datos relacional a XML y si ya lo habéis visto anteriormente, 97 00:18:54,220 --> 00:19:02,660 podemos utilizar cada una de las columnas o campos como atributos, los podemos utilizar tanto como subetiquetas de un nodo, etc. 98 00:19:03,000 --> 00:19:08,640 Pueden existir diferentes formas de estructurar los elementos, enfoques centrados en atributos o en elementos, lo que acabo de decir, 99 00:19:08,640 --> 00:19:25,119 Y esquemas más planos o más jerárquicos. Eso ya a elección. La elección dependerá del uso previsto del XML. Tendremos que ver cuál es el problema o el que nos subyace para ver cuál sería la fórmula más adecuada para nuestro caso en particular. 100 00:19:25,119 --> 00:19:35,299 Conclusión, el mapeo relacional a XML, es decir, transformar una base de datos relacional a XML implica decisiones de diseño. 101 00:19:36,019 --> 00:19:42,920 Se deben considerar unicidad de claves, colisiones de nombres, profundidad de la estructura, forma de representar las relaciones. 102 00:19:45,140 --> 00:19:49,700 Objetivo, pues como todo, siempre generar un XML estructurado, coherente y reutilizable. 103 00:19:51,730 --> 00:19:53,849 Ahora pasamos a las bases de datos orientadas a objetos. 104 00:19:53,849 --> 00:20:08,769 Veréis que una base de datos orientada a objetos, que no deja de ser un almacén de objetos, cada uno de ellos con sus atributos, es mucho más amigable con XML que lo que puede ser con una base de datos relacional. 105 00:20:09,910 --> 00:20:15,509 Hay que decir que una base de datos orientada a objetos implementa un modelo de objetos puro, no son extensiones de modelos.