DocsTec-1100

Vista previa del material en texto

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS 
SUPERIORES DE MONTERREY 
 
CAMPUS MONTERREY 
 
 
PROGRAMA DE GRADUADOS EN ELECTRÓNICA, 
COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES 
 
 
 
 
DISTRIBUCIÓN DE DATOS 
PARA BASES DE DATOS DISTRIBUIDAS, 
UNA ARQUITECTURA BASADA EN 
COMPONENTES DE SOFTWARE 
 
 
TESIS 
 
 
PRESENTADA COMO REQUISITO PARCIAL PARA OBTENER 
EL GRADO ACADEMICO DE: 
 
MAESTRÍA EN CIENCIAS EN 
TECNOLOGÍA INFORMÁTICA 
 
POR: 
 
FRANCISCO ÁLVAREZ CAVAZOS 
 
 
MONTERREY, NUEVO LEÓN, MÉXICO. MAYO 2003. 
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS 
SUPERIORES DE MONTERREY 
 
CAMPUS MONTERREY 
 
DIVISIÓN DE ELECTRÓNICA, COMPUTACIÓN, 
INFORMACIÓN Y COMUNICACIONES 
 
PROGRAMA DE GRADUADOS EN ELECTRÓNICA, 
COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES 
 
 
Los miembros del comité de tesis recomendamos que la presente tesis del Ing. Francisco 
Álvarez Cavazos sea aceptada como requisito parcial para obtener el grado académico de 
Maestro en Ciencias en Tecnología Informática. 
 
 
Comité de Tesis: 
 
 
 
_________________________________________ 
Juan Carlos Lavariega Jarquín, PhD. 
Asesor 
 
 
_________________________________________ 
Lorena Guadalupe Gómez Martínez, PhD. 
Sinodal 
 
 
_________________________________________ 
José Ignacio Icaza Acereto, PhD. 
Sinodal 
 
 
 
_________________________________________ 
David Alejandro Garza Salazar, PhD. 
Director del Programa de Graduados en Electrónica, 
Computación, Información y Comunicaciones. 
 
 
Mayo 2003 
DISTRIBUCIÓN DE DATOS 
PARA BASES DE DATOS DISTRIBUIDAS, 
UNA ARQUITECTURA BASADA EN 
COMPONENTES DE SOFTWARE 
 
 
 
 
 
POR: 
 
FRANCISCO ÁLVAREZ CAVAZOS 
 
 
 
 
 
TESIS 
 
 
 
 
 
Presentada al Programa de Graduados en Electrónica, Computación, 
Información y Comunicaciones. 
 
 
 
Este trabajo es requisito parcial para obtener el grado de 
Maestro en Ciencias en Tecnología Informática 
 
 
 
 
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS 
SUPERIORES DE MONTERREY 
 
CAMPUS MONTERREY 
 
 
 
MAYO 2003
Dedicatoria 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
A mi hermana Yvett y a mis hermanos Eduardo y Gerardo, por ser mis compañeros más 
cercanos en esta aventura de crecimiento espiritual; 
 
 
A mi madre por ser mi maestra en la caridad; 
 
 
A mi padre por enseñarme a buscar la verdad; y 
 
 
A ti Señor Jesús; Luz, Alegría y Caridad del mundo. 
 
iv 
Agradecimientos 
 
 
 
 
 
 
 
 
 
 
 
Agradezco a mi familia por la compañía, apoyo y atenciones que me dedicaron durante 
estos estudios de posgrado; 
 
 
A mis amigos Maximiliano Canché y Roger H. Castillo con quienes tuve la oportunidad de 
trabajar en el desarrollo de este proyecto. Gracias por brindarme su tiempo y amistad; 
 
 
A la Dra. Lorena Guadalupe Gómez Martínez y al Dr. José Ignacio Icaza Acereto por el 
interés y apoyo que dieron a este trabajo de tesis; 
 
 
Al Dr. Juan Carlos Lavariega Jarquín, asesor de esta tesis, por su valiosa ayuda y 
acertadas recomendaciones que me permitieron realizar una mejor investigación; y 
 
 
A todos aquéllos que fueron mis maestros y compañeros durante el curso de este posgrado. 
Sus enseñanzas hicieron posible el desarrollo de este trabajo. 
 
 
¡Muchas gracias! 
 
v 
Resumen 
 
El procesamiento de datos distribuidos es una necesidad que hoy en día muchas empresas 
tratan de satisfacer. Sin embargo, con frecuencia las organizaciones tienen problemas para 
encontrar un producto de software que les proporcione la solución que requieren. Este 
hecho parecería estar fuera de lugar en un mundo donde la tecnología de redes se ha vuelto 
una constante. Sin embargo, a pesar de que ya se cuenta con la infraestructura tecnológica 
requerida para el proceso de información distribuida, existen varios factores que han 
obstaculizado el desarrollo de software capaz de satisfacer estas necesidades. Uno de estos 
factores es la complejidad inherente que presenta el acceso a la información distribuida. 
Esto ha provocado que la mayor parte de las aplicaciones de base de datos se enfoquen a 
proporcionar acceso distribuido a una base de datos centralizada. 
 
Este trabajo de tesis propone una arquitectura genérica basada en componentes de la 
distribución de datos de un sistema de bases de datos distribuidas. A partir de la 
arquitectura propuesta es posible construir software capaz de proporcionar acceso 
distribuido a la información contenida en un conjunto distribuido de bases de datos. 
 
La arquitectura propuesta ha sido validada mediante su implementación en software. El 
prototipo de software resultado de la implementación provee un esquema global conceptual 
de la información almacenada en una base de datos distribuida, con lo cual la información 
es accedida como si perteneciera a una sola base de datos. 
 
El presente trabajo de tesis describe la arquitectura propuesta a nivel sistema y a nivel 
componente. Además, proporciona una guía para la implementación de dicha arquitectura. 
Resultando en las siguientes aportaciones: 
 
• Una arquitectura basada en componentes de la distribución de datos de un sistema 
de bases de datos distribuidas; 
• La arquitectura de los componentes de software requeridos; 
• Observaciones de implementación de la arquitectura propuesta; y 
• Código fuente de esta implementación que puede ser reutilizado en otras 
aplicaciones. 
 
Otra aportación del presente trabajo de tesis es el hecho de que se retoman y actualizan 
conceptos de bases de datos distribuidas con frecuencia descartados por las aplicaciones de 
bases de datos actuales. 
vi 
Contenido 
 
