Vous êtes sur la page 1sur 33

Asignatura de

Bases de Datos

Tema VII del Programa Docente 2010-11

Arquitecturas de los SGBD en


la Distribución

Por: Carmen Costilla

Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla

Tema VII del Programa Docente de Bases de Datos

Arquitecturas de los SGBD en la Distribución

ÍNDICE DE CONTENIDO

VII.1 Arquitectura ANSI/X3/SPARC de los SGBD Distribuidos __________________________________ 1 


1.1 Estándar ANSI/X3/SPARC de los SGBDs Centralizados. ___________________________________________ 1 
1.2 Contextualización. Organización de las BDR Distribuidas, Homogéneas y Altamente Integradas. ________ 2 
1.3 Arquitectura de los Sistemas de Bases de Datos Distribuidos. _____________________________________ 2 
1.4 Niveles de Transparencia de los aspectos de distribución. _________________________________________ 3 
1.5 Conceptos de Distribución, Autonomía y Heterogeneidad. _________________________________________ 3 
1.6 Alternativas de Implementación de los SGBD Distribuidos. ________________________________________ 3 
1.7 Arquitectura ANSI/X3/SPARC de los SGBD Distribuidos. __________________________________________ 4 
1.8 Arquitectura de los SGBD Multidatabase Distribuidos.____________________________________________ 4 
1.9 Conclusiones a las Arquitecturas de los SBDD. _________________________________________________ 5 
VII.2 Arquitecturas Cliente / Servidor, C/S ___________________________________________________ 5 
2.1 Ubicación del SGBD en la Arquitectura Cliente/Servidor (2 capas) ___________________________________ 5 
2.2 Arquitectura Cliente-Servidor (dos capas). ______________________________________________________ 6 
2.2.1 Funcionalidad de la Arquitectura Cliente-Servidor. _______________________________________________ 7 
2.2.2 Acceso a Bases de Datos. Caso del Protocolo Oracle Net y ODBC. _________________________________ 9 
VII.3 Arquitecturas Web con tres o más capas. ________________________________________________ 9 
3.1 Ubicación del SGBD en la Arquitectura Web. _____________________________________________________ 9 
3.2 Internet y la World Wide Web. ________________________________________________________________ 10 
3.3 Servidores de la capa intermedia en la Arquitectura Web._________________________________________ 12 
3.3.1 Servidor Web: URLs y Protocolo HTTP. ______________________________________________________ 12 
3.3.2 La seguridad en Internet. __________________________________________________________________ 14 
3.3.3 Gateways, CGI y Servidor de Aplicaciones. ____________________________________________________ 14 
3.4 Arquitectura Web con Plataforma J2EE, Java, Struts y MVC. ______________________________________ 16 
3.4.1 Java __________________________________________________________________________________ 16 
3.4.2 Plataforma J2EE _________________________________________________________________________ 17 
3.4.3 Tecnología Servlet _______________________________________________________________________ 18 
3.4.4 Tecnología Java Server Pages______________________________________________________________ 19 
3.4.5 MVC (Model View Controller) _______________________________________________________________ 20 
3.4.6 Struts _________________________________________________________________________________ 21 
VII.4 Sobre la Estructuración de los Datos y Consultas a Datos Intensivos y heterogéneos en la Web. __ 22 
4.1 Modelo OEM. Clasificación de Sistemas de consulta a datos intensivos y heterogéneos en la Web. ______ 23 
VII.5 Arquitectura Mediador-Wrapper _____________________________________________________ 26 
5.1 Casos de Arquitecturas Mediador-Wrapper en la Web. Nuestra Experiencia. _________________________ 26 
5.1.1 Bibliografía específica de nuestra experiencia en Mediador -Wrapper. _____________________________ 27 
VII.6 Referencias Bibliográficas. __________________________________________________________ 28 

i Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla

Tema VII del Programa Docente de Bases de Datos

Arquitecturas de los SGBD en la Distribución

Índice de Figuras

Fig. 7.1. Arquitectura de un SGBD Estándar Centralizado____________________________________________ 1


Fig. 7.2 Ejemplos de BD Relacionales Distribuidas, Homogéneas y Altamente Integradas. _________________ 2
Fig. 7.3 Componentes de las Bases de Datos Distribuidas. __________________________________________ 2
Fig. 7.4 Niveles de transparencia en los SBDD. ___________________________________________________ 3
Fig. 7.5 Una Anatomía del problema de las BDDs y los Sistema de Información Distribuidos. _______________ 3
Fig. 7.6 Alternativas de Arquitecturas e Implementación de los SGBDs. ________________________________ 4
Fig. 7.7 Arquitectura de los SGBDs. Modelo de Referencia del ANSI/X3/SPARC. ________________________ 4
Fig. 7.8 Modelo Multidatabase sin integración de Esquemas. _________________________________________ 5
Fig. 7.9 Arquitectura Cliente-Servidor de un SGBD. ________________________________________________ 7
Fig. 7.10 Detalle de la capa Cliente de un SGBD con arquitectura C/S. _________________________________ 8
Fig. 7.11 Arquitectura Web Abreviada (a tres capas) de un SGBD. ___________________________________ 10
Fig. 7.12 Detalle de la capa 2 de la Arquitectura Web de un SGBD. __________________________________ 13
Fig. 7.13 Detalle del Servidor de Aplicaciones en la Arquitectura Web de un SGBD. _____________________ 15
Fig. 7.14 Componentes de J2EE 1.4. __________________________________________________________ 18
Fig. 7.15 Funcionalidad del Web Server. ________________________________________________________ 18
Fig. 7.16 Ejemplo de ejecución de una JSP. _____________________________________________________ 20
Fig. 7.17 El ModeloVista Controlador. __________________________________________________________ 21
Fig. 7.18 Ejemplo de Objeto OEM para la asignatura BSDT 5403.____________________________________ 24
Fig. 7.19 Clasificación de los Sistemas para consultar datos heterogéneos. ____________________________ 25
Fig. 7.20 Arquitectura Mediador-Wrapper. _______________________________________________________ 26
Fig. 7.21. Web Digital Archive Integrated Architecture through Mediator and Wrappers. ___________________ 27

ii Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla

VII.1 Arquitectura ANSI/X3/SPARC de los SGBD Distribuidos

1.1 Estándar ANSI/X3/SPARC de los SGBDs Centralizados.

En el tema I se ha descrito la arquitectura de los SGBD del ANSI/X3/SPARC (American National Standards
Institute), establecida como primer estándar en 1975, que muestra la figura 7.1 como recordatorio de partida. Esta
arquitectura define tres niveles de representación de la información de las bases de datos que gestiona. Descritos
desde el interior de la BD hacia afuera, los niveles son: Nivel Interno o Físico, -NF-; Nivel Conceptual, -NC-, y
Nivel Externo o Lógico, -NL.
El Nivel Físico se encarga de "engranar" con el software más interno de cada máquina (Sistema Operativo, y
Sistema de Gestión de Ficheros generalmente). Los SGBDs actuales funcionan sobre casi todas las máquinas y
"corren" en casi todos los SOs del mercado.
El Nivel Conceptual define el resultado del diseño de la BD, para una parte del mundo real con interés
informativo para ser formulada y registrada en un ordenador. El resultado del diseño de una BD establece la
definición de un ESQUEMA CONCEPTUAL conforme a un modelo de datos, MD, que llamamos Esquema de la
BD. El Nivel Conceptual de un SGBD mantiene, en cada momento, tantos Esquemas distintos cuantas Bases de
Datos hayan sido diseñadas en ese SGBD.
Programa de Api. 2-i Api. 2-n
Aplicación 1-1 Aplicativo 1-2
Api. 1-i Api. 1-n Api. y-n
Api. x-i

NIVEL VISTA 1 ..… VISTA i .......... VISTA n


LÓGICO "View" "View" "View"

NIVEL Modelo de Datos


CONCEPTUAL ESQUEMA
CONCEPTUAL
SGBD
NIVEL ESQUEMA FÍSICO
FÍSICO
BD ALM ACENADA

Datos de la Base de Datos

Por cada BD, hay tres niveles de representación de la información.

Fig. 7.1. Arquitectura de un SGBD Estándar Centralizado

Y el tema VI: ‘Interoperabilidad entre SI heterogéneos’, concluyó -entre otras- con esta idea:
El software, en esencia, es una forma de arte. Idealmente, el usuario debería percibir a los sistemas
software en general como 'algo que le sitúa en su mundo', sin barreras artificiales de sistemas operativos,
arquitecturas del hardware, plataformas, compatibilidad de redes, de aplicaciones o de servidores de
información. En el ESPACIO DE DATOS del futuro, estas fronteras tecnológicas de hoy están llamadas a
desaparecer.

1 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
1.2 Contextualización. Organización de las BDR Distribuidas, Homogéneas y
Altamente Integradas.

La figura 7.2 muestra un ejemplo de cómo se organizan las BD Relacionales Distribuidas, Homogéneas y
altamente Integradas, en adelante BDDs. La figura representa dos Bases de Datos Distribuidas, -BDDs- a lo largo
de tres nodos de una red.

BDD1
BD Local 1
Nodo 1
Nodo 1 Red de
Comunicación Nodo 3
BD Local 2
Nodo 1

Nodo 2 BD Local 2 BD Local 1


Nodo 3 Nodo 3
BDD2
BD Local 2 BD Local 1
BDD 1 es una sola Base de Datos Distribuida, diseñada
‘top-down’ y cuyos datos residen entre los nodos
Nodo 2 Nodo 2 1, 2 y 3.

Datos Distribuidos en cada BDD, ello supone:


1. BDD1 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.
2. La distribución de los datos es totalmente transparente al usuario.
3. Permite la reusabilidad de Aplicativos en los nodos participantes en la distribución

Fig. 7.2 Ejemplos de BD Relacionales Distribuidas, Homogéneas y Altamente Integradas.

A su vez, la figura 7.3 describe los componentes software de los Sistemas de BDDs.

Comunicación SDDD
de Datos Sistema del Diccionario
Red de Datos Distribuido

SBDD SGBD
Sistema de Bases de Local
Datos Distribuido

Comunicación SDDD
de Datos Sistema del Diccionario
de Datos Distribuido
Bases de Datos
SBDD SGBD Locales
Sistema de Bases de Local
Datos Distribuido

Bases de Datos Locales

Fig. 7.3 Componentes de las Bases de Datos Distribuidas.

1.3 Arquitectura de los Sistemas de Bases de Datos Distribuidos.

Los Sistemas se construyen mediante Módulos con interfaces de flujos de control y datos:
Implementar un módulo Programming-in-the-small
Integrar los módulos Programming-in-the-large

