Entregado Cap1,2y3 Doctorado 2007-08

DIT-UPM
PARTE I y II: Conceptos y Tcnicas de BD
Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica
NDICE
Parte I. Conceptos y Tcnicas de Bases de Datos _______________________________________ 1 Captulo 1. Introduccin y Contextualizacin a Bases de Datos. __________________________ 1
1.1.- Introduccin. Niveles de Abstraccin, Modelado Conceptual y Modelos de Datos.____________ 1 1.2.- Introduccin. Las Bases de Datos vistas desde los proyectos informticos. __________________ 3 1.3.- Introduccin. Las Bases de Datos vistas desde la Tecnologa Comercial. ____________________ 3
1.3.1.- Tres grandes alternativas tecnolgicas para registrar la Informacin. ________________________________ 3
1.4.- Situacin Actual y Consolidada de las BDs. ____________________________________________ 5

1.4.1.- Arquitectura Estndar de los SGBDs Centralizados (ANSI/X3/SPARC). _____________________________ 5 1.4.2.- Ejemplo de los tres Niveles de representacin de una BD Centralizada. ______________________________ 8
1.5.- Bases de Datos Centralizadas. Software. ______________________________________________ 8 1.6.- Bases de Datos Centralizadas. Usuarios y Aplicativos. ___________________________________ 9 1.7.- Bases de Datos Centralizadas. Arquitectura de Procesos. ________________________________ 9 1.8.- Bases de Datos Centralizadas. Componentes de un Sistema de Informacin. _______________ 10 1.9.- Sistemas de Informacin Centralizados e Interconectados. ______________________________ 11
Captulo 2. Interoperabilidad entre Bases de Datos Heterogneas y Distribuidas. ___________ 12

2.1.- Contextualizacin del Captulo. ____________________________________________________ 12 2.2.- Concepto de Interoperabilidad entre Sistemas de Informacin Heterogneos. ______________ 13 2.3.- El mundo de la Interconexin: OSI, DARPA, SNA Y DNA ______________________________ 15 2.4.- Niveles de Interoperabilidad._______________________________________________________ 17
2.4.1.- Primer Nivel de Interoperabilidad: TCP, Interconexin de Aplicaciones cualesquiera. _________________ 2.4.2.- Segundo Nivel de Interoperabilidad: Arquitectura Cliente/Servidor y Acceso Remoto a Bases de Datos.___ 2.4.2.1.- Las APIs. ____________________________________________________________________________ 2.4.3.- Tercer Nivel. Interoperabilidad entre BDs Centralizadas e Interconectadas o entre BDs Distribuidas Homogneas y altamente Integradas. _______________________________________________________ 2.4.3.1.- Consultas Distribuidas a Bases de Datos Centralizadas e Interoperables. __________________________ 2.4.4.- Cuarto Nivel de Interoperabilidad: BDs Heterogneas, Distribuidas, Federadas y Multidatabases. ________ 17 17 19 20 22 24
2.5.- Conclusiones a los Niveles de Interoperabilidad._______________________________________ 25
Captulo 3. Software de Bases de Datos Distribuidas. Arquitecturas Cliente/Servidor y Web. ___ 29

3.1.- Contextualizacin. Organizacin de las BDR Distribuidas, Homogneas y Altamente Integradas.______ 29 3.2.- Arquitectura de los Sistemas de Bases de Datos Distribuidos. ________________________________ 30
3.2.1.- Niveles de Transparencia de los aspectos de distribucin. ________________________________________ 3.2.2.- Conceptos de Distribucin, Autonoma y Heterogeneidad. _______________________________________ 3.2.3.- Alternativas de Implementacin de los SGBD Distribuidos. ______________________________________ 3.2.4.- Arquitectura ANSI/X3/SPARC de los SGBD Distribuidos. ______________________________________ 3.2.5.- Arquitectura de los SGBD Multidatabase Distribuidos. _________________________________________ 3.2.6.- Conclusiones a las Arquitecturas de los SBDD. ________________________________________________ 30 30 31 31 32 32
3.3.- Diseo de Bases de Datos Distribuidas. ______________________________________________ 33 3.4.- Procesamiento de Consultas Distribuidas. ____________________________________________ 33
3.4.1.- Pasos internos del Procesamiento de Consultas Distribuido. ______________________________________ 34 3.4.2.- Parmetros de Anlisis en los Procesadores de Consultas.________________________________________ 34
Abril, 2008. Por: C.Costilla
DIT-UPM
Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica 3.5.- Gestin de Transacciones. _________________________________________________________ 35
3.5.1.- Arquitectura Revisitada de los SBDDs. ______________________________________________________ 3.5.2.- Protocolo COMMIT de dos Fases, 2PC.______________________________________________________ 3.5.3.- Acciones del Protocolo 2PC._______________________________________________________________ 3.5.4.- Diagrama de Transicin de Estados del Protocolo 2PC.__________________________________________ 3.6.1.- Protocolos de Fiabilidad Local._____________________________________________________________ 3.6.2.- Consideraciones sobre la Arquitectura._______________________________________________________ 3.6.3.- Informacin a Recuperar por Fallos del Sistema. _______________________________________________ 3.6.4.- Gestor de Recuperacin frente a fallos del Sistema._____________________________________________ 3.6.5.- Fallos del Sistema: LRM y Checkpoint. ______________________________________________________ 36 36 37 38 38 38 40 42 43
3.6.- Fiabilidad en los Sistemas de Bases de Datos Distribuidos._______________________________ 38
3.7.- Arquitectura funcional del SGBD: Cliente/Servidor (dos capas) y Arquitectura Web (tres capas). _________________________________________________________________________ 44 3.8.- Arquitectura Cliente-Servidor (dos capas). ___________________________________________ 45
3.8.1.- Funcionalidad de la Arquitectura Cliente-Servidor. _____________________________________________ 46
3.9.- Arquitectura Web (tres capas). _____________________________________________________ 48

3.9.1.- Internet y la World Wide Web. _____________________________________________________________ 49 3.9.2.- Servidores de la capa intermedia en la Arquitectura Web. ________________________________________ 50
3.9.2.1.- Servidor Web: URLs y Protocolo HTTP. _______________________________________ 3.9.2.2.- La seguridad en Internet. ____________________________________________________ 3.9.2.3.- Gateways, CGI y Servidor de Aplicaciones. _____________________________________
50 52 52
3.10.- Diseo de Bases de Datos en sitios Web. _____________________________________________ 54

3.10.1.- Sobre la estructuracin de los datos y consulta a datos intensivos y heterogneos en la Web. ___________ 55 3.10.2.- Hipertextos en sitios Web con datos intensivos. _______________________________________________ 58
3.10.2.1. Modelo lgico de hipertextos para datos intensivos. ______________________________ 58 3.10.2.2. Mtodo y principios del diseo hipertextual en bases de datos Web. _________________ 61
3.10.3.- Acceso a Bases de Datos Web. ____________________________________________________________ 63
Referencias Bibliogrficas. _____________________________________________________________ 65 Lecturas Complementarias de la Parte I: Modelo Relacional Transparencias del Protocolo 2PC Integracin de Archivos Digitales en la Web a partir del Sistema de Gestin Parlamentario SIAP e-government: A Legislative Ontology for the SIAP Parliamentary Management System
ii
DIT-UPM
Parte I. Conceptos y Tcnicas de Bases de Datos Captulo 1. Introduccin y Contextualizacin a Bases de Datos. 1.1.- Introduccin. Niveles de Abstraccin, Modelado Conceptual y Modelos de Datos.
La complejidad en informtica se plasma en la necesidad de considerar un nmero muy grande de variables, cuyas interrelaciones no son simples ni fcilmente expresables. La adquisicin y uso de un Sistema de Gestin de Bases de Datos -SGBD- es, a veces, una herramienta obligada para la puesta en marcha de un proyecto informtico. Un proyecto informtico de cierto nivel necesita generalmente afrontar dos grandes aspectos. Por un lado, la elaboracin de mltiples algoritmos, y, por otro, la organizacin de la informacin que es de inters al proyecto. Los algoritmos desembocan en la implementacin de un conjunto de programas operativos, y quedan escritos generalmente en algn lenguaje de programacin de alto nivel (el que mejor se adece al caso: Java, C, Fortran, Pascal, etc.). Cuando el conjunto de programas de un proyecto informtico produce un funcionamiento global cuya descripcin (o comprensin) no es sencilla, y el software generado va a ser usado de muy distintas maneras y con diversos fines, las tcnicas de ocultacin de la complejidad son algo importante en el proyecto. Si adems dicho software reside en la mquina como algo inherente a ella, se dice entonces que se trata de un "software bsico". Este es el caso de los sistemas operativos (SO) y de los Sistemas de Gestin de Bases de Datos (SGBD). La segunda necesidad que suelen tener los proyectos informticos se debe a la naturaleza de la informacin que es necesario procesar. Cuando sta no es simple, la estrategia que se adopte para organizar la informacin suele tener la clave del xito del proyecto. Mxime si el uso posterior de dicha informacin es imprevisible durante la etapa de realizacin del proyecto. Este es el caso habitual de las bases de datos -BDs- que, una vez diseadas e implementadas en el SGBD de una mquina, los posteriores usos de la misma suelen estar sometidos a continuos cambios. Es decir, tanto los programas de aplicacin como los tipos de usuario que acceden a una BD son, en principio, ilimitados en cada uno de sus alcances. Algunos ejemplos de proyectos informticos con estos dos tipos de necesidades podran ser: servicios de telecomunicaciones, aplicaciones bancarias, transportes, hacienda, sanidad, educacin, y, as, un inagotable etc. En la terminologa del rea, una BD representa y registra (para su gestin) la informacin que proviene de una parte del mundo real. El inters que cada parcela del mundo real pueda llegar a tener, para ser representada en una BD, lo establece la institucin que ser propietaria de la BD correspondiente. Sin duda, para instituciones como las arriba descritas, las BDs constituyen el servicio informtico que mayor rentabilidad proporciona (en tiempo, dinero y seguridad) a dichas instituciones. Siempre que se automatiza algn Servicio Informtico Pblico, que gestiona datos cuyo uso es compartido por muchos usuarios, se sabe que es necesario y til realizar con ciertas tcnicas el diseo de las BDs que han de albergar dichos datos. Disear una BD es algo ms que definir un molde donde se organiza la estructura de la informacin que es de inters a un determinado proyecto informtico. Disear una BD es adems controlar la semntica de todos los valores de los datos que van a residir en dicha BD a lo largo de su vida. Estos valores se comparten entre mltiples usuarios, y, en todo momento, los datos (a la vez que compartidos) deben ser ntegros y consistentes. Los aspectos de diseo hasta ahora comentados se materializan en la definicin del esquema conceptual de una base de datos. Pero, adems de lo dicho, disear una BD supone tambin facilitar al programador de aplicativos la codificacin de mltiples programas de aplicacin, a travs de los cuales se va a sacar provecho de la funcionalidad buscada en cada proyecto.
Captulo 1. Abril, 2008. Por: C.Costilla 1
DIT-UPM
En este sentido, las interfaces deben ser amigables para el usuario y deben adecuarse a cada uno de los medios que, en cada caso, sea el ptimo para representar la informacin de una base de datos: ventanas con grficos, textos, mapas, grficos, imgenes, vdeos, iconos, sonido, tartas o barras estadsticas, fotos, etc. El volumen de los datos no es indicativo de la complejidad que pueda tener la tarea de disear una cierta parcela del mundo real. La complejidad y el valor de una BD, definida mediante un particular esquema conceptual, se mide por el grado de fidelidad que ofrece la representacin en mquina con respecto a la parte del mundo real representada en dicha BD para ser automticamente gestionada por un SGBD particular. Una informacin es de naturaleza simple cuando se necesitan pocos tipos de datos y con escasas asociaciones entre ellos. Por el contrario, una informacin es compleja cuando su representacin en mquina ha de reflejar hechos observados del mundo real; donde, como es sabido, nada se percibe en aislado y, precisamente, es la capacidad de asociar unos conceptos con otros lo que da la medida del grado de conocimiento. Es decir, la capacidad que pueda tener una determinada representacin para interrelacionar los datos es un buen indicativo del valor que puede llegar a tener su almacenamiento en mquina. Lo que menos importa es el dispositivo fsico donde pueda luego albergarse dicha informacin: discos, cintas, etc. En resumen, la informacin ser tanto menos simple cuanto ms fielmente quede representada en la mquina esa parte del mundo real de donde ella proviene. La figura I.1 muestra diferentes niveles de abstraccin para representar en mquina una parcela de la realidad. Ellos van desde el mundo real hasta el tipo de cdigo ms elemental que poseen las mquinas. Entre los dos extremos descritos, y de arriba hacia abajo, se destacan en la figura los conceptos y las tcnicas ms relevantes con las que cuenta la ciencia de la computacin y su actual tecnologa.
El Mundo Real
Modelado Conceptual
Compaa de Fabricacin, Lneas de Transporte, Entidades Bancarias, Ministerios, Ayuntamientos, Servicios de Telecomunicacin, Ciencia, Arte, Deportes.....
Diseo BD
Modelos Sintcticos fciles de usar

Bases de Datos Convencionales
Relacional: Conjuntos, tuplas, atributos, dominios : , , , Codasyl: Esquemas en red, registros, links, items : Jerrquico: Esquemas en rbol, registros, items :
Las Estructuras de Datos
rboles, Ficheros indexados, Listas, Colas, ndices densos o ralos, Cadenas, Pilas, Accesos Hash, Listas invertidas, Anillos de coral, arrays, etc.
El Almacenamiento Fsico
Cilindros, Pistas, Sectores, Pginas, Buffers, Bits, Bytes, Items, Campos, Cdigo ASCII, EBDCDIC, Hollerit, etc.
Fig.I.1.- Niveles de Abstraccin y Naturaleza de la Informacin asociada a cada nivel.
Captulo 1.
DIT-UPM
1.2.- Introduccin. Las Bases de Datos vistas desde los proyectos informticos.
Los proyectos informticos aqu referidos son aquellos que renen los siguientes requisitos y caractersticas. organizar una informacin no simple. Ello supone la consideracin de los siguientes aspectos: Informatizar "partes del mundo real", donde las asociaciones son tan importantes como los conceptos modelados, Modelado Conceptual de la Informacin, Modelo de Datos usado y su Semntica, Diseo de BDs, Esquemas Conceptuales, Vistas de Ususario, Relativismo Semntico o Flexibilidad de Interpretacin. uso compartido por muchos usuarios a la vez y con distintos fines. Lo que generalmente implica: Privacidad de la Informacin (Vistas), Mecanismos de Autorizacin, Protocolos de Control de Concurrencia y Gestin de Transacciones. garantas de integridad, consistencia, persistencia y recuperacin. Esto conlleva: Reglas Semnticas que garanticen valores autnticos de los datos (integridad), Valores de Datos no contradictorios (consistencia), Valores duraderos (persistencia), Mecanismos Seguros de Recuperacin frente a fallos. aplicaciones complejas. Entendiendo por tales el diseo a la medida de mltiples Programas de Aplicacin dirigidos a aumentar la competencia y rentabilidad de la empresa. La empresa es quien considera cada una de las "partes del mundo real" que tiene inters informativo para ser formulada y registrada en una Base de Datos. 1.3.- Introduccin. Las Bases de Datos vistas desde la Tecnologa Comercial. La adquisicin y uso de un SGBD como herramienta es, a veces, obligado para la puesta en marcha de un proyecto informtico. Algunos ejemplos son: Aplicaciones bancarias, Transportes, Hacienda, Sanidad, Educacin, Negocios, etc., En general, al informatizar servicios pblicos es obligado usar SGBDs. El uso de las BDs ha crecido vertiginosamente; pero, an hoy, hay alguna confusin con el significado del par < BD, SGBD >. Intentaremos aclarar conceptos viendo, primero y a muy grandes rasgos, las distintas alternativas que ofrece hoy la Tecnologa Informtica.
1.3.1.- Tres grandes alternativas tecnolgicas para registrar la Informacin.
A.- Los Sistemas Operativos, o el Ordenador sin Aditamentos. Permiten: Ficheros Secuenciales (Siempre) " Indexados (Casi Siempre) " Directos (A Veces) " De Clave (A Veces)
"
Hash
(A Veces), etc.
Captulo 1.
DIT-UPM
B.- Sistemas de Gestin de Ficheros (Thesaurus sobre SO). Mejoran los tiempos de acceso a los ficheros principales, interponiendo, en general, ficheros ndices (en rbol) con entradas "Clave, Puntero" que agilizan la bsqueda de informacin asociada a una la clave residente en el fichero principal. Algunos Productos Comerciales son: ISAM y VSAM (IBM), DATATRIEVE (DEC), HSAM (IBM), CONTEXT e INTERMEDIATEX ( ORACLE), ALEF(DEC), Listas Invertidas, etc. y Multitud de Sistemas Documentales para bsqueda de informacin documental (Thesaurus, o Information Retrieval).
ndice maestro (nivel 3)
30500
61601
98765
2100 41500 .
30500 61601 95500 98765 300
710
1100 1510 1831
2100 41500
98300 98765
50
110
164
205
281
300 710 98765
Cilindro 1
Cilindro 2
Cilindro 3
Cilindro N
ndice de Pista ndice de Pista ndice de Pista ndice de Pista Pista 1 Pista 2 Pista 3 Fichero Principal que contiene los datos propiamente dichos Pista 4 Pista 5 Pista 6 Pista 7 110 160 98765 Pista 8 50 Pista de Desborde Desborde 164 Pista de Desborde Pista de Desborde
Fig. I.4.- El ISAM de IBM (Mtodo de Acceso Secuencial Indexado deun SGF).
Los Sistemas de Gestin de Ficheros presentan las siguientes carencias: No soportan Modelos de Datos, no tienen lenguaje asociado. No hay Esquemas Conceptuales, ni Vistas de Usuario. Escasa relacionabilidad de los datos. Se usan a travs de interfaces "ad hoc".
Captulo 1.
DIT-UPM
C.- Sistemas de Gestin de Bases de Datos, -SGBD-. Los SGBDs son la tecnologa que ofrece mejores soluciones cuando se necesita compartir y usar con distintos fines una gran cantidad de informacin. Los modos de uso de la informacin no se pueden conocer del todo "a priori", y se estiman variantes con el tiempo. Cada usuario de una BD ignora el tratamiento que otros puedan dar a la informacin almacenada, pero la consistencia y la integridad de la BD deben estar garantizadas por el diseador y mantenidas por el SGBD. Un usuario slo conoce, de la BD, aquella parte que es de su inters, o le est permitido ver, es decir su Vista. Esto implica que el SGBD soporte el llamado Nivel Lgico, donde residen las definiciones de las distintas Vistas de Usuario. Las Vistas han de poder ser cambiantes, y se derivan del Nivel Conceptual (como si se tratara de un "corta y pega"). La flexibilidad de un SGBD para la derivacin de vistas da la medida del Relativismo Semntico del Modelo de Datos que soporta. Slo el Modelo de Datos Relacional, de entre los convencionales, ofrece relativismo semntico. Caractersticas generales de los SGBD: Modelo de Datos que soporta Lenguajes de muy alto nivel Lenguaje de Definicin de Datos (DDL) Lenguaje de Manipulacin de Datos (DML) y Lenguaje anfitrin 4GL Lenguaje Consultivo (Query Language) Acceso Concurrente Independencia Fsica y Lgica Redundancia "controlada" de los Datos Reducen notablemente la dificultad de Programacin Alta relacionabilidad de los Datos Integridad de los Datos Consistencia de los Datos Seguridad de los Datos Actualizacin fcil y coherente Alto Rendimiento Funcional 1.4.- Situacin Actual y Consolidada de las BDs. El uso de las bases de datos ha crecido vertiginosamente; pero, an hoy, hay alguna confusin con el trmino del par <BD, SGBD>. Un SGBD es un software capaz de soportar mltiples BDs, proporciona facilidades para definir esquemas conceptuales de bases de datos, a travs del llamado Lenguaje de Definicin de Datos, "Data Definition Language, -DDL-", y, adems, suministra un lenguaje con sentencias (y operaciones) para consultar y actualizar (altas, bajas y modificaciones) la informacin residente en cualquiera de sus BDs. A los lenguajes de este segundo tipo se les conoce por Lenguaje Consultivo, "Query Language, -QL-" y por Lenguaje de Manipulacin de Datos, "Data Manipulation Language, -DML-". Como introduccin a la tecnologa convencional de las Bases de Datos, el siguiente apartado presenta la clsica arquitectura estandar de los SGBDs promulgada por el ANSI/X3/SPARC en 1975.
1.4.1.- Arquitectura Estndar de los SGBDs Centralizados (ANSI/X3/SPARC).
La arquitectura de los SGBD se establece en el primer estndar de ANSI/X3/SPARC (American National Standards Institute) en 1975. La figura I.5 representa dicha arquitectura. Desde entonces, nuevas versiones han ido ampliando y mejorando aquel estndar inicial.
DIT-UPM
La arquitectura interna de un SGBD, que sigue el estndar ANSI, presenta en su interior tres niveles bien diferenciados de representacin de la informacin de las bases de datos que gestiona. Descritos desde el interior del software hacia afuera, los niveles son: Nivel Interno o Fsico, -NF-, Nivel Conceptual, -NC-, y Nivel Externo o Lgico, -NL. El Nivel Fsico se encarga de "engranar" con el software ms interno de cada mquina (Sistema Operativo, y Sistema de Gestin de Ficheros generalmente). Los SGBDs actuales funcionan sobre casi todas las mquinas. Coloquialmente dicho, los SGBDs "corren" sobre casi todos los SOs del mercado y optimizan el tratamiento de los ficheros (depsitos del ms bajo nivel donde albergar la informacin). El Nivel Conceptual materializa el lugar donde definir el resultado del diseo de las BDs. Un SGBD soporta mltiples BDs. Cada BD se define al Nivel Conceptual para una cierta parte del mundo real con inters informativo para ser formulada y registrada en un ordenador. El diseo de una BD se establece en trminos de un Modelo de Datos, -MD-. Los MDs son herramientas intelectuales que sirven para definir la estructura y las constricciones (reglas semnticas) de los datos de una BD. El ANSI establece tres grandes familias de modelos de datos, que cronolgimente son: el modelo jerrquico (estructuras en rbol), el modelo Codasyl (estructuras en red), y, el modelo relacional (estructuras de la teora matemtica de conjuntos -lgebra relacional- y/o de la lgica de predicados -clculo relacional-). Est universalmente aceptada la superioridad que ofrece el modelo relacional, -MR- frente a sus antecesores (Jerrquico y Codasyl). La base matemtica del MR ha permitido, entre otras cosas, definir algoritmos e implementar tcnicas de fragmentacin y ubicacin de datos en las BD Distribuidas, que no existen en los otros MDs. De esto trataremos en los siguientes Captulos del guin establecido para esta primera parte del Seminario. Otra ventaja importante del MR, frente a sus predecesores, es la potencia que tienen las instrucciones de sus lenguajes formales (lgebra y clculo relacional), procesan conjuntos y no simples registros, y la sencillez con la que los lenguajes relacionales se presentan a los usuarios (SQL o QBE). Cualquier consulta (por muy extraa que sea) se puede realizar con igual facilidad que la que parezca ms simple. Comparen los entendidos la nica estructura sintctica de SQL "SELECT... FROM... [WHERE...]" con las setenta opciones que ms o menos tiene la sentencia "FIND..." en los otros MDs. El resultado del diseo de una BD establece la definicin de un ESQUEMA CONCEPTUAL conforme a un modelo de datos, MD, que llamaremos Esquema de la BD. El Nivel Conceptual de un SGBD mantiene, en cada momento, tantos Esquemas distintos cuantas BDs hayan sido diseadas para dicho SGBD. El Esquema de una BD contiene metadatos, es decir, datos que describen datos. La informacin del NC es siempre intensional y recoge, cual molde, las descripciones relevantes de cmo van a quedar organizados los datos de la BD correspondiente. La metainformacin del esquema de una BD forma parte de la informacin que reside en el diccionario de datos, -DD-, de toda BD. El Nivel Lgico, -NL-, de los SGBDs acta como un "filtro" de los Esquemas de las BDs que contiene. El NL permite "dejar ver" a cada tipo de usuario de una BD slo aquella parte del Esquema que es de su inters, o lo que le est permitido ver. Cada parte visible es una VISTA ("view"). De una BD se pueden derivar tantas Vistas como haga falta. El NL de un SGBD materializa la idea del relativismo semntico [Codd82], donde la derivacin de cada Vista acta como un "corta y pega" del Esquema de una BD. De esta forma, cada usuario final de una BD tiene una particular definicin intensional, un subesquema a su medida. La organizacin total del esquema de la BD, a nivel conceptual, es oculta para l. Cada Vista tiene un propietario y se define en funcin de un nivel de privilegio y del uso que se le permita hacer sobre los datos.
DIT-UPM
Programa de Aplicacin 1-1
Aplicativo 1-2
Api. 2-i Api. 1-i Api. x-i Api. 1-n
Api. 2-n Api. y-n
NIVEL LGICO
VISTA 1
"View"
..
VISTA i
"View"
..........
VISTA n
"View"
NIVEL CONCEPTUAL
Modelo de Datos ESQUEMA CONCEPTUAL
SGBD
NIVEL FSICO
ESQUEMA FSICO
BD ALMACENADA
DATOS DE LA BD
Fig. I.5. Arquitectura de un SGBD Estandar.
Por cada BD, existen tres niveles de representacin de la informacin.
De nuevo el MR es ventajoso frente a los otros dos citados porque slo l permite el relativismo semntico en las Vistas. Los otros dos derivan, desde el NC hacia el NL, meros "recortes" del esquema de una BD (siguiendo con los trminos del bricolage empleados, no pueden hacer el "pega"). El NL proporciona un alto nivel de seguridad a lo largo de la vida de una BD. Una Vista de una BD se define a nivel intensional y forma parte de la informacin contenida en el diccionario de datos. El diccionario de datos, DD, es como una minibase de datos dentro de la gran BD. A efectos de interoperabilidad y comunicacin entre BDs, los DDs con las Vistas tienen mucha relevancia. La figura I.5 representa la clsica arquitectura estndar que deben tener los SGBDs comerciales [ANSI75]. Son muchas las ventajas que reporta una arquitectura como sta. Aunque no entraremos en detalles, quiz la ms interesante sea la de garantizar la independencia fsica y lgica de los datos, que, en resumen, quiere decir que tanto si ocurren futuros cambios a nivel fsico (de hardware de mquina o discos) como si surgen a nivel lgico (otras Vistas, otros tipos de usuarios u otros programas de aplicacin), las BDs soportadas por tales Sistemas pueden seguir funcionando como lo venan haciendo antes de producirse dichos cambios.
Captulo 1.
DIT-UPM
Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica 1.4.2.- Ejemplo de los tres Niveles de representacin de una BD Centralizada.
#Emp. Sueldo #Emp. #Depart.
Empleado VISTA 1 NIVEL LGICO (PL/ I ) DCL 1 EMPP,
Empleado VISTA 2 NIVEL LGICO (COBOL) 01 EMPC.