Dedicatoria ............................................................................................................................ iv 
Agradecimientos..................................................................................................................... v 
Resumen ................................................................................................................................vi 
Contenido .............................................................................................................................vii 
Lista de Figuras ...................................................................................................................... x 
Lista de Tablas.....................................................................................................................xiii 
Capítulo 1. Introducción......................................................................................................... 1 
1.1 Antecedentes................................................................................................................. 1 
1.2 Objetivo del proyecto de tesis ...................................................................................... 1 
1.2.1 Arquitectura del D-DBS ........................................................................................ 2 
1.2.2 Componentes del D-DBS ...................................................................................... 3 
1.2.3 Implementación ..................................................................................................... 3 
1.3 Justificación.................................................................................................................. 4 
1.4 Alcance del proyecto de tesis ....................................................................................... 4 
1.5 Organización del documento de tesis ........................................................................... 4 
Capítulo 2. Marco Teórico ..................................................................................................... 7 
2.1 Introducción a la arquitectura de un D-DBS ................................................................ 7 
2.2 Bases de datos distribuidas ........................................................................................... 7 
2.2.1 Modelación de datos.............................................................................................. 9 
2.2.2 Fragmentaciónde datos ....................................................................................... 10 
2.3 Arquitecturas de software........................................................................................... 11 
2.3.1 Modelos de una aplicación de base de datos ....................................................... 13 
2.4 Componentes de software........................................................................................... 16 
2.5 SQL............................................................................................................................. 18 
2.6 UML ........................................................................................................................... 19 
2.7 Software...................................................................................................................... 20 
2.7.1 Características de los sistemas distribuidos......................................................... 21 
2.7.2 Sistema operativo ................................................................................................ 21 
2.7.3 Base de datos ....................................................................................................... 21 
2.7.4 Plataforma de implementación ............................................................................ 22 
2.8 Conclusión.................................................................................................................. 23 
Capítulo 3. Arquitectura del D-DBS .................................................................................... 25 
3.1 Importancia de la distribución de datos en un D-DBS ............................................... 25 
3.2 Dimensiones de una arquitectura de referencia.......................................................... 26 
3.3 Arquitectura estructural del D-DBS ........................................................................... 27 
3.4 Arquitectura basada en datos del D-DBS................................................................... 29 
3.5 Arquitectura basada en funciones del L-DBMS......................................................... 31 
3.5.1 Un API de acceso a base de datos ....................................................................... 32 
3.5.2 Funciones del API de acceso a base de datos...................................................... 32 
3.5.3 Operaciones SIDU............................................................................................... 33 
3.6 Arquitectura basada en componentes del D-DBMS................................................... 34 
3.6.1 Secuencia de ejecución de una operación de datos (Data SIDU)........................ 36 
3.6.2 Secuencia de ejecución de una operación de esquema (Schema SIDU) ............. 36 
vii 
3.6.3 GD/D-DB – Global directory/dictionary database .............................................. 37 
3.6.3.1 GCS – Global conceptual schema ................................................................ 38 
3.6.3.2 GLI – Global lock information..................................................................... 43 
3.7 Conclusión.................................................................................................................. 48 
Capítulo 4. Componentes del D-DBS .................................................................................. 49 
4.1 API de acceso a base de datos .................................................................................... 49 
4.1.1 Operaciones SIDU............................................................................................... 49 
4.1.2 Data SIDU ........................................................................................................... 49 
4.1.3 Schema SIDU ...................................................................................................... 54 
4.1.4 Implementación de las operaciones SIDU........................................................... 62 
4.1.5 Acceso a las operaciones SIDU........................................................................... 64 
4.2 Un API remoto mediante el uso de proxies................................................................ 66 
4.3 Componente L-DBMS................................................................................................ 71 
4.4 Servidor L-DBMS ...................................................................................................... 72 
4.5 Componentes del D-DBMS........................................................................................ 73 
4.5.1 Componente GUI................................................................................................. 73 
4.5.2 Componente GSC................................................................................................ 80 
4.5.3 Componente GTM............................................................................................... 83 
4.5.4 Componente GQD ............................................................................................... 89 
4.5.5 Componente GD/D.............................................................................................. 93 
4.6 Componente D-DBMS ............................................................................................... 99 
4.7 Servidor D-DBMS.................................................................................................... 101 
4.8 Cliente D-DBMS ...................................................................................................... 102 
4.9 Implementación del D-DBS ..................................................................................... 104 
4.10 Conclusión.............................................................................................................. 106 
Capítulo 5. Implementación ............................................................................................... 107 
5.1 Componentes del D-DBS ......................................................................................... 107 
5.1.1 API de acceso a base de datos ........................................................................... 107 
5.1.2 Un API remoto mediante el uso de proxies....................................................... 107 
5.1.3 Componente L-DBMS....................................................................................... 110 
5.1.4 Cliente L-DBMS ............................................................................................... 111 
5.1.5 Paquete common del D-DBMS......................................................................... 112 
5.1.6 Componente GUI............................................................................................... 119 
5.1.7 Componente GSC.............................................................................................. 123 
5.1.8 Componente GTM............................................................................................. 123 
5.1.9 Componente GQD ............................................................................................. 126 
5.1.10 Componente GD/D.......................................................................................... 132 
5.1.11 Componente D-DBMS .................................................................................... 132 
5.1.12 Cliente D-DBMS ............................................................................................. 133 
5.2 Casos de prueba........................................................................................................ 134 
5.3 Estadísticas de la implementación............................................................................ 135 
5.4 Conclusión................................................................................................................ 137 
Capítulo 6. Conclusiones.................................................................................................... 138 
Apéndices ...........................................................................................................................140 
A. Ventajas y desventajas de diferentes modelos arquitectónicos ................................. 140 
B. SQL para crear el esquema del GD/D........................................................................ 141 
C. Código fuente............................................................................................................. 143 
viii 
C.1 dbapi ................................................................................................................. 143 
C.2 L-DBMS .............................................................................................................. 188 
C.3 GSC...................................................................................................................... 190 
C.4 GTM..................................................................................................................... 194 
C.5 GQD..................................................................................................................... 197 
C.6 GD/D.................................................................................................................... 199 
C.7 D-DBMS.............................................................................................................. 206 
D. Ejemplos de operaciones SIDU................................................................................. 212 
E. Operación Select Join................................................................................................. 214 
F. Operaciones SIDU del D-DBS................................................................................... 218 
G. Casos de prueba ......................................................................................................... 219 
Referencias ......................................................................................................................... 235 
Vita ..................................................................................................................................... 238 
 
 
ix 
Lista de Figuras 
 
Figura 2.1: La idea del esquema global conceptual................................................................ 8 
Figura 2.2: Fragmentación horizontal. ................................................................................. 10 
Figura 2.3: Fragmentación vertical....................................................................................... 10 
Figura 2.4: Fragmentación mixta. ........................................................................................ 11 
Figura 2.5: El modelo de la aplicación de base de datos de dos capas................................. 13 
Figura 2.6: El modelo de la aplicación de base de datos de N capas. .................................. 14 
Figura 2.7: El mecanismo de fragmentación a manera de middleware................................ 14 
Figura 2.8: El mecanismo de fragmentación de datos.......................................................... 15 
Figura 3.1: Relación entre los problemas de diseño de un D-DBMS. ................................. 26 
Figura 3.2: Arquitectura cliente–servidor de 3 capas del D-DBS. ....................................... 28 
Figura 3.3: Arquitectura ANSI/SPARC. .............................................................................. 29 
Figura 3.4: Arquitectura datalógica del D-DBS. .................................................................. 30 
Figura 3.5: L-DBMS como un API de acceso a datos remotos............................................ 31 
Figura 3.6: Arquitectura basada en componentes del D-DBS.............................................. 35 
Figura 3.7: Definición de las tablas GD/D-GCS. ................................................................. 39 
Figura 3.8: Modelo de datos del GD/D-GCS. ...................................................................... 40 
Figura 3.9: Definición de las tablas GD/D-GLI. .................................................................. 44 
Figura 3.10: Modelo de datos del GD/D-GLI. ..................................................................... 44 
Figura 3.11: Matriz de compatibilidad de los tipos de bloqueo. .......................................... 46 
Figura 4.1: Jerarquía de las operaciones Data SIDU............................................................ 50 
Figura 4.2: Clase QueryResult. ...................................................................................... 51 
Figura 4.3: Interfaz Select................................................................................................ 52 
Figura 4.4: Interfaz Insert................................................................................................ 53 
Figura 4.5: Interfaz Delete................................................................................................ 53 
Figura 4.6: Interfaz Update................................................................................................ 54 
Figura 4.7: Jerarquía de las operaciones Schema SIDU....................................................... 55 
Figura 4.8: Interfaz DBMetaData. ..................................................................................... 55 
Figura 4.9: Clase DBTable. ................................................................................................ 57 
Figura 4.10: Clase DBColumn............................................................................................. 59 
Figura 4.11: Interfaz CreateTable.................................................................................. 60 
Figura 4.12: Interfaz AlterTable. ................................................................................... 61 
Figura 4.13: Implementación de las operaciones Data SIDU. ............................................. 63 
Figura 4.14: Implementación de las operaciones Schema SIDU. ........................................ 63 
Figura 4.15: Implementación de la fábrica de operaciones SIDU........................................ 64 
Figura 4.16: Interfaz DBConnection. .............................................................................. 65 
Figura 4.17: Clase DBConnectionImplementation. ................................................ 66 
Figura 4.18: Proxies de las operaciones Data SIDU. ........................................................... 67 
Figura 4.19: Clase abstracta SQLOperationProxy........................................................ 68 
Figura 4.20: Interfaz RemoteSQLOperation. ................................................................ 68 
Figura 4.21: Implementación remota de las operaciones Data SIDU. ................................. 68 
Figura 4.22: Clase abstracta SQLOperationImplementation. ................................. 69 
Figura 4.23: Proxies de las operaciones Schema SIDU. ...................................................... 69 
x 
Figura 4.24: Clase abstracta SQLSchemaOperationProxy. ........................................ 70 
Figura 4.25: Interfaz RemoteSQLSchemaOperation................................................... 70 
Figura 4.26: Implementación remota de las operaciones Schema SIDU. ............................ 70 
Figura 4.27: Clase abstracta SQLSchemaOperationImplementation.................... 70 
Figura 4.28: Implementación del L-DBMS.......................................................................... 72 
Figura 4.29: Interfaz LDBMS. ............................................................................................... 72 
Figura 4.30: Componente L-DBMS. .................................................................................... 72 
Figura 4.31: Servidor L-DBMS............................................................................................ 73 
Figura 4.32: Interfaz CreateTable (D-DBMS)............................................................... 75 
Figura 4.33: Composición de la clase DBTable (D-DBMS).............................................. 76 
Figura 4.34: Clase DBFragment........................................................................................77 
Figura 4.35: Secuencia de ejecución de una operación Data SIDU. .................................... 78 
Figura 4.36: Secuencia de ejecución de una operación Schema ID. .................................... 79 
Figura 4.37: Componente GUI. ............................................................................................ 80 
Figura 4.38: Implementación del componente GSC. ........................................................... 81 
Figura 4.39: Clase GSC......................................................................................................... 82 
Figura 4.40: Componente GSC. ........................................................................................... 83 
Figura 4.41: Clase GTM......................................................................................................... 84 
Figura 4.42: Composición de la clase LockObject.......................................................... 85 
Figura 4.43: Clase LockObject........................................................................................ 86 
Figura 4.44: Clase Restriction. .................................................................................... 88 
Figura 4.45: Componente GTM. .......................................................................................... 89 
Figura 4.46: Clase GQD......................................................................................................... 90 
Figura 4.47: Composición de la clase GQDOperations. ................................................. 91 
Figura 4.48: Clase GQDOperations................................................................................. 91 
Figura 4.49: Clase OperationThread............................................................................ 92 
Figura 4.50: Componente GQD. .......................................................................................... 92 
Figura 4.51: Clase GDD......................................................................................................... 94 
Figura 4.52: Composición de la clase GDD. ......................................................................... 96 
Figura 4.53: Clase GDDTables. ......................................................................................... 96 
Figura 4.54: Clase DBParameters. .................................................................................. 97 
Figura 4.55: Componente GD/D. ......................................................................................... 98 
Figura 4.56: Interfaz DBConnection del componente GUI............................................. 99 
Figura 4.57: Implementación del D-DBMS. ...................................................................... 100 
Figura 4.58: Interfaz DDBMS. ............................................................................................. 100 
Figura 4.59: Componente D-DBMS................................................................................... 101 
Figura 4.60: Servidor D-DBMS. ........................................................................................ 102 
Figura 4.61: Cliente D-DBMS. .......................................................................................... 103 
Figura 4.62: Implementación de la arquitectura basada en componentes del D-DBS. ...... 105 
Figura 5.1: Proxy de la operación Select............................................................................ 109 
Figura 5.2: Implementación de la operación Select. .......................................................... 109 
Figura 5.3: Implementación del L-DBMS en RMI. ........................................................... 110 
Figura 5.4: Clase Tuple.................................................................................................... 114 
Figura 5.5: Clase Relation............................................................................................. 116 
Figura 5.6: Clases derivadas de la operación Select........................................................... 121 
xi 
Figura 5.7: Implementación del D-DBMS en RMI............................................................ 133 
Figura 5.8: Tamaño relativo de los componentes del D-DBS............................................ 136 
Figura 5.9: Tamaño relativo de los componentes del D-DBMS. ....................................... 136 
 
 
 