2 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
1.4 Niveles de Transparencia de los aspectos de distribución.

Transparencia: capacidad de ocultar detalles de implementación al usuario o a los niveles altos del sistema.
Programming-in-the-small se oculta a Programming-in-the-large, conforme representa la figura 7.4.

Transparencia del
Lenguaje de la Distribución

Transparencia de
F t ió
Transparencia de Replicación

Transparencia de la Red

Independencia de Datos
Física Datos Lógica

Niveles de Ocultación

Fig. 7.4 Niveles de transparencia en los SBDD.

1.5 Conceptos de Distribución, Autonomía y Heterogeneidad.


Distribución de Datos

Localidades Diversas

Dos Localidades Hardware SOs SGBDs Control de la Semántica de


los Datos
(díficil problema)
Centralizado
Tipos de
SOs Heterogeneidad
SGBDs “Las soluciones empiezan a ser más díficiles a medida
que nos alejamos del origen”
Aplicaciones de los SIs
Autonomía
de los Sistemas

Fig. 7.5 Una Anatomía del problema de las BDDs y los Sistema de Información Distribuidos.

1.6 Alternativas de Implementación de los SGBD Distribuidos.

La figura 7.6 representa un esquema sobre las distintas formas de modelar e implementar los SGBD capaces,
en distinto modo, de incorporar aspectos de Distribución, Autonomía y Heterogeneidad.

3 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
Distribución

SGBD Centralizados, SBDD y SBDD y Federados


Homogéneos y lógicamente Homogéneos
integrados
Sistemas Multi-Database
Distribuidos
SGBD Heterogéneos y SBDDR
Sistemas Multi-Database
Distribuidos Sistemas de Gestión de Bases
Heterogéneos y Distribuidos
de Datos Distribuidos,
Relacionales y Homogéneos

Sistemas Multi-Database
Autonomía
SGBD Integrados y
Heterogéneos

Sistemas Multi-Database
SGBD Federados, Heterogéneos
Heterogéneos y Centralizados
SGBD Federados, Heterogéneos y
Distribuidos
Heterogeneidad

Fig. 7.6 Alternativas de Arquitecturas e Implementación de los SGBDs.

1.7 Arquitectura ANSI/X3/SPARC de los SGBD Distribuidos.

La figura 7.7 representa el Modelo de Referencia de ANSI/X3/SPARC extendido. Refiere la arquitectura de los
SBDD Integrados.

Esquema Esquema Esquema


Externo Externo ……………………… Externo
Global 1 Global 2 Global n

Esquema
Vista ……………Vista Conceptual Vista ……………Vista
Local 1 1 Local 1 k Global Local n 1 Local n m

Esquema Esquema
Conceptual ……….……………… Conceptual
BD Local 1 BD Local n

Esquema Esquema
París Madrid
…………….………………
Interno C/Alcalá Gran Vía Interno
BD Local 1 1ªPlanta 3ªPlanta BD Local n

Fig. 7.7 Arquitectura de los SGBDs. Modelo de Referencia del ANSI/X3/SPARC.

1.8 Arquitectura de los SGBD Multidatabase Distribuidos.

La figura 7.8 representa la arquitectura de los Sistemas ‘Multidatabase’ sin integración de Esquemas
Conceptuales Locales en un Esquema Conceptual Global. En esta propuesta, sólo a través del Multi Lenguaje, las
consultas interoperan con varias Bases de Datos independientes. Es una propuesta de W. Litwin, “MSQL
Language” [LiAb87].

4 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla

Esquema Esquema
……………………… Esquema
Externo 1 Externo 2 Externo n

Esquema Esquema Esquema


……….………………
Conceptual Conceptual Conceptual
BD Local 1 BD Local 2 BD Local n

Esquema Esquema Esquema


…………….…………
Interno Interno Interno
BD Local 1 BD Local 2 BD Local n

Fig. 7.8 Modelo Multidatabase sin integración de Esquemas.

1.9 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 Autonomía Local requerido es un ‘input’ importante para optar por un determinado modelo
de Arquitectura del SBDD y elegir una solución de diseño 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 Comunicación
¾ Control de Concurrencia Distribuido,
¾ Gestión de Transacciones Distribuido
¾ Recuperación distribuida frente a fallos distribuidos.
3. Las BDD relacionales y altamente integradas (por diseño ‘top-down’) son una tecnología comercial de
hoy, conocida como: “*** / STAR”.
4. Las Multidatabase, aunque existen prototipos, no han sido comercializadas por la industria.

VII. 2 Arquitectura Cliente / Servidor, C/S

2.1 Ubicación del SGBD en la Arquitectura Cliente/Servidor (2 capas)

El SGBD, una de las variedades más complejas del software actual, precisa utilizar el término arquitectura con
diversas acepciones y puntos de vista. La arquitectura del SGBD se describe ahora bajo el punto de vista de sus
formas operativas (funcionales), como un ente que realiza las aplicaciones del usuario.
La arquitectura ANSI/X3/SPARC, vista en el Tema I, explicó cómo se organiza la información de una BD. En el
Tema VI (cap. 8 de [Cost99]) hemos visto cómo se organizan varios SGBDs para la interoperabilidad
(generalmente distribuida). Allí vimos la arquitectura C/S con funcionalidad varios-a-varios (varios Clientes y varios -
no muchos- Servidores). Finalmente, en el Tema XI (cap. 9 de [Cost99]) atenderemos a otro tipo de arquitectura
llamada arquitectura revisitada, centrada en la descripción de los aspectos más internos del software que poseen
los motores o Servidores de bases de datos.

5 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
La arquitectura C/S surge a finales de los años 80’s, como una extensión del estándar RDA Remote database
Access [ISO89] y tuvo gran difusión en la tecnología de bases de datos en la década de los 90’s, marcando
importantes pautas en la concepción arquitectural de los SGBD, separando nítidamente las funciones del Servidor
y las de los Clientes.
La arquitectura para los SGBD es algo diferente a la organización del software genérico en Cliente/Servidor
(entendido sólo mirando a los procesos que invocan y a los que sirven), ya que la interacción en los SGBD está más
especializada y con requisitos funcionales más exigentes en lo relativo a: control de concurrencia, mecanismos de
recuperación frente a fallos y persistencia de la información.
Como sabemos, la distribución es hoy un ingrediente común de los actuales Sistemas de Información. En este
tema veremos la arquitectura del SGBD como un ente individual (sin cooperar con otros SGBD), para entender los
bloques que posibilitan su funcionamiento. Este tema no entra en detalles de cómo opera el motor o Servidor de
Bases de Datos, descrito en Cap. 9 de [Cost99] y que será estudiado en los últimos temas de nuestro programa.
Por ahora, nos bastará con entender que dicho motor contiene el núcleo de las funciones de un SGBD y que ha de
ejecutarse en un Servidor de Bases de Datos dotado de los debidos recursos para la gestión de datos intensivos.
Este tema describe cómo se organiza el SGBD en capas para -con ellas- llevar a cabo, en la capa Cliente,
determinadas funciones de los aplicativos de usuario. Cada Cliente realiza una especie de pre-procesamiento de
las aplicaciones que han de terminar ejecutándose en el Servidor de Bases de Datos. Además de esto, la
funcionalidad de la capa del Cliente consiste en implementar funciones de usuario con interfaces amigables y
ofrecer alta productividad para dichas funciones de usuario (entornos ofimáticos con: e-mail, procesadores de texto,
hojas de cálculo, etc.).
Estudiaremos dos tipos de arquitecturas principales. La primera describe la arquitectura a dos capas, llamada
también arquitectura Cliente/Servidor del SGBD. La segunda es la arquitectura a tres capas, dirigida hacia la World
Wide Web y añade una nueva capa conocida como Servidor de Aplicaciones que incluye al Servidor Web (o
Servidor HTTP).

2.2 Las dos capas de la Arquitectura Cliente-Servidor.

En el Tema VI (cap. 8 de [Cost99]) se ha descrito el paradigma Cliente/Servidor como el más simple del amplio
espectro de la interoperabilidad de los SGBDs distribuidos. Un SGBD con arquitectura Cliente-Servidor funciona
separando limpiamente el papel que juega el Servidor del que desempeña el Cliente. Esta arquitectura, pensada
en la distribución, organiza la ejecución de aplicaciones entre diversas máquinas -conectadas por una determinada
red (generalmente LAN) - que suele alcanzar a distintas dependencias del edificio(s) donde ella opera, como
muestra la figura 7.9.
En la tecnología relacional, la integración de esta arquitectura se basa principalmente en el protocolo Net (por
ejemplo, Oracle lo llama SQL*Net). Usa un solo motor SGBD y todas las máquinas son de tipo Cliente salvo la
máquina Servidora (varios Clientes y un Servidor).
Realmente no es preciso que Cliente y Servidor se ubiquen en distintas máquinas, pues el paradigma de esta
arquitectura se fundamenta en construir el software con independencia de dónde vayan a residir los procesos. Sin
embargo, en la gestión de datos, normalmente los procesos del Servidor se ubican en una sola máquina y las
máquinas Clientes se esparcen por la red de la institución o empresa para la que se instala este tipo de
arquitectura.

6 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla

Aplicativos del Aplicativos del Aplicativos del


Cliente 1 Cliente i Cliente n

Cliente 1 Cliente i Cliente n


Usuario

Red
‘NET’ junto al nombre del SGBD (LAN o MAN )
Capa Cliente
Cola de Cola de
Entrada Salida

Servidor de
Bases de Datos
Capa Servidora

Arquitectura C/S Abreviada


Bases de Datos Centralizadas

Fig. 7.9 Arquitectura Cliente-Servidor de un SGBD.


La arquitectura C/S de un SGBD balancea la carga de trabajo entre los Clientes y el Servidor, repartiendo las
tareas de la ejecución de las aplicaciones. Cuando el SGBD opera a nivel de producción industrial, se distribuye su
software en diversas máquinas. De esta forma, en la capa Cliente se pueden ejecutar en paralelo una buena parte
de las aplicaciones del Sistema de Información.

2.2.1 Funcionalidad de la Arquitectura Cliente-Servidor.