02 #EMP 02 #DEP
2 #EMP 2 SUELDO
CHAR(6), BIN(31);
PIC X(6). PIC X(4).
NIVEL CONCEPTUAL EMPLEADO
NIVEL FSICO STORED-EMPL

PREFIX # EMP # DEP PAY
# EMPLEADO # DEPARTAMENTO SUELDO
CHARACTER (6) CHARACTER (4) NUMERIC (5)
LENGTH = 18
TYPE = BYTE (6), OFFSET = 0 TYPE = BYTE (6), OFFSET = 6, INDEX = EMPX TYPE = BYTE (4), OFFSET = 12 TYPE = FULLWORD, OFFSET = 16
Fig.3. Ejemplo de una BD y los tres niveles de representacin de su informacin en la arquitectura estndar ANSI/X3/SPARC.
1.5.- Bases de Datos Centralizadas. Software.
Aplicativo 1
Aplicativo 2
Aplicativo N
Diseo, Herramientas, Y Utilidades diversas
Generador de Informes
S.G.B.D.
UFI, Grficos Nivel Fsico Nivel Conceptual Nivel Lgico
Tartas y barras Estadsticas
Ayuda de Administracin
Tecnologa Comercializada de Bases de Datos Centralizadas
Bases de Datos Fig. I.7.- Un SGBD Centralizado en torno a un Sistema Operativo.
Captulo 1.
DIT-UPM
1.6.- Bases de Datos Centralizadas. Usuarios y Aplicativos.

Modalidad Funcional Batch Base de Datos Centralizada y Aislada Aplicativos
Vista N Vista x API Programa de Aplicacin
Modalidad Funcional Interactiva

ISQL Usuario Interactivo
Aplicativos
Vista y
Vista 1
ISQL
Aplicativos
Vista i
Usuario Interactivo
Fig. I.8.- Usuarios y Programas en una BD Centralizada.
1.7.- Bases de Datos Centralizadas. Arquitectura de Procesos.

Modelo de Proceso Mono-Usuario
Proceso de Usuario Proceso de Usuario Proceso de Usuario
Compilador de SQL
Compilador de SQL
Compilador de SQL
Un Compilador de SQL por Usuario (dBase, Clipper, etc.) Modelo de Servidor nico
Procesos del SGBD
Un SGBD Multiusuario ( SQL, Control de Concurrencia, Gestin de Transacciones, Vistas, Recuperacin frente a Fallos, Modelo de Mltiples Servidores
Procesos del SGBD
Procesos del SGBD
Varios SGBD Multiusuario ( SQL, Control de Concurrencia, Gestin de Transacciones, Vistas, Recuperacin frente a Fallos,
Fig. I.9.- Tres Organizaciones Bsicas de Procesos ( SGBD y aplicativos de usuario).
Captulo 1.
DIT-UPM
1.8.- Bases de Datos Centralizadas. Componentes de un Sistema de Informacin.
Siguiendo los trminos de ANSI/SPARC [ANSI82], se entiende por Sistema de Informacin, -SI-, aquel que generalmente contiene a uno o varios SGBDs. Cada SGBD gestiona mltiples BDs como ya conocemos. Veamos, a modo de introduccin, tres definiciones preliminares expresadas mediante ecuaciones. La primera es muy conocida de todos, y se debe a Wirth: "Algoritmos + Estructuras de Datos = Programas", Utilizando una terminologa paralela, la segunda ecuacin es conocida por los entendidos en BD, y se debe a Dayal y Garca-Molina (dos personalidades del rea de BDs). Ella refleja los trminos de ANSI/X3/SPARC descritos en 1985, y dice as: "Programas + Bases de Datos = Sistemas de Informacin, SI" La tercera es original de la autora y con ella, por hoy, se podra cerrar el sistema de ecuaciones a los fines de enmarcar la interoperabilidad entre mltiples SIs. Es como sigue: " SI 1 + SI 2 +.......+ SI n = Interoperabilidad" Desde la definicin de Wirth, sabemos que la suma en estas ecuaciones no representa la operacin aritmtica convencional, sino que es una forma de expresar la integracin funcional que fusiona las partes que figuran al lado izquierdo de cada ecuacin, desde un punto de vista operativo, y cuyos efectos se reflejan en el correspondiente lado derecho. La interoperabilidad se ver en el Captulo 2. De momento, interesa saber que un SI se entiende como aquel formado por tres grandes componentes: a) Las Bases de Datos, como almacenes de datos organizados en los esquemas conceptuales conforme a un modelo de datos concreto (relacional, Codasyl, jerrquico, redes semnticas, orientado a objetos, ficheros planos, etc.). El SGBD es el software encargado de soportar el modelo de datos y la gestin de los datos para todas las BDs diseadas e implementadas en dicho sistema. b) Los Programas de Aplicacin, que interactan con la interfaz del SGBD y con el lenguaje de las bases de datos (SQL en las BDs relacionales). Los Aplicativos se escriben en un lenguaje de cuarta generacin (PL/SQL, por ejemplo) que es el resultado de haber integrado un lenguaje de programacin convencional (Java, C, Pascal, etc.) con el lenguaje de los SGBD (DML y QL). Los aplicativos sacan "el jugo" a los datos, usando los Esquemas Conceptuales y/o las Vistas de Usuario. c) Las interfaces del usuario, llamadas interfaces amigables del usuario (User Friendly Interfaces, UFI) que pueden representar la informacin multimedia: grficos, iconos, texto, fotos, vdeo, sonido, etc. La figura I.10 muestra las partes ms comunes que integran un SI genrico. En adelante, representaremos a los SIs por el smbolo del tambor de una Base de Datos ya que ste es el ms caracterstico. Y entenderemos que ello supone generalmente la inclusin de todos los componentes reflejados en esta figura. As entenderemos -por ejemplo- que la figura I.11 representa una interconexin cualquiera entre distintos SIs.
Captulo 1.
10
DIT-UPM
Interfaz de Usuario Multimedia:

Grficas, Mens, Alfanumrica, Iconos, Ratn, Ventanas, Sonido, Imagen, Vdeo, etc.
G.U.I. Aplicaciones o APIs:

Aplicativos, Procesos, Tareas, C, Cobol, Pascal, C++, Java, JavaScript, como Lenguajes Anfitriones que llevan SQL embebido
Gestor de Informacin
Sistemas de Gestin de Bases de Datos:

SGBD, Hoja de Clculo, Sistemas de Ficheros, Shell de Unix, etc.
Almacn de Datos
Bases de Datos, Ficheros .
Fig. I.10.- Componentes de un Sistema de Informacin.
1.9.- Sistemas de Informacin Centralizados e Interconectados.

La figura I.11 representa mltiples sistemas de informacin -SIs- que son realmente islas informativas. Islas interconectadas por una red de ordenadores, y nada ms. A efectos funcionales, cada aplicativo (API) se codifica para un SI concreto y slo de l extrae informacin. Con esta figura se cierra este primer captulo introductorio.
INVENTARIO Base de Datos API de INVENTARIO API de CLIENTES CLIENTES Base de Datos
RED
API de PRESUPUESTOS PRESUPUESTOS Base de Datos API de PROYECTOS PROYECTOS Base de Datos
Fig. I.11.- Sistemas de Informacin como islas interconectadas por una red de ordenadores.
Captulo 1.
11
DIT-UPM
Captulo 2. Interoperabilidad entre Bases de Datos Heterogneas y Distribuidas.

2.1.- Contextualizacin del Captulo. Este tema se centra en los medios tcnicos que facilitan la interconexin de varios SIs y en el concepto de Interoperabilidad que pretende lograr un funcionamiento global del conjunto integrado de manera fiable y eficaz. Existen tres razones fundamentales y bsicas que justifican los actuales esfuerzos y avances tecnolgicos en torno al concepto de INTEROPERABILIDAD. Las Bases de Datos proliferan hoy de forma muy copiosa en las instituciones. Ello exige de manera irrevocable que se pueda lograr una comparticin efectiva de la informacin albergada hoy en muy diversos SGBDs, donde, generalmente, cada sistema soporta muchas BDs diferentes. Esto ya dicho es un primer argumento, y la razn ms general, de la interconexin de BDs y de la interoperabilidad, que toma relevencia suma en cualquier entorno Web. Adicionalmente, las instituciones no estn dispuestas a perder el control sobre sus datos, residentes en cada isla de informacin -BD centralizada y aislada-, como precio por dicha comparticin. Los valores de los datos son, generalmente, el recurso informtico ms valioso que hoy existe, mxime si se trata de datos ntegros, consistentes, perdurables y fiables, en el alcance del negocio o actividad de una empresa. El citado valor se debe, no slo al esfuerzo que supone su acopio, sino tambin al mantenimiento y salvaguarda de su integridad y consistencia. Este segundo argumento es la razn fundamental del principio de autonoma establecida para cada isla de informacin frente al nivel de integracin pactado o permitido en cada isla que participa en un determinado funcionamiento global. Finalmente, la mayora de las instituciones estn diseminadas geogrficamente, y necesitan trabajar en cooperacin como si tales distancias geogrficas no existieran. En esto ltimo, como sabemos, reside el principio de la distribucin de cualquier sistema telemtico en general, y de los Sistemas de Informacin en particular. Este Captulo no incluye a las bases de datos relacionales distribuidas (cuyos datos estn propiamente distribuidos), homogneas y altamente integradas, abreviadas como BDDR. Ser el caso preferente a tratar en el Captulo 3. Tras ello, se describirn las tcnicas software, ms o menos estandarizadas, que dan soporte a esta avanzada tecnologa orientada a la distribucin de las bases de datos. Hablar de una BDDR significa, de entrada, que cada localidad que participa en la BDDR no es una isla de informacin, sino un componente altamente integrado en el conjunto, cuyos datos son fragmentos de los que alberga la BDDR en toda su globalidad. El Captulo que aqu nos ocupa pretende cubrir otros tipos de distribucin de datos ms primitivos que el ofrecido por las BDDR; pero cuyo uso est alcanzando con rapidez altas cotas en las instituciones ms diversas. Este Captulo se centra en describir los medios tcnicos que facilitan la interconexin de varios SIs y en el concepto de Interoperabilidad, cuya finalidad es lograr un funcionamiento global del conjunto como si fuera un todo integrado, de manera fiable a la vez que eficaz. Para ello, recordamos que ANSI/SPARC [ANSI85] establece que un Sistema de Informacin contiene generalmente a uno o varios Sistemas de Gestin de Bases de Datos. Cada SGBD da soporte a mltiples BDs y, en torno a cada BD, se aade una parte de software propia del Universo del Discurso que di origen a la correspondiente BD.
Captulo 2.
12
DIT-UPM
2.2.- Concepto de Interoperabilidad entre Sistemas de Informacin Heterogneos. Informalmente, la interoperabilidad [IHIS89], [HsNS93], [Cost99] es la capacidad requerida para que dos o ms sistemas de informacin, con datos locales, interacten conjuntamente mediante la ejecucin de sus procesos con intercambio de sus datos locales para producir cierta informacin global. Cuando los sistemas estn fsicamente distantes, la plataforma de comunicaciones requerida se basa, como mnimo, en algn servicio equivalente al proporcionado por el nivel tres de la torre OSI (nivel de red, instalado sobre el nivel dos de "Enlace", y ste sobre el nivel uno "Fsico"), o en el nivel de interconexin equivalente en otras implementaciones (nivel IP internet, instalado directamente sobre el nivel de acceso a red, en Darpa) [Mals88]. Si hablamos en trminos de los objetivos que caracterizan a los SIs, podra decirse que el nivel de red se encarga de la funcin de conexin para poder realizar una transferencia de informacin "pura y dura" entre dos o ms mquinas interconectadas por redes. Las redes de ordenadores, en general, son heterogneas y la interconexin de redes heterogneas se hace a niveles ms bajos que los descritos (es decir, a los niveles dos y tres en OSI, y al nivel de acceso a red en Darpa). Llamaremos a la funcionalidad del nivel tres de la torre OSI, y a sus equivalentes, por el servicio que ofrece y, por tanto, diremos que, a los efectos de este Tema, el nivel ms bajo -o de infraestructura para la interoperabilidad- es el encargado de proporcionar LA CONECTIVIDAD. En la conectividad se incluyen los protocolos de red, enlace y los medios para una transmisin fsica. Entre los protocolos del nivel tres estn el X.25 (standard del CCITT) y el IP (Internet Protocol). Los niveles de interoperabilidad, que pasamos a describir, se instalan, como mnimo, sobre el sustrato funcional referido arriba, aqu llamado LA CONECTIVIDAD. Los objetivos de la interoperabilidad son de mucho ms alto nivel que la conectividad que acaba de ser referida. La interoperabilidad tiene por finalidad la integracin de datos locales (datos tiles a los aplicativos que residen en mltiples y heterogneas bases de datos aisladas) para generar una informacin global producida por un procesamiento integrado. Entonces, la principal cuestin est en conocer cmo se puede lograr una interoperabilidad entre SIs heterogneos, cal sera su posible naturaleza y qu tipo de funcionalidad podra ofrecer. Hablando de la manera ms general posible, la interoperabilidad se obtiene mediante APIs (Application Programming Interfaces). Y hablando en concreto, la cuestin est en saber, de entre dichas APIs, cmo se puede lograr una interoperabilidad para las aplicaciones que hoy constituyen los ncleos ms valiosos de los SIs; es decir, cmo logralo para los SGBDs, las BDs y los aplicativos de cada BD [Kim95], [OzVa99], [Gupt89], [DAIS88] y [JaKS88]. Conseguir una interoperabilidad entre BDs heterogneas y distantes implica conocer cmo pueden interactuar distintos SGBD locales. Para ello, es preciso tener en cuenta que cada SGBD puede soportar: BDs que pueden tener modelos de datos distintos a los de otros SGBDs, Esquemas Conceptuales diferentes, Control particular de la semntica de los datos y Aplicativos dispares. La heterogeneidad en BD significa todas estas discrepancias, y alguna ms quizs ms importante que las ya dichas. Por ejemplo, faltara aadir la consideracin debida a: Heterogeneidad en los valores de los datos propiamente dichos,
DIT-UPM
Y este ltimo aspecto es mucho ms difcil e importante que todos los anteriores, porque la semntica ms relevante y valiosa de una BD est realmente inmersa en los valores de los datos propiamente dichos. La definicin de los esquemas conceptuales, como moldes que son, recoge una semntica muy necesaria, imprescindible, pero que resulta pobre y rgida. Los valores de los datos son, en s mismos, un recurso considerado, cada vez ms, como el ms valioso de entre todos los recursos informticos (ms valioso que el hardware y software juntos) [Cost88]. Los datos en s, cuando son fiables, son los que ayudan a incrementar el rendimiento de las empresas, y los que pueden permitirnos vivir en una sociedad mejor y ms justa, si se usan de forma correcta. La interoperabilidad trata pues de conseguir una funcionalidad que sea capaz de activar mltiples aplicativos dirigidos a actuar sobre varios SGBDs locales. De tal forma que cada SGBD local active -a su vez- los correspondientes programas para acceder a la informacin de sus BDs locales, que estn implicadas en el funcionamiento global. Cada conjunto de datos resultantes que proviene de una localidad ha de poder ser integrado con los que producen otros SGBDs que soportan otras BDs. De tal manera que el resultado final sea un nuevo conjunto de datos globales obtenido mediante la integracin de las partes. Los datos globales han de ser tan fiables, al menos, como lo eran en cada isla de informacin de donde provienen. Llamaremos datos locales a los obtenidos desde cada isla de informacin, y datos globales aquellos que se derivan de dos o ms islas y se perciben como extrados de una manera integrada. Los datos globales pueden, pues, proceder de varias localidades o islas de informacin particulares que estn fsicamente dispersas. Como ejemplos ilustrativos de lo necesario que es la interoperabilidad, baste con pensar en cualquier empresa multinacional o en la integracin de pases de la Comunidad Europea para entender fcilmente que sera impracticable definir una nueva BD que centralizara toda la informacin en una sla mquina y en un slo lugar geogrfico. El objetivo de la interoperabilidad es hoy un gran reto del campo de las BDs. Pero adems, como siempre en informtica, para que esta idea de interoperabilidad sea aceptada por la instituciones (que sin duda la requieren) es necesario que la elevada complejidad tcnica que esto conlleva se oculte a los usuarios finales tanto como sea posible. Para que los usuarios acepten y usen las nuevas tecnologas destinadas a la interoperabilidad de los SIs, es preciso que los accesos a una informacin global sean, a lo sumo, tan sencillos como lo fueran en las BD centralizadas y aisladas que vienen usando. La tecnologa que existe para lograr este objetivo es muy reciente, est muy diversificada, y no hay mucho asentamiento entre las distintas tcnicas disponibles para este interesantsimo aspecto. Este Captulo va a clasificar, en cuatro niveles jerrquicos, los conceptos y tcnicas que rodean a la idea de la interoperabilidad. La interoperabilidad es ortogonal a la distribucin de los sistemas, es decir, ni la implica ni la excluye. Por ejemplo, antes de describir los cuatro niveles de interoperabilidad, la figura VI.1 muestra un ejemplo de interoperabilidad sencillo donde los SIs residen en una sola mquina y, por tanto, no hay distribucin. Mientras que la figura VI.2 describe el mismo ejemplo de interoperabilidad, pero distribuido. Las dos figuras hacen referencia a los componentes de un SI mostrados en la figura I.10 del Captulo 1.
Captulo 2.
14
DIT-UPM
Aplicativos, Procesos,
G.U.I.
Aplicativos, Procesos,
SGBD
SGBD
Interoperabilidad en una sola plataforma

Base de Datos Base de Datos
Fig. VI.1.- Interoperabilidad Centralizada.
G.U.I.
Aplicativos, Procesos. Aplicativos, Procesos.
SGBD
Interoperabilidad en tres plataformas
SGBD
Base de Datos
Base de Datos
Fig. VI.2.- Interoperabilidad Distribuida.
2.3.- El mundo de la Interconexin: OSI, DARPA, SNA Y DNA El tipo de servicio bsico de las redes de ordenadores que interesa al tema de la interoperabilidad, entre SIs ubicados en mquinas distintas y distantes, es aqul que ofrece una transmisin de la informacin extremo a extremo, de manera fiable y econmica, que salva la heterogeneidad de las redes que soportan la conectividad, y oculta sus caractersticas a las Aplicaciones. Este servicio se llama bsico, en este tema, porque la idea de interoperabilidad (que nos ocupa) se instala sobre l como si de hardware se tratara. Este servicio bsico lo ofrecen hoy distintas tecnologas. Por ejemplo, el nivel cuatro de OSI, la capa de transporte, y sus equivalentes en otras implementaciones, independiza a los niveles superiores (sean o no de la torre) de las caractersticas fsicas de la red que se utilice. La figura VI.3 compara los didcticos niveles de la torre OSI (de ISO) con las tres implementaciones ms importantes de hoy: DARPA oriunda de Arpanet, SNA de IBM y DNA de DEC. La figura est tomada de "Data Communication, Computer Networks and OSI" [Mals88]. En ella vemos que, adems del nivel de transporte de OSI, existen otras implementaciones alternativas, y uno de los protocolos de transporte ms extendido es el TCP (Transmission Control Protocol) orientado a conexin que posibilita interconectar mquinas sobre el protocolo IP (Internet Protocol).
DIT-UPM
Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica OSI API Usu. 7 Aplicacin 6 Presentac. 5 Sesin 4 Transporte 3 Red
Control de Transmisin, -TCPInternet Protocol, -IP-
DARPA
SNA Usu. Final
DNA Usu. Final

Aplic. Red
Aplicaciones / Procesos
Funciones de Gestin de Datos