xii 
Lista de Tablas 
 
Tabla 3.1: Campos de la tabla TABLES. ............................................................................. 40 
Tabla 3.2: Campos de la tabla FIELDS................................................................................ 40 
Tabla 3.3: Campos de la tabla CONSTRAINTS.................................................................. 40 
Tabla 3.4: Campos de la tabla CONSTRAINT_FIELDS..................................................... 41 
Tabla 3.5: Campos de la tabla FRAGMENTATION_KEYS............................................... 41 
Tabla 3.6: Campos de la tabla FRAGMENTS. .................................................................... 41 
Tabla 3.7: Campos de la tabla FRAGMENTATION_CRITERIA....................................... 41 
Tabla 3.8: Campos de la tabla FRAGMENT_ALLOCATION............................................ 42 
Tabla 3.9: Campos de la tabla LOCK_TABLES. ................................................................ 45 
Tabla 3.10: Campos de la tabla LOCK_FIELDS. ................................................................ 45 
Tabla 3.11: Campos de la tabla RESTRICTION_FIELDS.................................................. 45 
Tabla 4.1: Ejemplos de las llamadas SQL de las operaciones Data SIDU........................... 50 
Tabla 4.2: Ejemplos de las llamadas SQL de las operaciones Schema SIDU...................... 54 
Tabla 5.1: Estadísticas LOC de la implementación del D-DBS......................................... 135 
 
 
 
 
xiii 
Capítulo 1. Introducción 
 
Este capítulo es una introducción a este trabajo de tesis. A continuación se presentan los 
antecedentes, el objetivo y el alcance del proyecto de tesis. También se incluye una 
justificación del tema de tesis y una breve descripción del contenido de este documento. 
 
1.1 Antecedentes 
 
El procesamiento de datos distribuidos es una necesidad que hoy en día muchas empresas 
tratan de satisfacer. Sin embargo, con frecuencia las organizaciones tienen problemas para 
encontrar un producto de software que les proporcione la solución que requieren. Este 
hecho parecería estar fuera de lugar en un mundo donde la tecnología de redes se ha vuelto 
una constante. 
 
A pesar de que ya se cuenta con la infraestructura tecnológica requerida para el proceso de 
información distribuida, existen varios factores que han obstaculizado el desarrollo de 
software capaz de satisfacer estas necesidades. Uno de estos factores es la complejidad 
inherente que presenta el acceso a la información distribuida. Esta complejidad se 
manifiesta en una serie de problemas que demandan una mayor investigación. Estos 
problemas son [Özsu & Valduriez, 1991; pp. 17-18]: 
 
1. La necesidad de modelos de desempeño, metodologías y análisis de benchmark para 
un mejor entendimiento de los algoritmos y mecanismos de la tecnología de bases 
de datos distribuidas; 
2. El procesamiento de consultas distribuidas; 
3. Modelos transaccionales avanzados que reflejen el tipo de procesamiento requerido 
por las aplicaciones distribuidas; 
4. Análisis de la replicación y su impacto en la arquitectura de un sistema de bases de 
datos distribuidas; 
5. Estrategias de implementación de software D-DBMS que contemplen una mejor 
interfaz y comunicación con sistemas operativos distribuidos; 
6. Metodologías teóricamente completas, correctas y aplicables para el diseño de bases 
de datos distribuidas; y 
7. El conjunto de problemas implicado en la intercomunicación de sistemas autónomos 
de proceso de datos. 
 
Esta serie de problemas ha provocado que la mayor parte de las aplicaciones de base dedatos se enfoquen a proporcionar acceso distribuido a una base de datos centralizada como 
una alternativa relativamente más simple a la creación de un sistema de bases de datos 
distribuidas. 
 
1.2 Objetivo del proyecto de tesis 
 
El objetivo de esta tesis es formular una arquitectura genérica basada en componentes de la 
distribución de datos de un sistema de bases de datos distribuidas. Con el fin de que a partir 
1 
dicha arquitectura sea posible construir software capaz de proporcionar acceso distribuido a 
la información contenida en un conjunto distribuido de bases de datos. La arquitectura 
propuesta se valida mediante su implementación en software. El prototipo de software 
resultado de la implementación provee un esquema global conceptual de la información 
almacenada en una base de datos distribuida, con lo cual la información es accedida como 
si perteneciera a una sola base de datos. 
 
El presente trabajo de tesis tiene por objetivo la descripción de la arquitectura propuesta a 
nivel sistema y a nivel componente. Adicionalmente, proporciona una guía para la 
implementación de la arquitectura. 
 
De tal forma, las aportaciones de esta tesis son: 
 
• Una arquitectura basada en componentes de la distribución de datos de un sistema 
de bases de datos distribuidas; 
• La arquitectura de los componentes de software requeridos; y 
• Observaciones de implementación de la arquitectura propuesta. 
 
Con estas aportaciones se contribuye a un mejor entendimiento de la complejidad inherente 
del acceso a información distribuida ya que en ellas se tratan algunos de los problemas 
asociados con esta complejidad (ver sección 1.1), en particular: 
 
• En las observaciones de implementación de la arquitectura propuesta se incluye el 
detalle de algoritmos empleados con sus respectivos análisis de complejidad (ver 
problema 1). 
• La arquitectura propuesta incluye un componente encargado de realizar las 
consultas distribuidas (ver problema 2). Este componente, llamado GQD, será 
descrito en los capítulos 3, 4 y 5. 
• Las observaciones de implementación de la arquitectura propuesta, incluidas en el 
capítulo 5, son una guía para la implementación de un D-DBS compuesto de un 
servidor D-DBMS, un conjunto de servidores L-DBMS y los clientes globales (ver 
problema 5) previamente descritos en los capítulos 3 y 4. 
• Se propone un modelo de datos para el diseño del esquema de una base de datos 
distribuida (ver problema 6) en las secciones 3.6.3.1 y 3.6.3.2. 
• Se incluye un modelo de comunicación de sistemas autónomos de proceso de datos 
(ver problema 7) que comprende el acceso remoto a un API de acceso a base de 
datos mediante objetos smart proxies [Wilson, 2000]. Este modelo de comunicación 
es descrito en los capítulos 3, 4 y 5. 
 
Es posible categorizar los objetivos específicos de este trabajo de tesis a partir de sus 
aportaciones generales, como se muestra a continuación. 
 
1.2.1 Arquitectura del D-DBS 
 
Se propone una arquitectura basada en componentes como una alternativa a la arquitectura 
monolítica de un DBMS tradicional. Entendiendo por arquitectura monolítica a la de un 
2 
DBMS integrado cuyas partes se encuentran conectadas dependiendo unas de otras a tal 
grado que no es fácil hacerle modificaciones o extensiones al sistema [Geppert & Dittrich, 
2000; pp. 7]. 
 
La arquitectura propuesta será descrita desde los siguientes puntos de vista: 
 
1. Estructural; 
2. Basado en datos; y 
3. Basado en componentes. 
 