La funcionalidad Cliente-Servidor se basa en un modelo de interacción entre procesos software. Los clientes
invocan y solicitan la ejecución de procesos (requests, queries, etc.) que ellos requieren y no poseen. Los procesos
solicitados residen en la parte Servidora. La arquitectura genérica C/S se organiza de forma que un Cliente pueda
solicitar servicios a varios (no muchos) Servidores.
Este epígrafe, dedicado a la arquitectura de un solo SGBD, parte de la hipótesis que el Servidor de Bases de
Datos es único en este tipo de arquitectura y los Clientes quedan conectados a él mediante una red (LAN casi
siempre) cuya interacción 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 pre-procesan para transformarlas en
otras unidades software (transacciones de bajo nivel, que estudiaremos en el Tema XI) que envían al Servidor
para solicitar su servicio. Los Clientes solicitan a la capa Servidora que lleve cabo la ejecución definitiva de los
aplicativos (accesos y/o actualizaciones a los valores de los datos de la BD). Por tanto, el Cliente envía siempre todas
sus solicitudes al Servidor, mientras que el Servidor atiende 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 separación de objetivos y trabajos. Por un lado, cada máquina Cliente se
dirige a optimizar determinadas aplicaciones del usuario final, conocidas de antemano por quien construye el
sistema de información [CoBV93]. El 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 específicas en cada máquina. Por otro lado, el diseñador y administrador de
las bases de datos, trabajará en la capa Servidora para realizar las tareas propias y relativas a diseño y
administración: asignación de roles de usuario, permisos y privilegios, definiciones de Vistas, configuración 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 clientes.

7 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
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 gestión de múltiples buffers y una alta capacidad de disco
duro para almacenar completamente la base de datos. Sin embargo, en la máquina Cliente bastaría con un típico
ordenador personal que proporcione las herramientas de un entorno ofimático y que albergue el software o
procesos de la parte cliente del SGBD. Entre dichas herramientas, casi siempre enmascaradas por interfaces
amigables del usuario, tiene que tener instaladas las destinadas a solicitar servicios al Servidor de Bases de Datos
y las herramientas de ayuda al desarrollo de las aplicaciones (reports/forms), como muestra la figura 7.10.
Usuario

Interfaces
Sistema Operativo de Aplicativos Entorno
Ususario de BD Ofimático

Capa Cliente Procesos Cliente


del SGBD

Comunicación de datos

Red (LAN )
Consultas SQL

Resultados
S. Operativo

Comunicación de datos
Capa Servidora
Servidor de Bases de Datos,
motor del SGBD

Bases de Datos Centralizadas

Fig. 7.10 Detalle de la capa Cliente de un SGBD con arquitectura C/S.

SQL es ideal para identificar los servicios de interfaz de la capa cliente, responsable de interpretar la consulta del
usuario, darla formato y presentar los resultados al usuario de forma adecuada. La consulta, escrita en el Cliente,
se envía al Servidor para que se procese allí. El Servidor extrae los resultados de la base de datos, los empaqueta
y, finalmente, los devuelve al Cliente que hizo la solicitud. De esta forma, por la red circula la mínima información
útil.
La consulta SQL del usuario admite dos formas de invocación diferentes.
La primera, conocida como consulta compilada de forma estática que llega al Servidor sólo una vez, allí se
compila y se almacena para ser re-llamada tantas veces cuantas sea preciso. De esta forma, el Servidor almacena
el código compilado de la consulta en forma parametrizada; y, en cada invocación del cliente (típicamente se
invoca a un procedimiento), basta con pasar los valores de los parámetros que en cada caso corresponda. A
menudo, el Servidor que procesa estos procedimientos es multi-hebra (multi-threaded) y cada unidad de ejecución
del proceso del Servidor, para una transacción dada, es una hebra. Como muestra la figura 7.9, los procesos del
Servidor están 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 enviárselos a cada respectivo Cliente. El
dispatcher del SGBD gestiona las colas del Servidor.
La segunda forma de invocación se conoce como consulta dinámica, donde el Cliente envía al Servidor la
consulta como un string de caracteres, y allí es compilada y ejecutada cada vez.

8 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
La idea global de un Sistema de Información con arquitectura C/S es que funcione en el modo de consulta
estática (compila una vez y se guarda en el Servidor), para ser re-llamada de continuo, cuantas veces se precise su
ejecución en el Servidor. Mientras que el modo de consulta dinámica está pensado para un tipo de consulta
esporádica o no frecuente, su rendimiento es más bajo que el de la invocación estática y por tanto con un tiempo
de respuesta mayor.

2.2.2 Acceso a Bases de Datos con Protocolo Oracle Net y ODBC.

El acceso a la base de datos en la distribución abarca a todos aquellos procedimientos, protocolos, métodos y
funciones que proporcionan una comunicación con la Base de Datos.
Oracle Net es el protocolo de red empleado utilizado para el acceso a Oracle 10g y reemplaza al Net 8 desde la
versión 8 y a SQL*Net utilizado para el acceso a la versión 7.3 e inferiores.
Oracle Net forma parte del Oracle Networking Package junto a Oracle Names, Oracle Connection Manager y
Oracle Internet Directory.
Oracle Net realiza tres operaciones básicas:
¾ Conexión: Abre y cierra las conexiones entre un cliente y el servidor de la BD a través de un protocolo de
red.
¾ Transporte de Datos: Empaqueta y transfiere información (peticiones SQL y datos de respuesta) entre el
cliente y el servidor.
¾ Control de Excepciones: Acepta peticiones de interrupción entre el cliente y el servidor.
Oracle Net soporta muchos protocolos de red como: TCP/IP, SPX/IPX, IBM LU6.2, Novell o DECTnet; y
proporciona una comunicación transparente a la red, a los distintos sistemas operativos y a los tipos de máquinas
conectadas en C/S. Además, permite ata escalabilidad en cuanto al número de usuarios conectados
simultáneamente.
Por otro lado, contamos con el acceso a Bases de Datos ODBC (Open Database Connectivity), ya visto en el
Tema VI como una interfaz que sigue el estándar RDA (Remote Database Access) de ISO y sus CLI rutinas (Call
Level Interface). ODBC se desarrolla según las especificaciones del SQL Access Group, y proporciona al
programa cliente una vía para el acceso a los datos de los servidores de bases de datos.
ODBC define un conjunto de llamadas, códigos de error y tipos de datos que pueden ser utilizadas por las
aplicaciones que acceden a una Base de Datos con independencia de cuál sea ésta. No obstante, para el acceso
vía ODBC a Oracle es necesario tener instalado el Oracle Net, Net 8 o SQL*Net.
Por último, hay que comentar que el retardo entre un acceso vía ODBC en comparación con otro vía
SQL*Net/Net8 está estimado -según Oracle- que es un 5% más lento. Sin embargo, como veremos a
continuación, ODBC tiene predominancia funcional en las arquitecturas Web que veremos a continuación.

VII.3 Arquitecturas Web con tres o más capas.

3.1 Ubicación del SGBD en la Arquitectura Web.

La espectacular evolución de Internet plantea grandes retos para mejorar su potencialidad y actual forma
operativa. La tecnología world-wide-web (www) [BCGP92], [BeCG92], [Bern97] es el substrato de interconexión de
la sociedad de la información actual y futura. Su ritmo de expansión 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 menor velocidad). Muchas empresas e instituciones han
desarrollado su propia Intranet conectada a Internet. Los sistemas de información así ubicados se conocen como
Sistemas de Información Web (en adelante, SIW, en inglés WIS), y acoplados con un SGBD se puede

9 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
proporcionar acceso rápido e inteligente a grandes cantidades de datos estructurados, como los que alberga una
base de datos [FlLM98].
La Web empezó siendo una interfaz para el acceso a documentos distribuidos, y hoy es una plataforma para
sistemas de información de todo tipo. Se trata de un paradigma que permite difundir y adquirir cualquier tipo de
información a través de su arquitectura, configurada en capas, que en el caso de un SGBD con arquitectura Web,
serían las tres siguientes que muestra la figura 7.11. Y se dibuja vs. la arquitectura C/S (a su derecha).
Capa frontal (Front End), formada por una herramienta genérica llamada navegador1 o browser (p.ej.: Netscape
Navigator o Microsoft Internet Explorer). Constituye la interfaz de la máquina del usuario para navegar por la Web. 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 mínimas las exigencias del ordenador que así funciona. Se puede entender al
browser como una Interfaz Gráfica de Usuario (GUI) que reside en la máquina cliente o máquina remota del
usuario.
Capa intermedia, llamada Servidor HTTP o Servidor Web que, generalmente, contiene además al Servidor de
Aplicaciones. Se puede entender a esta capa como un conjunto de programas residentes en sitios Web.
Actualmente, se trata de bibliotecas de servicios (Java) que siguen estándares del W3C (WSDL, SOA, UDDI, etc.)
Capa dorsal (Back End), llamada Servidor de Información o Servidor de Bases de Datos, descrito con detalle en
el Tema XI de este programa docente (cap. 9 de [Cost99]).

Browser Capa 1 Cliente (Front End con el


Navegador del Usuario)
Usuario
Internet

Servidor Web y Capa 2 (1er. Servidor)


Servidor de Capa Cliente
(Intermedia o Middleware)
Aplicaciones
Internet

Servidor de Capa 3, Servidor de BDs (Back End)


Capa Servidora
Bases de Datos

Arquitectura C/S Abreviada

Bases de Datos

Fig. 7.11 Arquitectura Web Abreviada (a tres capas) de un SGBD.


Casi toda la actual tecnología de bases de datos dispone de un Servidor de Aplicaciones además del Servidor
Web como primera máquina servidora (ubicada en la capa 2 o intermedia) y de una segunda máquina servidora
donde reside el Servidor de Bases de Datos que pasa a estar en la 3ª y más interna capa operativa de esta
arquitectura, como quiere describir la figura 7.11.

3.2 Internet y la World Wide Web.

Internet funciona como una federación de redes comunicadas todas ellas 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
pequeño alcance.
1
Navegador, máquina conectada a Internet, en inglés: browser. Este texto usa indistintamente ambos términos.