Flujo de Datos y Control de Transmisin
Control de Path
Control de Ruta Virtual Control de Ruta Explcita Control del Grupo de Transmisin
7 6
Control Sesin
5 4 3 2 1
Servicios de Red
Transporte Enlace Fsico
2 Enlace 1 Fsico
Acceso a Red
Control de Enlace
Fsico
Fig. VI.3.- Arquitectura OSI vs. DARPA, SNA y DNA.
El protocolo TCP/IP, diseado por ARPANET en los 60s, est hoy adoptado como estndar de facto, extendido en nuestro planeta y conocido por Internet donde se apoya la actual Web. El conjunto de protocolos TCP/IP es el ms utilizado para la interoperabilidad de los SIs y, adems, da soporte a otros servicios inmediatamente superiores, como quiere representar la figura VI.4, que en la torre OSI se sitan en las capas altas [OSDT89]. De entre ellos, destacamos los siguientes: acceso remoto de terminales (Telnet) que es de la arquitectura de TCP/IP. Su equivalente en OSI es el "Virtual Terminal Protocol" (VTP, nivel 7), transferencia de ficheros (FTP), el equivalente en OSI es FTAM - nivel 7, correo electrnico (SMTP,7) , el equivalente en OSI es X.400 - nivel 7, y llamadas a procedimientos remotos (RPC) en el que se basa la interaccin Cliente/Servidor. Por otra parte, la figura VI.4 muestra algunas de las dependencias jerrquicas entre los distintos servicios y protocolos de las redes. En ella se reflejan dos aspectos que merece la pena destacar: 1) la diversidad de implementaciones que existen con poca estructuracin conceptual y la escasez de contenido que hoy ofrecen los niveles altos de OSI (5, 6 y 7). Por ejemplo, mientras los servicios de X.400 (correo electrnico de OSI) estn en el nivel 7 de su torre, su equivalente SMTP se instala directamente sobre TCP/IP. 2) destacar al protocolo RPC (Remote Procedure Call), por la relevancia que tiene en la tecnologa de BDs interconectadas. Y a XDR, propuesto por SUN, que es un formato de representacin externa para las llamadas a procedimientos remotos.
Programas de Aplicacin FTP SMTP
e-mail
NFS XDR TFTP RPC
SNMP ASN.1 DNS UDP
TELNET TCP
(orientado a conexin)
(no orientado a conexin, datagramas)
IP, Internet Protocol (ms ICMP y IGMP) ARP RARP Nivel de Enlace Hardware y Protocolos de Acceso a Red Fig. VI.4.- Dependencias jerrquicas entre protocolos.
Captulo 2.
16
DIT-UPM
RPC es una implementacin de SUN, hoy adoptada como estndar de facto en la mayora de las implementaciones que dicen llamarse distribuidas y que funcionan realmente bajo una arquitectura Cliente/Servidor.
Sistemas de GBD Distribuidos
Cliente / Servidor Sistemas Operativos Distribuidos Acceso Remoto a Bases de Datos
Redes de Ordenadores (TCP/IP) y Comunicacin de Datos Fig. VI.5.- Escenario tecnolgico actual de los Sistemas Distribuidos: RO, SD y BDD.
2.4.- Niveles de Interoperabilidad. Se definen en este punto, cuatro niveles que, de forma jerrquica y modular, van proporcionando cada vez servicios ms interoperables, segn se va subiendo en la jerarqua. Un nivel se instala sobre el inmediatamente inferior y, para su implementacin, utiliza los servicios que le ofrece su nivel inmediato inferior; pero no puede usar los que figuren en las capas superiores a l. Este es el principio bsico de las organizaciones modulares y jerrquicas de los sistemas software con cierto nivel de complejidad en su implementacin. A continuacin se describe el tipo de funcionalidad que cada nivel ofrece a los efectos de la interoperabilidad.
2.4.1.- Primer Nivel de Interoperabilidad: TCP, Interconexin de Aplicaciones cualesquiera.
Basado en los servicios del nivel de transporte (como TCP/IP) tenemos el primer nivel de Interoperabilidad entre diferentes SIs. Con TCP/IP pueden interoperar aplicaciones que residen en mquinas diferentes y con distintos Sistemas Operativos (Unix, VMS, MS-DOS, etc.., y algunos entornos como Windows). Tambin, sobre TCP/IP pueden interactuar procesos remotos de los SIs que se ejecutan en plataformas distintas y distantes. TCP/IP fue adoptado por Berkeley para incluirlo en su versin de UNIX. Usando este primer nivel bsico de interoperabilidad, el usuario interacta de forma transparente a la red de interconexin de ordenadores. Entenderemos al primer nivel de interoperabilidad como aquel cuyo servicio consiste en lo siguiente: Garantizar la interconexin entre Aplicaciones cualesquiera que residen en mquinas diferentes (con Sistemas Operativos heterogneos) e interconectadas con redes que pueden ser heterogneas.
2.4.2.- Segundo Nivel de Interoperabilidad: Arquitectura Cliente/Servidor y Acceso Remoto a Bases de Datos.
El segundo nivel de interoperabilidad, instalado en jerarqua sobre el primero, materializa, entre otros, el protocolo de interaccin Cliente/Servidor. La idea en C/S es considerar slo el papel que juegan los programas al interactuar respecto a los procesos que han de ejecutarse. Un programa que requiere un servicio se erige como cliente y el proceso requerido por el cliente, y que atiende su solicitud, acta de servidor. Estos procesos pueden residir en Sistemas de Informacin Heterogneos, SI, (como, por ejemplo: SGBD, Sistemas Expertos, Sistemas de Ficheros como los
DIT-UPM
Documentales; Hojas de Clculo como Lotus 123, Excel, etc.) donde unos interoperan con otros siguiendo esta forma de interaccin C/S. Cuando un usuario (o API) de una mquina necesita la ejecucin de un programa que ella no tiene (o no puede ejecutar), entonces se erige como CLIENTE del sistema interconectado. El nodo cliente se entiende en este tema como aquel que requiere del servicio de un SI. La mquina que alberga el SI necesitado ser la SERVIDORA. El usuario, para este nivel de interoperabilidad, necesita dar en los comandos de interconexin los siguientes parmetros al solicitar el servicio que requiere: la direccin o el nombre del servidor, invocar al SI en cuestin y enviar el cdigo a ejecutarse en remoto (en BD, el "Query" o la Consulta), dar el nombre de su mquina cliente y dems parmetros necesarios al cdigo en cuestin que se enva.
La consulta, o en general el acceso, al SI se ejecuta en el Servidor quien, tras obtener la respuesta en su mquina, enva sus resultados al Cliente. En resumen, el protocolo C/S acta nicamente como portador de comandos, consultas (queries) y datos (respuestas). En este nivel se tienen nicamente accesos desde un slo punto cliente a otro nico punto que le sirve. La interconexin es, pues, punto-a-punto entre un aplicativo y un SGBD que acta de servidor.
CLIENTE Elemento de Servicio RDA ACSE ROSE CCR Presentacin Sesin Transporte Red Enlace Fsico SERVIDOR Elemento de Servicio RDA ACSE ROSE CCR Presentacin Sesin Transporte Red Enlace Fsico SGBD
Local
BD1 Local
Nivel 7
BD2 Local
6 5 4 3 2 1 Comandos + Consulta
Datos de la Respuesta a la Consulta
Fig. VI.6.- Modelo Bsico del RDA. Relacin entre RDA y la arquitectura C/S.
Una de las funcionalidades ofrecida por el protocolo C/S es el Remote Database Access, RDA, Acceso Remoto a Bases de Datos. RDA fue promulgado estndar en 1989 [ISO89], y pasamos a comentarlo. Para este segundo nivel de interoperabilidad, OSI ofrece el estndar RDA que est por encima de la modalidad C/S, pero los dos pertenecen a la capa siete de su torre, como representa la figura VI.6. Junto a RDA, y por debajo de l, estn los elementos de servicio ACSE (Association Control Service Element) y ROSE (Remote Operation Service Element), tambin pertenecientes a la capa siete de la torre OSI (Aplicaciones). Por ltimo, en dicha capa 7, est el protocolo CCR (Commitment Concurrency Recovery) que garantiza la ejecucin segura y atmica de transacciones que afectan a la representacin de datos. CCR se dise e implement en los aos 70s en, y para, la tecnologa de los SGBD y, posteriormente, OSI lo incorpor en el nivel siete de su torre. La figura VI.6 representa la arquitectura de la torre OSI, destacando el RDA. Ningn producto comercial ha seguido esta arquitectura para ofrecer RDA.
DIT-UPM
Interesa destacar, desde el punto de vista del tema que nos ocupa, que el RDA proporciona un nivel muy primitivo y bajo para lo que pretende la interoperabilidad. Como representa la figura VI.6, RDA permite que, desde una mquina remota, se acceda a una sla BD (normalmente, una isla) y nada ms. Bajo el punto de vista de los datos resultantes que obtiene el programa que accede a la BD, la cosa es bastante anloga a los accesos realizados a una BD centralizada y aislada. Nada ms aade el RDA, salvo que hay distancia geogrfica de por medio. Las implementaciones comerciales llamadas RDA utilizan directamente los servicios que ofrece TCP/IP (puenteando los niveles 5 y 6 de OSI). As, el consorcio de suministradores SQL Access Group ha mejorado las especificaciones del Acceso Remoto a Bases de Datos de OSI. Por otra parte, XA/XOPEN ha definido sobre TCP/IP directamente una coleccin de rutinas, llamadas CLI routines (Call Level Interface). Sobre CLI estn implementadas las llamadas a procedimientos remotos RPC con formato de representacin externa XDR. Estas implementaciones se han realizado por, y para, la tecnologa de BD (los SGBD) de manera que un Cliente puede acceder a cualquier Servidor de Bases de Datos Relacional (por ejemplo: Sybase, Oracle, Ingres, Informix, etc.) de forma transparente, sin estar obligado a incorporar cada vez los comandos antes descritos en las llamadas al servidor. Uno de los productos ms utilizados para el acceso remoto a bases de datos es el de Microsoft, conocido como Open DataBase Connectivity, ODBC. La figura VI.7 muestra el funcionamiento de estas implementaciones de RDA, que son las que realmente funcionan en toda la tecnologa de Bases de Datos.
Consulta Respuesta Redes de Ordenadores (LAN, MAN o Wan)
Comunicacin de Datos
LINK o NET junto al nombre del SGBD
SGBD Local
Bases de Datos Centralizadas
Fig. VI.7.- Acceso a Bases de Datos Remotas (RDA).

2.4.2.1.- Las APIs.
Las APIs (Application Programming Interface), por otra parte, ofrecen funciones que se organizan en bibliotecas (libraries) para distintos fines: Acceso a funciones de Comunicacin, Acceso a funciones de BDs, etc. En la interfaz de cada nivel de la torre OSI, existen distintas APIs. Existen productos que tambien materializan este segundo nivel de interoperabilidad entre distintos SO y distintos SI heterogneos (BD Codasyl, BD Relacionales, Hojas de Clculo, etc.) como el de UNIFACE que establece vas de comunicacin en C/S para el RDA. Tambin, por ejemplo, Microsoft ha creado una interfaz llamada ODBC (Open Database Connectivity) para el acceso a datos de SGBDs hetergeneos (relacionales o no). Con ODBC el programador de aplicativos puede acceder (consultar y/o actualizar) a muchas BDs heterogneas concurrentemente. Por tanto ODBC ofrece una API portable a diversos entornos, adems de contener al SQL estndar. Adicionalmente, de forma complementaria, y como ejemplo prctico, Microsoft comercializa, bajo Windows, una interfaz de programacin, llamada API (Application Programming Interface), correspondiente a la parte front-end de un sistema interconectado, y, tambin est elaborando una arquitectura WOSA (Windows Open Service Architecture), que incluir APIs para mensajera.
DIT-UPM
En el segundo nivel de interoperabilidad se ha incluido tambin el protocolo DDE (Dynamic Data Exchange) de Microsoft. DDE es equivalente, en su funcionalidad, al nivel 6 de OSI. Con DDE, una aplicacin local Windows puede intercambiar datos con cualquier otra, como representa la figura VI.8 (por ejemplo, desde Excel a Lotus o dBase).
WINDOWS Microsoft Dynamic Data Exchange (DDE)
Aplicacin Local 1
Aplicacin Local 2
Fig. VI.8.- Interoperabilidad entre aplicaciones en una mquina.
El protocolo DDE funciona punto-a-punto y puede trabajar en forma remota si se intercala un gestor de red (router) DDE, como indica la figura VI.9. As est integrado en la tecnologa Windows For WorkGroups. Tambin tienen cabida en este segundo nivel de interoperabilidad las pasarelas software (Gateways software) que desde una aplicacin cliente permiten acceder a datos que residen en otras mquinas (IBM, UNISYS, VAX, TANDEM, etc).
R
WINDOWS Microsoft
Router (DDE)
API de Comunicacin
E D
Router
API de Comunicacin
Aplicacin 1
(DDE)
Aplicacin 1
Fig. VI.9.- Interoperabilidad de aplicaciones en distintas mquinas.
En resumen, para los objetivos aqu propuestos, el nivel dos de interoperabilidad descrito asegura la interaccin simple entre una aplicacin remota y un servidor de informacin (SGBD, SGF, Hoja de Clculo, Shell de Unix, etc.). Obsrvese que el segundo nivel de interoperabilidad se sita en los niveles ms altos del mundo de la interconexin, y usa algunos de estos servicios. Este segundo nivel materializa, entre otros, el protocolo de interaccin Cliente/Servidor. Se considera en este Captulo a la arquitectura C/S slo por el papel que juegan los programas remotos al interactuar con los procesos que han de ejecutarse en los SGBD, que son los servidores de informacin. En adelante, conoceremos al segundo nivel de interoperabilidad como el encargado de proporcionar el siguiente servicio:
Servicios de Acceso Remoto a BDs (RDA) y de Interfaces a otros SI Heterogneos (APIs), basados en la interaccin Cliente/Servidor.
Las utilidades de los SGBD comerciales llaman a este software con las palabras LINK (para acceso
remoto directo punto-a-punto) o NET (mediante gateways) junto al nombre del producto. 2.4.3.- Tercer Nivel. Interoperabilidad entre BDs Centralizadas e Interconectadas o entre BDs Distribuidas Homogneas y altamente Integradas.
El nivel tres de interoperabilidad contempla los problemas del acceso (concurrente) a varios servidores, con distintos SGBDs, producido por una aplicacin que accede a datos globales. Se llama global porque necesita integrar informacin proveniente de varias localidades, cada una con uno o varios SGBD.
DIT-UPM
En este nivel se incluyen los algoritmos, tcnicas y herramientas adecuados para la descomposicin, planificacin y ejecucin de consultas distribuidas, que son llevadas a cabo por el Procesador de Consultas Distribuidas (Distributed Query Processor) y Optimizadores de las Consultas Distribuidas. Lo que significa tambin la actualizacin (altas, bajas y modificaciones) de datos distribuidos, de forma ntegra, consistente y fiable. Los accesos a una BD, antes de ser ejecutados, se traducen internamente a transacciones para poder ser tratados, si fuera necesario, como bloques especiales a los que poder exigir caractersticas tambin especiales de: Atomicidad, Consistencia, aIslamiento y Duradera (o persistente) conocidas como las propiedades ACID, que veremos en el Captulo 3. Las transacciones contienen los siguientes tipos de instrucciones elementales: de lectura de datos, -read(x)-, de escritura de datos, -write(y)-, begin-transaction, sentencia propia de los mecanismos para controlar la concurrencia que seala el punto de inicio de la transaccin, commit, sentencia propia de los mecanismos para controlar la concurrencia que seala un punto de fin de la transaccin que ha terminado con xito, abort o rollback, sentencia propia de los mecanismos para controlar la concurrencia que seala un punto de fin de la transaccin que ha terminado de forma anormal. Dentro de los SBDD, la parte de software encargada de procesar las transacciones a BDD de forma concurrente, distribuida y segura, es conocida como Gestor de Transacciones Distribuidas (Distributed Transaction Manager), y la parte de software encargada de la recuperacin frente a fallos es conocida por el Gestor de Recuperacin Distribuido (Distributed Recovery Manager). La tecnologa de BDs es maestra en estas tcnicas del software bsico desde ya muchos aos, cuando los SGBDs eran y funcionaban slo como centralizadas y como autnticas islas [BeHG87]. Para el nivel tres de interoperabilidad se tienen hoy soluciones comercializadas, a veces distintas. Por ejemplo, para la gestin global de transacciones en entornos de servidor de Bases de Datos Heterogneos, algunos comercializan sistemas de gestin de transacciones usando monitores de transacciones con interfaces normalizadas de acuerdo a XA/XOPEN como referencia de estandarizacin. El protocolo para el control de la concurrencia Two Phase Commit (2PC), basado a veces en el Two Phase Locking, en Timestamping o en Hbridos, asegura una buena ejecucin de transacciones concurrentes y distribuidas. Este tercer nivel cae de lleno en el Seminario de BD que nos ocupa, y el siguiente Captulo va a describir este tipo de software. Por el momento, slo decir que la interoperabilidad ofrecida en este nivel se puede conocer como la encargada de dos objetivos que son diferentes y que suelen no ser distinguidos hoy con claridad por los usuarios:
Procesamiento de Consultas a Bases de Datos Distribuidas, Homogneas y altamente integradas (diseadas "Top-Down") [OzVa99]., y Procesamiento de Consultas Distribuidas a mltiples Bases de Datos Centralizadas e Interconectadas [Gupt98], [LaRa85] y [Boba96].
En [OzVa99] se estudian los conceptos y las tcnicas ms avanzados que existen en el mundo del procesamiento de datos actual. Se sita en el caso donde todo est distribuido: los datos y los procesos; otras referencias con igual escenario son: [Cost90], [Date87], [Date88] y [Gard89]. Para dichas tcnicas existen ya productos disponibles en el mercado que soportan BDR Distribuidas (como contrapuestas a las tcnicas que slo proporcionan procesamiento distribuido). Los Sistemas Relacionales de BDDs permiten que el esquema conceptual de una BDR, y sus correspondientes datos, habiten en una variedad de mquinas diferentes, con distintos SOs, e interconectadas por una variedad de redes diversas, para funcionar como si todo estuviera almacenado en una sla BDR virtual de una nica mquina. La transparencia ofrecida por estos sistemas es muy
DIT-UPM
alta, ya que el usuario (programador de aplicaciones o final) de una BDD no necesita conocer en absoluto ningn detalle sobre los aspectos de distribucin. Este Captulo describe un tipo de distribucin referido al procesamiento distribuido de las consultas, cuando existen muchas BDs, cada una de ellas est centralizada (sus datos no estn distribuidos), y cada BD puede estar en un lugar geogrfico distinto y distante de donde residen las dems que, de alguna forma, participan en un funcionamiento global. Trataremos pues sobre distintas organizaciones que permiten accesos distribuidos a mltiples BD centralizadas (son islas de informacin). Los SGBD clsicos o centralizados, para proporcionar procesamiento distribuido sobre BDs centralizadas, tienen un software aadido que logra esta forma de interoperabilidad. Por ejemplo, en las figuras que siguen este software adicional (sombreado en las figuras) se llama de muy diversas maneras:
QE Library, instalado sobre SQL NET o LINK Open Server, en otros casos, Uni SQL, a veces, etc.
El trmino ms significativo de este tipo de productos es 'OPEN'. Debido a la novedad que tienen estos aspectos, se hace necesario mencionar la tecnologa junto al producto que lo ofrece, sin que ello quiera decir que la referenciada sea la nica que exista. Por la novedad mencionada, estas tcnicas no tienen an hoy bien unificada su tecnologa comercial. Detallar cada producto concreto desborda los lmites permitidos en este Seminario. Por tanto, uno de los intereses, al describirlos, es remarcar que es preciso 'bucear' en cada producto para conocer fielmente las caractersticas que cada uno ofrece. Por ello, se dar una descripcin somera sobre las distintas formas operativas de esta tecnologa moderna de BDs. Los esquemas de las tres figuras que siguen muestran dichos funcionamientos, desde un punto de vista muy general.
2.4.3.1.- Consultas Distribuidas a Bases de Datos Centralizadas e Interoperables.
A continuacin se muestran distintas formas de interoperabilidad "Front-end" y "Back-end", basadas en la arquitectura Cliente/Servidor del nivel 2 descrito. En el procesamiento distribuido, el nodo cliente desde donde interacta el usuario (o su aplicativo) es siempre la parte "Front-end", y los nodos servidores de informacin constituyen la parte "Back-end". Un ejemplo de Sistema de Informacin industrial, construido en el Grupo de Bases de Datos del DIT-ETSIT-UPM puede verse en [CoBV93]. Adicionalmente, la Parte III de este Seminario describe otras formas de distribucin de otros dos sistemas industriales construidos por dicho Grupo de Investigacin. Designaremos a una u otra parte ("Front-end" o "Back-end") como la encargada de la interoperabilidad, cuando en ella se realice la integracin de datos locales para obtener los datos globales que requiere el usuario. As, por ejemplo, en la parte "Back-end" de la figura VI.10, puede verse cmo las consultas se ejecutan de forma aislada -en cada BD centralizada-, y la interoperabilidad conseguida en la parte "Front-end" corre a cargo de cada aplicativo del usuario (no del sistema). Esta solucin no ofrece transparencia al usuario, lo que dificulta enormemente su uso por su alta complejidad, a la vez que vulnerable e inseguro. Esta tecnologa suele conocerse con el nombre del producto servidor seguido del vocablo NET (con 'gateways'). La figura VI.11 muestra una forma de interoperabilidad "Back-End", donde los servidores de informacin intercambian comandos entre s, al acceder a los datos referidos en la consulta. Los datos globales pueden obtenerse en una mquina diferente a donde residen las APIs del usuario.
Captulo 2.
22
DIT-UPM
Usuarios
Interfaz de Usuario Programas de Usuario Cliente
(Visual Basic, C++, etc.)
Aplicacin Comercial
(Excell, Lotus, Dbase, etc.)
Windows MS
DDE QE Library
Protocolo de Interaccin
Front-End
SQL Net
DB Library
Informix Net
Protocolo Transporte / Red (TCP/IP)
Oracle
Procesos del SGBD
Sybase
Procesos del SGBD
Ingres
Procesos del SGBD
Informix Back-End
Procesos del SGBD
Servidores de Informacin de Tecnologa Relacional

Fig. VI.10.- Ejemplo de Interoperabilidad Front-End con SGBDs Back-End Heterogneos.
Usuarios
Interfaz de Usuario Programas de Usuario (Visual Basic, C++, etc.) Aplicacin Comercial (Excell, Lotus, Dbase, etc.)
Windows
MS
Cliente
Front-End
DDE
Protocolo de Interaccin
DB Library Back-End
Protocolo de Transporte / Red (TCP/IP)
Open Server
Open Ingres
Open Server
Back-End
Oracle
BD1
Ingres
BD2
Sybase
BD3
Procesos del SGBD
Procesos del SGBD
Procesos del SGBD
Servidores de Informacin de Tecnologa Relacional

Fig. VI.11.- Ejemplo de Interoperabilidad Back-End con SGBDs Heterogneos.
Captulo 2.
23
DIT-UPM
La figura VI.12 muestra otra forma de interoperabilidad entre BDs aisladas y heterogneas. El sistema UNI-SQL posibilita la interaccin entre distintos servidores a travs de comandos de control con islas de informacin que ya existan anteriormente en cada localidad. Al igual que en el caso representado en la figura VI.11, normalmente se comercializa esta tecnologa con el nombre OPEN (con 'gateways') junto al nombre del producto. De nuevo, en esta figura, es el aplicativo escrito por el usuario quien lanza accesos a cada isla de informacin y se encarga (en su cdigo) de confeccionar a la medida los datos globales.
Usuarios, Aplicativos
DB Library
Uni SQL
Open Server Oracle

BD1
Open Server Informix

BD2
Open Server Sybase

BD3
Procesos del SGBD
Procesos del SGBD
Procesos del SGBD
Datos Centralizados en cada BDi

Fig. VI.12.- Ejemplo de una Consulta Distribuida a Bases de Datos Aisladas con SGBD Heterogneos.
2.4.4.- Cuarto Nivel de Interoperabilidad: BDs Heterogneas, Distribuidas, Federadas y Multidatabases.
El cuarto nivel de interoperabilidad es el encargado de integrar en una globalidad la informacin heterognea residente en mltiples localidades de forma automtica, transparente al usuario, y con independencia del tipo de aplicaciones que vayan a requerirse. Arranca al considerar la existencia previa de islas de informacin que fueron diseadas con independencia unas de otras y se busca una forma viable de cooperacin global, lo ms automtica posible, donde la autonoma local es un principio vital e ineludible. De manera que la totalidad del Sistema Interoperable se perciba por el usuario como si de un SI centralizado se tratara. Este cuarto nivel pretende ofrecer soluciones para la heterogeneidad anlogas a las que ya dispone la tecnologa relacional distribuida, homognea y diseada 'top-down'. Este nivel constituye un dificil reto an no logrado. Trminos afines al cuarto nivel de Interoperabilidad son Data Warehouse y Data Mining como puede leerse en [SrCh99] cuyo trabajo se adjunta en esta documentacin. Este nivel incluye los siguientes aspectos: integracin de esquemas heterogneos en SGBD diferentes, salvar de forma automtica la heterogeneidad semntica de los valores de los datos, multidatabases y lenguajes para multisistemas (MSQL3 e IPL4).
DIT-UPM
Para este nivel de interoperabilidad no se dispone an de tecnologa comercializada, y el tema est teniendo un esfuerzo investigador muy alto [HsNS93]. Como ejemplo de ello, puede verse el trabajo de un proyecto Esprit (EP 8629) (1994-96), llamado IRO-DB: Interoperable Relational and Object Databases, donde ha participado el Grupo de Bases de Datos de esta Escuela. La especificacin de la funcionalidad general de IRO-DB puede encontrarse en [IRO94]. Adicionalmente, en [SrCh99] se describen los actuales esfuerzos realizados en DataWarehousing y DataMinig. Conoceremos al cuarto nivel descrito como el encargado de ofrecer una:
Interoperabilidad entre Bases de Datos Heterogneas y Pre-existentes, para conseguir una Cooperacin Global Distribuida, bien por diseo "Bottom Up" (BDs integradas por federacin de esquemas) o bien por un lenguaje para "multidatabases", que oculte su inherente complejidad a los usuarios.
La figura VI.13 da una panormica de los cuatro niveles descritos para la interoperabilidad.
APLICACIONES
...
Integracin de Esquemas de Bases de Datos Heterogneas
Heterogeneidad Semntica
Lenguajes Multi-DB y Multi-SI
Integracin Automtica de Informacin Global desde Bases de Datos Heterogneas, Aisladas e Interconectadas
Mximo nivel de la actual tecnologa de Bases de Datos
Procesadores de Consultas Distribuidas