Los tres enfoques son utilizados para describir la arquitectura propuesta ya que cada uno de 
ellos hace énfasis en un aspecto diferente de la arquitectura y todos son requeridos para 
crear una definición completa de una arquitectura de referencia (sección 3.2). 
 
1.2.2 Componentes del D-DBS 
 
En este trabajo de tesis se propone una arquitectura genérica basada en componentes de la 
distribución de datos de una base de datos distribuida y con ello se pretende comprobar que 
es posible describir sistemas de software similares por medio de arquitecturas genéricas 
incrementadas y completadas por componentes 
 
Para cumplir con este objetivo, los componentes propuestos deberán: 
 
1. Ser funcionales; 
2. Ser reutilizables; 
3. Proveer una descripción clara de su propósito; y 
4. Proveer una descripción clara de sus interfaces. 
 
El primer criterio, la funcionalidad de los componentes, permite validar la eficacia del 
diseño propuesto. Este trabajo de tesis realiza esta validación mediante casos de prueba 
realizados a un prototipo de software creado a partir de la arquitectura de referencia. Estos 
casos de prueba se incluyen en el apéndice G. El resto de los criterios son, por definición, 
metas del diseño de componentes de software. Al cumplir con estos criterios de diseño, se 
espera que un sistema basado en la arquitectura propuesta facilite la adición o reemplazo de 
sus componentes (sección 2.4). 
 
1.2.3 Implementación 
 
La guía para la implementación de la arquitectura propuesta tiene los siguientes objetivos: 
 
• La implementación deberá ser confiable. Para esto, debe de contar con un 
mecanismo para el manejo de errores; 
• La implementación deberá ser representativa de los componentes propuestos; 
• La implementación procurará satisfacer los objetivos de un sistema distribuido; y 
• Un enfoque académico. El código fuente deberá ser simple, legible y estar 
comentado. 
3 
1.3 Justificación 
 
El presente trabajo de tesis se enfoca en la distribución de datos de una base de datos 
distribuida porque es excelente punto de partida para la creación de una arquitectura 
genérica de un sistema de bases de datos distribuidas debido a que la solución al problema 
de la distribución de datos tiene un papel central en el diseño de un D-DBMS [Özsu & 
Valduriez, 1999; pp. 20-24]. 
 
La arquitectura propuesta se define en base a componentes debido a que la creación de una 
arquitectura de un D-DBMS basado en componentes ha sido calificada como una tarea 
compleja que sin embargo puede dar lugar a nuevas maneras de implementar aplicaciones y 
servidores de base de datos además de estandarizar los sistemas de bases de datos 
distribuidas [Geppert & Dittrich, 2000; pp. 7]. La arquitectura propuesta reduce la 
complejidad de esta tarea al ser un ejemplo de arquitectura de D-DBMS basada en 
componentes creada con la finalidad de facilitar modificaciones o extensiones a la misma. 
 
1.4 Alcance del proyecto de tesis 
 
El presente proyecto de tesis tiene el siguiente alcance: 
 
• La arquitectura propuesta considera exclusivamente a bases de datos con un modelo 
de datos relacional. 
• La arquitectura propuesta contempla un modelo de distribución de datos sin 
redundancia (modelo fragmentado). 
• El modelo fragmentado contemplado por la arquitectura propuesta comprende 
solamente criterios de fragmentación horizontal. 
• Se emplea el paradigma orientado a objetos para describir la arquitectura propuesta. 
• La arquitectura propuesta está definida en base a las operaciones SQL SELECT, 
INSERT, DELETE, UPDATE, CREATE TABLE y DROP TABLE. No se 
contempla al agrupamiento de estas operaciones en transacciones. 
• La arquitectura propuesta permite la concurrencia de las operaciones de datos 
(SELECT, INSERT, DELETE, UPDATE) pero limita la ejecución de las 
operaciones de esquema (CREATE TABLE, DROP TABLE) bajo un modo de 
usuario único. 
• La arquitectura no contempla las cláusulas de agrupamiento (GROUP BY, 
HAVING) de la operación SELECT. 
• La validez de la arquitectura propuesta se justifica mediante pruebas de concepto 
realizadas a una implementación prototipo del producto de esta investigación. 
 
1.5 Organización del documento de tesis 
 
El resto del documento de tesis presenta la siguiente organización: 
 
En el capítulo 2, “Marco teórico,” se describen los conceptos teóricos utilizados en este 
trabajo de tesis. Entre estos conceptos se incluyen nociones de arquitecturas de software, 
4 
bases de datos distribuidas, fragmentación dedatos, componentes de software y su 
aplicación en una base de datos distribuida, modelos de aplicación de sistemas de bases de 
datos, SQL, UML y el software requerido por un sistema de bases de datos distribuidas. 
 
El capítulo 3, “Arquitectura del D-DBS,” propone una arquitectura genérica de la 
distribución de datos de un sistema de bases de datos distribuidas (D-DBS) basada en 
componentes, a nivel sistema. 
 
El capítulo 4, “Componentes del D-DBS,” describe la arquitectura propuesta en el capítulo 
3 a nivel componente. Este capítulo incluye diagramas UML para la descripción de los 
componentes propuestos. 
 
El capítulo 5, “Implementación,” contiene observaciones de la implementación en software 
de la arquitectura propuesta. El contenido de este capítulo pretende facilitar el proceso de 
implementación de la arquitectura propuesta. 
 
El capítulo 6, “Conclusiones,” presenta las lecciones aprendidas durante el desarrollo de 
esta tesis, así como posibles líneas de trabajo futuro. 
 
Este documento de tesis se vale de términos técnicos en inglés con el fin de evitar la 
confusión que una traducción al español puede causar. Con este mismo propósito, en caso 
de proveer una traducción en español de un determinado término, está se dará al momento 
de citar al término original en inglés. 
 
En el documento se emplean los siguientes acrónimos: 
 
• DB: Base de datos (Database). Colección de datos almacenados según una 
determinada organización (sección 2.2). 
• DBMS: Sistema manejador de base de datos (Database Management System). 
Producto de software diseñado para ayudar en el mantenimiento y utilización de una 
base de datos (sección 2.2). 
• D-DB: Base de datos distribuida (Distributed Database, Distributed DB). 
Colección de bases de datos distribuidas a través de una red de computadoras 
interrelacionadas lógicamente (sección 2.2). 
• D-DBMS: Sistema manejador de base de datos distribuida (Distributed Database 
Management System, Distributed DBMS). Software que administra la base de datos 
distribuida y hace que su distribución sea transparente a los usuarios (sección 2.2). 
• D-DBS: Sistema de bases de datos distribuidas (Distributed Database System). 
Sistema cliente–servidor que permite que un cliente acceda a información 
almacenada en más de un servidor al mismo tiempo (sección 2.1). 
• GCS: Esquema global conceptual (Global Conceptual Schema) Representa una 
base de datos virtual cuyos datos se encuentran almacenados en distintas bases de 
datos (sección 2.2.1, sección 3.6). 
• GD/D: Directorio/diccionario de datos global (Global Directory/Dictionary) 
Componente de la arquitectura del D-DBMS propuesta. Almacena tanto al esquema 
5 
global conceptual (GCS) como a la información de los candados globales (GLI) 
(sección 3.6) en una base de datos. 
• GD/D-DB: Base de datos del directorio/diccionario de datos global (Global 
Directory/Dictionary Database). Ver acrónimo GD/D. 
• GLI: Información de los candados globales (Global Lock Information). Representa 
los parámetros de operación de las operaciones concurrentes en la base de datos 
distribuida (sección 3.6). 
• GQD: (Global Query Decomposer) Componente de la arquitectura del D-DBMS 
propuesta. Traduce las instrucciones globales en instrucciones locales utilizando la 
información del esquema global conceptual (GCS). Adicionalmente, se encarga de 
ensamblar los resultados de la ejecución de las operaciones locales y de formar una 
respuesta global (sección 3.6). 
• GSC: (Global Semantic Controller) Componente de la arquitectura del D-DBMS 
propuesta. Verifica la validez de la instrucción del usuario de acuerdo al esquema 
global conceptual (sección 3.6). 
• GTM: (Global Transaction Manager). Componente de la arquitectura del D-DBMS 
propuesta. Garantiza la sincronización de los accesos a la base de datos distribuida 
(sección 3.6). 
• GUI: (Global User Interface). Componente de la arquitectura del D-DBMS 
propuesta. Recibe los comandos del usuario y da formato a la respuesta que le es 
regresada (sección 3.6). 
• L-DB. Base de datos local (Local Database, Local DB). La base de datos de un 
nodo de la base de datos distribuida (sección 3.3). 
• L-DBMS: (Local Database Management System, Local DBMS). Componente que 
implementa un API de acceso a datos de una base de datos remota al punto de 
acceso (sección 4.3). Es parte de un nodo de la base de datos distribuida (sección 
3.3). 
• SIDU: El acrónimo SIDU proviene de las iniciales de los nombres de las 
operaciones de datos: Select, Insert, Delete y Update. La sección 3.5.3 muestra 
como corresponde a las operaciones de datos (Data SIDU) y de esquema (Schema 
SIDU). 
 
 
6 
Capítulo 2. Marco Teórico 
 