10 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
Las redes locales se comunican con las demás formando una jerarquía de redes; por ejemplo: la red universitaria, la
red de todas las universidades de un país, toda la red nacional, y así sucesivamente. Físicamente, la jerarquía de redes y
la estructura de direcciones de los nodos dentro de una red se muestran transparentes (a usuarios y a programas);
de tal forma, que el usuario puede referenciar2 a cualquier nodo cuya dirección sea conocida por él. Lógicamente,
esta federación 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 Tema VI.
El protocolo TCP permite que los ordenadores (de cualquier fabricante y con sistemas operativos distintos) se
comuniquen entre sí, y resulta apasionante ver cómo se han superado todas las estimaciones en cuanto a su
crecimiento. Lo que comenzó a finales de los años 60 como un proyecto de investigación financiado por el
gobierno norteamericano sobre redes de conmutación de paquetes, ha llegado a ser desde los 90 la forma de
comunicación entre ordenadores más difundida. Se trata de un sistema abierto, donde la definición del protocolo y
muchas de sus implementaciones son públicas y gratuitas. 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, sino que 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 colección de documentos no estructurados. La idea de hipertexto se ha
generalizado en muchos sentidos. La técnica no estructurada no tiene porqué aplicarse sólo al documento, más
bien puede usarse para relacionar diversos documentos producidos por distintas personas en distintos momentos.
Además, los documentos no tienen porqué ser textuales, también pueden tener imágenes, vídeo, voz, etc. y;
cuando esto ocurre, entonces hablamos de navegación por los hipermedia. Adicionalmente, dichos documentos
suelen estar distribuidos entre los nodos de cualquier red de ordenadores; en suma, en Internet. Adicionalmente, la
Web no sólo permite acceso a documentos estáticos, también permite lanzar programas [GoEi01] para que éstos
generen dinámicamente documentos nuevos (en páginas dinámicas).
El punto VII.3.2.2 describe los principales componentes tecnológicos que posibilitan la implementación de estas
breves ideas sobre la Web. Principalmente son:
1. el protocolo de comunicación HTTP,
2. el concepto URL para referenciar a los servidores que poseen los recursos,
3. el lenguaje HTML para marcar las partes de los documentos, y
4. el avanzado lenguaje XML, algo posterior a HTML.

Desgraciadamente, la Web está aún lejos de ser un repositorio bien organizado de documentos XML, más bien
hoy es un conglomerado de páginas HTML volátiles cuyas estructuras han de ser extraídas4 en cada acceso. El
gran éxito logrado por la Web ha puesto en evidencia la necesidad urgente de ir más allá de una simple
navegación humana por entre los documentos. Ahora, es preciso abordar la construcción de nuevos pasos que
permitan realizar dicha navegación automática a las aplicaciones con el fin de llegar a ofrecer nuevas formas de
interoperabilidad entre los servicios Web.
Para lograr esto, las fuentes de información de la Web necesitan ser accesibles de forma estructurada y, en este
sentido, XML y sus diversas extensiones (en modelo de datos y lenguaje consultivo) son pasos que se vienen dando
en esta dirección.

2
Referenciar, en la técnica se entiende como apuntar, señalar o enlazar algo con otra entidad u objeto.
3
Hiper, prefijo griego que significa "exceso".
4
Extraer, sacar algo que está incrustado en el documento.
11 Madrid, Diciembre de 2010
DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla

3.3 Servidores de la capa intermedia en la Arquitectura Web.

La figura 7.12 muestra de nuevo la arquitectura Web (desde la fig. 7.11) destacando la segunda capa donde está
ubicada la primera máquina Servidora que incluye dos tipos de servicios: el proporcionado por el Servidor Web y el
del Servidor de Aplicaciones, descritos a continuación.

3.3.1 Servidor Web: URLs y Protocolo HTTP.

La arquitectura Web es una variante de C/S, basada 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 7.12, la Web trabaja con
Servidores HTTP, más conocidos como Servidores Web. El protocolo HTTP es de naturaleza muy simple y
consta de cuatro fases:
a) Abrir Conexión. En ella, el browser contacta con el servidor HTTP que se indica en el URL para verificar su
disponibilidad y corrección (llamado Solicitud HTTP en la figura 7.12);
b) Establecer Conexión. Si el servidor está disponible, éste acepta la conexión y envía una confirmación al cliente
(no representado en la figura 7.12);
c) Enviar Solicitud. El cliente envía un mensaje al servidor solicitando un servicio y dando el nombre del recurso
invocado y los posibles parámetros de la invocación (llamado Entrada en fig. 7.12);
d) Recibir Respuesta. El servidor devuelve al cliente el resultado del servicio requerido (llamado Respuesta HTML
en la fig. 7.12), y se cierra la conexión por el servidor sin retener información alguna para ser usada en conexiones
subsiguientes.
La Web utiliza la naturaleza distribuida de los hipertextos y, basándose en C/S, provee un servicio de transferencia
de hipertextos basado en el protocolo HTTP, usado desde 1990. Por tanto, HTTP es un protocolo de nivel de
aplicación con la agilidad y velocidad necesarias para sostener sistemas de información hipermedia
distribuidos. Se trata de un protocolo orientado a objetos, de carácter genérico, que se puede usar para muchas
tareas, tales como nombrar servidores y sistemas de manipulación de objetos distribuidos, a través de la utilización
de las extensiones de sus comandos.
Las principales características de HTTP son su tipado de objetos y la negociación de la representación de los
datos, permitiendo que los sistemas se construyan con independencia de los datos que deben transferir.
Una buena parte de los datos accesibles en la Web están almacenados en repositorios estructurados, como ocurre
en bases de datos. Otros repositorios, como los ficheros planos (textos, imágenes, audio y vídeo), se gestionan a
menudo mediante aplicaciones ad hoc. Aunque, desde el momento en que los datos son accedidos vía Web, la
forma física de cómo están organizados estos datos en el repositorio queda siempre oculta para el usuario, quien
sólo percibe que unas veces el acceso es ágil e inteligente, y otras es lento, algo rígido y no hábil.
La dirección de cada máquina -nodo de Internet- que funciona en la modalidad C/S es conocida en el alcance donde
ella coopera (para un funcionamiento global) por su dirección IP (Internet Protocol, o nombre asociado a ella) que la
identifica unívocamente y TCP es el protocolo para controlar las transferencias de información entre máquinas.

5
URL, es el Localizador de Recursos Uniforme. Su género es masculino, aunque a veces se designe como la dirección donde
se encuentra el recurso (en femenino).
12 Madrid, Diciembre de 2010
DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
Sobre TCP/IP, la tecnología Web se fundamenta en saber localizar sitios Web desde una máquina conectada a
Internet, que -a su vez- también es un sitio Web.
Browser

Internet
Solicitud HTTP
(URL + Entrada) Respuesta en HTML

Servidor Web o Servidor HTTP

Entrada HTML

Servidor de Aplicaciones
Gateways: CGI/Fast CGI/Java
Servlest/ASP/JSP

Internet
Consulta SQL Datos de la BD
Cola de Entrada Cola de Salida

Servidor de Bases de Datos

Base de Datos

Fig. 7.12 Detalle de la capa 2 de la Arquitectura Web de un SGBD.


El punto de entrada a la Web desde un sitio Web es su página casera (home page), identificada por un URL
formado por bloques (de números o nombres asociados a esa dirección) y separados por puntos (por ejemplo:
http://www.etsit.upm.es es la página casera de nuestra Escuela de Telecomunicación, y http://www.w3c.org es el URL del sitio
web que es responsable de la definición de estándares Web). Un URL se refiere a otros documentos de otros URLs. Así
es como se proporciona la navegación por los hipertextos para su localización.
Todo URL tiene la siguiente estructura: [Protocolo://][Servidor/]Recurso,
y define objetos en una red Internet, que contienen los siguientes datos sobre:
a) la naturaleza del Protocolo que deberá ser de alguno de los tipos disponibles en Internet; por ejemplo HTTP, o
FTP (File Transfer Protocol), Telnet (para emulación de terminales) o e-mail para correo electrónico (todos ellos 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 simbólico, aunque
también se puede escribir la dirección 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 físico contiene el objeto solicitado.
Por ejemplo, esto es un URL: http://microsoft.com/download/aspdoc.zip. Si se omite el puerto se tomará el válido 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 un valioso medio para establecer enlaces entre un gran número de nodos independientes. Su
contrapartida es que no mantiene ningún contexto entre el cliente y el servidor, lo que puede resultar muy pesado
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 información 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,
13 Madrid, Diciembre de 2010
DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
lo que representa serias limitaciones en aquellos casos que requieren una interacción fluida entre máquinas, como
las que necesitan las transacciones realizadas en las bases de datos.

3.3.2 La seguridad en Internet.

Como todo sistema informático de comunicaciones, la Web precisa una serie de herramientas de seguridad
asociadas como son:
La autenticación de solicitudes y de servidores.
La privacidad de solicitud y respuesta.
Protección contra abusos de la capacidad del servidor y de la información disponible
Control de acciones inconscientes sobre la red.
Aunque HTTP intenta abordar algunos de estos problemas, la seguridad se mejora con el protocolo HTTPS, cuya
'S' final significa Security.

3.3.3 Gateways, CGI y Servidor de Aplicaciones.

Los Servidores Web invocan a programas (llamado Entrada en la Figura 7.12) y, en cada invocación, pasan los
debidos parámetros, como por ejemplo: los datos de entrada que el usuario ha escrito en un formulario (form).
Ahora veremos el concepto básico relativo a la forma de acceso a una base de datos.
En la figura 7.12 se observa el flujo de mensajes (unos de petición, otros de respuesta) entre el browser, el Servidor
Web y el Servidor de Aplicaciones. La primera petición del cliente se envía al Servidor Web y éste, a su vez, envía
la solicitud 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 información procesada siguiendo el camino
anterior, pero ahora recorrido en dirección contraria, hasta que la respuesta llegue al browser que lanzó la solicitud
[Or9i01].
Describiremos brevemente cómo se establece la comunicación entre el Servidor Web y el Servidor de
Aplicaciones. Para ello, el Servidor Web utiliza diferentes tecnologías para obtener y enviar la información que va a
ofrecerle el Servidor de Aplicaciones. Dichas tecnologías son las siguientes:
- CGI (Common Gateway Interface), mecanismo de comunicación escrito en: Java, C, C++, Perl, etc.,
- ASP (Active Server Pages), tecnología de Microsoft,
- JSP (Java Server Pages),
- Java Servlets, tecnología de Sun,
- Java Script, tecnología 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 puede estar escrito en un lenguaje interpretado
(como Perl o Tcl -usado para realizar operaciones sobre cadenas de caracteres-), o incluso puede estar en algún
lenguaje script de los sistemas operativos.
Como su nombre indica, el gateway permite establecer una conexión 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 lógica de negocio para las aplicaciones.

6
Gateway, puerta de paso o pasarela a otro entorno. Usaremos gateway por brevedad y uniformidad con la
terminología técnica.
14 Madrid, Diciembre de 2010
DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
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:// , después se indica el nombre del servidor, el del directorio y el de un
fichero (path), y los parámetros se pueden especificar añadidos al URL. El mecanismo de comunicación 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 sea enviando un formulario o bien haciendo click con el ratón
sobre un ancla. Con ello, se transmiten los parámetros al Servidor Web, cuyas técnicas detalladas escapan al
interés de nuestro programa.
2. El Servidor Web lanza el gateway (también llamado programa CGI) según el protocolo CGI y le transmite los
parámetros.
3. Con los parámetros 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 7.12).
4. Cuando el gateway reciba respuesta del Servidor de Bases de Datos (llamado Datos de la BD en la figura 7.4),
retornará el resultado al Servidor Web (llamado HTML en la figura 7.12).
5. Finalmente, el Servidor Web transmite el resultado al browser (Respuesta HTML en la fig. 7.12).
La figura 7.13 detalla algunas implementaciones utilizadas para el Servidor de Aplicaciones, cuyas principales
características se resumen en los siguientes puntos:

Browser

Servidores de Aplicaciones Web


JAVA ActiveX C / C++
♦Netscape App Server ♦ Lotus Domino ♦Applet Web Objects
♦IBM Websphere ♦ Microsoft ASP/MTS ♦ Seagate Info APS
♦Oracle Web App Server
♦Sun NetDynamics
♦BEA WebLogic
♦Silver Stream
♦Inprise App Server

Servidor de Bases de Datos

Bases de Datos
Fig. 7.13 Detalle del Servidor de Aplicaciones en la Arquitectura Web de un SGBD.
Gestión de Componentes: Proporcionan herramientas para controlar todos los componentes y servicios de
ejecución, como la gestión de sesiones, notificaciones síncronas / asíncronas entre clientes, así como la
ejecución de servidores de lógica de negocio.
Tolerancia frente a Fallos: Capacidad de recuperación frente a fallos, evitando un único punto de ruptura,
definiendo políticas de recuperación en 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.
Gestión de Transacciones: Descrito en Tema XI, lo veremos en Capítulo 9 de [Cost99].
Gestión Centralizada: Gestión centralizada a través de una consola gráfica para monitorizar los clientes y los
distintos servidores o clusters.
Seguridad: Características de seguridad y gestión de usuarios y grupos.

15 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla

Los servidores de aplicaciones se organizan principalmente en tres grandes tipos:


Web Information Servers: Este tipo de servidores emplea plantillas HTML y Scripts para generar páginas 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. Ejemplos de Servidores de este tipo son el
Netscape Server, Allaire o Sybase.
Component Servers: La principal característica de estos servidores es 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.
También son stateless servers. Ejemplos de este tipo de servidores son MTS, Sybase Jaguar, e IBM
Component broker.
Active Application Server: Este tercer tipo de servidores soporta y proporciona un buen entorno para la lógica del
servidor expresada en objetos, reglas y componentes. A diferencia de los anteriores, son stateful servers y son
más propicios para desarrollos basados en e-commerce y procesos de toma de decisiones. Los stateful servers
son los que juegan el rol de coordinadores de transacciones y gestionan el estado de los datos, se estudiarán
en el Tema XII junto al protocolo Two Phase Commit.

3.4 Arquitectura Web con Plataforma J2EE, Java, Struts y MVC.

Es sabido que la tecnología de aplicaciones Web tiene un peso específico muy alto en el desarrollo y despliegue
de aplicaciones de los Sistemas de Información industriales. Por ello, este apartado describirá la plataforma J2EE,
y sus tecnologías propias para el desarrollo de Servicios Web, como es el caso de la herramienta Struts
desarrollada bajo el patrón MVC (Model-View-Controller).

3.4.1 Java

Java es un lenguaje de programación orientado a objetos desarrollado por Sun Microsystems a principios de los
años 1990. Las aplicaciones Java están típicamente compiladas en un bytecode. En tiempo de ejecución, el
bytecode es interpretado o compilado a código nativo para la ejecución.
El lenguaje en sí mismo parte de la sintaxis de C y C++, pero tiene un modelo de objetos más simple y elimina
herramientas de bajo nivel como punteros.
Sun Microsystems proporciona una implementación GNU (acrónimo recursivo, GNU is Not Unix) de un compilador
Java y una máquina virtual Java, conforme a las especificaciones de Java Community Process, aunque la
biblioteca de clases que se requiere para ejecutar los programas Java no es software libre.
Desde el 27 de enero de 2010, Oracle adquiere con éxito total la tecnología de Sun Microsystems, tras haber sido
aprobada por la Unión Europea el 21 de enero de 2010.
Java es un lenguaje conocido y practicado por nuestros estudiantes. Por tanto, bastará ahora con una breve
reseña de sus características más relevantes:
Java se basa en el paradigma orientado-a-objetos: sus conceptos, técnicas y metodologías de programación.
Java permite diseñar programas para que su código se pueda ejecutar en sistemas remotos de forma segura.
Para ello, Java conlleva un soporte para trabajar en red.
Además, un programa Java es independiente del Sistema Operativo y de la Plataforma donde se vaya a
ejecutar dicho código. Coloquialmente dicho: el código Java ‘corre’ en distintos sistemas operativos y en distintas
máquinas y plataformas.

16 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
Para conseguir estas formas de ejecución dichas (código remoto y soporte de red), a veces el programador de
Java recurre a extensiones como CORBA (Common Object Request Broker Architecture), Internet
Communications Engine u OSGi (Open Services Gateway Initiative).
CORBA se ha visto en el Tema VI de este programa docente, en el Capítulo 8 de [Cost99], bajo la óptica de la
interoperabilidad entre Bases de Datos Heterogéneas y Distribuidas.
La independencia de la plataforma permite que los programas Java se puedan ejecutar en cualquier tipo de
hardware. Por ello, Java hizo famoso el dicho: “write once, run everywhere”, escribe el programa una vez y lo
ejecutas en cualquier máquina (u organización de ellas). Para ello, se compila el código fuente en Java, y se
genera el código bytecode (instrucciones máquina simplificadas propias de la plataforma Java). El código
bytecode está “a medio camino” entre el código fuente y el código máquina destino donde se va a ejecutar. A mitad
del camino, bytecode se ejecuta en la máquina virtual (VM), un programa escrito en código nativo de la
plataforma destino, que es quien entiende su hardware, lo interpreta y ejecuta el código finalmente. Existen
múltiples bibliotecas software que permiten acceder a las características de cada máquina de forma unificada. De
esta forma, el bytecode generado es interpretado o convertido a instrucciones máquina del código nativo por el
compilador JIT (Just In Time).
La máquina virtual moderna, está hoy en día implementada como una JVM (Java Virtual Machine) que mejora
notablemente los tiempos de ejecución de los programas (las antiguas VM estaban escritas en C o C++). JVM
emplea técnicas nuevas como: compilar directamente en código nativo al estilo de los compiladores tradicionales,
eliminar la etapa del bytecode, la compilación JIT o la re-compilación dinámica.

3.4.2 Plataforma J2EE

J2EE significa Java 2 Platform, Enterprise Edition. La plataforma J2EE describe cómo se puede integrar un
conjunto de APIs escritas en Java para proporcionar una solución conjunta.
La versión que aquí se describe es la J2EE 1.4 [J2EE14] y coincide con la que haremos las prácticas en el
laboratorio y también será la utilizada en uno de los trabajos académicos propuestos en esta asignatura. Por ello,
una mayor abundancia de detalles se verá más adelante. En el Laboratorio de Bases de Datos veremos cómo un
servidor de aplicaciones J2EE configura y despliega componentes: Enterprise JavaBeans 2.0 [JavaBeans],
Java Servlets 2.3 [Servlet23] y JavaServer Pages (JSP) 1.2 [JSP12], y cómo debe gestionarlos en tiempo de
ejecución.
Además de lo dicho, la especificación J2EE indica la forma mediante la cual estos componentes interactúan entre
sí y con el servidor de aplicaciones J2EE donde se ejecutan. Entre las numerosas APIs, están las APIS de acceso
a recursos como Java Database Connectivity (JDBC), [JDBC].
La figura 7.14muestra los distintos componentes y APIs soportados por la plataforma J2EE 1.4, y está tomada
directamente de [J2EE14]. Esta figura representa una visión global de la arquitectura de la plataforma J2EE.
Los componentes Enterprise JavaBeans y Servlets/JSPs residen en su propio contenedor, que gestiona su ciclo de
vida, su comunicación con el entorno, transacciones, seguridad, y otros aspectos relacionados con la calidad del
servicio. Estos componentes tienen acceso a todas las APIs de recursos proporcionadas por la plataforma J2EE
como, por ejemplo, JDBC (Java DataBase Connectivity).
En las prácticas del Laboratorio de Bases de Datos, destinadas a J2EE, se abundará exhaustivamente en ello.

17 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla

Fig. 7.14 Componentes de J2EE 1.4.

3.4.3 Tecnología Servlet

La tecnología Servlet amplía la funcionalidad de un servidor Web añadiéndole la capacidad de generar páginas
HTML dinámicas. Un servlet es un programa Java que se ejecuta en un servidor Web.
Como muestra la figura7.15, el servlet toma una petición HTTP (HyperText Transfer Protocol) procedente de un
navegador (HttpServlet Request), genera contenido dinámico y produce la respuesta HTTP (HttpServlet
Response), que se devuelve al navegador Web.

Fig. 7.15 Funcionalidad del Web Server.

A diferencia de otras aplicaciones Java, un servlet no puede ejecutarse de forma directa haciendo uso del método
estático main(). Un servlet debe ejecutarse bajo el control de un contenedor externo. El contenedor de
servlets, o servlet engine, gestiona el entorno de ejecución de un servlet.

18 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
Dicho contenedor es el encargado de realizar las llamadas a los métodos correspondientes ante la recepción de
una petición HTTP, además gestiona el ciclo de vida de un servlet, y, en general, proporciona todos los servicios
que necesita un servlet para su ejecución.
Generalmente, el contenedor de servlets está implementado en Java y forma parte de un servidor Web (si también
está escrito en Java), y –si no forma parte de un Servidor Web, entonces estará asociado con un servidor Web que
lo utiliza y que puede ejecutarlo bajo el control de un servidor de aplicaciones J2EE.
El éxito de esta tecnología se debe a su aparente simplicidad. Cuando el browser (navegador Web) solicita una
página Web, envía una petición (normalmente) GET del protocolo HTTP al contenedor de servlets. Dicho
contenedor localiza una instancia del servlet apropiada para procesar la petición HTTP. Esta instancia de servlet
recibe un flujo de entrada que representa la petición y otro de salida para enviar la respuesta al cliente. La API
de servlet define una serie de interfaces con un nivel de abstracción mayor al ofrecido por estos flujos de entrada y
salida. Dichas interfaces permiten: acceder a parámetros, a cabeceras de la petición recibida, establecer sesiones
con cliente, etc.
La popularidad adquirida por la tecnología de servlets, llevó a Sun Microsystems (hoy Oracle) a introducir las
JavaServer Pages (JSP), que combinan HTML con etiquetas especializadas y código Java. De esta forma, el uso
de JSP está más extendido que el de la tecnología Servlet; sin embargo, interesa entender que una JSP es un
servlet de facto. La única diferencia está en el código fuente de su implementación. Para desarrollar un servlet
convencional, el desarrollador utiliza ficheros en código fuente Java, mientras que para desarrollar JSPs, el mismo
desarrollador edita una página HTML con determinadas etiquetas especiales y cierto código Java embebidas en la
página, que se compila en un servlet.