(Descomposicin de Consultas / Optimizadores de Consultas)
Gestores de Transacciones Distribuidas

(Protocolos de control de concurrencia y tcnicas de recuperacin frente a fallos)
1. Consultas Distribuidas a Bases de Datos Aisladas 2. Consultas Distribuidas a Bases de Datos Distribuidas con alta integracin de Datos y SGBDD Homogneos
2 1
RDA
CCR
APIs
Interaccin CLIENTE / SERVIDOR
Servicios de Transporte (TCP/IP)
Interconexin de las Aplicaciones
Protocolo de Red (IP, X.25)

Conectividad
Protocolos de Enlace y Medios de Transmisin Fsica Fig. VI.13.- Niveles deInteroperabilidad en los Sistemas de Informacin Distribuidos.
2.5.- Conclusiones a los Niveles de Interoperabilidad.

La moderna tecnologa de BD proporciona hoy productos que funcionan hasta el llamado nivel tres de interoperabilidad, como se ver en las dos siguientes Partes de este Seminario. El actual reto tecnolgico del nivel 4 de interoperabilidad est muy bien comentado en [SrCh99]. En la panormica descrita sobre los distintos niveles de interoperabilidad entre los SIs, quiz merezca la pena destacar algunos aspectos adicionales, que a continuacin se indican.
DIT-UPM
Primero: hasta dnde llegan los protocolos y servicios de la interconexin. Aunque es cierto que en algunos sistemas ciertos niveles de interoperabilidad pueden no existir, si comparamos los cuatro niveles de interoperabilidad descritos con las capas altas de la torre OSI, podemos concluir diciendo que:
El nivel siete de la torre OSI corresponde, por la funcionalidad que ofrece para los SIs Heterogneos, al segundo nivel de interoperabilidad que aqu se ha descrito.
Segundo: hasta dnde llega el procesamiento distribuido de consultas que acceden a varias BDs heterogneas. Llega hasta el nivel 3, pero no hay apenas transparencia para el usuario en lo relativo a la distribucin ni en lo relativo a la heterogeneidad. La heterogeneidad se salva (cuando es posible) de forma manual y, por tanto, insegura. Sin embargo, afortunadamente, la tecnologa de BDR Distribuidas, Homogneas y Altamente Integradas (es decir, con distribucin de datos y de procesamiento de consultas) es la mejor realidad tecnolgica de nuestros das, donde la transparencia para el usuario es total, como veremos en el siguiente captulo. Para conseguir (en el futuro) los objetivos descritos del nivel 4, parece cada vez ms evidente que el paradigma orientado a objetos es quien mejor puede ayudar a ello. De hecho, al observar las figuras VI.10, VI.11 y VI.12; se comprende fcilmente que la interoperabilidad del nivel 3 se consigue gracias al programa del usuario que utiliza, adems de su cdigo, los elementos software que le proporciona una biblioteca (DB Library, o QE Library en las figuras). La biblioteca dicha casi siempre est prxima a la parte 'Front-end'. Tercero: la tecnologa de bases de datos orientada a objetos parece la mejor solucin al reto de la interoperabilidad de mayor nivel. Esta tercera conclusin se inicia con la siguiente idea preliminar.
El software, en esencia, es una forma de arte. Idealmente, el usuario debera percibir a los sistemas software en general como 'algo que le sita en su mundo', sin barreras artificiales de sistemas operativos, arquitecturas del hardware, plataformas, compatibilidad de redes, de aplicaciones o de servidores de informacin. En el ESPACIO DE DATOS del futuro, estas fronteras tecnolgicas de hoy estn llamadas a desaparecer.
El paradigma orientado a objetos viene recibiendo enorme atencin como enfoque cargado de potencia para el diseo de sistemas software complejos, y se manifiesta como enfoque igualmente vlido para diversas reas de la informtica, como son: los lenguajes de programacin, las bases de datos capaces de representar el conocimiento que se observa del mundo real, y los sistemas distribuidos. El estndar de las bases de datos de objetos, -BDOs- reporta beneficios importantes. Entre otros, cabe recordar que el xito de los SGBDRs no se ha debido slamente a su alto nivel de independencia de datos ni a la sencillez de su modelo de datos respecto a los anteriores modelos de datos y SGBDs afines. La mayora de su xito se debe a la estandarizacin que l ofrece. La aceptacin del SQL estndar, [ISO87] y [ANSI89], permite un alto grado de portabilidad e interoperabilidad entre los sistemas, y simplifica el aprendizaje de nuevos SGBDs Relacionales. Ello ha supuesto un amplio refrendo del enfoque relacional, que busca, con igual suerte, la Tecnologa de Bases de Datos Orientada a Objetos, en adelante, los sistemas SBDOs. El alcance de los SBDOs es mayor que el de los sistemas relacionales, puesto que los SBDOs integran los lenguajes de programacin y los sistemas de bases de datos (reunificando las operaciones de una aplicacin con los datos), y puesto que el modelo de objetos tienen una semntica mucho ms rica que el relacional. Por ello, dicho alcance est ms lejos de lograr que en los SGBD relacionales. La existencia de un estndar era crtica para que las aplicaciones de BDOs llegasen a tener utilidad prctica. Lo ya dicho justifica la existencia del reciente estndar ODMG 3.0 [Catt99], promulgado por el consorcio ODMG (Object Database Management Group), que reune a las ms importantes industrias de
DIT-UPM
la tecnologa de las BDOs. Siguiendo dicho estndar, se permite que varios productos comerciales ofrezcan y refrenden una interfaz comn a las BDOs sobre las cuales pueden codificarse sus respectivos aplicativos. El estndar ODMG define los siguientes aspectos: el modelo de datos o Modelo de Objetos (OM) para especificar los esquemas conceptuales de las BDOs (nico aspecto descrito en el Tema II), el Lenguaje de Definicin de Objetos (ODL), el Lenguaje Consultivo (OQL) y la ligadura del lenguaje de programacin C++ para la codificacin de aplicativos portables (C++ODL, C++OML como Lenguaje de Manipulacin de Objetos y C++OQL). El consorcio ODMG es una rama del consorcio OMG (Object Management Group). OMG ha definido una arquitectura genrica para cualquier Sistema Distribuido, llamada CORBA (Common Object Request Broker Architecture), cuya funcionalidad interna se basa en la ofrecida por la modalidad Cliente/Servidor. CORBA [OMG91] facilita que una aplicacin dada no tenga que preocuparse de cmo se invoca al Servidor implicado en su peticin. De ello se encarga la arquitectura distribuida. Cualquier aplicacin, que sigue la normativa CORBA, se ejecuta en la distribucin gracias a que su interfaz se declara siguiendo un lenguaje establecido para ello. El lenguaje se llama IDL (Interface Definition Language). Por el momento parece que, en lo que es competencia de este seminario, puede ser suficiente con describir slo algunos detalles muy elementales de la arquitectura CORBA; los que representan las figuras VI.14 y VI.15. Desde ambas figuras, s parece interesante destacar que los servidores de CORBA (donde quiera que residan) son BIBLIOTECAS C++, y las aplicaciones de las BDOs que satisfacen el estndar ODMG 2.0 son compatibles con IDL de CORBA. (El caso tiene cierta analoga con la interoperabilidad del nivel 3 descrito, donde siempre se lograba interoperar gracias a la utilizacin de Bibliotecas Software).
Cliente
Implementacin del objeto servidor
Peticin
ORB (Object Request Broker)

Fig. VI.14.- Peticin de un Servicio enviada a travs de la arquitectura distribuida ORB.
La arquitectura CORBA est estructurada para permitir la integracin de una gran variedad de sistemas de objetos que pueden estar distribuidos. Las razones para proponer dicha arquitectura, o el motivo de sus caractersticas, puede que no sea evidente de entrada; pero segn se van desarrollando las expectativas iniciales en el abanico de implementaciones actuales, optimizaciones y usos que se espera englobar, el nivel de la flexibilidad que CORBA puede llegar a ofrecer para la integracin de sistemas distribuidos parece cada vez ms alto, claro y eficaz. La figura VI.15 muestra, como ejemplo, una peticin enviada por un cliente a la implementacin de un objeto. El cliente es una entidad que necesita realizar una operacin sobre el objeto servidor, y la implementacin del objeto consta de cdigo y de datos, ambos implementan dicho objeto servidor. ORB es responsable de todos los mecanismos necesarios para encontrar la implementacin del objeto al que se refiere la peticin del cliente, de preparar a la implementacin para recibir la peticin y de la comunicacin de los datos. La interfaz que ve el cliente es completamente independiente del lugar dnde est localizado el objeto servidor, en qu lenguaje de programacin est implementado y de cualquier otro aspecto que la interfaz no necesita reflejar a los Clientes externos.
Captulo 2.
27
DIT-UPM
La figura VI.15 muestra la estructura de un ORB. Las interfaces de ORB estn representadas por cajas rayadas, y las flechas indican quin llama a quin (si ORB es llamado o si realiza una invocacin a travs de la interfaz)
Cliente
Implementacin del objeto servidor
Invocacin Dinmica
Cabos IDL
Interfaz ORB
Esqueleto IDL
Adaptador de objetos
Ncleo de ORB
Interfaz idntica para todas las implementaciones de ORB Puede haber varios adaptadores de objetos Hay cabos y un esqueleto para cada tipo de objeto Interfaz dependiente de ORB Interfaz de llamada Interfaz de Invocacin al objeto servidor
Fig. VI.15.- Estructura de las Interfaces ORB.
Para hacer una peticin, el cliente puede usar una interfaz de invocacin dinmica (la misma interfaz independiente de la interfaz del objeto destinatario) o un cabo IDL (el cabo o enchufe especfico, dependiendo de la interfaz en el objeto destinatario). El cliente tambin puede interactuar directamente con el ORB para la invocacin de algunas funciones. Conclusin Final: El paradigma orientado a objetos como solucin al reto de la interoperabilidad del ms alto nivel para los SIs distribuidos y heterogneos. Aunque todava no sea una realidad consolidada, cada vez es ms patente que el desarrollo de software, basado en la funcionalidad Cliente/Servidor (con RPCs), se difumina con las tcnicas de la orientacin a objetos, y la revolucin que puede llegar a producir este paradigma permite aventurar lo siguiente:
En el futuro slo habr dos tipos de profesionales de la ingeniera informtica, uno disear objetos destinados a ofrecer servicios, agrupados en bibliotecas de objetos; el otro, se concentrar en resolver los problemas de su empresa o institucin a travs de la codificacin de aplicaciones que ensamblen dichos objetos.
Captulo 2.
28
DIT-UPM
Captulo 3. Software de Bases de Datos Distribuidas. Arquitecturas Cliente/Servidor y Web.

3.1.- Contextualizacin. Organizacin de las BDR Distribuidas, Homogneas y Altamente Integradas. La figura VI.16 presenta un ejemplo introductorio de cmo se organizan las BD Relacionales Distribuidas, Homogneas y altamente Integradas, en adelante BDDs. Su descripcin detallada se estudia en [OzVa99]. La figura, tomada de [Date87] representa dos Bases de Datos Distribuidas, BDDs- a lo largo de tres nodos de una red.
BDD 1
BD Local 1 Nodo 1
Nodo 1
BD Local 2 Nodo 1
Red de Comunicacin
Nodo 3
Nodo 2
BDD 2
BD Local 2 Nodo 2 BD Local 1 Nodo 2
BD Local 2 Nodo 3
BD Local 1 Nodo 3
BDD 1 una sola Base de Datos Distribuida,

diseada top-down y cuyos datos residen entre los nodos 1, 2 y 3.
Datos Distribuidos en cada BDD, ello supone:

1. 2. 3. La BDD 1 es un todo altamente integrado con datos distribuidos en la BD Local 1 del Nodo 1, BD Local 1 del Nodo 2 y la BD Local 1 del Nodo 3. La distribucin de los datos es totalmente transparente al usuario. Permite la reusabilidad de Aplicativos en los nodos participantes en la distribucin
Fig. VI.16.- Ejemplos de BD Relacionales Distribuidas, Homogneas y Altamente Integradas.
No muchas ms descripciones van a darse en este curso de Doctoradoo. Slo se aade, en lo que resta, un conjunto de figuras que van a complementar esta primera parte del Captulo 3. La figura VI.17 describe los componentes software de los Sistemas de BDDs.
Red
SDDD Comunicacin Sistema del Diccionario de Datos de Datos Distribuido SBDD

Sistema de Bases de Datos Distribuido
SGBD Local
SDDD Comunicacin Sistema del Diccionario de Datos de Datos Distribuido SBDD

Sistema de Bases de Datos Distribuido
SGBD Local
Bases de Datos Locales
Bases de Datos Locales
Fig. VI.17.- Componentes de las bases de Datos Distribuidas.
Captulo 3.
29
DIT-UPM
3.2.- Arquitectura de los Sistemas de Bases de Datos Distribuidos. Los Sistemas se construyen mediante Mdulos con interfaces de flujos de control y datos: Implementar un mdulo Integrar los mdulos Programming-in-the-small Programming-in-the-large
3.2.1.- Niveles de Transparencia de los aspectos de distribucin.
Transparencia: es la habilidad de ocultar detalles de implementacin al usuario o a los niveles altos del sistema. Programming-in-the-small se oculta a Programming-in-the-large, conforme representa la figura VI.18.
Transparencia del Lenguaje de la Distribucin Transparencia de Fragmentacin Transparencia de Replicacin Transparencia de la Red Independencia de Datos Fsica Datos Lgica Niveles de Ocultacin
Fig. VI.18.- Niveles de transparencia en los SBDD.
3.2.2.- Conceptos de Distribucin, Autonoma y Heterogeneidad.
Distribucin de Datos
Localidades Diversas
Dos Localidades
Hardware
SOs
SGBDs Control de la Semntica de los Datos (dficil problema) Tipos de Heterogeneidad
Centralizado SOs SGBDs Aplicaciones de los SIs Autonoma de los Sistemas
Las soluciones empiezan a ser ms dficiles a medida que nos alejamos del origen
Fig. VI.19.- Anatoma del problema de las BDDs y los Sistema de Informacin Distribuidos.
Captulo 3.
30
DIT-UPM
Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica 3.2.3.- Alternativas de Implementacin de los SGBD Distribuidos.
La figura VI.20 representa un esquema sobre las distintas formas de modelar e implementar los SGBD capaces, en distinto modo, de incorporar aspectos de Distribucin, Autonoma y Heterogeneidad.
Distribucin
SGBD Centralizados, Homogneos y lgicamente integrados SGBD Heterogneos y

Distribuidos
SBDD y Homogneos
SBDD y Federados Sistemas Multi-Database Distribuidos
SBDDR
Sistemas de Gestin de Bases de Datos Distribuidos, Relacionales y Homogneos
Sistemas Multi-Database Heterogneos y Distribuidos
Sistemas Multi-Database Autonoma SGBD Integrados y

Heterogneos
SGBD Federados,
Heterogneos y Centralizados SGBD Federados, Heterogneos y Distribuidos
Sistemas Multi-Database Heterogneos
Heterogeneidad
Fig. VI.20.- Alternativas de Arquitecturas e Implementacin de los SGBDs.
3.2.4.- Arquitectura ANSI/X3/SPARC de los SGBD Distribuidos.
La figura VI.21 representa el Modelo de Referencia de ANSI/X3/SPARC extendido. Refiere la arquitectura de los SBDD Integrados.
Esquema Externo Global 1 Esquema Esquema Externo Externo Global 2 Global n
Vista Vista Local 1 1 Local 1 k Esquema Conceptual BD Local 1
Esquema Conceptual Global
Vista Vista Local n 1 Local n m
Esquema . Conceptual BD Local n
Esquema Interno BD Local 1
Pars Madrid . C/Alcal Gran Va 1Planta 3Planta
Esquema Interno BD Local n
Fig. VI.21.- Arquitectura de los SGBDs. Modelo de Referencia del ANSI/X3/SPARC.
Captulo 3.
31
DIT-UPM
Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica 3.2.5.- Arquitectura de los SGBD Multidatabase Distribuidos.
La figura VI.22 representa la arquitectura de los Sistemas Multidatabase sin integracin de Esquemas Conceptuales Locales en un Esquema Conceptual Global. En esta propuesta, slo a travs del Multi Lenguaje, las consultas interoperan con varias Bases de Datos independientes. Es una propuesta de W. Litwin, MSQL Language [LiAb87].
Esquema Externo 1 Esquema Externo 2 Esquema Externo n
Esquema Conceptual BD Local 1
Esquema Esquema . Conceptual Conceptual BD Local 2 BD Local n
Esquema Interno BD Local 1
Esquema Esquema . Interno Interno BD Local 2 BD Local n
Fig. VI.22.- Modelo Multidatabase sin integracin de Esquemas.
3.2.6.- Conclusiones a las Arquitecturas de los SBDD.
1. Los Modelos de Arquitecturas son marcos abstractos que sirven para: describir los aspectos de las BDDs, para analizar y comparar los productos comerciales existentes. 2. El grado de Autonoma Local requerido es un input importante para optar por un determinado modelo de Arquitectura del SBDD y elegir una solucin de diseo para cada BDD. El SBDD es un software que incluye: Procesamiento de Consultas Distribuidas Adaptadores entre las BDs Locales y la BD Global (mappings) Protocolos de Comunicacin Control de Concurrencia Distribuido, Gestin de Transacciones Distribuido Recuperacin distribuida frente a fallos distribuidos. 3. Las BDD relacionales y altamente integradas (por diseo top-down) son una tecnologa comercial de hoy, conocida como: *** / STAR. 4. Las Multidatabase son ms nuevas y no estn comercializadas, aunque existen prototipos.
Captulo 3.
32
DIT-UPM
3.3.- Diseo de Bases de Datos Distribuidas. El software de los nodos participantes en la distribucin se ha representado en la figura VI.17. Para disear una BDD es preciso seguir los siguientes pasos metodolgicos que muestra la fig. VI.23.
Anlisis de Requerimientos
Requisitos y Objetivos del Sistema de

Entradas de
Diseo Conceptual
Integraci n de
Diseo Lgico (Vistas)
Esquema Conceptual
Formas de Acceso
Definicin de Vistas
Entradas de
Diseo de la Distribucin
Esquemas Conceptuales
Diseo Fsico
Esquema Fsico
Monitorizacin y Observacin
Fig. VI.23.- Estrategias y Alternativas del Diseo de Bases de Datos Distribuidas.
3.4.- Procesamiento de Consultas Distribuidas. SQL lenguaje de muy alto nivel, procesador complejo. Funciones del Procesador de Consultas Distribuidas: 1. Transformar SQL a clculo y lgebra relacional 2. Construir un conjunto de tcnicas para: Minimizar costes (I/O, CPU y Comunicac.) tpicas en lenguajes de programacin Garantizar la Consistencia y la Integridad de la Base de Datos, Diseo de BDD y Procesador de Consultas Maximizar la concurrencia, Procesador de Consultas, Control de Concurrencia y Gestor de Transacciones 3. Traducir y especificar la estrategia de ejecucin de consultas a BDD en trminos de: lgebra relacional para las operaciones y Primitivas de comunicacin Cliente/Servidor, send/receive aplicadas a los fragmentos en las BDD locales.
Captulo 3.
33
DIT-UPM
Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica 3.4.1.- Pasos internos del Procesamiento de Consultas Distribuido.
Los siguientes puntos resumen los hitos ms relevantes del procesamiento de una consulta distribuida. La figura VI.24 representa dicho procesamiento en forma grfica. A).- Descomposicin de la Consulta Global 1.2.Paso del SQL al Clculo relacional referido a relaciones globales y Optimizacin. Traduccin del Clculo al lgebra referida a relaciones globales y Optimizacin.
B).- Localizacin de Datos 3.Traduccin del lgebra global al lgebra referida a fragmentos y Optimizacin en el correspondiente rbol algebraico. C).- Comunicacin de Consultas Locales 4.- Se enva el rbol algebraico referido a fragmentos a los Procesadores de Datos de las correspondientes Bases de Datos Locales. D).- Procesamiento de Consultas Locales 5.- Optimizacin del rbol algebraico recibido en la localidad e invocacin al procesador de datos (caso tpico de las Bases de Datos centralizadas).
3.4.2.- Parmetros de Anlisis en los Procesadores de Consultas.
Las siguientes caractersticas pueden ser un buen indicativo para analizar y comparar los procesadores de consultas distribuidos que acompaan a los productos comerciales que son Sistemas de Gestin de Bases de Datos Relacionales y Distribuidos.
Tipos de Algoritmos utilizados Granularidad en la Optimizacin Tiempo de Optimizacin Uso de Estadsticas Estrategia de adopcin de posibles rutas entre los nodos participantes Explotacin de la Topologa de la Red Explotacin de los Fragmentos Replicados Uso de Semijoins
Captulo 3.
34
DIT-UPM
Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica Consulta en SQL
Esq. Conceptual Global
Consulta en Clculo sobre Relaciones Globales
Descomposicin de la Consulta
Nodo de Control Central que usa metainformacin global
Esquema de Fragmentos
Consulta en lgebra sobre Relaciones Globales
Localizacin de Datos
Estadsticas sobre Fragmentos
Consulta en lgebra sobre Fragmentos
Optimizacin Global
Consulta optimizada referida a fragmentos, incluye operaciones de Comunicacin a las Bases de Datos Locales
Esq. de Frag. Local 1 Esq. de Frag. Local n
Optimizacin Local
Nodo Local 1
Optimizacin Local
Nodo Local n
Consulta Local
(rboles algebraicos optimizados)
Consulta Local
(rboles algebraicos optimizados)
Nodo Local 1 Al Procesador de Datos 1
Nodo Local n Al Procesador de Datos n
BD Local 1
BD Local n
Fig. VI.24.- Esquema genrico del Procesamiento de Consultas a Bases de Datos Distribuidas.
3.5.- Gestin de Transacciones.

El concepto de transaccin se apoya bsicamente en la teora de la Serializabilidad, y sirve, principalmente, para poder garantizar las propiedades ACID en la ejecucin de aquellas transacciones que las requieran. Son las siguientes: Propiedades ACID: Atomicidad (Todo o Nada) Consistencia (Preserva la Integridad y la Consistencia) AIslamiento (Cambios no visibles hasta alcanzar el estado Committed)
Duradero o persistencia (Los cambios persisten una vez Committed)

DIT-UPM
Tres clases de acciones sobre los objetos de la BD: No Protegido (no necesitan ACID) Protegido (necesitan ACID, pueden ser undo/redo) Real (necesitan ACID, no pueden ser undo) Las acciones protegidas necesitan ser committed o aborted; Las acciones Real slo pueden ejecutarse tras un Commit.
3.5.1.- Arquitectura Revisitada de los SBDDs.
Procesador de Consultas (QP)

Resultados
Begin-transaction, Read, Write, Commit, Abort
Con otros SCs
Con otros TMs
Gestor de Transacciones (TM)

Solicitud de Planificacin
Planificador (Scheduler, SC)