Este capítulo presenta a los conceptos teóricos utilizados en este trabajo de tesis. Entre 
estos conceptos se incluyen nociones de arquitecturas de software, bases de datos 
distribuidas, fragmentación de datos, componentes de software y su aplicación en una base 
de datos distribuida, modelos de aplicación de sistemas de bases de datos, SQL, UML y el 
software requerido por un sistema de bases de datos distribuidas. 
 
2.1 Introducción a la arquitectura de un D-DBS 
 
Cuando se desarrolla software para un problema basado en la información, la selección de 
la arquitectura a emplear está en función de la distribución que presentará la información, la 
cual depende a su vez de la naturaleza del problema y de la estrategia de solución a utilizar 
[Maciaszek, 2001; pp. 197]. Esta estrategia de solución implica la definición de procesos 
cliente, procesos servidor y procesos que se encargarán de enlazarlos (comúnmente 
denominados middleware). Se emplea el término cliente para nombrar a un proceso que 
realizará una petición a un proceso servidor. Recíprocamente, el término servidor denota a 
un proceso que atiende a las peticiones de los procesos cliente. 
 
La proximidad lógica y geográfica de los procesos cliente, servidor y del middleware es un 
factor determinante en la selección de la arquitectura a emplear. Lo más usual es que el 
proceso cliente y el proceso servidor sean ejecutados en diferentes computadoras, pero este 
no es necesariamente el caso. Es posible implementar un sistema cliente–servidor en una 
misma computadora. De tal forma, un sistema de bases de datos distribuidas (D-DBS) 
puede ser visualizado como un sistema cliente–servidor que permite que un cliente acceda a 
información almacenada en más de un servidor al mismo tiempo. La siguiente sección 
describe la composición de un sistema de bases de datos distribuidas. 
 
2.2 Bases de datos distribuidas 
 
Una base de datos (DB) es una colección de datos almacenados según una determinada 
organización [Forta, 1999; pp. 2] mientras que una sistema manejador de bases de datos 
(DBMS) es un producto de software diseñado para ayudar en el mantenimiento y 
utilización de una base de datos [Bell & Grimson, 1992; pp. 14-15]. 
 
Un DBMS típicamente provee las siguientes funciones [Bell & Grimson, 1992; pp. 15-16]: 
 
1. Mantenimiento de las estructuras físicas de datos (archivos, índices, etc.); 
2. Lenguajes para la recuperación y actualización de la información (SQL, por 
ejemplo); 
3. Facilidades para asegurar la integridad y seguridad de los datos; 
4. Acceso concurrente a múltiples usuarios; 
5. Medidas de respaldo y recuperación; 
6. Facilidades para el mantenimiento de los meta-datos, por ejemplo mediante un 
diccionario de datos o un catálogo del sistema. 
7 
7. Independencia de datos, el aislamiento de los datos físicos de la forma en que son 
percibidos por los usuarios y los programadores de aplicaciones (vista lógica); y 
8. Herramientas para el administrador del sistema de base de datos. Estas pueden 
incluir herramientas tanto para el diseño como para el monitoreo de la base de 
datos. 
 
Un sistema de bases de datos distribuidas (D-DBS) está compuesto de una base de datos 
distribuida (D-DB) y un sistema manejador de bases de datos distribuidas (D-DBMS). Una 
base de datos distribuidaes una colección de bases de datos distribuidas a través de una red 
de computadoras interrelacionadas lógicamente mientras que un sistema manejador de 
bases de datos distribuidas es el software que administra la base de datos distribuida y hace 
que su distribución sea transparente a los usuarios [Özsu & Valduriez, 1999; pp. 4]. 
 
El concepto de una base de datos distribuida implica un esquema global conceptual común 
a todos los usuarios de la misma. Este esquema permite recibir las peticiones de 
información que requieran los usuarios, localizar la información solicitada y devolverla a 
los usuarios. Como se puede apreciar en la figura 2.1, el esquema global conceptual crea la 
ilusión de la existencia de una sola base de datos a pesar de que la información se encuentra 
distribuida. 
 
A B Fb
Esquema Global Conceptual
C, D, E Fa
¿AB? ¿C? ¿F?¿DE?
 
Figura 2.1: La idea del esquema global conceptual. 
 
Dependiendo de su implementación, un D-DBS puede presentar las siguientes ventajas 
[Ceri & Pelagatti, 1983; pp. 11-12]: 
 
1. Beneficio organizacional y económico. Muchas empresas son de naturaleza 
distribuida y les resulta más conveniente poseer varias bases de datos pequeñas en 
distintas locaciones que una base de datos centralizada; 
8 
2. Crecimiento por incrementos. Es posible dotar a cada sitio de trabajo de la 
organización con su propia base de datos, misma que se convertirá en un nodo más 
de la base de datos distribuida de la organización. De este modo, la organización y el 
sistema crecen de forma simultánea; 
3. Interconexión de bases de datos existentes. En el caso de que la organización tenga 
distintas implementaciones de datos, un sistema de bases de datos distribuidas es la 
alternativa requerida para aprovechar la información de la empresa en su totalidad; 
4. Menores requerimientos de comunicación. La información puede distribuirse a través 
de los nodos de la base de datos distribuida de tal manera que esté geográficamente 
próxima a los sitios donde se requiere. Esto reduce el tráfico de información entre 
locaciones de la empresa distantes entre sí; 
5. Consideraciones de desempeño. La naturaleza de la distribución de información y 
hardware que puede implicar una base de datos distribuida permite que cada nodo del 
sistema procese la información como más le convenga. En caso de requerir un alto 
grado de desempeño, puede asignar los recursos de hardware a un nodo del sistema 
en particular; y 
6. Confiabilidad y disponibilidad. La distribución del sistema le confiere cierta 
resistencia a fallas. En el caso de una base de datos centralizada, una falla en la 
misma pondrá fin a la operación del sistema mientras que en una base de datos 
distribuida ocurrirá un fenómeno conocido como degradación, que significa que el 
sistema sigue operando, aunque no toda la información siga disponible. 
 
2.2.1 Modelación de datos 
 
Se emplea el término modelación de datos para nombrar al proceso de abstraer de los 
problemas del mundo real las entidades involucradas y las relaciones existentes entre ellas 
[Sommerville, 2000]. De tal forma, el modelo de datos describe las relaciones entre los 
datos que forman una base de datos. A partir del modelo de datos, se crea el esquema de la 
base de datos. El esquema de la base de datos es la descripción de una colección particular 
de datos. En este trabajo de tesis, se propone una arquitectura a partir de la cual es posible 
construir software capaz de proveer un esquema global conceptual (GCS) que representa 
una base de datos virtual cuyos datos se encuentran almacenados en distintas bases de 
datos. 
 
Existen tres modelos de bases de datos que han sido usados tradicionalmente. Estos son: el 
jerárquico, el de redes y el relacional. Siendo el modelo relacional el de mayor importancia 
[Bell & Grimson, 1992; pp. 18-19]. Un DBMS soporta un solo modelo de datos y dado que 
el modelo de datos afecta las características del esquema global conceptual es necesario 
señalar que este trabajo de tesis considera exclusivamente a bases de datos con un modelo 
de datos relacional. 
 
El modelo de datos relacional representa los datos a manera de tablas bidimensionales, 
compuestas de renglones y columnas. Donde las tablas reciben el nombre de relación, los 
renglones el nombre de tuplas y las columnas el de atributos. Una colección de relaciones 
conforma una base de datos relacional [Bell & Grimson, 1992; pp. 19]. 
 
9 
2.2.2 Fragmentación de datos 
 
En un sistema de bases de datos distribuidas, los datos pueden ser distribuidos con o sin 
duplicación de datos. La duplicación, o redundancia, puede ser deseable para ciertas 
aplicaciones [Buretta, 1997; pp. 40-47] en las cuales la información es accedida desde 
distintos sitios. Como se describe en la sección 2.3, la arquitectura propuesta por este 
trabajo de tesis contempla un modelo estructural cliente–servidor donde la información de 
la base de datos distribuida es accedida por a través del servidor. Este hecho hace que la 
redundancia de datos sea innecesaria y por ello este trabajo de tesis se concentra en un 
modelo de distribución de datos sin redundancia. Un modelo de distribución de datos sin 
redundancia recibe el nombre de modelo fragmentado. 
 
En un modelo fragmentado, la distribución de los datos se logra mediante particiones 
horizontales y/o verticales. Cabe señalar que esta distribución de datos ocurre sin 
redundancia de datos con excepción de las llaves primarias de las relaciones en el caso de la 
fragmentación vertical. 
 
En el modelo relacional, la fragmentación horizontal divide a una tabla en grupos de 
renglones. Por lo general, el criterio de partición es el valor presente en una o más 
columnas de la relación (ver figura 2.2). 
 