3.4.4 Tecnología Java Server Pages

La tecnología JSP (Java Server Pages) permite -de forma sencilla- crear contenido Web tanto estático como
dinámico. Véase más información en [JSP12], [Falk03] sobre ello. Las JSPs explotan las capacidades dinámicas
de los servlet, proporcionando una forma natural de generar contenido estático. Las principales características de
la tecnología JSP son:
• Un lenguaje de programación que consiste en un documento basado en texto, describiendo cómo procesar
una petición y generar una respuesta.
• Un conjunto de expresiones que describen cómo acceder a los objetos del servidor.
• Mecanismo para definir extensiones del lenguaje JSP.
Así pues, una JSP es un documento de texto que contiene dos tipos de texto: uno estático que puede estar
escrito en cualquier formato de texto (como HTML, SVG, WML y XML) y elementos JSP que constituyen la parte
dinámica.
Los elementos JSP de una página pueden estar expresados en dos tipos de sintaxis (estándar y XML). Pero cada
documento sólo puede tener un tipo de sintaxis. Una JSP expresada en XML es un documento XML que puede
ser gestionado por herramientas y APIs para XML.
Como representa la figura 7.16, la tecnología JSP funciona en general como un intérprete del código contenido en
la JSP por el Servidor de Aplicaciones. De esta forma, se construye un Servlet. La salida que produce el Servidor
de Aplicaciones es un documento estático (típicamente HTML) que, finalmente, se presentará en el browser del
usuario.
A su vez, este lenguaje se puede enriquecer con etiquetas, y mediante la implementación de Bibliotecas de
Etiquetas (Tags Libraries) se puede extender la capa de alto nivel JSP.
JSP no puede considerarse como un script, ya que, antes de ejecutarse, el Servidor de Aplicaciones compila el
contenido del documento JSP (script y etiquetas) y genera una clase Servlet. Por lo tanto, se puede decir que -
aunque este proceso sea transparente al programador- no deja de ser una tecnología compilada.

19 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla

Fig. 7.16 Ejemplo de ejecución de una JSP.


En la práctica del Laboratorio que haremos se verán algunos ejemplos de una JSP. Además, se profundizará en
mayores detalles dentro del trabajo práctico destinado a la arquitectura Web-Centric J2EE.

3.4.5 MVC (Model View Controller)

El Modelo Vista Controlador (MVC) es un patrón de arquitectura software que separa los datos de una
aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. La figura 7.17
muestra su esquema. El patrón MVC se ve frecuentemente en aplicaciones Web, donde:
• la vista es la página HTML y el código que provee de datos dinámicos a la página,
• el controlador se encarga de organizar la forma de invocación a la lógica de negocio y de
seleccionar la vista donde se presentan los resultados de la interacción con la misma, y
• el modelo lo constituyen los componentes definidos para soportar la lógica de negocio de la
aplicación, encargado de gestionar el acceso a base de datos de manera transparente para el
controlador.
El Modelo es la representación específica de la información con la que opera el sistema. La lógica de
datos asegura la integridad de la información y permite derivar nuevos datos. En base al tipo de
arquitectura sobre el que se está construyendo la aplicación, el modelo puede seguir distintos patrones
en su diseño. El modelo es responsable de:
• Acceder a la capa de almacenamiento de datos.
• Definir las reglas de negocio (la funcionalidad del sistema).
• Llevar un registro de las vistas y controladores del sistema.
• Si estamos ante un modelo activo, notificará a las vistas los cambios que en los datos pueda
producir un agente externo.
La Vista en una aplicación Web está compuesta por aquellos elementos que aporten algo a la
presentación, como: jsps, páginas html, imágenes, animaciones, componentes, etc. La mayoría del
contenido dinámico de la presentación será generado en la capa superior de la aplicación, en el servidor
de aplicaciones. Aunque tambié se puede generar una parte en el cliente (vía algún lenguaje de script),
debido a requisitos o simplemente por preferencias del desarrollador. La vista es responsable de:
• Recibir datos del modelo y mostrarlos al usuario.
• Mantener un registro de su controlador asociado.

20 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
• Puede dar servicio de "Actualización()", para ser invocado por el controlador o por el modelo.
El Controlador suele implementarse mediante un servlet (en proyectos java, lógicamente) y es el
corazón del funcionamiento del patrón. El controlador es responsable de:
• Interceptar y recoger las peticiones http del cliente. Así, el cliente no invocará ninguna página jsp o
html, sino que será redireccionado adecuadamente por el controlador.
• Traducir la petición en una operación de negocio específica.
• Invocar la operación o bien delegar en un manejador.
• Determinar la siguiente vista a mostrarle al cliente.
• Devolver (retornar) el control al cliente.

Controlador

Vista Modelo

Fig. 7.17 El ModeloVista Controlador.


Como todas las peticiones HTTP pasan por el controlador, se facilita mucho el mantenimiento de la
aplicación, sobre todo en lo relativo al control de la navegabilidad, sustitución de páginas, etc.
Aunque existen diferentes implementaciones de MVC, generalmente el flujo de control es el siguiente:
1) El usuario interactúa con su interfaz de usuario de alguna forma, y el controlador recibe (por parte
de los objetos de la interfaz-vista) la notificación de la acción que solicita el usuario. El controlador
gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler o
manejador) o callback. Normalmente, los controladores complejos se estructuran usando un patrón
de comando, que encapsula las acciones y simplifica su extensión.
2) La lógica de negocio definida en el modelo recibe esta petición e interactúa con el modelo de
información subyacente, y puede modificarlo para adecuarlo a la acción solicitada por el usuario.
3) El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista
obtiene sus datos a partir del resultado de la interacción con el modelo para generar la interfaz
apropiada para el usuario, donde se refleja los cambios en el sistema de información subyacente. El
modelo no debe tener conocimiento directo sobre la vista. Sin embargo, el patrón de observador
puede ser utilizado para proveer cierta indirección entre el modelo y la vista, permitiendo al modelo
notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y
esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista.
La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.

3.4.6 Struts

Struts es una herramienta para desarrollar aplicaciones Web bajo el patrón MVC de la plataforma J2EE.
Struts surge como parte del proyecto Jakarta de la Apache Software Foundation, y actualmente es un
proyecto independiente conocido como Apache Struts. La página oficial de Apache contiene información
actualizada [Struts].

21 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
Struts permite reducir el tiempo de desarrollo. Su carácter de "software libre", y su compatibilidad con
todas las plataformas donde esté disponible Java Entreprise, lo convierten en una herramienta de alta
utilidad.
Struts se basa en el patrón Modelo Vista Controlador (MVC) [MVC] ya descrito y, consecuentemente, su
funcionamiento se separa en tres secciones diferenciadas (el modelo, las vistas y el controlador).
Cuando se programan aplicaciones Web con el patrón MVC, siempre surge la duda de si usar un solo
controlador o varios controladores. Si se opta por usar un solo controlador para tener toda nuestra lógica
en un mismo lugar, nos encontraremos con el grave problema de que nuestro controlador se convierta
en un controlador "fat controller", es decir un controlador pesado de peticiones.
Struts surge como una solución al problema dicho, ya que implementa un solo controlador
(ActionServlet) que evalúa las peticiones del usuario mediante un archivo configurable (struts-
config.xml) donde se definen acciones que son las responsables de procesar cada petición individual.
Struts tiene los dos tipos de componentes siguientes:
1. Componentes del Modelo. Corresponden a la lógica del negocio con la que se comunica la
aplicación Web. Normalmente, el modelo comprende accesos a Bases de Datos del back-end y
sistemas que funcionan independientemente de la aplicación Web.
2. Componentes del Control. Los componentes del control se encargan de coordinar las
actividades de la aplicación, que van desde la recepción de datos del usuario, las verificaciones de
forma y la selección de un componente del modelo a ser llamado. Por su parte, los componentes
del modelo envían al control sus resultados (o errores, en su caso) de manera que pueda
continuar con otros pasos de la aplicación. Esta separación de competencias simplifica
enormemente la escritura, tanto de vistas como de componentes del modelo: Las páginas JSP no
tienen que incluir manejo de errores, mientras que los elementos del control simplemente deciden
sobre el paso siguiente.
Algunas de las características más destacadas de Struts serían las siguientes:
• Configuración del control centralizada.
• Las interrelaciones entre acciones y página (u otras acciones) se especifican mediante
documentos XML en lugar de codificarlas en los programas o páginas.
• La utilización de componentes de aplicación que son el mecanismo para compartir información -
de forma bidireccional- entre el usuario de la aplicación y las acciones del modelo.
• La utilización de bibliotecas de entidades para facilitar la mayoría de las operaciones que
generalmente realizan las páginas JSP.
• La existencia de herramientas para validar campos de plantillas bajo varios esquemas que
van desde validaciones locales en la página (en javaScript) hasta las validaciones de fondo
hechas a nivel de las acciones.
Finalmente y como ya se dijo, la práctica del Laboratorio profundizará en mayores detalles sobre la arquitectura
Web-Centric J2EE.

VII.4 Sobre la Estructuración de los Datos y Consultas a Datos Intensivos y


heterogéneos en la Web.
Todos los conceptos y técnicas del Modelado Conceptual (vistos en el Tema II, Cap. 2 de [Cost99]) y del Diseño de
Bases de Datos XML-Objeto-Relacionales (Tema IV, Capítulos 4 y 5 de [Cost99]) son adaptables al caso que nos