Monitor de la ejecucin distribuida
A los Procesadores de Datos Locales
Con otros Procesadores de Datos
Fig. VI.25.- Modelo Detallado del Monitor de Ejecucin de Transacciones Distribuidas.
3.5.2.- Protocolo COMMIT de dos Fases, 2PC.
El protocolo Two Phase Commit, 2PC, controla la ejecucin de una transaccin distribuida. La transaccin distribuida se inicia en un determinado nodo (flecha nmero 1 de la figura VI.26) que posee un SGBD participante en la distribucin -llamado el Coordinador-. Para la ejecucin de la transaccin, se precisa emitir o difundir partes de las operaciones a otros nodos donde residen otros SGBDs llamados Participantes- que son los encargados del acceso a los datos ubicados en cada localidad (flechas con nmero 2 en la figura VI.26). Cada Participante responde a la solicitud del Coordinador, indicando si est o no dispuesto para llevar a cabo su correspondiente transaccin local (flechas con nmero 3 en la figura VI.26). Con esta informacin de control, recibida de los Participantes, el Coordinador adopta una decisin unnime de si ha de llevarse a cabo la transaccin o no, y se la difunde a todos los Participantes (flechas con nmero 4 en la figura VI.26). El papel de Coordinador o de Participante que puede jugar un determinado nodo, es eventual en cada ejecucin. Ser Coordinador el nodo que vaya a hacerse cargo de dirigir la ejecucin de dicha transaccin, y ser Participante aquel nodo encargado del acceso a los datos de su localidad participante. La figura VI.26 representa el protocolo de interaccin, indicado mediante flechas numeradas.
DIT-UPM
Commit de una transaccin dada 5 1
Coordinado 2 3 SGBD 1 4 3 2 4 3 2 4 SGBD n
SGBD 2
-----
Participantes
Fig. VI.26.- Protocolo COMMIT de dos Fases, 2PC.
3.5.3.- Acciones del Protocolo 2PC.
La figura VI.27 representa, con cierto detalle, las acciones del protocolo Commit de dos Fases. Coordinador Participante
Inicial
Preparar
write begin-commit in log write abort in log
Inicial
No
Ready to COMMIT?
Voto-ABORT Voto-COMMIT
U n i l a t e r a l A b o r t
Si
write ready in log
WAIT
Alguien NO listo?
Si
write abort in log
Global-ABORT
READY
No
write commit in log
Global-COMMIT
Abort
write abort in log
Tipo de Mensaje?
ACK
COMMIT
ABORT
ACK
Commit
write commit in log
write end-of-transaction in log
ABORT COMMIT
Fig. VI.27.- Acciones del Protocolo COMMIT de dos Fases, 2PC.
Captulo 3.
37
DIT-UPM
3.5.4.- Diagrama de Transicin de Estados del Protocolo 2PC.
Finalmente, la figura VI.28 muestra el diagrama de transicin de estados del protocolo 2PC, en el Coordinador y en los Participantes.
Inicial
Commit Ready Ready Abort
Inicial
Ready Ready-to-Commit
Wait
Ready
Ready-to-Commit Global-Commit
Abort Global-Abort
Global-Abort ACK
Global-Commit ACK
Commit
Abort
Abort
Commit
Coordinador
Participantes
Fig. VI.28.- Transiciones de Estados en el Protocolo 2PC.
3.6.- Fiabilidad en los Sistemas de Bases de Datos Distribuidos.

3.6.1.- Protocolos de Fiabilidad Local.
La parte de software de los SGBD locales encargada de gestionar la recuperacin local, de cada lugar participante en una BDD, se llama LRM (Local Recovery Manager). Sus funciones mantienen la propiedades de atomicidad y persistencia de las transacciones locales. Estas funciones son las relativas a la ejecucin de los comandos que entran al LRM: begin-transaction, read, write, commit y abort. Existen, adems, nuevas instrucciones en el repertorio del LRM encargadas de iniciar las acciones de recuperacin despues de que aparezca un fallo. Primero describiremos la ejecucin de estos comandos en un entorno centralizado, despues se abordarn los aspectos adicionales para BDD.
3.6.2.- Consideraciones sobre la Arquitectura.
La figura VI.29 presenta un modelo abstracto de un SGBD centralizado, cuya arquitectura describe cuatro mdulos encargados de la gestin de transacciones y la gestin de los datos de las BD. Este modelo no se corresponde fielmente con alguna arquitectura de los SGBD comerciales. Su descripcin interesa porque, pedaggicamente, es importante separar limpiamente los problemas de control de concurrencia y recuperacin del resto de las funciones de un SGBD.
Captulo 3.
38
DIT-UPM
T1
T2
.....
Tn
Ejecuta pre-procesos de las operaciones read, write y de commit, abort Controla la ejecucin concurrente de las Ts, restringiendo el orden en el que el DM ejecutar las read, write, commit y abort de varias Ts. RM es el responsable de commit y abort de las Ts. Mantiene la atomicidad y la persistencia de las Ts locales. Opera directamente sobre la BD ejecutando las operaciones read y write
aislamiento
Gestor de Transacciones (TM)
integridad y consistencia
Planificador (Scheduler) Gestor de Recuperacin (Recovery Manager) Gestor de Buffers de BD

(cache memory)
Gestor de Datos (Data Manager)
BD
Fig. VI.29.- Sistema de Bases de Datos Centralizado
La anterior figura VI.25 represent la arquitectura revisitada de la parte del SGBD distribuido que se encarga de la gestin de las transacciones distribuidas y de controlar su ejecucin concurrente en BDD. A continuacin, en la figura VI.30, se describe la interfaz especfica entre el Gestor de Recuperacin Local y el Gestor de Buffers de la BD. Este ltimo es responsable de todos los accesos a la BD (operaciones read y write).
Gestor de Recuperacin Local
Fetch, Flush
Read Write
Memoria principal
Memoria Secundaria BD Estable
Gestor de Buffer de la BD cache-
Read Write
Buffers de la Base de Datos (BD voltil)
Fig. VI.30.- Interfaz entre el Gestor de Recuperacin Local y el Gestor de Buffers.
Se supone que la BD estable est almacenada permanentemente en memoria secundaria [Larson and Sturgis,1976]. La estabilidad de este medio de almacenamiento se debe a su robustez frente a fallos. En un dispositivo de almacenamiento estable las expectativas de fallo son mucho menos frecuentes que en uno no-estable, como lo es la memoria principal. En la actual tecnologa, se considera estable a los discos magnticos que almacenan copias duplicadas de datos, que siempre se guardan mutuamente consistentes. A la versin de la BD guardada en un dispositivo estable, se la llama BD estable. Una pgina de disco es la unidad de almacenamiento y de acceso a una BD estable. El gestor del buffer de la BD guarda, en memoria principal, los datos recientemente accedidos desde el disco, para mejorar as los tiempos de acceso a disco. Es tpico que el buffer est dividido en pginas, cada una del mismo tamao que las pginas del disco. La parte de la BD que reside en los buffers se la llama BD volatil. Es importante destacar que el Gestor de Recuperacin Local ejecuta las operaciones
DIT-UPM
que le envan las transacciones slo sobre la BD voltil, donde residen los nuevos valores de los datos, los cuales, un tiempo despues, sern grabados en la BD estable. Cuando el Gestor de Recuperacin Local necesita leer una pgina de datos (o un bloque) pedidos por alguna operacin de alguna transaccin, enva un comando fetch indicando la pgina que quiere leer. El gestor del buffer examina si la pgina est en su rea (debido a previos comandos fetch de otra transaccin), si es as deja la pgina disponible para esa transaccin; si no, lee la pgina desde la BD estable en un buffer vaco. Hay varios algoritmos distintos por los que el gestor del buffer elige la pgina a ser sustituida por una nueva. El gestor del buffer tambien proporciona la interfaz por la cual el Gestor de Recuperacin Local puede forzarle a re-escribir alguna de las pginas del buffer. Esto se puede conseguir mediante el comando flush, que indica las pginas del buffer que el GRL quiere que se re-escriban. No todas las implementaciones de los GRL tienen esta modalidad de escritura forzada por el GRL. Este asunto ser tratado posteriormente.
3.6.3.- Informacin a Recuperar por Fallos del Sistema.
Vamos a suponer que slo habr fallos debidos al sistema. Ms adelante se tratarn las tcnicas para la recuperacin de fallos debidos a los medios. Puesto que trataremos de la recuperacin en bases de datos centralizadas, los fallos debidos a la comunicacin tampoco sern aplicables. Cuando aparece un fallo del sistema, la BD voltil se pierde. Por tanto, el SGBD tiene que mantener alguna informacin sobre su estado en el momento del fallo para poder llevar a la base de datos al estado que tena cuando apareci el fallo. Llamaremos a esta informacin la informacin a recuperar. La informacin a recuperar que mantiene el sistema depende de los mtodos con los que se ejecuten las actualizaciones. Hay dos posibilidades para ello, actualizacin in-situ o fuera-del-lugar. La actualizacin in-situ cambia fsicamente los valores de la BD en la BD estable, y, por tanto los valores anteriores se pierden. Por otro lado, la actualizacin fuera-de-lugar no cambia los valores de los datos en la basede datos estable, sino que mantiene los nuevos valores separadamente. Por supuesto, peridicamente, estos nuevos valores tienen que ser integrados en la base de datos estable. Los estudios de fiabilidad son ms simples si no se usa la actualizacin in-situ. Sin embargo, la mayora de los SGBD utilizan actualizaciones in-situ porque se mejora el rendimiento.
Estado anterior de la BD Estable
Oper. Actualizacin
Estado nuevo de la BD Estable
BD Log Fig. VI.31.- Ejecucin de una operacin de actualizacin
Informacin a Recuperar con Actualizacin in-situ. Ya que la actualizacin in-situ produce que los previos valores de los items de datos afectados se pierdan, es necesario guardar la informacin suficiente sobre los cambios de estado de la BD para facilitar la recuperacin de la BD a un estado consistente despues del fallo. Esta informacin se mantiene tpicamente en una base de datos, llamada log. De esta forma, cada actualizacin no slo cambia la BD sino tambien se queda registrada en la BD log (fig. VI.31). Consideremos el siguiente escenario. El SGBD empez a funcionar en el tiempo 0 y, en el tiempo t aparece un fallo del sistema. Durante el periodo [0, t], dos transacciones se han iniciado en el SGBD (sean T1 y T2). Una de ellas, T1 est commited, y T2 est activa, como indica la figura VI.32.
Captulo 3.
40
DIT-UPM

BT T1 BT Commit T2 Fallo del sistema
t
Fig. VI.32.- Ocurrencia de un fallo del sistema
tiempo
La propiedad de persistencia (durability) de las transacciones requiere que los efectos de la transaccin T1 queden reflejados en la BD estable. Anlogamente, la propiedad de atomicidad requiere que la BD estable no contenga ninguno de los efectos de la transaccin T2. Sin embargo, para asegurar esto el SGBD necesita tomar precauciones especiales. Supongamos que el GRL y los algoritmos del gestor del buffer son tales que las pginas del buffer se re-escriben en la BD estable slo cuando el gestor del buffer necesita nuevo espacio en el buffer. Es decir, el comando flush no es lanzado por el GRL, y la decisin de re-escribir las pginas en la BD estable se toma a discrecin por el gestor del buffer. En este caso, es posible que las pginas en la BD voltil hayan sido actualizadas por T1 pero no se hayan re-escrito en la BD estable en el momento en que aparece el fallo. Por tanto, en la recuperacin es muy importante poder re-hacer (redo) las operaciones de T1. Ello requiere guardar informacin en el BD log sobre los efectos de T1. Con la informacin del LOG es posible recuperar la BD desde su "viejo" estado al "nuevo" estado que refleje los efectos de T1, como indica la figura VI.33.
Viejo Estado de la BD Estable
REDO
Nuevo Estado de la BD Estable
BD Log Fig. VI.33.- Accin REDO
Anlogamente, puede que el gestor de buffer haya escrito en la BD estable algunas pginas de la BD voltil que hayan sido actualizadas por T2. Por lo cual, para la recuperacin despues del fallo es necesario des-hacer (undo) las operaciones de T2. De forma tal que la informacin a recuperar deber incluirdatos suficientes para poder deshacer desde el "nuevo" estado de la Bd que contiene los efectos parciales de T2 y recuperar el "viejo" estado que tena antes de arrancar la transaccin T2, como refleja la figura VI.34.
Nuevo Estado de la BD Estable
UNDO
Viejo Estado de la BD Estable
BD Log
Fig. VI.34.- Accin UNDO
Las acciones REDO y UNDO son equipotentes, es decir, su aplicacin reiterada sobre una transaccin produce el mismo efecto que si se ejecuta slo una vez. Undo y Redo constituyen la base de distintos mtodos de ejecucin de los comandos Commit. El contenido del Log difiere de unas implementaciones a otras. Sin embargo, el Log debe contener, al menos, la siguiente informacin mnima por cada transaccin: un registro begin-transaction, el valor del item del dato antes de la actualizacin (llamado imagen anterior), el valor del dato actualizado (imagen posterior), un registro de terminacin indicando la condicin del fin de la transaccin (commit, abort). La granularidad de las imgenes anterior y posterior puede ser distinta, se puede guardar en el Log pginas enteras o unidades de informacin ms pequeas.
DIT-UPM
Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica 3.6.4.- Gestor de Recuperacin frente a fallos del Sistema.
Al igual que la BD voltil, el Log tambien se mantiene en buffers de memoria principal (llamado buffers del log) y se re-escribe en el almacenamiento estable (llamado log estable) anlogo a como se hace con las pginas del buffer de la BD (ver figura VI.35).
Memoria Secundaria Memoria principal
Log Estable
Read Write
Gestor de Recuperacin Local

Fetch, Flush
Buffers del Log
BD Estable
Gestor de Buffer de la BD -cache-
Read Write
Fig. VI.35.- Interfaces de los Logs.
Las pginas del Log pueden guardarse en el log estable de dos formas. Pueden ser escritas de forma sncrona, (conocido como forzar un log) en la cual, cada vez que se aade un registro al log es necesario llevar un registro del log en memoria principal a la memoria estable. Tambien, las pginas del Log pueden guardarse de forma asncrona, donde el log se graba en disco bien por intervalos de tiempo peridicos, bien porque se llene el buffer. Con la forma sncrona, se suspende la ejecucin de la transaccin hasta que se complete la escritura, lo que retarda el tiempo de respuesta de los datos.Por otro lado, si el fallo aparece despues de haber forzado una escritura, resulta relativamente fcil la recuperacin de la BD a un estado consistente. Bien se escriba el log de forma sncrona o asncrona, es muy importante que el mantenimiento de los logs se regule por algn protocolo. Consideremos el caso donde las actualizaciones a la BD se escriben en la BD estable antes de haber modificado el Log estable para reflejar el nuevo valor. Si aparece un fallo antes de escribir en el log, la BD estar actualizada pero no el Log lo que hara imposible recuperar la BD a un estado consistente y actualizar su estado. Esto se conoce como el protocolo write-ahead-logging, -WAL- [Gray, 1979] y se especifica como se indica a continuacin: 1.- Antes de actualizar la BD estable (quiz debido a las acciones de una transaccin activa y no commited), la imagen anterior deber ser guardada en el log estable. Esto facilita el UNDO. 2.- Cuando una transaccin alcanza el estado commited, la imagen anterior tiene que ser grabada en el log estable antes de actualizar la BD estable. Esto facilita el REDO. En definitiva, el Log es como un mini-base-de-datos que vaguardando los cambios habidos durante un da. El Log estable reside en el disco duro y suelen generarse unos 200 MB. Por motivos de espacio y seguridad, el Log suele guardarse tambin en cinta. La parte del Log generada ms recientemente, reside en un bloque de Memoria Principal y se llama Log Activo, como representa la figura VI.36. El Gestor del Log (Log Manager, LM) hace el volcado a disco y a cinta cuando el bloque del Log Activo se llena. Este bloque lleno, slo tiene transacciones que se han ejecutado correctamente y completamente. Si una transaccin activa no cabe en el Log Activo, es fallada por el sistema y pasa al estado aborted.
Captulo 3.
42
DIT-UPM

Memoria Secundaria Memoria principal
Log Estable
Gestor de Recuperacin Local (LRM)

Fetch, Flush
Buffers del Log Activo
BD Estable
Read Write
Gestor de Buffers (BM) de la BD y del Log (LM)

Write Write
Read Write
Archivo de la BD
Archivo del Log
Fig. VI.36.- Jerarqua completa de memorias gestionadas por el LRM y el BM.
Cuando una transaccin quiere leer una pgina de datos, indicada en el comando Fetch, el LRM enva un Fetch al BM; primero accede a Memoria Principal, si no est all, va a disco duro a modo de Cach o memoria virtual (ver figura VI.36). El LRM enva un Flush al BM; para forzar una escritura desde Memoria Principal a disco duro y a cinta de un nmero de pginas en los Buffers. El BM es quien decide cundo se van a escribir dichas pginas.
3.6.5.- Fallos del Sistema: LRM y Checkpoint.
Un fallo del sistema supone parar todos los procesos y arrancar de nuevo. Las transacciones que estuvieran activas en el momento del fallo hay que abortarlas ya que no haban finalizado cuando vino el fallo. Ello supone realizar una operacin UNDO desde el Log Estable. El LRM podra abortar las transacciones leyendo el Log y buscando las que tienen BeginTransaction pero no tienen Commit o Abort. Pero, si se hace as, se gasta mucho tiempo. Para agilizar, se usa la tcnica de los Checkpoint. El LRM, cada cierto tiempo (5 min. o cuando el Log Activo tiene ya una cantidad de datos) toma un Checkpoint que adopta la forma de registro y lo graba en el Log Estable ( estos registros Checkpoint hacen las veces de las piedras que Pulgarcito dejaba por el camino para saber volver por lo ya andado). Grabar un registro Checkpoint supone seguir los tres pasos siguientes: Paso 1.- Grabar en el Log Activo un registro Checkpoint (Begin-Check) Paso 2.- Forzar a que el contenido de los Baffers de la BD salga hacia laBD Estable Paso 3.- Escribir en un fichero de re-arranque la direccin del Log Activo donde se ha grabado el ltimo Checkpoint y escribir un End-Check en el Log Activo. Si aparece un fallo entre el Paso 1 y el Paso 3, el LRM al rearrancar- no considera vlido el ltimo Checkpoint e ira a buscar el anterior atomicidad de la operacin checkpoint. Cada registro Checkpoint grabado en el Log contiene la siguiente informacin: Una lista con todas las transacciones activas en el momento del Checkpoint. La direccin que tiene cada transaccin en el Log, que son las ms recientemente Al rearrancar, el LRM crea las dos listas siguientes, y efecta las siguientes acciones: Lista-UNDO Lista-REDO
Captulo 3.
43
DIT-UPM
A.- Consulta el fichero de re-arranque para leer en qu direcciones del Log estn los registros Checkpoint ms recientes. B.- Localiza el registro Checkpoint ms reciente en el Log C:- Explora el Log hacia delante y hasta el final. Inicialmente, la Lista-UNDO contiene todas las transacciones grabadas en el registro Checkpoint y la Lista-REDO est vaca. El LRM, en el paso C.-, explora el Log desde el ltimo Checkpoint hasta el final, como representa la figura VI.37; y lleva a cabo las siguientes acciones, de forma que: 1.- Si encuentra un registro Begin-transaction para una transaccin dada, aade esa transaccin a la Lista-UNDO. 2.- Si encuentra un registro Commit para una transaccin dada, lleva esa transaccin de la ListaUNDO a la Lista-REDO.
Fallo LOG
ltimo Reg.Checkp. Transacciones activas en el mto. del Checkpoint Paso C1: Grabando en las Listas UNDO y REDO Paso C2: Compara las Listas para ir deshaciendo (UNDO) y explora el Log hasta encontrar los Begin-Transaction de las transacciones que constan en ese registro checkpoint. Paso C3: Empieza a rehacer (REDO) las transacciones que tiene en la Lista-REDO.
Fig. VI.37.- Acciones UNDO y REDO del LRM.
La figura VI.38 muestra un ejemplo de las acciones llevadas a cabo por el LRM, para un determinado contenido de un registro Checkpoint, en el momento que surge un fallo.
T Check T1 T2 T3 T4 T5
Tiempo
Local Recovery Manager
T 3 y T5 deben ser deshechas, UNDO
Fallo
T 2 y T4 deben ser rehechas, REDO, porque -aunque en estado commited-, no se tiene la garanta de que las actualizaciones se hayan grabado en la BD.
Fig. VI.38.- Ejemplo de las Acciones UNDO y REDO del LRM.
3.7.- Arquitectura funcional del SGBD: Cliente/Servidor (dos capas) y Arquitectura Web (tres capas). Los SGBD, una de las variedades ms complejas del software actual, precisan la utilizacin del trmino arquitectura con diversas acepciones y varios puntos de vista. Este epgrafe describe la arquitectura del SGBD bajo el punto de vista de sus formas operativas (o de funcionamiento), contemplado ahora como un ente individual que lleva a cabo las aplicaciones del usuario. La arquitectura ANSI/X3/SPARC, descrita en el captulo 1, explica cmo se organiza la informacin de una BD. En el captulo 2 se ha descrito cmo se organizan varios SGBDs para la interoperabilidad (generalmente distribuida), all vimos la arquitectura C/S con funcionalidad varios-a-varios (varios
DIT-UPM
Clientes y varios -no muchos- Servidores). Finalmente, en 3.2 y 3.5 hemos atendido a otro tipo de arquitectura llamada arquitectura revisitada, centrada en la descripcin de los aspectos ms internos del software que poseen los motores o Servidores de bases de datos. La arquitectura C/S surge a principios de la dcada de los 90s, se extendi con gran difusin en la tecnologa de bases de datos, y marc importantes pautas en la concepcin arquitectural de los SGBDs, separando ntidamente las funciones del Servidor y las funciones de los Clientes. La arquitectura para los SGBD es algo diferente a la organizacin del software genrico en Cliente/Servidor (entendido slo mirando a los procesos que invocan y a los que sirven), ya que la interaccin en los SGBDs est ms especializada. Como se ha dicho en el captulo 2, la distribucin es el ingrediente ms comn en los actuales Sistemas de Informacin. En este epgrafe se atiende a la arquitectura de un SGBD, visto como un ente individual (sin cooperar con otros SGBDs) para llegar a entender los bloques que posibilitan su funcionamiento. Este punto no entra en detalles sobre cmo opera el motor o Servidor de Bases de Datos (vistos en 3.4 a 3.6; para ms detalles vase el captulo 9 de [Cost99]). Basta ahora con entender que dicho motor contiene el ncleo de las funciones de un SGBD y ha de ejecutarse en un ordenador donde la CPU, la memoria secundaria y la principal han de ser adecuadas para la gestin de datos masivos. Ahora veremos cmo se organiza el SGBD en capas para, con ellas, llevar a cabo, en la capa Cliente, determinadas funciones de los aplicativos de usuario, es como una especie de pre-procesamiento de las aplicaciones que han de terminar ejecutndose en el Servidor de Bases de Datos. Adems de esto, la funcionalidad de la capa del Cliente consiste en implementar funciones del usuario para ofrecer interfaces amigables a ste y ofrecer alta productividad para dichas funciones de usuario (entornos ofimticos con: e-mail, procesadores de texto, hojas de clculo, etc.). Estudiaremos dos tipos de arquitecturas. En la primera, se describe la arquitectura a dos capas, llamada tambin arquitectura Cliente/Servidor del SGBD. La segunda describe la arquitectura a tres capas, dirigida hacia la World Wide Web y aade una nueva capa conocida como Servidor de Aplicaciones que incluye al Servidor Web (o Servidor HTTP). 3.8.- Arquitectura Cliente-Servidor (dos capas). En el captulo 2 vimos el paradigma Cliente-Servidor como el ms simple dentro del amplio espectro de la distribucin de los SGBDs. Un SGBD cuya arquitectura es de tipo Cliente-Servidor funciona separando limpiamente el papel que juega el Servidor del que desempea el Cliente. Esta arquitectura, pensada para operar en modo distribuido, organiza la forma de llevar a cabo la ejecucin de las aplicaciones entre mquinas distintas que estn conectadas por una red (generalmente LAN) que suele alcanzar a distintas dependencias del edificio(s) donde ella opera, como muestra la figura 9.1. En la tecnologa relacional, la integracin de esta arquitectura se basa principalmente en el protocolo Net (Oracle, por ejemplo, lo llama SQL*Net ). Usando un solo motor SGBD, todas las mquinas son de tipo Cliente salvo una que es la Servidora (varios Clientes y un Servidor). Realmente no es preciso que Cliente y Servidor se ubiquen en distintas mquinas, pues el paradigma de esta arquitectura se fundamenta en construir el software con independencia de dnde se ubiquen los procesos. Sin embargo, en la gestin de datos, normalmente los procesos del Servidor se ubican en una sola mquina y las mquinas de los Clientes se esparcen por la red de la institucin o empresa para la cual se instala este tipo de arquitectura. La arquitectura C/S de un SGBD balancea la carga de trabajo entre los Clientes y el Servidor, repartiendo las tareas implicadas en la ejecucin de las aplicaciones. El SGBD distribuye, por tanto, su software en diversas mquinas cuando opera a nivel de produccin industrial.
Captulo 3.
45
DIT-UPM