A B C D
1 B1 C1 D1
1 B2 C2 D2
A B C D
1 B1 C1 D1
1 B2 C2 D2
2 B3 C3 D3
2 B4 C4 D4 A B C D
2 B3 C3 D3
2 B4 C4 D4
Si A = 1, Sitio N
Si A = 2, Sitio M
Mecanismo de
Fragmentación
Sitio N
Sitio M
 
Figura 2.2: Fragmentación horizontal. 
 
La fragmentación vertical implica dividir una tabla en grupos de columnas. Por lo general, 
los requerimientos del esquema global conceptual dictados por la naturaleza de los datos de 
una relación y el uso que será dado a los mismos, constituyen el criterio de división (ver 
figura 2.3). 
A B
A1 B1
A2 B2
A3 B3
A4 B4
A B C D
A1 B1 C1 D1
A2 B2 C2 D2 C D
A3 B3 C3 D3 C1 D1
A4 B4 C4 D4 C2 D2
C3 D3
C4 D4
Si A o B,
Sitio N
Si C o D,
Sitio M
Mecanismo de
Fragmentación
Sitio N
Sitio M
 
Figura 2.3: Fragmentación vertical. 
10 
 
En el caso de tener un esquema global conceptual donde se presenten ambos tipos de 
fragmentación, se dice que tenemos fragmentación mixta (ver figura 2.4). 
 
A B
A1 B1
A2 B2
A B
Sitio A3 B3
V1 H1 N A4 B4
V1 H2 M
V2 H1 O
V2 H2 P
A B C D
A1 B1 C1 D1 C D
A2 B2 C2 D2 C1 D1
A3 B3 C3 D3 C2 D2
A4 B4 C4 D4
C D
C3 D3
C4 D4
Fragmento
H1
H2
V1 V2
Mecanismo de
Fragmentación
Sitio M
Sitio O
Sitio N
Sitio P
 
Figura 2.4: Fragmentación mixta. 
 
Las figuras 2.2, 2.3 y 2.4 postulan un mecanismo de fragmentación hipotético capaz de 
relacionar un esquema global conceptual con una colección de bases distribuidas. La 
arquitectura propuesta en este trabajo de tesis corresponde a un mecanismo de 
fragmentación aumentado al nivel de un D-DBMS. 
 
Cabe señalar que el grado de complejidad de este mecanismo de fragmentación aumenta de 
acuerdo al tipo de fragmentación que es capaz de administrar, lo cual resulta en una 
arquitectura de software más compleja a su vez. Este trabajo de tesis se limita a la 
arquitectura de un mecanismo de fragmentación capaz de administrar la fragmentación 
horizontal debido a que este tipo de fragmentación depende fuertemente de la información 
almacenada, en contraste con la arquitectura vertical o híbrida que depende en mayor o 
menor grado del esquema de la base de datos. Este hecho hace que la fragmentación 
horizontal sea relevante desde el punto de vista datalógico, siendo este el enfoque sugerido 
por el Database ArchitectureFramework Task Group [1986, citado por Özsu & Valduriez, 
1999; pp. 76-77] como la mejor guía para los esfuerzos de estandarización de sistemas 
DBMS ya que otorga un papel central al recurso de la información. 
 
2.3 Arquitecturas de software 
 
El software puede descomponerse en tres niveles de diseño: arquitectura, código y 
ejecutable. De estos niveles, el de arquitectura es el menos estudiado [Shaw & Garlan, 
1996; pp. 4]. 
 
11 
El nivel de arquitectura es una asociación general de las capacidades del sistema 
dimensionado en subsistemas, módulos y control de proceso [Sommerville, 2000]. Sin 
embargo, este nivel de diseño no ha sido entendido a profundidad por la ingeniería de 
software, lo cual ha ocasionado que esté representado por términos informales y 
diagramación inconsistente [Shaw & Garlan, 1996; pp. 4]. 
 
Como lo indica la definición precedente, el proceso de diseño arquitectónico puede 
dimensionarse en [Sommerville, 2000]: 
 
• Arquitectura estructural. Descompone al sistema en sub-sistemas e identifica la 
comunicación que tiene lugar entre ellos; 
• Arquitectura del control. Establece un modelo de control de las relaciones entre las 
diferentes partes del sistema; y 
• Arquitectura modular. Descompone a los sub-sistemas en módulos. 
 
Un sub-sistema es un sistema por derecho propio y su operación es independiente a la 
proporcionada por los demás sub-sistemas mientras que un módulo es un componente del 
sistema que provee servicios a otros componentes, pero que normalmente no puede ser 
considerado un sistema independiente [Sommerville, 2000]. El resto del documento de 
tesis, capítulos 3, 4 y 5, profundiza en las características de los módulos o componentes de 
un sistema D-DBS haciendo énfasis en el problema del diseño de la distribución de datos. 
 
El producto del proceso de diseño arquitectónico es una descripción o modelo de la 
arquitectura del software. Como este proceso puede ser dimensionado y dividido de la 
forma mencionada anteriormente, tiene como producto a varios modelos que representarán 
cada uno a una perspectiva diferente de una misma arquitectura de software [Sommerville, 
2000]. Una breve clasificación de los diversos modelos arquitectónicos, con sus ventajas y 
desventajas, se incluye en el apéndice A de este trabajo de tesis. 
 
En forma general, la arquitectura propuesta en este trabajo de tesis incluye: 
 
• Un modelo estructural cliente–servidor de 3 capas con un solo servidor; 
• Un modelo de control centralizado en el servidor; y 
• Un modelo modular orientado a objetos. 
 
Desde la perspectiva estructural ha sido seleccionado un modelo cliente–servidor de 3 
capas con un solo servidor dado que permite hacer un uso eficiente de los sistemas de red y 
hace que la tarea de distribución de la información sea sencilla [Sommerville, 2000], ambas 
características deseables en un sistema de bases de datos distribuidas. 
 
El modelo de control centralizado en el servidor se seleccionó con el fin de simplificar el 
código de una aplicación cliente de un D-DBMS implementado a partir de esta arquitectura. 
 
Finalmente, el modelo modular orientado a objetos ha sido seleccionado con el propósito de 
definir claramente las interfaces entre los módulos o componentes del sistema. 
 
12 
El capítulo 3 describe la arquitectura propuesta a nivel sistema, mientras que el capítulo 4 la 
describe a nivel componente. 
 
2.3.1 Modelos de una aplicación de base de datos 
 
Existen 2 modelos de aplicación de base de datos ampliamente difundidos: el modelo de 
dos capas y el modelo de N capas [Birnam, 2001; pp. 3-14]. 
 
En el modelo de dos capas, las aplicaciones clientes se comunican con el proceso servidor 
de base de datos utilizando un protocolo particular de la implementación de la base de 
datos. Prácticamente toda la lógica de la aplicación reside en el cliente. Este modelo 
presenta una arquitectura demasiado rígida para el propósito de este trabajo de tesis, pues se 
dependería totalmente de las características de comunicación remota del protocolo de 
acceso de la base de datos empleada (ver figura 2.5). 
 
Servidor de
Base de Datos
Protocolo de la base de datos
Aplicaciones Cliente 
Figura 2.5: El modelo de la aplicación de base de datos de dos capas. 
[Birnam, 2001; fig. 1-1, pp. 4] 
 
En el modelo de N capas, los clientes se comunican con una capa intermedia (middleware), 
por medio de un protocolo definido por la implementación e independiente de la base de 
datos. Esta capa intermedia es la que se encarga de mantener la conexión con la base de 
datos utilizando el protocolo de acceso de la base de datos (ver figura 2.6). 
 
13 
Capa Intermedia:
Lógica de 
Negocios,
Validación de 
Datos,
Consolidación de 
Datos
Protocolo de la
base de datos
Aplicaciones Cliente:
Lógica de la Aplicación,
Validación de Campos
Servidor de
Base de Datos:
Stored 
Procedures,
Triggers,
Integridad 
Referencial
 
Figura 2.6: El modelo de la aplicación de base de datos de N capas. 
[Birnam, 2001; fig. 1-2, pp. 7] 
 
Como lo implica el nombre de este modelo, pueden existir tantas capas intermedias como 
sea necesario. Las capas intermedias pueden servir de intermediario entre los clientes y una 
o más bases de datos Esta característica proporciona la flexibilidad requerida por este 
trabajo de tesis, pues la capa intermedia es capaz de alojar al mecanismo de fragmentación 
que dará lugar a la base de datos distribuida al proveer un esquema global conceptual entre 
los clientes y uno o más servidores de bases de datos (ver figura 2.7). 
 
Capa Intermedia:
Esquema Global 
Conceptual,
Mecanismo de 
Fragmentación
Servidor de
Base de Datos
Servidor de
Base de Datos
Servidor de
Base de Datos
Protocolo de la
base de datos
Aplicaciones Cliente 
Figura 2.7: El mecanismo de fragmentación a manera de middleware. 
 
Como se ha mencionado anteriormente, el modelo de aplicación correspondiente a la 
arquitectura producto de este trabajo de tesis es el modelo de aplicación de base de datos de 
3 capas, donde el mecanismo de fragmentación se aloja en la capa intermedia, es decir, es 
un middleware (ver figura 2.7). 
14 
 