22 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
ocupa. Ahora, la base de datos se concibe para operar en la arquitectura Web, donde el sitio de nuestro interés
contendrá un Servidor de Bases de Datos y, por tanto, los accesos a la BD serán 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 objetivo es ofrecer grandes cantidades de información a una variedad de usuarios. Es
decir, sitios que cuentan con uno o varios Servidor de Bases de Datos.
La idea general que hoy tenemos de la Web se puede situar en algún punto intermedio de los dos extremos
siguientes:
a) Por un lado, se puede percibir la Web como una fuente de información unificada. Aunque esto no sería veraz del
todo, ya que la Web adolece bastante de coherencia en la forma de presentar la información ú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 colección de páginas independientes
(conglomeradas) donde, cada página se percibe como una fuente independiente de información útil que nada tiene
que ver con lo que ofrecen las demás (y casi infinitas) páginas. Éste es el punto de vista que adoptan las listas de
bookmarks7 para señalar sitios Web, gestionados por el navegador y los motores de búsqueda (p. ej. Google, Alta
Vista, Yahoo, etc.) ocupados en seleccionar enlaces a páginas simples, cuyas técnicas son propias de la búsqueda
documental (Information Retrieval, thesaurus, véase epígrafe I.3.b del capítulo 1 [Cost99]).
Ambos extremos resultan inapropiados para delimitar el alcance del diseño de bases de datos en, y para, la Web.
En efecto, el diseño tiene que concentrarse en un determinado Universo del Discurso (el que, en cada caso, resulte
necesario) que debe estar sometido al control requerido en los objetivos de cada diseño 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 extensión a incorporar en la actividad del diseño de bases de datos, como un ingrediente más
que se añade al trabajo de diseño de bases de datos que hasta ahora conocemos como clásico.
Este epígrafe se dedica al análisis y estudio de dicho ingrediente nuevo: concentrado en diseñar sitios Web con
datos intensivos cuyas exigencias son las de ser los mejores servidores utilizando estructuras muy regulares.
Lo que contrasta con la organización de la información que hoy ofrece Internet, cuya descripción se realiza en todo
este epígrafe.

4.1 Modelo OEM. Clasificación de Sistemas de consulta a datos intensivos y


heterogéneos en la Web.

Aunque la Web comenzó siendo una colección que interconecta documentos no estructurados, hoy cuenta con un
gran número de fuentes de datos estructurados en bases de datos (de todo tipo y naturaleza) a las que, como
sabemos, se accede mediante gateways.
Desde la arquitectura C/S, la interfaz de estas bases de datos gateways está formada típicamente por múltiples
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 información de la BD, cuya
presentación final (valores de datos, barras o tartas estadísticas, etc.) está prevista en cada tipo de informe.
En la Web, el resultado de una consulta a la BD toma forma de documento HTML que está muy estructurado y que
puede ser convertido (con un parser) a un conjunto de tuplas o a tipos de datos más complejos. Este asunto está
hoy bastante bien resuelto, como se describe en el siguiente epígrafe.
Sin embargo, además de lo dicho para las BD operativas en Web, existen otras fuentes de información como el
nombre de los servidores, fuentes bibliográficas, amplios sistemas de información (sobre universidades, empresas,
etc.) que ofrecen información online pero que pueden no estar disponibles en la Web y cuyas interfaces también
proporcionan accesos consultivos [TRCH05].

7
Bookmark, lo que se coloca entre las páginas de un libro para marcar un lugar.
23 Madrid, Diciembre de 2010
DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
Actualmente, sabemos que la estructuración de los datos disponibles en Internet se organiza de muy diversas
maneras, cuyo rango varía desde los datos sin estructura alguna (texto bruto, mapas, imágenes, etc.) hasta los datos
totalmente estructurados como lo están en las bases de datos (jerárquicas, Codasyl, relacionales u orientadas a objetos).
Entre estos dos extremos, están los documentos HTML que se han denominado como semi-estructurados
[Abit97] y se sitúan en algún lugar intermedio de las técnicas de estructuración, y que presentan notables
diferencias a las técnicas usadas en las BD.
Los datos semi-estructurados no utilizan el concepto de esquema (nivel intensional en BD) como molde que acoge a
múltiples valores de datos (nivel extensional en BD). Al contrario, en el documento HTML (semi-estructurado) cada una de
sus partes componentes posee una definición propia y exclusiva. De forma que la organización del documento
consiste principalmente en definir los enlaces entre sus partes y albergar el valor del dato (sea un objeto estructurado
o valor atómico) 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 heterogéneas con la idea de incorporar alguna estructura a los datos no
estructurados [PaGW95], [BDFS97] y permitir la formulación de consultas y su optimización a datos semi-
estructurados [GoWi97]. Se define la semi-estructura como un grafo etiquetado, acíclico y dirigido, donde los
nodos etiquetados contienen objetos y los arcos son referencias.
Un objeto OEM consta de:
a) una etiqueta nombre de la clase de objetos, opcionalmente puede llevar un oid (object identifier).
b) un tipo que puede ser atómico (string, entero, etc.) o conjunto (set),
c) un valor (uno y sólo uno) que puede ser atómico o un conjunto de objetos.
La figura 7.14 muestra un objeto OEM con la etiqueta 'BSDT 5403 Telecomunicación' cuyos valores muestran un
conjunto de las características docentes de la asignatura donde se usa este libro.
A este respecto, la nueva propuesta del estándar SQL-99 [ISOa99], [ISOb99], [ISOc99] y [ISOd99] realizó, entre
otros [EiMe00], un importante avance en el SQL/MED que tiene especial importancia para el tema que ahora nos
ocupa.
BSDT 5403 Telecomunicación
set

Web de BSDT Departamento Créditos


Ubicación
char set string char
http://sinbad.dit.upm.es Telemática, DIT 6 (4,5 T +1,5 P)

Ciclo Curso Semestre Web del DIT Materia que desarrolla (BOE)
string string string char string
segundo quinto primero http://www.dit.upm.es Ingeniería de Sistemas Informáticos

Fig. 7.18 Ejemplo de Objeto OEM para la asignatura BSDT 5403.

24 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla

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 magnéticas,
o bases de datos jerárquicas 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 cooperación en este asunto. Por ejemplo, Oracle tiene Miracle: Open
Transparent Gateway y proporciona servicios de acceso a datos heterogéneos, 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/ en el fichero: fcdi-fcd1-med-1999-11.pdf (.ps o .txt).
Los esfuerzos de estandarización de SQL, en su secuencia de promulgaciones parecen no tener un final
inmediato. Mientras cambien las necesidades o mientras la tecnología cambie de forma drástica, SQL continuará
evolucionando para llegar a ser el lenguaje intergaláctico de datos (como dijo Mike Stonebreaker en 2000). Por ello,
SQL está llamado a mejorar y seguir creciendo continuamente hasta alcanzar su final. Indiscutiblemente, el tema
de la variopinta estructuración de los datos en la Web es un paso más (abierto a la investigación actual) sumado al de
la heterogeneidad de las 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, etc. Estos sistemas utilizan algunas técnicas y mecanismos que son exclusivos para
la Web. Una referencia recomendada es [FlLM98] por cuanto que describe una panorámica de sistemas para la
gestión de datos en Web utilizando tecnología de bases de datos.
Finalmente, y como una valiosa panorámica del tema, en [DoDi99] se describe una clasificación de los actuales
sistemas para consultar datos heterogéneos (estructurados, semi-estructurados o nada estructurados). La figura 7.19
muestra lo más relevante de esta aportación. En ella, las cajas sin sombra se han estudiado en esta asignatura y
las cajas sombreadas se refieren al asunto que ahora nos ocupa.

Sistemas para consultar


fuentes de datos
mover heterogéneos dejar el dato
los datos donde está
materializado virtual

Sistemas materializados Sistemas virtualmente integrados