Aplicativos del Cliente 1 Aplicativos del Cliente i Aplicativos del Cliente n Usuario
Cliente 1
Cliente i
Cliente n
Capa Cliente
Red (LAN o MAN )
Cola de Salida
NET junto al nombre del SGBD

Cola de Entrada
Capa Servidora Servidor de Bases de Datos
Arquitectura C/S Abreviada

Fig. 9.1. Arquitectura Cliente-Servidor de un SGBD.
3.8.1.- Funcionalidad de la Arquitectura Cliente-Servidor.
La funcionalidad Cliente-Servidor se basa en un modelo de interaccin entre procesos software. Los clientes solicitan y requieren la invocacin de procesos (requests, queries, etc.) que ellos no poseen y los procesos solicitados residen en la parte Servidora. La arquitectura genrica C/S se organiza de forma que un Cliente puede solicitar servicios a varios (no muchos) Servidores. Este epgrafe, dedicado a la arquitectura de un solo SGBD, parte de la hiptesis que el Servidor (Servidor de BDs) es nico en este tipo de arquitectura y los Clientes quedan conectados a l mediante una red (LAN casi siempre) cuya forma de interaccin (C/S) se basa en el protocolo NET. Los procesos del lado Cliente se dedican a atender las necesidades del usuario final, ellos reciben las aplicaciones del usuario y las preprocesan para transformarlas en otras unidades que envan al Servidor para solicitar sus servicios. Los Clientes son los que solicitan a la parte Servidora que lleve cabo la ejecucin definitiva de los aplicativos (accesos y/o actualizaciones a los valores de los datos de la BD). Por tanto, el Cliente enva siempre todas sus solicitudes al Servidor, mientras que el Servidor atiende las solicitudes de varios Clientes. Las siguientes razones justifican el uso de la arquitectura C/S en bases de datos: La arquitectura C/S permite una limpia separacin de objetivos y trabajos. Por un lado, cada mquina Cliente se dirige a optimizar determinadas aplicaciones del usuario final, conocidas de antemano por quien construye el sistema de informacin. Cada Cliente atiende a un conjunto determinado de aplicaciones (las de un tipo de usuario) y el programador de aplicaciones es responsable de escribir programas (aplicativos) para que cada Cliente responda a las necesidades especficas en cada mquina. Por otro lado, el diseador y el administrador de las bases de datos, trabajarn en la capa Servidora para realizar las tareas propias y relativas a temas de diseo, asignacin de roles de usuario, permisos y privilegios, configuracin de espacios de tablas, mantenimiento de ndices para un ptimo rendimiento funcional, etc. Todo ello ser compartido por todos los clientes de una arquitectura dada. En definitiva, los trabajos del Servidor se dirigen a proporcionar ptimos servicios a todos los procesos de sus clientes. La potencia del ordenador donde se ubica el Servidor depende estrechamente de los servicios que ste tiene que ofrecer, necesita una gran memoria principal para la gestin de mltiples buffers y
DIT-UPM
una alta capacidad de disco duro para almacenar completamente la base de datos. Sin embargo, en la mquina Cliente suele bastar con un tpico ordenador personal que proporcione diversas herramientas de un entorno ofimtico. Entre dichas herramientas, casi siempre enmascaradas por unas interfaces amigables para el usuario, tiene que tener instaladas las destinadas a solicitar aplicaciones al Servidor de Bases de Datos, como muestra la figura 9.2. El lenguaje SQL de los SGBDR es ideal para identificar los servicios de interfaz de la capa cliente, que es la capa responsable de interpretar la consulta del usuario, darla formato y presentar los resultados al usuario de forma adecuada. La consulta, escrita en la parte Cliente, se enva al Servidor para que all sea procesada. El Servidor extrae los resultados de la base de datos, los empaqueta y, finalmente, se lo devuelve al Cliente que hizo la solicitud. De esta forma, por la red circula la mnima informacin til [Cost88]. La consulta SQL del usuario admite dos formas de invocacin diferentes. La primera, conocida como consulta compilada de forma esttica donde sta llega al Servidor slo una vez, all se compila y se almacena para ser re-llamada tantas veces cuantas sea preciso. De esta forma, el Servidor almacena el cdigo compilado de la consulta en forma parametrizada; y, en cada invocacin del cliente (tpicamente se invoca a un procedimiento), basta con pasar los valores de los parmetros que corresponda. A menudo, el Servidor que procesa estos procedimientos es multi-hebra (multi-threaded) y cada unidad de ejecucin del proceso del Servidor, para una transaccin dada, es una hebra. Como representa la figura 9.1, los procesos del Servidor estn activos permanentemente para ir recibiendo solicitudes de los Clientes desde la cola de entrada, y dejan en la cola de salida los resultados que el Servidor obtiene para envirselos a cada respectivo Cliente. La gestin de las colas del Servidor se lleva a cabo por el dispatcher.
Usuario
Sistema Operativo
Interfaces Aplicativos Entorno de de BD Ofimtico Ususario
Capa Cliente
Procesos Cliente del SGBD

Comunicacin de datos
Red (LAN )
Consultas SQL Resultados
S. Operativo
Capa Servidora
Comunicacin de datos
Servidor de Bases de Datos, motor del SGBD
Fig. 9.2. Detalle de la capa Cliente de un SGBD con arquitectura C/S.
La segunda forma de invocacin se conoce como consulta dinmica, donde la consulta del Cliente se transmite al Servidor como un string de caracteres y all es compilada y ejecutada cada vez. La idea global de un Sistema de Informacin con esta arquitectura es que funcione en el modo de consulta esttica (compila una vez y lo guarda en el Servidor), para ser re-llamada de continuo, cuantas
DIT-UPM
veces se precise su ejecucin en el Servidor. Mientras que el modo de invocacin de consulta dinmica est pensado para un tipo de consultas espordicas o no frecuentes, su rendimiento es ms bajo que el de la invocacin esttica y por tanto con un mayor tiempo de respuesta.
3.9.- Arquitectura Web (tres capas).

La espectacular evolucin de Internet plantea grandes retos para mejorar su potencialidad y actuales soluciones. La tecnologa world-wide-Web (www) es y ser el substrato de interconexin de la sociedad de la informacin actual y futura. Su ritmo de expansin y la diversidad de usuarios crecen de forma continua y exponencial. Se conectan a Internet desde las empresas y gobiernos (con redes de alta velocidad) hasta los individuos desde los hogares (con modems de baja velocidad). Muchas empresas e instituciones han desarrollado su propia Intranet conectada a Internet. Los sistemas de este tipo se conocen como Sistemas de Informacin Web (en adelante, SIW, en ingls WIS), y acoplados con un SGBD se puede proporcionar acceso rpido e inteligente a grandes cantidades de datos estructurados, como ya conocemos que estn y existen en una base de datos. La Web empez siendo una interfaz para el acceso a documentos distribuidos, y hoy es una plataforma para los sistemas de informacin de todo tipo. La Web es un paradigma que permite difundir y adquirir cualquier tipo de informacin a travs de una arquitectura, configurada en capas que, en el caso de un SGBD con arquitectura Web, son las tres siguientes (vase figura 9.3):
Browser Capa 1 Cliente (Front End con el Navegador del Usuario)
Internet
Servidor Web y Servidor de Aplicaciones

Internet
Capa 2, 1er. Servidor (Intermedia)
Servidor de Bases de Datos
Capa 3, 2 Servidor (Back End)
Bases de Datos
Figura 9.3. Arquitectura Web Abreviada (a tres capas) de un SGBD.
Capa frontal (Front End), formada por una herramienta genrica llamada navegador1 o browser (como Netscape Navigator o Microsoft Internet Explorer), que constituye la interfaz de la mquina del usuario para navegar por dicha informacin. El browser es la parte del usuario, por tanto, es el lado Cliente (descrito en C/S como 1 capa) ahora llamado Cliente delgado, ligero o fino porque son mnimas las exigencias del ordenador que as funciona. Se puede entender al browser como una Interfaz Grfica de Usuario (GUI) que reside en la mquina cliente o mquina remota del usuario. Capa intermedia, llamada Servidor HTTP o Servidor Web que, generalmente, contiene adems al Servidor de Aplicaciones. Se puede entender a esta capa como un conjunto de programas residentes en sitios Web.
Navegador, mquina conectada a Internet, en ingls: browser. Este texto usa indistintamente ambos trminos.
Captulo 3.
48
DIT-UPM
Capa dorsal (Back End), llamada Servidor de Informacin o Servidor de Bases de Datos, descrito con detalle en los puntos de 3.4 a 3.6. Casi toda la actual tecnologa de bases de datos ya dispone de un Servidor de Aplicaciones adems del Servidor Web como primera mquina servidora (ubicada en la 2 capa intermedia) y de una segunda mquina servidora donde reside el Servidor de Bases de Datos que pasa a estar en la 3 y ms interna capa operativa de esta arquitectura, como muestra la figura 9.3.
3.9.1.- Internet y la World Wide Web.
Internet funciona como una federacin de redes comunicadas todas por el mismo conjunto de protocolos, procedentes de la familia TCP/IP (Transmission Control Protocol/Internet Protocol). Un nodo de Internet forma parte de una red de rea local (LAN) que se forma conectando nodos (con PCs o estaciones de trabajo) ubicados en un rea de pequeo alcance. Las redes locales se comunican con las dems formando una jerarqua de redes, por ejemplo: la red universitaria, la red de todas las universidades de un pas, toda la red nacional, y as sucesivamente. Fsicamente, la jerarqua de redes y la estructura de direcciones de los nodos dentro de una red se muestran transparentes (a los usuarios y a los programas), de tal forma que el usuario puede referenciar2 a cualquier nodo cuya direccin sea conocida por l. Lgicamente, esta federacin de redes se percibe como que cualquier nodo Internet puede conectarse con cualquier otro. Para ello, TCP/IP se organiza en capas como se describi brevemente en el captulo 2. El protocolo TCP permite que ordenadores de todos los tamaos (de cualquier fabricante y con sistemas operativos totalmente distintos) se comuniquen entre s, y resulta apasionante ver cmo se han superado todas las estimaciones en cuanto a su crecimiento. Lo que comenz a finales de los aos 60 como un proyecto de investigacin financiado por el gobierno norteamericano sobre redes de conmutacin de paquetes, ha llegado a ser desde los 90 la forma de comunicacin entre ordenadores ms difundida. Se trata de un sistema abierto, donde la definicin del protocolo y muchas de sus implementaciones son pblicas y gratuitas. Y actualmente TCP/IP es la infraestructura de Internet, la red de rea global que, como sabemos, recubre el globo interconectando millones de ordenadores. La Web se inici con la idea de llegar a ser el medio para poder acceder a diversos documentos de varios tipos, producidos para temas diferentes y mantenidos desde multitud de nodos conectados por Internet. El documento recibi el nombre de hipertexto3 porque su naturaleza no es secuencial, est formada por varias partes relacionadas mediante enlaces; de forma que se puede acceder a cada parte directamente, sin la rigidez de tener que seguir una secuencia dada. La Web se percibe normalmente como una coleccin de documentos no estructurados. La idea de hipertexto se ha generalizado en muchos sentidos. La tcnica no estructurada no tiene porqu aplicarse slo al documento, mas bien puede usarse para relacionar diversos documentos producidos por distintas personas en distintos momentos. Adems, los documentos no tienen porqu ser textuales, tambin pueden tener imgenes, vdeo, voz, etc. y; cuando esto ocurre, entonces hablamos de navegacin por los hipermedia. Adicionalmente, dichos documentos suelen estar distribuidos entre los nodos de cualquier red de ordenadores; en suma, en Internet. Finalmente, la Web no slo permite acceso a documentos estticos, sino que tambin permite lanzar programas para que stos generen dinmicamente documentos nuevos (en pginas dinmicas). El epgrafe 3.9.2 describe los principales componentes tecnolgicos que posibilitan la implementacin de estas ideas que acaban de esbozarse para la Web. Principalmente son: 1. el protocolo de comunicacin HTTP, 2. el concepto URL para referenciar a los servidores que poseen los 3. el lenguaje HTML para marcar las partes de los documentos, y 4. el avanzado lenguaje XML, extensin de HTML.
2 3
recursos,
Referenciar, en la tcnica se entiende como apuntar, sealar o enlazar a algo con otra entidad u objeto. Hiper, prefijo griego que significa "exceso". Captulo 3. Abril, 2008. Por: C.Costilla
49
DIT-UPM
Desgraciadamente, la Web est an lejos de ser un repositorio bien organizado de documentos XML, mas bien hoy es un conglomerado de pginas HTML voltiles cuyas estructuras han de ser extradas4 en cada acceso. El xito alcanzado por la Web ha puesto en evidencia que existe una necesidad urgente de ir ms all de una simple navegacin humana por entre los documentos. Ahora, es preciso abordar la construccin de nuevos pasos que permitan realizar dicha navegacin automtica a las aplicaciones con el fin de llegar a ofrecer nuevas formas de interoperabilidad entre los servicios Web. Para lograr esto, las fuentes de informacin de la Web necesitan ser accesibles de forma estructurada y, en este sentido, XML y sus diversas extensiones (en modelos de datos y lenguajes consultivos) son pasos que se vienen dando en esta direccin.
3.9.2.- Servidores de la capa intermedia en la Arquitectura Web.
La figura 9.4 muestra de nuevo la arquitectura Web (de la figura 9.3) destacando la segunda capa donde est la primera mquina Servidora en la cual se incluyen dos tipos de servicios: el proporcionado por el Servidor Web y el del Servidor de Aplicaciones, descritos a continuacin.
Browser
Internet Solicitud HTTP (URL + Entrada) Respuesta HTML
Servidor Web o Servidor HTTP
Entrada
HTML
Programa Servidor, Gateways: CGI/Fast CGI/Java Servlest/ASP/JSP
Internet Consulta SQL

Cola de Entrada
Datos de la BD
Cola de Salida
Base de Datos
Figura 9.4. Detalle de la capa 2 de la Arquitectura Web de un SGBD.
3.9.2.1.- Servidor Web: URLs y Protocolo HTTP.
Extraer, sacar algo que est incrustado en el documento. Captulo 3. Abril, 2008. Por: C.Costilla
50
DIT-UPM
La arquitectura Web es una variante de C/S, ya descrita, que se basa en el protocolo TCP/IP; y, sobre ste, en Web se instala el protocolo HTTP (Hyper Text Transfer Protocol). Con HTTP cualquier cliente browser puede solicitar un documento a un servidor Web usando su URL5 (Uniform Resource Locator). Como indica la figura 9.4, la Web trabaja sobre Servidores HTTP, ms conocidos como Servidores Web. El protocolo HTTP es de naturaleza muy simple y consta de cuatro fases: a) Abrir la Conexin; en ella, el browser contacta con el servidor HTTP que se indica en el URL para verificar su disponibilidad y correccin (llamado Solicitud HTTP en la figura 9.4); b) Establecer la conexin, si el servidor est disponible, ste acepta la conexin y enva una confirmacin al cliente (no representado en la figura 9.4); c) Enviar solicitud, el cliente enva un mensaje al servidor con la solicitud de un servicio dando el nombre del recurso invocado y los posibles parmetros de la invocacin (llamado Entrada en la figura 9.4); d) Recibir respuesta, el servidor devuelve al cliente el resultado del servicio requerido (llamado Respuesta HTML en la figura 9.4), y se cierra la conexin por el servidor sin retener informacin alguna para ser usada en conexiones subsiguientes. La Web hace uso de la naturaleza distribuida de los hipertextos y, mediante un esquema clienteservidor, proporciona un servicio de transferencia de hipertextos basado en el protocolo HTTP, usado desde 1990. Por tanto, HTTP es un protocolo de nivel de aplicacin con la agilidad y velocidad necesarias para sostener sistemas de informacin hipermedia distribuidos. Se trata de un protocolo orientado a objetos, de carcter genrico, que puede ser usado para muchas tareas, tales como nombrar servidores y sistemas de manipulacin de objetos distribuidos, a travs de la utilizacin de las extensiones de sus comandos. Las principales caractersticas del protocolo HTTP son su tipado de objetos y la negociacin de la representacin de los datos, permitiendo que los sistemas se construyan con independencia de los datos que deben transferir. Una buena parte de los datos accesibles sobre la Web estn almacenados en repositorios estructurados, como ocurre en bases de datos. Otros repositorios, como los ficheros planos (textos, imgenes, audio y vdeo), se gestionan a menudo mediante aplicaciones ad hoc. Aunque, desde el momento en que los datos son accedidos va Web, la forma fsica de cmo estn organizados estos datos en el repositorio queda siempre oculta para el usuario quien slo percibe que unas veces el acceso es gil e inteligente, y otras es lento, algo rgido y no hbil. La direccin de cada mquina -nodo de Internet- que funciona en la modalidad C/S es conocida en el alcance donde ella coopera (para un funcionamiento global) por su direccin IP (Internet Protocol, o nombre asociado a ella) que la identifica unvocamente y TCP es el protocolo para controlar las transferencias de informacin entre mquinas. Sobre TCP/IP, la tecnologa Web se fundamenta en saber localizar sitios Web desde una mquina conectada a Internet, que -a su vez- tambin es un sitio Web. El punto de entrada a la Web desde un sitio Web es su pgina casera (home page), identificada por un URL formado por bloques (de nmeros o nombres asociados a esa direccin) y separados por puntos (por
ejemplo: http://www.etsit.upm.es es la pgina casera de nuestra Escuela de Telecomunicacin, y http://www.w3c.org es el URL del sitio Web que es responsable de la definicin de estndares Web). Un URL
se refiere a otros documentos de otros URLs. As es como se proporciona la navegacin por los hipertextos para su localizacin. Todo URL tiene la siguiente estructura: [Protocolo://][Servidor/]Recurso, y define objetos en una red Internet, que contienen datos sobre:
URL, es el Localizador de Recursos Uniforme. Su gnero es masculino, aunque a veces se designe como la direccin donde se encuentra el recurso (en femenino).
Captulo 3.
51
DIT-UPM
a) el Protocolo deber ser de alguno de los tipos disponibles en Internet; por ejemplo HTTP, o FTP (File Transfer Protocol), Telnet (para emulacin de terminales) o e-mail para correo electrnico (todos vistos
como objetos asociados con alguno de los protocolos o servicios disponibles en Internet: ftp, http, mailto, file, etc.),
b) el nodo Servidor de la red, formado [host]:, que viene dado generalmente por su nombre simblico, aunque tambin se puede escribir la direccin IP donde se encuentra dicho servidor, y c) el Recurso dado por el path del directorio seguido del nombre del fichero expresado como
[puerto]/[path del fichero] cuyo fichero fsico contiene el objeto solicitado.
Por ejemplo, esto es un URL: http://microsoft.com/download/aspdoc.zip. Si se omite el puerto se tomar el vlido por defecto para el protocolo o servicio utilizado (puerto 80 para servicios Web). Existen URLs absolutos y relativos. Los absolutos especifican un path completo (como el del ejemplo anterior) y los relativos especifican un path relativo al URL del documento (por ejemplo: imagenes/dibu1.gif). HTTP es el valioso medio por el que se establecen enlaces entre un gran nmero de nodos independientes. Su contrapartida es que no mantiene ningn contexto entre el cliente y el servidor, lo que puede redundar en una alta pesadez para el usuario a la hora de mantener determinadas sesiones. Si un cliente lanza a un mismo servidor varias solicitudes, el servidor no es capaz de mantener informacin sobre las solicitudes anteriormente hechas por el mismo cliente ni de los resultados anteriormente enviados a ste. Ello se debe a la gran simplicidad del protocolo, lo que representa serias limitaciones en aquellos casos donde se requiere una interaccin fluida entre mquinas, como las que necesitan las transacciones realizadas en las bases de datos.
3.9.2.2.- La seguridad en Internet.

Como todo sistema de comunicaciones informtico, la Web precisa una serie de herramientas de seguridad asociadas como son: La autenticacin de solicitudes. Autenticacin de servidores. La privacidad de solicitud y respuesta. Proteccin contra abusos de la capacidad del servidor. Control de acciones inconscientes sobre la red. El abuso de la informacin disponible. Aunque HTTP intenta abordar algunos de estos problemas, la seguridad se ve muy mejorada en el protocolo HTTPS, cuya 'S' final significa Security.
3.9.2.3.- Gateways, CGI y Servidor de Aplicaciones.