La función del mecanismo de fragmentación, mostrada en la figura 2.8, consiste en: 
 
1. Recibir peticiones de los clientes globales; 
2. Traducir las peticiones de los clientes globales en términos que las bases de datos 
distribuidas puedan entender; 
3. Recibir una respuesta de las bases de datos distribuidas; 
4. Procesar la información producto del paso anterior, uniendo y ordenando las 
respuestas recibidas según sea necesario; y 
5. Proporcionar a cada cliente el resultado que solicitó. 
 
El mecanismo de fragmentación considerado en este trabajo de tesis, contempla que los 
clientes globales pueden efectuar tanto operaciones orientadas a los datos, como 
operaciones orientadas al esquema de la base de datos. Estas operaciones son descritas en 
los capítulos 3, 4 y 5. 
 
Por medio de la capa intermedia, los clientes globales podrán realizar operaciones sobre un 
esquema global conceptual, producto de la relación creada entre el mecanismo de 
fragmentación y las bases de datos (ver figura 2.8). 
 
A B C D A B
A1 B1 C1 D1 A1 B1
A2 B2 C2 D2 A2 B2
A3 B3 C3 D3
A4 B4 C4 D4
A B
A3 B3
A4 B4
C D
C1 D1
A C2 D2
A1
A2
A3
A4 C D
C3 D3
Sitio C4 D4
V1 H1 N
V1 H2 M
V2 H1 O
V2 H2 P
Fragmento
V1 V2
H1
H2
Capa Intermedia:
Esquema Global Conceptual (EGC),
Mecanismo de Fragmentación
Mecanismo de Fragmentación:
"Ligas de Base de Datos"
Base de Datos,
Sitio P
Base de Datos,
Sitio O
Base de Datos,
Sitio M
Base de Datos,
Sitio N
Esquema Global
Conceptual
¿A?
 
Figura 2.8: El mecanismo de fragmentación de datos. 
 
15 
La figura 2.8 muestra como un cliente solicita al mecanismo de fragmentación la 
información de la columna A. La columna A es parte de una relación fragmentada aunque 
este hecho es transparente al cliente. El mecanismo de fragmentación consulta un mapa de 
la localización de los datos para poder recuperar la informaciónsolicitada de las bases de 
datos involucradas. Una vez que el mecanismo de fragmentación obtiene la información de 
las bases de datos, la integra para producir una respuesta global. En el ejemplo mostrado en 
la figura 2.8 esta respuesta global es la información de la columna A. 
 
Como puede apreciarse en la figura 2.8, el mecanismo de fragmentación de datos ilustrado 
posee una base de datos que contiene un mapa de la localización de los datos. Al proceso de 
acceder información distribuida por medio de direcciones almacenadas en un directorio 
global se le conoce con el término de “ligas de base de datos.” 
 
En la arquitectura propuesta por este trabajo de tesis se contempla la existencia de una base 
de datos auxiliar donde se almacena tanto la localización de los datos como información de 
las operaciones concurrentes para garantizar la integridad de los datos distribuidos. Esta 
base de datos y sus funciones se describen en los capítulos 3, 4 y 5 de este trabajo de tesis. 
 
2.4 Componentes de software 
 
Es posible definir la arquitectura de un sistema específico como una colección de 
componentes junto con una descripción de la interacción entre dichos componentes [Shaw 
& Garlan, 1996; pp. 20]. 
 
Un componente de software es un artefacto de software que modela e implementa un 
conjunto coherente y bien definido de funciones. Un componente se compone de una 
interfaz y una implementación [Geppert & Dittrich, 2000; pp. 11] creados con el propósito 
de ser reutilizables [Jacobson et al., 1997; pp. 85]. La interfaz del componente representa el 
punto lógico de conexión entre el componente y el sistema. La interfaz debe de ocultar los 
detalles de implementación del componente y al mismo tiempo proporcionar información 
necesaria sobre sus características al resto del sistema [Molina, 2000; pp. 4]. Un 
componente es comparable con una caja negra, lo cual significa que los clientes pueden 
usarlos adecuadamente sin conocer su implementación a través de su interfaz. Es deseable 
que la interfaz y la implementación existan por separado para que puedan existir múltiples 
implementaciones para una interfaz y que las implementaciones puedan ser intercambiadas 
[Geppert & Dittrich, 2000; pp. 11]. 
 
Un componente es diseñando, empacado y documentado para ser reutilizable. Esto trae 
como consecuencia que el componente sea cohesivo y tenga una interfaz pública 
relativamente estable. El potencial de reutilización depende del alcance del componente, 
que puede ser muy general (reutilizable en mucho tipos de sistemas de aplicación) o 
limitado (específico para cierta área de negocios) [Jacobson et al., 1997; pp. 85]. Para que 
un componente tenga un alto potencial de reutilización se procura evitar la existencia de 
una gran cantidad de relaciones con otros componentes [Geppert & Dittrich, 2000; pp. 11] 
por lo que una buena parte del proceso de diseño de componentes debe de considerar como 
minimizar dichas relaciones y como dividir a un modelo en componentes reutilizables del 
16 
tamaño y estructura correctas [Jacobson et al., 1997; pp. 85]. Como parte de este trabajo de 
tesis, las relaciones entre los componentes de la arquitectura propuesta son identificadas en 
el capítulo 4 y se incluyen estadísticas referentes al tamaño de los mismos en el capítulo 5. 
 
Un componente no es útil por su propia cuenta, sino que es reutilizado conjuntamente con 
otros componentes formando así un sistema basado en componentes [Jacobson et al., 1997; 
pp. 86]. Este principio es conocido como reutilización por composición y los sistemas así 
construidos pueden ser modificados o expandidos mediante el reemplazo o la adición de 
nuevos componentes. Se espera que un sistema basado en componentes facilite la adición o 
reemplazo de los componentes sin la necesidad de recompilar (o incluso apagar) el sistema 
[Geppert & Dittrich, 2000; pp. 11]. 
 
Es posible describir sistemas de software similares por medio de arquitecturas genéricas 
incrementadas y completadas por componentes. Siendo para esto necesario que la 
arquitectura genérica subyacente esté definida en términos de componentes y conexiones de 
tal forma que sea posible añadirle componentes de forma significativa y consistente 
[Geppert & Dittrich, 2000; pp. 11]. En este trabajo de tesis se propone una arquitectura 
genérica basada en componentes de la distribución de datos de una base de datos 
distribuida. 
 
El paradigma orientado a objetos tiene muchas características que simplifican el desarrollo 
de buenos componentes, como lo son la encapsulación y el polimorfismo. Pero también 
posee elementos que, usados descuidadamente, pueden obstaculizar la meta de un 
desarrollo basado en componentes. Uno de esos mecanismos es la herencia. La herencia 
crea una fuerte dependencia entre una clase y su superclase, o un tipo y su supertipo. Lo 
que dificulta el mantenimiento de los componentes [Jacobson et al., 1997; pp. 86]. 
 
Con el fin de que el diseño de componentes no sea adversamente afectado por la fuerte 
dependencia creada por la herencia en los sistemas o modelos orientados a objetos, es 
común que los componentes posean un mayor nivel de granularidad que una clase u objeto. 
Un componente bien diseñado soporta un conjunto coherente de tareas mientras que los 
objetos y las clases típicamente comprenden solamente una fracción de dicho conjunto. 
Esto no significa que los conceptos de componente y objeto sean mutuamente excluyentes, 
más bien los componentes elevan la orientación a objetos a un nivel más alto de abstracción 
y granularidad. De hecho, los componentes con frecuencia son arreglos de objetos [Geppert 
& Dittrich, 2000; pp. 11]. 
 
En este trabajo de tesis se utilizará el paradigma orientado a objetos con el fin de 
aprovechar las características de encapsulación y polimorfismo facilitando así la creación 
de componentes y el diseño de los mismos tendrá un nivel de abstracción más elevando que 
el nivel clase-objeto para minimizar la fuerte dependencia creada por el mecanismo de la 
herencia con el propósito de crear componentes altamente reutilizables. 
 
La arquitectura basada en componentes propuesta por este trabajo de tesis pretender ser una 
alternativa a una arquitectura de D-DBMS monolítica. Entendiendo por arquitectura 
monolítica a la presentada en un sistema de software integrado cuyas partes se encuentran 
17 
conectadas dependiendo unas de otras a tal grado que no es fácil hacerle modificaciones o 
extensiones al sistema [Geppert & Dittrich, 2000; pp. 7]. 
 
Es de especial interés para este trabajo de tesis proponer una arquitectura basada en 
componentes dado que un DBMS monolítico podría presentar las siguientes desventajas 
[Castillo, 2002; pp. 8]: 
 
• El DBMS podría llegar a ser tan grande y complejo que no podría ser mantenido a 
un costo razonable; 
• Los usuarios tendrían que pagar un alto precio para adicionar funcionalidad, aún si 
ellos no requieren de la totalidad de las funciones del DBMS; y 
• Un proveedor de DBMS podría no tener la experiencia para realizar tales 
extensiones y podría no tener los recursos para comprometer todas las extensiones 
en un período de tiempo razonable. 
 