(los datos que provienen de fuentes (los datos permanecen en las fuentes locales, las consultas operan
locales se integran en una sola BD sobre directamente sobre ellas y la integración de los datos se produce, 'a
la que operan las consultas) sobrevuelo' durante el procesamiento de la consulta

datos nativos
datos nativos estructurados, semi-
datos nativos datos estructurados mayoritariamente
estructurados nativos y derivados datos nativos y estructurados o no
estructurados estructurados
no estructurados

SGBD Almacén de Datos motores de BD Federadas Sistemas Consultivos con


Universal (data warehouse) (meta)búsqueda (multidatabase) Mediador
(Mediator-Wrapper)

Fig. 7.19 Clasificación de los Sistemas para consultar datos heterogéneos.

25 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
VII.5 Arquitectura Mediador-Wrapper
Para los Sistemas Consultivos basados en el paradigma Wrapper-Mediator (figura 7.20) se propone una
arquitectura virtual ‘al-vuelo’. Su objetivo es permitir consultas distribuidas a múltiples fuentes de datos en Internet
[OzVa99] y su enfoque es algo próximo a la arquitectura Multidatabases [LiAb87] (Cap. 2 de [OzVa99]).
Cada wrapper exporta al diccionario de datos global información sobre su esquema fuente, sus datos y sus
posibilidades consultivas. Con ello, el Mediador centraliza la información 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 pequeñas consultas (ejecutables por los wrappers) toma los resultados parciales y
elabora la respuesta a la consulta del usuario web[Wied92], [Wied99].
Como se refleja en la figura 7.19, la arquitectura Mediador-Wrapper de la figura 7.20 difiere de la de los almacenes
de datos en que en la primera los datos integrados no están materializados, son virtuales.
Empaquetador
Fuente de
(Wrapper)
Datos
Vista Global
Servidor Consultas Empaquetador
Diccionario de Fuente de
Web (Wrapper)
Datos Global Datos

Empaquetador
Fuente de
(Wrapper)
Datos

Fig. 7.20 Arquitectura Mediador-Wrapper.


No existe aún consenso sobre cómo puede el wrapper describir las posibilidades de su fuente de datos ni sobre
cómo trabaja el mediador. La ventaja de este enfoque radica en que cada wrapper atiende a un dominio de
información específico y particular, sobre el que puede conocer el nivel de estructuración de sus datos fuente, su
semántica (si existe), etc.
Este tipo de arquitecturas virtuales se instancian ‘al vuelo’ (on-the-fly) y están basadas en estándares del W3c
Consortium, como J2EE o ‘web-centric’ (http://www.w3.org). Dichas arquitecturas utilizan la invocación a Servicios
Web (SOA, WSDL, UDDI, etc.) y/o Servicios Grid y se implementan mediante bibliotecas de Java [CRCF05],
[RoCC06].

5.1 Casos de Arquitecturas Mediador-Wrapper en la Web. Nuestra Experiencia.

En [THCH05], [CRPC05], [CRCF05], [PCC05], y [CPCV05] pueden verse mayores detalles de arquitecturas
basadas en el enfoque Mediador-Wrapper, como propuesta resultante de la actividad investigadora realizada en
SINBAD para el acceso a múltiples fuentes de datos Web heterogéneas.
La siguiente figura (7.21) muestra, a modo de ejemplo, nuestra propuesta investigadora para un Sistema de
Información que consulta múltiples fuentes de datos heterogéneas.
Cada Wrapper se ubica conceptualmente en la parte back-end sobre cada fuente de datos. Esta arquitectura
propone un Modelo Extractor de Datos (MED) que traduce a tecnología XML la información provinente de cada
fuente de datos.
Junto a ello, en la capa mediadora de esta arquitectura Web, hemos propuesto un Modelo de Unificación
Semántica (MUS), donde se instalan diversas ontologías encargadas de la unificación semántica de los conceptos.
Estos conceptos responden al dominio específico de interés donde hemos aplicado esta arquitectura: unas veces
relativos al dominio específico de los Archivos Digitales del mundo documental, y otras veces al dominio de e-
government referido a la actividad legislativa parlamentaria durante el proceso de sustanciación de la Iniciativa
Legislativa, que es aquella iniciativa que realiza una propuesta de ley (o proposición de ley) para su
promulgación, o rechazo, en el seno de un Parlamento. Así se construyen las Leyes en democracia.

26 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
Data Source
Wrapper 1 Digital Archive 1
Mediator: (XML translator)
URL + Request Global and Virtual
Web Query Web Query Dynamic Integrated
Browser S e rv e r Integration Data Source ( Asamblea of Madrid)
HTML HTML Metadata
Digital Archive N
Form Form
(results) (results) Mappings
Ontologies
Wrapper N
(XML translator)

Fig. 7.21. Web Digital Archive Integrated Architecture through Mediator and Wrappers.
Mayores detalles se explican en clase con cierto detenimiento. Además, el lector interesado puede recabar detalles
en la bibliografía específica que refiere el apartado 5.1.1 siguiente.

5.1.1 Bibliografía específica de nuestra experiencia en Mediador-Wrapper.

[THCH05] Thiran P., Risch T., Costilla C., Henrard J., Kabisch T., Petrini J., van den Heuvel W. and Hainaut J., Report
on the Workshop on Wrapper Techniques for Legacy Data Systems, ACM Sigmod Record (Web
Edition), 34(3), pp 85-86, Sept. 2005. Available in:
http://www.sigmod.org/sigmod/record/issues/0509/p85-column-brian-1.pdf
[CRPC05] Costilla C, Rodríguez MJ, Palacios JP, Cremades J, Calleja A and Fernández R, A Contribution to Web
Digital Archive Integration from the Parliamentary Management System ‘SIAP’, Frontiers in Artificial
Intelligence and Applications, Data Bases and Information Systems. Selected papers from the Sixth
International Baltic Conference DB&IS'2004, Vol. 118, Barzdins J. and Caplinskas A. (eds), ISBN: 1-58603-
485-5, IOS Press, The Netherlands, pp. 273-287, 2005.
[CRCF05] Calleja A, Rodríguez MJ, Costilla C and Fernández R., A Grid Semantic Approach for a Digital Archive
Integrated Architecture, in The Third International Conference on Information Technology and Applications
(ICITA'05), Session: Agent, Datamining and Ontologies, ADO'05, Sydney, Australia,
http://attend.it.uts.edu.au/icita05/, ISBN: 0-7695-2316-1, IEEE Computer Society, Los Alamitos,
California, USA, pp. 227-232, July 2005.
[PCC05] Palacios JP, Cremades J and Costilla C., Towards a Web Digital Archive Ontological Unification, in The
Third International Conference on Information Technology and Applications (ICITA'05), Session: Agent,
Datamining and Ontologies, ADO'05, Sydney, Australia, http://attend.it.uts.edu.au/icita05/, ISBN: 0-7695-
2316-1, IEEE Computer Society, Los Alamitos, California, USA, pp. 221-226, July 2005,
[CPCV05] Costilla C, Palacios J, Cremades J and Vila J, e-government: A Legislative Ontology for the 'SIAP'
Parliamentary Management System, in E-Government: Tow ards Electronic Democracy, Proceedings of
International Conference TCGOV 2005, Lecture Notes in Artificial Intelligence, LNAI 3416-0134, LNCS
Series, ISBN 3-540-25016-6, Springer, Berlin, Germany, IFIP 2005, Bozen-Bolzano, Italy
http://www.inf.unibz.it/tcgov2005/, pp. 134-146, March 2005.

Finalmente, por tratarse de un enfoque de futuro y que viene del autor a quien debemos la Web, señalaremos una
de sus recientes perspectivas investigadoras. Literalmente, en [Bern05], Tim Berners-Lee dice lo siguiente:
The key property of the WWW is its universality: One must be able to access it whatever
the hardware device, software platform, and network one is using, and despite the
disabilities one might have, and whether one is in a “developed” or “developing” country;
it must support information of any language, culture, quality, medium, and field without
discrimination so that a hypertext link can go anywhere; it must support information
intended for people, and that intended for machine processing. The Web architecture
incorporates various choices which support these axes of universality.

27 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
Currently the architecture and the principles are being exploited in the recent Mobile
Web initiative in W3C to promote content which can be accessed optimally from
conventional computers and mobile devices. New exciting areas arise every few months as
possible Semantic Web flagship applications. As new areas burst forth, the fundamental
principles remain important and are extended and adjusted. At the same time, the principles
of openness and consensus among international stakeholders which the WWW Consortium
(W3C) employs for new technology are adjusted, but ever-important.

Como conclusión final, hay que resaltar que el acceso o consulta a múltiples sitios Web con datos heterogéneos y
diferentes niveles de estructuración, como hoy se precisa en la Web, es un problema complejo abierto a la
investigación y cuya solución inteligente y eficaz requiere de nuevos conceptos y técnicas sobre los que aún queda
mucho camino por andar.

VII.6 Referencias Bibliográficas.

[Abit97] 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.
[ArMe98] Arocena G. and Mendelzon A., WebOQL: Restructuring Documents, Databases and Webs, Proc. of 14th
Int. Conf. on Data Engineering (ICDE98), Florida, 1998.
[BCGP92] Tim Berners-Lee, Robert Cailliau, Jean-François Groff, Bernd Pollermann: World-Wide Web: The
Information Universe. Electronic Networking: Research, Applications and Policy 1(2): 74-82 (1992)
[BeCG92] Tim Berners-Lee, Robert Cailliau, Jean-François Groff: The World-Wide Web. Computer Networks and
ISDN Systems 25(4-5): 454-459 (1992)
[Bern97] Tim Berners-Lee: World-Wide Computer. Commun. ACM 40(2): 57-58 (1997)
[Bern05] Tim Berners-Lee: WWW at 15 years: looking forward. WWW 2005: 1
[BDFS97] 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.
[CoBV93] Carmen Costilla, M. J. Bas, J. Villamor: SIRIO: A Distributed Information System over a Heterogeneous
Computer Network. ACM SIGMOD RECORD, 22(1): 28-33, 1993.
[Cost99] C.Costilla, Sistemas de Bases de Datos. Conceptos, Técnicas y Lenguajes, ISBN: 84-7402-271-1, 464
páginas, Servicio de Publicaciones, ETSI Telecomunicación, 1999.
[CRCF05] Calleja A, Rodríguez MJ, Costilla C and Fernández R., A Grid Semantic Approach for a Digital Archive
Integrated Architecture, in The Third Int. Conf. on Information Technology and Applications (ICITA'05),
Session: Agent, Datamining and Ontologies, ADO'05, Sydney, ISBN: 0-7695-2316-1, IEEE Computer
Society, USA, pp. 227-232, July 2005.
[CRPC05] Costilla C, Rodríguez MJ, Palacios JP, Cremades J, Calleja A and Fernández R, A Contribution to Web
Digital Archive Integration from the Parliamentary Management System ‘SIAP’, in ‘Frontiers in Artificial
Intelligence and Applications, Data Bases and Information Systems’. Selected papers from the Sixth Int.
Baltic Conference DB&IS'2004, Vol. 118, Barzdins J. and Caplinskas A. (eds), ISBN: 1-58603-485-5, IOS
Press, The Netherlands, pp. 273-287, 2005.
[DoDi99] 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.
[EiMe00] Eisenberg A. and Melton J., SQL Standardization: The Next Steps, in ACM SIGMOD Record, 29(1), 2000.
[FlLM98] Florescu D., Levy A. and Medelzon A., Database Techniques for the World Wide Web: A Survey, SIGMOD
RECORD, September, 1998.
[GoEi01] Goodman, D., Eich, B., JavaScript Bible”, 4th Edition, Hungry Minds Inc., 2001.
[GoWi97] 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.
[ISO89] Information Systems -Open Systems - Remote Database Access. ISO/JTC 1/SC 21, 1989.
[ISOa99] ISO/IEC 9075-1:1999, ‘Information Technology - Database language - SQL - Part 1: Framework
(SQL/Framework), 1999.

28 Madrid, Diciembre de 2010


DIT-ETSIT-UPM Bases de Datos Curso 2010-11
TemaVII Arquitecturas de los SGBD en la Distribución Por: Carmen Costilla
[ISOb99] ISO/IEC 9075-2:1999, ‘Information Technology - Database language - SQL - Part 2: Foundation
(SQL/Foundation), 1999.
[ISOc99] ISO/IEC 9075-3:1999, ‘Information Technology - Database language - SQL - Part 3: Call Level Interface
(SQL/CLI), 1999.
[ISOd99] ISO/IEC 9075-4:1999, ‘Information Technology - Database language - SQL - Part 4: Persistent Stored
Modules (SQL/PSM), 1999.
[LiAb87] W. Litwin and A. Abdellatif, An overview of the Multidatabases Manipulation Language - MDL, Proc. IEEE,
Vol. 75, Nº 5, pp. 621-631, May 1987.
[MeMM97] Mendelzon A., Mihaila G. and Milo T., Querying the World Wide Web, J. of Digital Libraries, Vol. 1, N. 1,
1997.
[Or9i01] ORACLE 9i, SQL Reference, disponible en: http://technet.oracle.com/doc, June 2001
[OzVa99] Özsu T. and Valduriez P., Principles of Distributed Database Systems, 2nd edition, Prentice Hall, 1999.
[PaGW95] 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.
[RoCC06] Ramses Rodríguez, Carmen Costilla, Antonio Calleja: A Topic-based approach to express dynamic
capabilities of Semantic WS-Resources, Int. Conf. on Internet and Web Applications and Services,
AICIT/ICIW 2006, track: Web Services-based Systems and Applications (WEBSA 2006), IEEE Computer
Society, USA, ISBN: 0-7695-2522-9, On page(s): 181- 181, Digital Object Identifier: 10.1109/AICT-
ICIW.2006.39, 2006.
[TRCH05] Philippe Thiran, Tore Risch, Carmen Costilla, Jean Henrard, Thomas Kabisch, Johan Petrini, Willem-Jan van
den Heuvel, Jean-Luc Hainaut: Report on the workshop on wrapper techniques for legacy data systems.
SIGMOD Record, 34(3): 85-86, 2005.
[Wied92] Gio Wiederhold (1992). Mediators in the Architecture of Future Information Systems. IEEE
Computer, 25(3):38–49.
[Wied99] Gio Wiederhold: Meditation to Deal with Heterogeneous Data Sources. INTEROP 1999: 1-16

29 Madrid, Diciembre de 2010

Vous aimerez peut-être aussi