Los Servidores Web invocan a programas (llamado Entrada en la Figura 9.4) y, en cada invocacin, pasan los debidos parmetros, como por ejemplo: los datos de entrada que el usuario ha escrito en un formulario (form). Ahora veremos el concepto bsico relativo a la forma de acceso a una base de datos. En la figura 9.4 se observa el flujo de mensajes (unos de peticin, otros de respuesta) entre el browser, el Servidor Web y el Servidor de Aplicaciones. La primera peticin del cliente se enva al Servidor Web y ste, a su vez, enva la informacin pedida al Servidor de Aplicaciones que es quien invocar al Servidor de Bases de Datos. Cuando ste ltimo servidor realice las acciones necesarias, enviar la respuesta con la informacin procesada siguiendo el camino anterior, pero ahora recorrido en direccin contraria, hasta que la respuesta llegue al browser que lanz la solicitud. Describiremos brevemente cmo se establece la comunicacin entre el Servidor Web y el Servidor de Aplicaciones. Para ello, el Servidor Web utiliza diferentes tecnologas para obtener y enviar la informacin que va a ofrecerle el Servidor de Aplicaciones. Dichas tecnologas son las siguientes: CGI (Common Gateway Interface) es el mecanismo de comunicacin y suele estar escrito en: Java, C, C++, Perl, etc., - ASP (Active Server Pages), tecnologa de Microsoft,
DIT-UPM
- JSP (Java Server Pages), - Java Servlets, tecnologa de Sun, - Java Script, tecnologa de Netscape Un gateway6 es cualquier programa que ha sido llamado por un Servidor Web. El programa puede estar escrito en un lenguaje de alto nivel (C, C++ o Java) y compilado, o bien en un lenguaje interpretado (como Perl o Tcl -usado para realizar operaciones sobre cadenas de caracteres-), o incluso puede estar en algn lenguaje script de los sistemas operativos. Como su nombre indica, el gateway permite establecer una conexin entre el Servidor Web y otro entorno cualquiera que proporcione el servicio requerido. El Servidor de Aplicaciones es un programa que reside en el 1er. Servidor (2 capa) de la arquitectura Web y proporciona cierta lgica de negocio para las aplicaciones. El gateway se invoca usando un URL parecido a como se invoca a los ficheros HTML mediante el protocolo HTTP donde, normalmente se inicia con http:// , despus se indica el nombre del servidor, el del directorio y el de un fichero (path), y los parmetros en curso se pueden especificar aadindoles al URL.
Browser
Servidores de Aplicaciones Web
JAVA
Netscape App Server IBM Websphere Oracle Web App Server Sun NetDynamics BEA WebLogic Silver Stream Inprise App Server
ActiveX
Lotus Domino Microsoft ASP/MTS
C / C++
Applet Web Objects Seagate Info APS
Bases de Datos
Figura 9.5. Detalle del Servidor de Aplicaciones en la Arquitectura Web de un SGBD.
El mecanismo de comunicacin entre el Servidor Web y los gateways se llama CGI y sigue los siguientes pasos: 1. El usuario, desde su browser, solicita el URL bien enviando un formulario o bien haciendo click con el ratn sobre un ancla. Con ello, se transmiten los parmetros al Servidor Web, cuyas tcnicas detalladas escapan al inters de este libro. 2. El Servidor Web lanza el gateway (tambin llamado programa CGI) segn el protocolo CGI y le transmite los parmetros. 3. Con los parmetros recibidos, se ejecuta el gateway y, en la arquitectura que nos ocupa, interactuar con el Servidor de Bases de Datos (llamado Consulta SQL en la figura 9.4).
Gateway, puerta de paso, pasarela a otro entorno. Usaremos gateway por brevedad y uniformidad con la terminologa tcnica.
Captulo 3.
53
DIT-UPM
4. Cuando el gateway reciba respuesta del Servidor de Bases de Datos (llamado Datos de la BD en la figura 9.4), retornar el resultado al Servidor Web (llamado HTML en la figura 9.4). 5. Finalmente, el Servidor Web transmite este resultado al browser (llamado Respuesta HTML en la figura 9.4). La figura 9.5 muestra detalles de algunas implementaciones utilizadas para el Servidor de Aplicaciones, cuyas principales caractersticas se resumen en los siguientes puntos: Gestin de Componentes: Proporcionan herramientas para controlar todos los componentes y servicios de ejecucin como la gestin de sesiones, notificaciones sncronas / asncronas entre clientes, as como la ejecucin de servidores de lgica de negocio. Tolerancia frente a Fallos: Capacidad de recuperacin frente a fallos, evitando un nico punto de ruptura, definiendo polticas de recuperacin en el caso de fallo de uno o varios objetos. Balanceo de Carga: Posibilidad de enviar las peticiones a diferentes servidores dependiendo de la carga y capacidad de cada uno de ellos. Gestin de Transacciones: Descrito en 3.5. Gestin Centralizada: Gestin centralizada a travs de una consola grfica para monitorizar los clientes y los distintos servidores o clusters. Seguridad: Caractersticas de seguridad y gestin de usuarios y grupos. Los servidores de aplicaciones se organizan principalmente en tres grandes tipos: Web Information Servers: Este tipo de servidores emplean plantillas HTML y Scripts para generar pginas e incorporar valores de las bases de datos en ellas. Estos servidores son stateless servers, es decir, no gestionan el estado de los datos ni coordinan las transacciones. Servidores de este tipo son el Netscape Server, Allaire o Sybase. Component Servers: La principal caracterstica de estos servidores es la de proporcionar acceso a la base de datos y servicios de procesamiento de transacciones a componentes DLL, CORBA, y JavaBeans. Proporcionan el entorno para los componentes del servidor y acceso a los datos y otros servicios a estos componentes. Tambin son stateless servers. Ejemplos de este tipo de servidores son MTS, Sybase Jaguar, y el IBM Component broker. Active Application Server: Este tercer tipo de servidores soportan y proporcionan un buen entorno para la lgica del servidor expresada en objetos, reglas y componentes. A diferencia de los anteriores, son stateful servers y son ms propicios para el desarrollo basado en e-commerce y procesos de toma de decisiones. Los stateful servers son aquellos que juegan el rol de coordinadores de transacciones y gestionan el estado de los datos (se estudiarn junto al protocolo Two Phase Commit). 3.10.- Diseo de Bases de Datos en sitios Web. Todos los conceptos y tcnicas del Modelado Conceptual (descrito en el captulo 2 de [Cost99]) y del Diseo de Bases de Datos Relacionales (descrito en el captulo 4 de [Cost99]) son adaptables al caso que nos ocupa. Ahora, la base de datos se concibe para operar en la arquitectura Web, donde el sitio de nuestro inters contendr un Servidor de Bases de Datos y, por tanto, los accesos a la BD sern percibidos en la Web como un sitio que contiene datos intensivos y estructurados en una BD (o en varias). Los sitios con datos intensivos son aquellos cuyo principal propsito es ofrecer grandes cantidades de informacin a una variedad de usuarios; es decir, sitios que cuentan con un Servidor de Bases de Datos. La idea general que hoy tenemos de la Web se puede situar en algn punto intermedio de los dos extremos siguientes:
Captulo 3.
54
DIT-UPM
a). Por un lado, podramos percibimos que toda la Web es como una fuente de informacin unificada. Esto no sera til ya que la Web adolece bastante de coherencia en la forma de presentar la informacin til al usuario, sobretodo en lo concerniente a su calidad en lo sustancial y a su accesibilidad. b). Por otro lado, la Web se puede considerar como una inmensa coleccin de pginas independientes (conglomeradas) donde, cada pgina se percibe como una fuente independiente de informacin til que nada tiene que ver con lo que ofrecen las dems (y casi infinitas) pginas. ste es el punto de vista que adoptan las listas de bookmarks7 para sealar sitios Web, gestionados por el navegador y los buscadores (como Alta Vista, Yahoo, etc.) ocupados en seleccionar enlaces a pginas simples, cuyas tcnicas son las propias de la bsqueda documental (Information Retrieval, thesaurus, vase epgrafe I.3.b del captulo 1 de [Cost99]). Ambos extremos resultan inapropiados para delimitar el alcance del diseo de bases de datos en, y para, la Web. En efecto, el diseo tiene que concentrarse en un determinado Universo del Discurso (el que, en cada caso, resulte necesario) que debe estar sometido al control que se exija en los objetivos de cada diseo concreto. Debido a que los sitios Web disfrutan normalmente de la propiedad enunciada en b), nosotros deberemos entender que los sitios Web son como una extensin a incorporar en la actividad del diseo de bases de datos, como un ingrediente ms que se aade al trabajo de diseo de bases de datos que hasta ahora conocemos como clsico. Este epgrafe se dedica al anlisis y estudio de dicho nuevo ingrediente: concentrado en disear sitios Web con datos intensivos cuyas exigencias son las de ser los mejores servidores utilizando estructuras muy regulares. Lo que contrasta con la organizacin de la informacin que hoy ofrece Internet, cuya descripcin se realiza en todo este epgrafe.
3.10.1.- Sobre la estructuracin de los datos y consulta a datos intensivos y heterogneos en la Web.
Aunque la Web comenz siendo una coleccin que interconecta documentos no estructurados, hoy cuenta con un gran nmero de fuentes de datos estructurados en bases de datos (de todo tipo y naturaleza) a las que se accede mediante gateways. Desde la arquitectura C/S, la interfaz de estas bases de datos gateways est formada tpicamente por mltiples formularios (forms) y por multitud de informes (reports). Los forms son como una plantilla (template) donde se actualiza el estado de la BD (altas, bajas y modificaciones) en los campos y ventanas previstos en cada formulario. Los reports, por su parte, realizan accesos meramente consultivos para devolver informacin de la BD, cuya presentacin final (valores de datos, barras o tartas estadsticas, etc.) est prevista en cada informe. En Web, el resultado de una consulta a una BD toma la forma de un documento HTML que est muy estructurado y que puede ser convertido (con un parser) a un conjunto de tuplas o a tipos de datos ms complejos. Se puede decir que este asunto est hoy bastante bien resuelto y ser tratado en el siguiente epgrafe. Sin embargo, adems de lo dicho para las BD operativas en Web, existen otras fuentes de informacin como el nombre de los servidores, fuentes bibliogrficas, amplios sistemas de informacin (sobre universidades, empresas, etc.) que ofrecen informacin online pero que pueden no estar disponibles en la Web y cuyas interfaces tambin proporcionan accesos consultivos. Actualmente, la estructuracin de los datos disponibles en Internet se organiza de muy diversas maneras, cuyo rango vara desde los datos sin estructura alguna (texto bruto, mapas, imgenes, etc.) hasta los datos totalmente estructurados como lo estn en las bases de datos (jerrquicas, Codasyl, relacionales u orientadas a objetos). Entre estos dos extremos, estn los documentos HTML que se han denominado como
Bookmark, lo que se coloca entre las pginas de un libro para marcar un lugar.
Captulo 3.
55
DIT-UPM
semi-estructurados [Abit97] y se sitan en algn lugar intermedio de las tcnicas de estructuracin, y que presentan notables diferencias a las tcnicas usadas en las BD. Los datos semi-estructurados no utilizan el concepto de esquema (nivel intensional en BD) como molde que acoge a mltiples valores de datos (nivel extensional en BD). Al contrario, en el documento HTML (semi-estructurado) cada una de sus partes componentes posee una definicin propia y exclusiva. De tal manera, que la organizacin del documento consiste principalmente en definir los enlaces entre sus partes y albergar el valor del dato (sea un objeto estructurado o valor atmico) en cada parte. El Modelo de Intercambio de Objetos, en adelante OEM (Object Exchange Model) se ocupa del intercambio de objetos entre fuentes de datos heterogneas con la idea de incorporar alguna estructura a los datos no estructurados [PaGW95], [BDFS97] y permitir la formulacin de consultas y su optimizacin a datos semi-estructurados [GoWi97]. Se define la semi-estructura como un grafo etiquetado, donde los nodos etiquetados contienen objetos y los arcos son referencias. Un objeto OEM consta de: a) una etiqueta que es el nombre de la clase de objetos, opcionalmente puede llevar un oid (object identifier). b) un tipo que puede se atmico (string, entero, etc.) o conjunto, c) un valor (uno y slo uno) que puede se atmico o un conjunto de objetos. La figura 9.6 muestra un objeto OEM con la etiqueta 'BSDT 5403 Telecomunicacin' cuyos valores es un conjunto de las caractersticas docentes de la asignatura donde se usa este libro. A este respecto, la nueva propuesta del estndar SQL-99 [ISOa99], [ISOb99], [ISOc99] y [ISOd99] realiza, entre otros [EiMe00], un importante avance en el SQL/MED que tiene especial importancia para el tema que ahora nos ocupa:
BSDT 5403 Telecomunicacin set
Ubicacin set
Departamento string Telemtica, DIT Semestre string primero Web del DIT char
http://www.dit.upm.es
Crditos char
6 (4,5 T +1,5 P)
Ciclo string segundo
Curso string quinto
Materia que desarrolla (BOE) string

Ingeniera de Sistemas Informticos
Fig. 9.6. Objeto OEM de la asignatura BSDT 5403.
Management of External Data, abreviado como SQL/MED, se dirige a proporcionar soluciones para permitir que las aplicaciones usen SQL para acceder a datos no-SQL (datos en ficheros ordinarios, o en cintas magnticas, o bases de datos jerrquicas o Codasyl, o incluso datos obtenidos en tiempo real, o datos no almacenados como los que devuelven los sensores). SQL/MED proporciona una API entre un servidor de SQL (base de datos local) y otra entidad llamada 'empaquetador de datos externos' (foreign-data wrapper). Las casas comerciales tienden a establecer una estrecha cooperacin en este asunto. Por ejemplo, Oracle tiene Miracle: Open Transparent Gateway y proporciona servicios de acceso a datos heterogneos, Sybase tiene OmniConnect para proporcionar accesos a diferentes fuentes de datos y, finalmente, IBM proporciona el DB2 DataJoiner para poder acceder a datos tradicionales o no. El documento de SQL/MED puede encontrarse en el directorio /SC32/WG3/ Progression_Documents/FCD/ dentro del fichero: fcdi-fcd1-med-1999-11.pdf (o .ps o .txt). Los esfuerzos de estandarizacin de SQL, en su secuencia de promulgaciones parecen no tener un final inmediato. Mientras cambien las necesidades o mientras la tecnologa cambie de forma drstica, SQL continuar evolucionando para llegar a ser el lenguaje intergalctico de datos (como dijo Mike Stonebreaker). Por ello, SQL est llamado a mejorar y seguir creciendo probablemente de forma
DIT-UPM
continua hasta alcanzar su final. Indiscutiblemente, el tema de la variopinta estructuracin de los datos en la Web es un paso ms (tema abierto a la investigacin actual) que se aade al de la heterogeneidad de diferentes fuentes de datos. Adicionalmente, el explosivo crecimiento de datos en la Web ha producido el desarrollo de sistemas que aplican el 'estilo de las bases de datos' para consultar y gestionar los datos Web. Por ejemplo, WebSQL [MeMM97], WebOQL [ArMe98], Strudel [FFKL97], etc. Estos sistemas utilizan algunas tcnicas y mecanismos que son exclusivos para la Web. Una referencia recomendada es [FlLM98] por cuanto que describe una panormica de sistemas para la gestin de datos en Web utilizando tecnologa de bases de datos. Finalmente, y por tratarse de una valiosa panormica del tema, en [DoDi99] se describe una clasificacin de los actuales sistemas para consultar datos heterogneos (estructurados, semi-estructurados o nada estructurados). La figura 9.7 muestra lo ms relevante de esta aportacin. En ella, las cajas sombreadas se refieren al asunto que ahora nos ocupa.
Sistemas para consultar fuentes de datos heterogneos
materializado virtual
mover los datos
dejar el dato donde est
Sistemas materializados
(los datos que provienen de fuentes locales se integran en una sola BD sobre la que operan las consultas)
Sistemas virtualmente integrados