Una aportación de este trabajo de tesis es presentar una posible solución a una tarea 
considerada compleja por los autores Geppert y Dittrich. Estos autores afirman que dividir 
la funcionalidad de un DBMS en partes independientes (componentes) es un problema 
complicado porque es necesario encontrar un balance adecuado entre la granularidad de los 
servicios y el número de relaciones entre servicios. De forma similar, determinar interfaces 
adecuadas entre los servicios también es una tarea compleja [Geppert & Dittrich, 2000; pp. 
7]. A pesar de esta complejidad, los mismos autores proponen que las arquitecturas de 
DBMS basadas en componentes darán lugar a formas completamente nuevas de 
implementar aplicaciones y servidores de bases de datos. Lo cual reportará las siguientes 
ventajas: 
 
• Las aplicaciones y los servidoresde bases de datos podrán elegir al proveedor de 
servicio óptimo para sus necesidades y no dependerán de un DBMS monolítico de 
gran tamaño; y 
• En el caso de los tener servicios estandarizados, sería posible un escenario en el cual 
se mezclen servicios de diferentes proveedores. 
 
De acuerdo a Geppert y Dittrich, estas ventajas podrán ser alcanzadas sólo si estos servicios 
(las aplicaciones y los servidores de bases de datos) y sus implementaciones son descritos y 
construidos a partir de componentes de software. 
 
2.5 SQL 
 
SQL (acrónimo para Structured Query Language) es un lenguaje diseñado específicamente 
para la comunicación con bases de datos. Su objetivo es proporcionar una forma eficiente 
para leer y escribir datos en una base de datos. El estándar SQL se rige por el comité de 
estándares ANSI y con frecuencia es llamado ANSI SQL [Forta, 1999; pp. 5-6]. SQL tiene 
las siguientes ventajas [Forta, 1999; pp. 6]: 
 
• No es un lenguaje propietario utilizado por una determinada base de datos 
comercial. Prácticamente todas las bases de datos soportan SQL; 
18 
• SQL es fácil de aprender. Los estatutos están compuestos de palabras descriptivas 
en inglés; y 
• SQL es un lenguaje poderoso. A pesar de la aparente simplicidad de SQL es posible 
realizar complejas y sofisticadas operaciones de base de datos mediante el uso de 
sus elementos de lenguaje. 
 
Con el propósito de una funcionalidad extra al usuario o simplificar alguna operación 
específica, muchas bases de datos comerciales han extendido su soporte de SQL añadiendo 
estatutos o instrucciones al lenguaje. Desafortunadamente estas extensiones, con frecuencia 
muy útiles, tienden a ser específicas a un determinado DBMS y raramente son soportadas 
por más de vendedor [Forta, 1999; pp. 6]. 
 
Un testimonio del éxito de SQL es el hecho de que la mayor parte de la programación de 
base de datos es realizada por medio de estatutos SQL embebidos en el código de las 
aplicaciones. Sin embargo, a pesar de que esta técnica es conveniente y ampliamente 
difundida, con frecuencia promueve un problema de mantenimiento de código a medida 
que el esquema de la base de datos crece o cambia con el tiempo. Además, pueden llegar a 
existir diferentes versiones de SQL en varias partes del código o, lo que es peor, diferentes 
estatutos de SQL que producen el mismo resultado. Estos problemas se vuelven más 
difíciles de administrar a medida que crece el alcance de la aplicación y rápidamente se 
vuelven intratables si existen múltiples aplicaciones que usan el mismo esquema de la base 
de datos [Birnam, 2001; pp. 15-16]. Este problema está particularmente presente en las 
llamadas básicas DML (Data Manipulation Language) correspondientes a los estatutos 
SQL INSERT, DELETE y UPDATE o en las llamadas DQL (Data Query Language) 
correspondientes al estatuto SQL SELECT [Birnam, 2001; pp. 16]. 
 
Una solución al problema del SQL embebido es la construcción de un API (Application 
Program Interface) de base de datos [Birnam, 2001; pp. 16]. Un API es una colección de 
métodos de acceso a un programa, módulo o componente de software, de tal manera que la 
funcionalidad de este software pueda ser utilizada a partir de otro software independiente. 
La forma en que se accede a la funcionalidad del API es mediante llamadas a sus métodos 
de acceso [Molina, 2000; pp. 7]. Con el fin de minimizar el problema del SQL embebido, 
se incluye un API de acceso a base de datos como parte de la arquitectura propuesta basada 
en componentes. Este API se describe en los capítulos 3, 4 y 5. 
 
2.6 UML 
 
UML (Unified Modeling Language) es un lenguaje visual de propósito general para 
especificar, visualizar, construir y documentar los artefactos de un sistema de software. Es 
el lenguaje estándar de modelación del Object Management Group (OMG) desde 1997 y 
desde entonces ha sido desarrollado y ampliamente aceptado por la industria de la 
tecnología informática [Maciaszek, 2001; pp. 8]. 
 
UML es independiente de un determinado proceso de desarrollo del software. Sin embargo, 
un proceso que adopta UML debe de soportar el paradigma orientado a objetos para la 
producción de software. UML no es adecuado para el antiguo paradigma de programación 
19 
estructurada resultante del uso de lenguajes de programación orientada a procedimientos, 
como lo es COBOL [Maciaszek, 2001; pp. 8]. 
 
UML también es independiente de las tecnologías de implementación (siempre y cuando 
estas sean orientadas a objetos). Lo cual hace que UML sea algo deficiente para soportar la 
fase de diseño detallado del ciclo de desarrollo del software. Sin embargo, esta misma 
característica hace que UML sea resistente a cambios frecuentes en las plataformas de 
implementación [Maciaszek, 2001; pp. 8]. 
 
Las construcciones de lenguaje de UML permiten la modelación de la estructura estática y 
el comportamiento dinámico de un sistema. Un sistema se modela como un conjunto 
cooperativo de objetos (módulos de software) que reaccionan a eventos externos para 
realizar tareas en beneficio a sus clientes (usuarios). Los modelos individuales enfatizan 
algunos aspectos del sistema e ignoran aspectos que son enfatizados en otros modelos. 
Conjuntamente, todos los modelos proporcionan una descripción completa del sistema 
[Maciaszek, 2001; pp. 8-9]. 
 
Los modelos UML pueden clasificarse en tres grupos [Maciaszek, 2001; pp. 9]: 
 
• Modelos de estado (describen estructuras estáticas); 
• Modelos de comportamiento (describen las colaboraciones entre objetos); y 
• Modelos de cambio de estado (describen los estados válidos para el sistema). 
 
Este trabajo de tesis hará uso de UML para describir la arquitectura propuesta por las 
siguientes razones: 
 
• El que UML sea resistente a cambios frecuentes en las plataformas de 
implementación lo convierte en un lenguaje adecuado para describir una 
arquitectura genérica de software; 
• UML está construido en base al paradigma orientado a objetos por lo cual simplifica 
la descripción de los componentes de la arquitectura propuesta; y 
• UML es capaz de describir la estructura estática (arquitectura) y el comportamiento 
dinámico de un sistema como un conjunto cooperativo de objetos. 
 
Los capítulos 4 y 5 utilizan modelos UML de estado y de comportamiento para describir 
los componentes de la arquitectura propuesta. 
 
2.7 Software 
 
Este trabajo de tesis comprende una implementación en software de la arquitectura 
propuesta. El software utilizado en la implementación fue seleccionado tomando en cuenta 
las características de un sistema distribuido, como se describe a continuación. 
 
20 
2.7.1 Características de los sistemas distribuidos 
 
Los sistemas distribuidos, de los cuales las bases de datos distribuidas con un ejemplo, 
exhiben las siguientes características [Buretta, 1997; pp. 30]: 
 
• Componentes remotos. Los componentes del sistema están distribuidos 
geográficamente; 
• Concurrencia. Cualquier número de componentes pueden ejecutarse en paralelo. 
• Aislamiento de fallas. Cualquier componente puede fallar independientemente de 
los demás; 
• Mezcla heterogénea de tecnologías. El entorno usualmente contiene una mezcla de 
tecnologías que cambia lentamente con el tiempo; 
• Movilidad de los componentes. Los recursos, nodos de proceso y los usuarios son 
físicamente móviles; 
• Naturaleza asíncrona de los eventos. No puede asumirse que ocurren cambios 
relacionados en un instante determinado de tiempo; y 
• Carencia de un estado global. El estado global de un sistema distribuido no puede 
determinarse con precisión. 
 
2.7.2 Sistema operativo 
 
En un sistema de bases de datos distribuidas donde existen componentes remotos, una 
mezcla heterogénea de tecnologías y componentes móviles, es deseable que la 
implementación pueda ejecutarse en cualquier hardware y bajo cualquier sistema operativo. 
Una manera de lograr esto es mediante el uso de una máquina virtual. 
 
Con una máquina virtual es posible crear software independiente de