(los datos permanecen en las fuentes locales, las consultas operan directamente sobre ellas y la integracin de los datos se produce, 'a sobrevuelo' durante el procesamiento de la consulta
datos nativos estructurados
datos estructurados nativos y derivados
datos nativos y no estructurados
datos nativos mayoritariamente estructurados
datos nativos estructurados, semiestructurados o no estructurados
SGBD Universal
Almacn de Datos
(data warehouse)
motores de (meta)bsqueda
BD Federadas (multidatabase)
Sistemas Consultivos con Mediador

(Mediator-Wrapper)
Fig. 9.7. Clasificacin de los Sistemas para consultar datos heterogneos.
Por otro lado, la figura 9.8 muestra la arquitectura propuesta para los Sistemas Consultivos con Mediador y Empaquetador. Su objetivo es permitir consultas distribuidas a mltiples fuentes de datos en Internet [OzVa99] y su enfoque est muy cerca a la arquitectura de las Multidatabases descrita en el captulo 2.
Empaquetador
(Wrapper) Fuente de Datos
Vista Global Servidor Consultas Web

Diccionario de Datos Global
Empaquetador
(Wrapper)
Fuente de Datos
Empaquetador
(Wrapper)
Fuente de Datos
Fig. 9.8. Arquitectura con Mediador y Empaquetador.
Cada wrapper exporta al diccionario de datos global informacin sobre su esquema fuente, sus datos y sus posibilidades consultivas. Con ello, el Mediador centraliza la informacin recibida de los wrappers en una vista unificada de todos los datos disponibles (almacenados en el Diccionario de Datos global), descompone las consultas del usuario en pequeas consultas (ejecutables por los wrappers) toma los resultados parciales y elabora la respuesta a la consulta del usuario Web.
Captulo 3.
57
DIT-UPM
La arquitectura de la figura 9.8 difiere de la de los almacenes de datos en que los datos integrados no estn materializados, como se refleja en la figura 9.7. En [CRPC04], [CPRC04] y [CPRC04] se describe nuestra reciente investigacin en este tipo de arquitecturas aplicadas a la integracin virtual de Archivos Digitales Web. No existe an consenso sobre cmo puede el wrapper describir las posibilidades de su fuente de datos ni sobre cmo trabaja el mediador. La ventaja de este enfoque radica en que cada wrapper atiende a un dominio de informacin especfico y particular, sobre el que puede conocer el nivel de estructuracin de sus datos fuente, su semntica (si existe), etc. Como conclusin final a este punto hay que resaltar que la consulta a datos heterogneos y con diferentes niveles de estructuracin, como hoy se precisa en la Web, es un problema altamente complejo que est abierto a la investigacin y cuya solucin inteligente y eficaz requiere de nuevos conceptos y tcnicas sobre los que an queda mucho por trabajar.
3.10.2.- Hipertextos en sitios Web con datos intensivos.
El caso que estudiaremos ahora es mucho ms sencillo que el planteado en el epgrafe anterior. El alcance de este punto es la consideracin de una sola base de datos cuyos usuarios finales residen en sitios Web. Los sitios Web con datos intensivos requieren el diseo de los hipertextos, como nueva caracterstica aadida a la habitual tarea diseo de una BD. Este punto estudiar primero un modelo lgico para disear hipertextos, despus hablaremos de sus niveles de representacin y de los principios y mtodo de diseo. Todo ello referido a hipertextos en sitios Web con datos intensivos que residen en una base de datos.
3.10.2.1. Modelo lgico de hipertextos para datos intensivos.

Cuando se realiza el diseo de una BD, se obtiene el esquema conceptual del Universo del Discurso objeto del diseo, como ya conocemos tras el estudio del Modelado Conceptual, el Modelo Relacional y el Modelo Orientado a Objetos (captulos 2, 4 y 6 de [Cost99]). El hipertexto se presenta al usuario en pginas configuradas como plantillas donde se muestran los valores de los datos de la BD. Por analoga con la nocin de esquema de una BD, podemos entender que cada plantilla acta como un esquema de pgina porque describe una estructura comn para todos los valores de los datos que ella presentar en cada caso (equivalente, en cierto modo, al esquema de relacin en las BDR y a la definicin de la interfaz de un objeto en las BDO). El esquema de pgina muestra datos de la BD que, en proximidad con las BDO, pueden ser valores de cualquier propiedad de los datos; es decir, la pgina muestra valores tanto de los atributos (attributes) como de las asociaciones o enlaces (relationship). Cada pgina puede contener valores atmicos (los clsicos: integer, char, date, etc.) y los tipos atmicos pueden incluir tipos multimedia (para describir documentos, imgenes, fotos, mapas, voz y vdeo digitalizados). Los valores complejos se definen mediante una lista de constructores, puesto que las pginas tienen un orden fsico de presentacin. Al igual que en el Modelo de Objetos (donde los enlaces conectan tipos de objetos); aqu los enlaces conectan esquemas de pginas, salvo que ahora cada ocurrencia de un enlace conecta una referencia y un ancla (anchor) que es un valor cuyo contenido identifica la pgina referenciada por dicho enlace. El esquema de pgina acta al nivel lgico, igual que operan las vistas en la arquitectura ANSI/X3/SPARC (figura 1.5 del captulo 1). Es decir, cada definicin del esquema de una pgina resulta ser una derivacin lgica de la informacin que reside en el esquema conceptual de la BD. Lo que conlleva la existencia del relativismo semntico (la derivacin lgica realiza el 'corta y pega' desde el nivel conceptual al nivel lgico, -vase epgrafe 1.3.1.). Entonces, el modelo lgico de los hipertextos consiste en la definicin del nivel lgico, ahora materializado en un conjunto de esquemas de pgina a travs de los cuales se mostrarn los datos de la BD. Al igual que una vista (en la arquitectura ABSI/X3/SPARC) puede definirse en trminos de otras vistas ya establecidas, en los hipertextos -adems de los valores que son atributos- el esquema de una
DIT-UPM
pgina se puebla normalmente con enlaces a otras pginas para establecer el orden fsico de la presentacin de informacin al usuario Web. En esto consiste el modelado lgico de los hipertextos en sitios Web con datos intensivos. Usaremos un ejemplo para afianzar las ideas ya descritas. Supongamos que el esquema conceptual de la BD de una empresa est definido en el modelo relacional como sigue:
Empleado Proyecto Oficina Participa (Apellido, Nombre, Sueldo, Departamento, Oficina) (Ttulo, Presupuesto, Esfuerzo, Fecha_Inicio, Fecha_Final) (Ciudad, Direccin ) (Apellido, Ttulo, Puesto, Fecha_Comienzo, Fecha_Acaba) Departamento (Nombre, Oficina, Jefe, Telfono)
Esta empresa desea ofrecer el contenido de su BD en un sitio Web para que pueda ser consultada por usuarios Web. Supongamos que la organizacin de este sitio, en lo que a pginas Web se refiere, implica lo siguiente: establecer una pgina casera (home page) de la empresa con enlaces a todas las oficinas, a todos los empleados y a todos los proyectos de la empresa. establecer una pgina para cada oficina con una lista de sus departamentos, cada uno enlazado a su respectivo jefe y un enlace a otra pgina con la lista de los empleados del departamento. establecer una pgina para cada empleado con informacin personal y enlaces a la oficina y a los proyectos donde l (o ella) trabaja. establecer una pgina para cada proyecto con una lista de enlaces a los empleados que participan en el proyecto. En esto va a consistir el diseo lgico de los hipertextos de nuestro ejemplo. Para definir el esquema de estas pginas, como siempre, necesitamos usar un lenguaje (as como en SQL tenemos Create View). La sintaxis que usaremos es un invento acadmico y ser un hbrido del lenguaje DDL de SQL y del lenguaje ODL de ODMG (en cada tecnologa tendremos las sentencias propias para definir el esquema de pgina). A continuacin vamos a definir el esquema de pgina8 de Empleado:
page_schema Empleado ( Apellido: Nombre: Sueldo: Departamento: Oficina: Proyectos: ); ) string; string; integer; string; link ( Ciudad: string; Fecha_Comienzo: date; *Oficina);
list_of ( Proyecto: link ( Ttulo: string; *Proyecto);
Ntese que cada vez que se define un enlace (link) estamos usando un atributo con el papel de ancla (por ejemplo, Ciudad en el enlace con OFICINA). El ancla puede llevar uno o varios atributos de la pgina a la que referencia y tambin puede ser una constante. Anlogamente, definiremos los otros esquemas de pgina a nivel lgico que hemos supuesto necesita este ejemplo:
page _schema es un smbolo terminal (palabra reservada) del lenguaje, como lo es Create View en SQL o interface en ODL. Marcamos en
negrita a todos los supuestos smbolos terminales de este hipottico lenguaje.
Captulo 3.
59
DIT-UPM
Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica page_schema Empresa unique (Oficinas: Empleados: Proyectos: ) page_schema Lista_de_Proyectos unique ( Proyectos: list_of ( Proyecto: link ( Ttulo: string; *Proyecto ) ) ); list_of ( Oficina: link ( Ciudad: string; link ( "Proyectos" ; *Oficina ) ); link ( "Empleados" ; *Lista_de_Empleados ) ; *Lista_de_Proyectos ) ;
page_schema Lista_de_Empleados unique ( Empleados: list_of ( Empleado: link ( Apellido: string; *Empleado ) ) ); page_schema Oficina ( Ciudad: Direccin: Dptos.: Nombre: Telfono: Jefe: ) ) page_schema Empleados_del_Dpto. (Oficina: Dpto.: ) page_schema Proyecto (Ttulo: Esfuerzo: string; float; Presupuesto: integer; Fecha_Inicio: date; Fecha_Final: date; Empleados: list_of ( Empleado: link ( Apellido: string; ) *EMPLEADO ) ); link ( Ciudad: string; *OFICINA ) ; string; *EMPLEADO ) ); string; string; list_of string; number; link ( Apellido: string; *EMPLEADO ); (
Empleados: link ( Apellido: string; *Empleados_del_Dpto. );
Empleados: list_of ( Empleado: link ( Apellido: string;
Interesa destacar que este nivel lgico de los hipertextos est describiendo la estructura hipertextual, pero no define todos los detalles del hipertexto en s mismo: Por ejemplo, se ha omitido la capa actual de las pginas y algunos otros enlaces adicionales que normalmente se incluyen en los sitios Web, como vimos en HTML. Adems, igualmente se podran incluir otros esquemas de pgina en este nivel lgico, as como cualquier modificacin a los esquemas de pgina definidos en el ejemplo. Asunto ste bien conocido por quien ha practicado en temas de diseo de BD. La figura 9.9 muestra la estructura hipertextual del ejemplo que nos ocupa.
Captulo 3.
60
DIT-UPM
En resumen, el esquema lgico de un hipertexto en un sitio Web con datos intensivos es un ingrediente que se aade al proceso de diseo de bases de datos que ya conocemos. El siguiente punto aborda lo ms esencial del proceso de diseo de una base de datos que ha de operar en la Web.
Empresa unique Oficinas: list-of oficinas de la empresa
OFICINA: Ciudad: string Empleados: Proyectos: "Empleados" "Proyectos"
Oficina Ciudad: string Direccin: string Dptos.: list_of
empleados de la empresa
proyectos de la empresa Lista_de_Proyectos Proyectos: PROYECTO: list_of Ttulo: string unique
Lista_de_Empleados Empleados: Empleado: list_of Apellido: string
Nombre: string Tfono.: number Jefe: Apellido: string "Empleados"
Empleados:
Empleados_del_Dpto. Proyecto Ttulo: Presupuesto: Esfuerzo: Fecha_Inicio: Fecha_Final: Empleados: EMPLEADO: string integer float date date list_of Apellido: string Oficina: Ciudad: string list_of Apellido: string string
Departamento: Empleados: EMPLEADO: Empleado
Apellido: Nombre: Sueldo: Departamento: Oficina:
string string integer string Ciudad: string
empleados del dpto. jefes de los dptos. de la oficina oficina del empleado
Proyectos_Emp.: list_of Proyecto: Ttulo: string
Fecha_Comienzo: date proyectos del empleado
Fig. 9.9. Esquema lgico de un hipertexto con datos intensivos.
3.10.2.2. Mtodo y principios del diseo hipertextual en bases de datos Web.

A diferencia de lo que hasta ahora ha sido habitual, el proceso de diseo de bases de datos Web que describe este punto no va a considerar el modelo de datos en trminos del cual se obtiene el esquema conceptual de la base de datos objeto del diseo (relacional, orientado a objetos, Codasyl, etc.), porque ya lo conocemos de anteriores captulos. El Modelo de Datos sera el que soporte un SGBD dado, que se ha elegido para gestionar la base de datos Web que ahora nos ocupa. Nuestra consideracin ahora est centrada principalmente en la parte de la Web, pero sin perder por ello la perspectiva global. En general, son dos los aspectos a tratar en el diseo de una base de datos Web: 1) El contenido de la informacin que estar albergado en la base de datos y en un sitio Web con datos intensivos, cuyas fases de diseo conocemos. 2) La estructura del hipertexto que describe cmo se organiza la informacin en pginas Web y cmo se disea la navegacin entre pginas, descrito en IX.4.2.1. La materializacin de dicha estructura es la presentacin del hipertexto que se encarga de organizar la disposicin grfica y geogrfica del contenido de la pgina Web y de los enlaces entre todas las pginas.
DIT-UPM
Anlisis de Requerimientos
Requisitos del Sistema (definicin de objetivos)
Diseo Conceptual
Integracin de vistas
Diseo Conceptual del hipertexto
Esquema Conceptual
Esquema de Pginas
Diseo Lgico
Diseo Lgico del hipertexto
Vistas a nivel Lgico Presentacin del hipertexto Diseo Fsico Generacin del sitio web
Esquema Fsico Base de Datos Web
Observacin y Monitorizacin
Fig. 9.10. Mtodo de diseo de una base de datos Web.
La presentacin del hipertexto trata asuntos como por ejemplo: dnde situar en la pgina los datos del empleado (para mostrarlos bien alineados), dnde colocar su fotografa (si la hubiera), dnde poner los iconos (si los hay), dnde ubicar en la pgina los botones que enlazan al empleado con los proyectos en los que ste ha participado, etc. Para ello, se utilizar cdigo HTML [Cast00]. La figura 9.10 muestra una metodologa global y genrica para abordar la tarea de diseo de una 'base de datos Web'. El proceso de diseo mostrado es de arriba-hacia-abajo y supone que se inicia desde la nada (es decir, top-down y from scratch). En ella, los pasos del lado izquierdo de la figura son los conocidos como clsicos en la tarea de diseo de cualquier BD y los de la parte derecha describen el ingrediente aadido por tratarse de una 'base de datos Web'. En la figura 9.10, las cajas rectangulares representan las grandes fases a realizar en el proceso de diseo y las elipses representan los resultados alcanzados tras la realizacin de cada correspondiente fase. Cualquier diseador debera tener muy en cuenta cada una de las fases representadas en esta figura porque, desde la experiencia y la praxis, se sabe bien que esta forma metodolgica va a estar presente en cualquier trabajo de diseo de una base de datos Web o, lo que es lo mismo, de un sitio Web con datos intensivos organizados en una base de datos. Si la base de datos ya estuviera operativa y lo que se pretende es organizarla para que opere en la Web, entonces el principal trabajo de diseo estara concentrado en la parte derecha de esta figura; aunque, probablemente, ello supondra tambin la consideracin de algunas elipses (y de alguna caja) de su parte izquierda.
DIT-UPM
Muchas cajas de esta figura se estudian en varios captulos de [Cost99]. El anlisis de requerimientos en el captulo 2 y todas las de la parte izquierda de la figura (diseo conceptual, lgico y fsico de la BD) se estudian en el captulo 1, y del 4 al 7 en [Cost99]. El diseo conceptual del hipertexto ha sido el objeto de este epgrafe. Sus entradas son la especificacin de los Requisitos del Sistema de Informacin y el Esquema Conceptual de la BD. Su salida, o resultado, es el esquema de pginas Web. El diseo lgico del hipertexto toma como entradas: la especificacin de los Requisitos del Sistema de Informacin y el esquema de pginas Web y su salida, o resultado, es la presentacin del hipertexto, con diferentes niveles de presentacin (layouts) para cada esquema de pgina. La presentacin del hipertexto queda finalmente descrita en HTML. La generacin del sitio Web corresponde al trabajo de conexin de la base de datos al sitio Web correspondiente. Este aspecto est 'servido en bandeja' por la tecnologa del SGBD que se utilice en cada caso, y depende de cules sean las opciones adoptadas por el constructor del sistema de informacin Web en cuanto a las herramientas disponibles que se deseen utilizar. El siguiente punto estudiar este aspecto. Finalmente, la observacin y monitorizacin de la operativa del sistema, como es clsico dentro del ciclo de vida de cualquier sistema software, consistir en producir -a modo de retro_alimentacin (feedback)- nuevas reconsideraciones a cada fase realizada. Ello suele suponer la realizacin de una o varias vueltas atrs hasta la consecucin de buenos resultados de diseo y con buen rendimiento funcional.
3.10.3.- Acceso a Bases de Datos Web.
El protocolo CGI, descrito en 3.9.2.3., constituye la tcnica ms simple para el acceso a bases de datos Web, cuya arquitectura resume de nuevo la figura 9.11.
URL + Entradas Solicitud de Consulta Consulta Consulta
Web Browser
Form en HTML
Servidor Web
CGI, Servidor Gateway

Form en HTML
Servidor de BDs
Base de Datos
Form en HTML
Datos (tuplas / objetos)
Fig. 9.11. CGI para el acceso a bases de datos Web.
Como se dijo, la tcnica CGI es la ms simple; consiste en que el Servidor Web (o HTTP) recibe (desde el browser) una solicitud y reconoce que el recurso indicado por el URL es un programa (con los debidos parmetros) y llama a dicho programa a travs del protocolo CGI. ste enva la llamada al Servidor de Bases de Datos en forma de consulta (SQL, por ejemplo), de cuya ejecucin obtiene los resultados solicitados (datos de la BD) en el Servidor de Bases de Datos, quien transforma la respuesta resultante a un Formulario HTML y se lo enva por el mismo camino que lleg -pero ahora recorrido en sentido contrario, hasta llegar al browser del usuario que inici todo el proceso. Como ejemplo, si quisiramos escribir un programa CGI para generar la pgina de un empleado dado, con datos como los definidos en la figura 9.9. El cdigo fuente HTML sera como sigue:
Captulo 3.
63
DIT-UPM
Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica <html> <head><title>Juan Perez</title></head> <body> <H3>Juan Perez</H3> <table> <tr><td><em>Departamento</em> : </td><td> Ventas</td></tr> <tr><td><em>Ciudad</em> : </td><td> Madrid</td></tr> <tr><td><em>Direccion</em> : </td><td> Calle Princesa, 47</td></tr> <tr><td><em>Sueldo</em> : </td><td> 4.500.000 anual</td></tr> <tr><td><a href= " /cgi-bin/Proyectos? Apellido = Perez">Proyectos realizados</a></td><td> </td></tr> </table> </body> </html>
Este programa no accede a ninguna BD y genera una pgina esttica sin ms. A continuacin escribiremos un programa CGI, escrito en C con SQL embebido, que recibe como parmetro de entrada el apellido de un empleado y genera la pgina Web del empleado que tiene ese apellido. El programa se llama usando un URL que contiene el apellido como parmetro de entrada, por ejemplo:
http://www.etsit.upm./cgi-bin/Empleado?Apellido=Perez main (char Apellido[ ]) { char Nombre [20], Departamento [20], Ciudad [20]; char Direccion [70] ; int Edad, Sueldo; $ open connection to BDWebEmpresa $ select Nombre, Departamento, Ciudad, Direccion, Sueldo into :Nombre, :Departamento, :Ciudad, :Direccion, :Sueldo from Empleado E, Oficina O where E.Oficina = O. Ciudad and Apellido = :Apellido ; $ close connection if (sqlcode == 0) { printf ("<html>\n<head><title> %s %s", Nombre, Apellido, "</title></head>\n<body>\n") ; printf ("<H3> %s %s", Nombre, Apellido, "</H3>\n") ; printf ("<table> \n") ; printf ("<tr><td><em>Departamento</em>:</td><td> %s", Departamento, "</td></tr>\n") ; printf ("<tr><td><em>Ciudad</em>:</td><td> %s", Ciudad, "</td></tr>\n") ; printf ("<tr><td><em>Direccion</em>:</td><td> %s", Direccion, "</td></tr>\n") ; printf ("<tr><td><em>Sueldo</em>:</td><td> %s", Sueldo, "</td></tr>\n") ; printf ("<tr><td><a href= \"/ cgi-bin/Proyectos_Emp.?Apellido=%s", Apellido, "\"> Proyectos Realizados </a></td><td></td></tr>\n") ; printf ("</table>\n</body\n</html>") ; } else { printf ("<html>\n<head><title> No encontrado</title></head>\n<body>\n ") ; printf ("Ningun empleado tiene el apellido %s\n", Apellido, "</body>\n</html> ") ; } } } Captulo 3. Abril, 2008. Por: C.Costilla 64
DIT-UPM
Este programa abre una sesin en la base de datos, ejecuta la consulta, almacena los resultados por ella obtenidos en las variables adecuadas y genera la pgina. En el ejemplo usado el atributo Apellido es la clave de la relacin Empleado lo que garantiza que esta consulta devuelve a lo sumo una tupla y, por tanto, no es necesaria la utilizacin de cursores dentro de la consulta SQL. En el programa del ejemplo, interesa resear que los nombres de las variables que empiezan por ":" son variables de C, mientras que las que no lo llevan son atributos de la BD. Esta tcnica CGI ha evolucionado en otras alternativas que buscaron descargar y disminuir la pesadez de tanto servidor intermediario como los que se han mostrado en la figura 9.11 y que sern descritas en los captulos que siguen de este seminario.
Referencias Bibliogrficas.
[Abit97] [ANSI75] [ANSI78] Abiteboul S., Querying Semi-Structured Data, in Proc. 6th Int. Conf. On Database Theory, Vol. 1186 of Lecture Notes in Computer Science, Springer_Verlag, January pp. 1-18, 1997. ANSI/X3/SPARC, Study Group on Data Base Management Systems: Interim Report, FDT (ACM SIGMOD bull.), Vol.7, N.2, 1975. ANSI/X3/SPARC Study Group Database Management Systems, "Framework Report on Database Management Systems, AFIPS Press, 1978; also published in The ANSI/X3/SAPARC DBMS Framework, Information Systems, Vol.13, N 3, 1978. ANSI/X3/SPARC Reference Model for the DBMS Standardization, Database Architecture Framework Task Group of the ANSI/X3/SPARC, in ACM SIGMOD RECORD, Vol.15, N.1, March, 1986. The SQL Standard, Propuesta que coincide con el SQL de [ISO87], 1989. Anstey D., ORACLE8 bject-Oriented Design High Performance, Coriolis, 1988. Arocena G. and Mendelzon A., WebOQL: Restructuring Documents, Databases and Webs, Proc. of 14th Int. Conf. on Data Engineering (ICDE98), Florida, 1998. Buneman P., Davidson S., Fernandez M. and Suciu D., Adding Structure to Unstructured Data, in Proc. 6th Int. Conf. on Database Theory, Vol. 1186 of Lecture Notes in Computer Science, Springer-Verlag, January pp. 336-350, 1997. Concurrency Control and Recovery in Database Systems, P.A.Bernstein, V.Hadzilacos and N.Goodman, Addison Wesley, 1987. A.R. Bobak, Distributed and Multi-Database Systems, Artech House, 1996. Castro, E., HTML 4 for the World Wide Web (Visual Quickstart Guide), 4th Edition, 2000. R.G.G. Cattell (de.), The Object Database Standard: ODMG 3.0, Morgan Kaufmann, 2000. Distributed Databases. Principles and Systems, S.Ceri and G.Pelagati, Mc Graw Hill, 1984. C. Costilla, M.J. Rodrguez, J.P. Palacios, J. Cremades, A. Calleja and R. Fernndez, A Contribution to Web Digital Archive Integration from the Parliamentary Management System SIAP, Sixth International Baltic Conference on Databases and Information Systems, DB&IS2004, pp. 481-496, Riga, Latvia, June, 2004. C. Costilla, J.P. Palacios, M.J. Rodrguez, R. Fernndez, J. Cremades and A. Calleja, Web Digital Archive Integrated Architecture, The 2004 International MultiConference in Computer Science & Computer Engineering, in The 5th International Conference on Internet Computing (IC 2004), Web Mining session, Las Vegas, Nevada, http://www.world-academy-of-science.org, June 2004. C. Costilla, JP. Palacios, MJ. Rodrguez, J. Cremades, A. Calleja, R. Fernndez and J. Vila, Semantic Web Digital Archive Integration, International Workshop on Web Semantics - WebS 2004, in the 14th International Conference on Database and Expert Systems Applications, DEXA 2004, http://www.dexa.org, Zaragoza, Spain, Sept. 2004. C.Costilla, M.J. Bas, J.Villamor, SIRIO: A Distributed Information System over a Heterogeneous Computer Network, ACM SIGMOD RECORD, Vol. 22, N 1, pp. 28-33, March, 1993. Costilla C. , A Contribution to Knowledge Communication in Distributed Knowledge-Based Systems, in Research into Networks and Distributed Applications, EUTECO88 (R.Speth, de.), pp. 1153-1162, NorthHolland, 1988. C.Costilla, Estado Actual de las Bases de Datos Distribuidas. Evolucin desde la Tecnologa Relacional, en Computerworld, N. 400, Junio, 1990.
[ANSI85] [ANSI89] [Anst98] [ArMe98] [BDFS97]
[BeHG87] [Boba96] [Cast00] [Catt00] [CePe84] [CRPC04]
[CPRC04]
[CPRC04]
[CoBV93] [Cost88]
[Cost90]
Captulo 3.
65
DIT-UPM

[Cost92] [Cost99] [DAIS88] [Date87] [DoDi99] [EiMe00] [FFKL97] [FlLM98] [GoEi01] [GoWi97] [GuPe99] [Gupt89] [IHIS89] C.Costilla, Avances Recientes y Tendencias Previsibles de las Bases de Datos, en Encuentro sobre Bases de Datos en la Administracin Pblica, De. MAP, ISBN:84-7088-618-5, pp. 119-145, Madrid, Mayo, 1992. C.Costilla, Sistemas de Bases de Datos. Conceptos, Tcnicas y Lenguajes, ISBN: 84-7402-271-1, 464 pginas, Servicio de Publicaciones, ETSI Telecomunicacin, 1999. DAISY Group, DAISY: Distribution Aspects in Information Systems, in Research into Networks and Distributed Applications (R.Speth, de.), pp. 1029-1049, North-Holland, 1988. C.J. Date, A Guide to INGRES. Addison-Wesley, ver su captulo 21 Distributed Database Support, 1987. Domenig R. and Dittrich K.R., An Overview and Classification of Mediated Query Systems, in ACM SIGMOD RECORD, Vol. 28, N. 3, pp. 63-72, September, 1999. Eisenberg A. and Melton J., SQL Standardization: The Next Steps, in ACM SIGMOD Record, Vol. 29, No. 1, March 2000. Fernandez M., Florescu D., Kang J. and Levy A., STRUDEL: A Web Site Management System, in Proc. of the 1997 ACM SIGMOD, Vol. 26, N. 2, pp. 549-552, Arizona, May, 1997. Florescu D., Levy A. and Medelzon A., Database Techniques for the World Wide Web: A Survey, SIGMOD RECORD, September, 1998. Goodman, D., Eich, B., JavaScript Bible, 4th Edition, Hungry Minds Inc., 2001. Goldman R. and Widom J., DataGuides: Enabling Query Formulation and Optimization in Semistructured Databases, in Proc. 23rd Int. Conf. on Very Large Data Bases, September, pp. 436-445, 1997. Gulutzan P. and Pelzer T., SQL-99 Complete, Really. An example-Based Reference Manual of the New Standard, R&D Books, 1999. A. Gupta (de.), Integration of Information Systems: Brindging Heterogeneous Databases, IEEE Press, 1989. DAISY Group, IHIS: Interoperability of Heterogeneous Information Systems, A Report from de DAISY Group of the Cost11 ter european action in Teleinformatics. Commission of European Communities, DG XIII, (Tirri, de.), Dpt. Of Computer Science, Univ. Helsinki, Finland, ISBN 951-45-4597-4, March 1989. D.K. Hsiao, E.J. Neuhold and R. Sacks-Davis (eds.), IFIP Transactions: Interoperable Database Systems (DS-5), North-Holland, 1993. G.Attali, M.Bas, C.Costilla, P.Fankauser, B.Finance, G.Gardarin and W.Klas, IRO-DB: Interoperable Relational and Object Databases; General Functionality Specification Document, Identifier: IRO/SPEC/IBER-UPM/ D11.1/CC940730, 30 July, 1994. Information Processing Systems -Database language- SQL. ISO 8975: 1987. Information Systems -Open Systems - Remote Database Access. ISO/JTC 1/SC 21, 1989. ISO/IEC 9075-1:1999, Information Technology - Database language - SQL - Part 1: Framework (SQL/Framework), 1999. ISO/IEC 9075-2:1999, Information Technology - Database language - SQL - Part 2: Foundation (SQL/Foundation), 1999. ISO/IEC 9075-3:1999, Information Technology - Database language - SQL - Part 3: Call Level Interface (SQL/CLI), 1999. ISO/IEC 9075-4:1999, Information Technology - Database language - SQL - Part 4: Persistent Stored Modules (SQL/PSM), 1999. S. Jajodia, W.Kim and A. Silberschatz (eds.), Proceedings: International Symposium on Databases in Parallel Distributed Systems, IEEE Computer Society Press, 1988. W. Litwin and A. Abdellatif, An overview of the Multidatabases Manipulation Language - MDL, Proc. IEEE, Vol. 75, N 5, pp. 621-631, May 1987. F. Malsall, Data Communication, Computer Networks and OSI, Addison- Wesley, 1988.
[HsNS93] [IRO94]
[ISO87] [ISO89] [ISOa99] [ISOb99] [ISOc99] [ISOd99] [JaKS88] [LiAb87] [Mals88]
[MeMM97] Mendelzon A., Mihaila G. and Milo T., Querying the Wordl Wide Web, Journal of Digital Libraries, Vol. 1, N. 1, 1997. [OMG91] [Or9i01] [OSDT89] [OzVa99] [PaGW95] OMG, The Common Object Request Broker: Architecture and Specification, OMG Doc. N. 91.12.1, Published by Object Management Group and X/Open, 1991. ORACLE 9i, SQL Reference, disponible en: http://technet.oracle.com/doc, June 2001 OSDT, Open Systems Data Transfer, advising in Open Systems Interconnection Standards, Technology and Products, ISSN 0741286X, December, 1989. zsu T. and Valduriez P., Principles of Distributed Database Systems, 2nd edition, Prentice Hall, 1999. Papakonstantinou Y., Garcia-Molina H. and Widom J., Object Exchange across Heterogeneous Information Sources, in Proc. 11th Int. Conf. On Data Engineering, March pp. 251-260, 1995.
Captulo 3.
66
DIT-UPM

[SiZd97] [SrCh99] Silberschatz A. and Zdonik S., Database systems-breaking out of the box, ACM SIGMOD RECORD Vol. 26, n.3, September 1997. J.Srivastava and P.Y.Chen, Warehouse Creation - A Potential Roadblock to Data Warehousing, IEEE Transaction on Knowledge and Data Engineering, Vol. 11, N.1, pp. 118-126, January/February, 1999.
Captulo 3.
67

Entregado Cap1,2y3 Doctorado 2007-08

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Entregado Cap1,2y3 Doctorado 2007-08

Hochgeladen von

Copyright:

Verfügbare Formate

DIT-UPM

PARTE I y II: Conceptos y Tcnicas de BD

Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica

1.4.- Situacin Actual y Consolidada de las BDs. ____________________________________________ 5

Captulo 2. Interoperabilidad entre Bases de Datos Heterogneas y Distribuidas. ___________ 12

2.5.- Conclusiones a los Niveles de Interoperabilidad._______________________________________ 25

Captulo 3. Software de Bases de Datos Distribuidas. Arquitecturas Cliente/Servidor y Web. ___ 29

Abril, 2008. Por: C.Costilla

PARTE I y II: Conceptos y Tcnicas de BD

3.6.- Fiabilidad en los Sistemas de Bases de Datos Distribuidos._______________________________ 38

3.9.- Arquitectura Web (tres capas). _____________________________________________________ 48

3.10.- Diseo de Bases de Datos en sitios Web. _____________________________________________ 54

Abril, 2008. Por: C.Costilla

PARTE I y II: Conceptos y Tcnicas de BD

Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica

PARTE I y II: Conceptos y Tcnicas de BD

Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica

Modelos Sintcticos fciles de usar

Las Estructuras de Datos

Fig.I.1.- Niveles de Abstraccin y Naturaleza de la Informacin asociada a cada nivel.

Abril, 2008. Por: C.Costilla

PARTE I y II: Conceptos y Tcnicas de BD

Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica

Abril, 2008. Por: C.Costilla

PARTE I y II: Conceptos y Tcnicas de BD

Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica

ndice maestro (nivel 2)

30500 61601 95500 98765 300

ndice maestro (nivel 1)

1100 1510 1831

300 710 98765

Abril, 2008. Por: C.Costilla

PARTE I y II: Conceptos y Tcnicas de BD

Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica

PARTE I y II: Conceptos y Tcnicas de BD

Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica

PARTE I y II: Conceptos y Tcnicas de BD

Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica

Programa de Aplicacin 1-1

Api. 2-i Api. 1-i Api. x-i Api. 1-n

Api. 2-n Api. y-n

Modelo de Datos ESQUEMA CONCEPTUAL

Abril, 2008. Por: C.Costilla

PARTE I y II: Conceptos y Tcnicas de BD

Empleado VISTA 1 NIVEL LGICO (PL/ I ) DCL 1 EMPP,

Empleado VISTA 2 NIVEL LGICO (COBOL) 01 EMPC.

PIC X(6). PIC X(4).

NIVEL CONCEPTUAL EMPLEADO

NIVEL FSICO STORED-EMPL

# EMPLEADO # DEPARTAMENTO SUELDO

CHARACTER (6) CHARACTER (4) NUMERIC (5)

1.5.- Bases de Datos Centralizadas. Software.

Diseo, Herramientas, Y Utilidades diversas

Tartas y barras Estadsticas

Tecnologa Comercializada de Bases de Datos Centralizadas

Bases de Datos Fig. I.7.- Un SGBD Centralizado en torno a un Sistema Operativo.

Abril, 2008. Por: C.Costilla

PARTE I y II: Conceptos y Tcnicas de BD

Curso Doctorado: Arquitecturas de Bases de Datos Web. Tecnologas de la Web Semntica

1.6.- Bases de Datos Centralizadas. Usuarios y Aplicativos.

Modalidad Funcional Interactiva

Fig. I.8.- Usuarios y Programas en una BD Centralizada.

1.7.- Bases de Datos Centralizadas. Arquitectura de Procesos.

Procesos del SGBD