INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS ESTADO DE MÉXICO MANEJO DE FRAGMENTACIÓN Y REPLICACIÓN . TRANSPARENTE EN BASES DE DATOS RELACIONALES DISTRIBUIDAS TESIS PARA OPTAR EL GRADO DE MAESTRO EN CIENCIAS COMPUTACIONALES PRESENTA FRANCISCO JAVIER FLAMENCO SANDOVAL Asesor: Dr. JUAN FRANCISCO CORONA B. Comité de Tesis: Dr. JESÚS SÁNCHEZ VELÁZQUEZ MC. FRANCISCO CAMARGO SANTACRUZ Jurado: Dr. JESÚS SÁNCHEZ VELÁZQUEZ Presidente MC. FRANCISCO CAMARGO SANTACRUZ Secretario Dr. JUAN FRANCISCO CORONA BURGUEÑO Vocal Atizapán de Zaragoza, Edo. Méx., Diciembre de 1996
135
Embed
Manejo de fragmentación y replicación transparente en ...
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS ESTADO DE MÉXICO
MANEJO DE FRAGMENTACIÓN Y REPLICACIÓN . TRANSPARENTE EN BASES DE DATOS
RELACIONALES DISTRIBUIDAS
TESIS PARA OPTAR EL GRADO DE MAESTRO EN CIENCIAS COMPUTACIONALES
PRESENTA
FRANCISCO JAVIER FLAMENCO SANDOVAL
Asesor: Dr. JUAN FRANCISCO CORONA B.
Comité de Tesis: Dr. JESÚS SÁNCHEZ VELÁZQUEZ MC. FRANCISCO CAMARGO SANTACRUZ
Jurado: Dr. JESÚS SÁNCHEZ VELÁZQUEZ Presidente MC. FRANCISCO CAMARGO SANTACRUZ Secretario Dr. JUAN FRANCISCO CORONA BURGUEÑO Vocal
Atizapán de Zaragoza, Edo. Méx., Diciembre de 1996
2.1 LOS SISTEMAS DISTRIBUIDOS ...................................................................... 13 2.1.2 Generalidades .......................................................................................... 14 2.1.3 Objetivos en el Diseño de Sistemas Distribuidos .............. 15 2.1.4 El Subsistema de Comunicación .................................................. 16
2.1.4.l Parámetros de Desempeño ....................................................... 16 2.1.4.2 Requerimientos de Desempeño ............................................... 17 2.1.4.3 Requerimientos de Confiabilidad ............................................ 17 2.1.4.4 Tipos de Redes .............................................................................. 17 2.1.4.5 Los Paquetes .................................................................................. 18 2.1.4.6 El Trabajo entre Redes ............................................................... 18
2.1.5 Comunicación entre Procesos ....................................................... 18 2.1.5.1 El Paradigma Cliente Servidor ................................................. 19 2.1.5.2 Llamadas a Procedimientos Remotos ..................................... 19
2.1.6 La Coordinación entre Procesos ................................................ 19
2.1.7 Transacciones ........................................................................................ 20 2.1.8 Tolerancia a Fallas .............................................................................. 21
2.2 LOS SISTEMAS MANEJADORES DE BASES DE DATOS ...................... 21 2.2.1 Objetivos .................................................................................................... 22
2.2.2 Abstracción de Datos ......................................................................... 22
2.2.3 Modelos de Datos ................................................................................. 23 2.2.3.1 Modelos Lógicos de Datos Basados en Objetos ................... 23 2.2.3.2 Modelos Lógicos de Datos Basados en Registros ................ 23 2.2.3.3 Modelos Físicos de Datos ........................................................... 24
2.2.4 Instancias y Esquemas ...................................................................... 24
2.2.5 Independencia de Datos ................................................................. 24 2.2.6 Lenguajes de Definición de Datos ............................................ 25
2.2. 7 Lenguajes de Manipulación de Datos ..................................... 25 2.2.8 Manejadores de Bases de Datos ................................................. 25
3.1 SISTEMAS BASADOS EN ARCHIVOS .................... : ....................................... 26 3.2 BASES DE DATOS JERÁRQUICAS Y DE RED ........................................... 26 3.3 LAS BASES DE DATOS RELACIONALES ..................................................... 27
4
Ftl<IINII
3.4 MODELOS DE BASES DE DATOS DISTRIBUIDAS Y EXTENDIDAS ............................................................................................................. 28
3.5 BASES DE DATOS ORIENTADAS A OBJETOS ......................................... 29
3. 7 BASES DE DATOS INTELIGENTES ............................................................... 29
3.8 TRABAJOS PARA ENCAUSAR LA INVESTIGACIÓN DE SISTEMAS MANEJADORES DE BASES DE DATOS EN LOS 90's ....................................................................................................................... 30
3.8.l Manifiesto de los Sistemas de Bases de Datos de la Tercera Generación ................................................................. 30
3.8.2 Manifiesto de los Sistemas de Bases de Datos Orientados a Objetos ........................................................................ .32
3.8.3 El Grupo de Trabajo de la National Science Foundation ............................................................................................. 32
4.1 VENTAJAS Y DESVENTAJAS .............................................................................. .34
4.2 ARQUITECTURA DE UNA BASE DE DATOS DISTRIBUIDA ............................................................................................................ 3 5
4.2.1 Arquitectura de un Sistema Manejador de Bases Datos Distribuidas ................................................................................... 39
4.2.2 Arquitectura de los Sistemas Multi Base de Datos ......... 42
4.2.3 El Directorio Global... .......................................................................... 43
4.3.l Transparencia de Red ........................................................................ 45
4.3.2 Transparencia de Replicación ....................................................... 45 4.3.3 Transparencia de Fragmentación ............................................... 45
4.4 DISEÑO DE BASES DE DATOS DISTRIBUIDAS ..................................... 45
4.4. l El Diseño Ascendente y Descendente del Esquema Global ......................................................................................... 46
4.4.2 Diseño de Fragmentación ................................................................ 47
4.4.3 Diseño de Localización de Fragmentos .................................. 48
4.5 PASO DE CONSULTAS GLOBALES A CONSULTAS EN FRAGMENTOS ........................................................................................................... 48
4.6 ESTRATEGIAS DE ACCES0 ................................................................................ 56
4.6.l Modelado de Consultas para su Análisis ................................ 57
4.6.2 Modelado para Optimar Consultas ...................................... : ..... 61 4. 7 ADMINISTRACIÓN DE TRANSACCIONES ................................................. 63
4.7.l Objetivos en la Administración de Transacciones ........... 64
5
YIÍQINl1
4. 7.2 Las Transacciones Distribuidas ................................................... 65
4.8 CONTROL DE CONCURRENCIAS ................................................................... 69
4.8.1 Candados a dos Fases ......................................................................... 70 4.8.2 Detección y Prevención de Abrazos Mortales ..................... 71
4.8.3 Estampillas de Tiempo ....................................................................... 71
4.8.4 Método Optimista para el Control de Concurrencias .... 72
4.9.1 Catálogo ..................................................................................................... 73 4.9.1.1 Contenido de los Catálogos ...................................................... 73 4.9.1.2 Distribución de los Catálogos ................................................... 73 4.9.1.3 Nombre de Objetos y Administración
Autónoma ....................................................................................... 74 4.10 CONCLUSIONES DEL CAPÍTULO 4 ................................................ 74
5.2.9 Manejo de Transacciones ................................................................. 87
5.3 HERRAMIENTAS PARA EL TRABAJO DISTRIBUID0 ........................... 88
5.3.1 Protocolo de Compromiso a Dos Fases ................................... 88
5.3.2 Manipulación de Datos Distribuidos ........................................ 89
5.3.3 Servicios de Replicación de Datos .............................................. 90
5.3.4 Open Server ............................................................................................. 91
5.3.5 Replication Server ............................................................................. : .. 93
5.3.6 Navigation Server ................................................................................. 94
5.4 CONCLUSIONES DEL CAPÍTULO 5 .................................................. 95
<í. fW<ODlleruÍTICdlJ f dü~~ ILl btSJ~~~(OIL10 lDJIE ~~ lli\ÓICl~lO ICl!E r~~~MfNT 61(1ÓN T f{ff'UCdll<C.!Ó~ TIK<~N~r ~~f~T!E'. ............................................................. 9 7
6 .1 NIVELES DE TRANSPARENCIA EN LA DISTRIBUCIÓN ................... 97
6
t'IÍQINII
6.1.l Transparencia en Aplicaciones Simples de Sólo Lectura ............................................................................................ 97
6.1.2 Transparencia en Aplicaciones Complejas de Sólo Lectura ............................................................................................ 99
6.1.3 Transparencia en Aplicaciones que Modifican Datos .... 100
6.2 MODIFICACIONES EN EL LENGUAJE DE DEFINICIÓN DE DATOS ................................................................................................................. 102
6.2. l Definición ~e Bases de Datos Fragmentada con Enfoque Descendente ........................................................................... 102
6.2.2 Definición de Bases de Datos Fragmentada con Enfoque Ascendente ............................................................................. .-.103
6.3 MECANISMOS PARA LECTURA Y ESCRITURA EN FRAGMENTOS REPUCADOS ............................................................................ 105
6.3. l Copias Sincrónicas: se lee una copia, se actualizan todas .................................................................................... 105
6.3.2 Copias Sincrónicas: lectura y actualización basadas en quórum ............................................................................. 106
6.3.3 Copias Sincrónicas: actualización de una o todas las copias, dependiendo del tipo y montq de la operación ................................................................................................... 106
6.3.4 Copias Asincrónicas: primaria actualizable, secundarias de lectura; datos no voluminosos .................. 107
6.3.5 Copias Asincrónicas: todas actualizables ............................... 107
6.3.6 Copias Asincrónicas: primarias actualizables secundarias de lectura; datos voluminosos ......................... 107
6.4 CONCLUSIONES DEL CAPÍTULO 6 .................................................. 107
7.3 RUTINAS EMPLEADAS EN LA IMPLEMENTACIÓN .............................. 122
7.3.1 Definiciones y Encabezados ............................................................ 122
7.3.2 Conexiones al Monitor Global y a Nodos ............................... 124 7.3.3 Consultas a Servidores SQL. .......................................................... 124
7.3.4 Modificacio~es en el Leguaje de Definición de Datos .... 125 7.3.5 Protocolo de Compromiso a Dos Fases ................................... 126
7.3.6 Lecturas y Escrituras Distribuidas ............................................ 127
7.4 EVALUACION DEL SISTEMA ............................................................. 129 7.5 COMPARACIÓN CON OTRAS FORMAS DE DISTRIBUIR
LOS DATOS .................................................................................. 130 7.6 PROPUESTAS PARA FUTURAS INVESTIGACIONES ...................... 131 7.7 CONCLUSIONES DEL CAPÍTULO 7 ............................................... 131
si iylili:)l!(()qjlf(,~u,[h1! .................................................................................................................................. 13s
\\Ji~ .05ill~(~O [íllt. '.1>1(~11.«l~J ...................................................................................................................... l 3 7
Alternativas de Implementación en Sistema Manejador de Bases de Datos Distribuidas.............................................................................................................. 36 Arquitectura Referencial para una Base de Datos Distribuidas............................. 37 Fragmentos e Imágenes Físicas para una Relación Global................................... 38 Arquitectura de Esquemas para una un Base de Datos Distribuida.................... 39 Esquema Funcional de un Sistema Manejador de Bases de Datos Distribuido............................................................................................................... 40 Componentes de un Sistema Manejador de Bases de Datos Distribuido........... 41 Arquitectura de Sistemas Multi Base de Datos con ECG....................................... 42 Arquitectura de Sistemas Mulli Base de Datos sin ECG (Litwin. 1998) ................... 43 Componentes de un Sistema Multi Base de Datos................................................... 44 Direcciones en el Diseño de la Distribución............................................................... 46 Árbol de Operaciones..................................................................................................... 50 Join no Distribuido............................................................................................................ 63 Join Distribuido.................................................................................................................. 63 Uniones paciales.............................................................................................................. 63 Comunicación en el Protocolo de Compromiso a Dos Fases............................... 67 Transacciones Distribuidas con Estructura Centralizada ......................................... 68 Transacciones Distribuidas con Estruchxa Jeráquica ............................................. 68 Transacciones Distribuidas con Estructura Linear ...................................................... 68 Transacciones Distribuidas con Estructura Distribuida .............................................. 68 Funciones de Comunicación Cliente - Servidor en Sybase .................................... 79 Aplicación de sólo Lectura en diferentes Niveles de Transparencia................... 98 Aplicación SUPOFPART con Diferentes niveles de Transparencia................................... 99 Aplicación de Modificación de Datos con Diferentes Niveles de Distribución Transparente................................................................................................... 101 Componentes del Sistema............................................................................................. 109 Catálogo Global de la Base de Datos........................................................................ 112 Ejemplo para mostrar la Implementación.................................................................. 115 Propuesta para la Implementación de un Monitor Global de Transacciones................................................................................................ 116 Receptor de Transacciones........................................................................................... 117 Receptor. Analizador de Semántica de Solicitudes Globales, Manejador de LOO y Catálogo Global....................................................................... 118 Componentes Relacionados con el Calendorizador de Transacciones............ 121 Esquema de la Programación del Monitor Global de Distribución...................... 123
9
El progreso que ha presentado la tecnología de redes en los últimos años. al igual que la
comercialización de bases de datos de tipo relacional ha sido dramático. La combinación de
ambas tecnologías. y el avance en las investigaciones sobre sistemas distribuidos han dado
origen a las Bases de Datos Relacionales Distribuidas. caracterizadas por dos propiedades
principales [Belford.1982):
• La creación de subconjuntos de bases de datos en varias computadoras. que pueden
encontrarse. o no. en lugares geográficamente lejanos. Con la capacidad de accesar y
manipular todos los subconjuntos.
• Las computadoras están enlazadas por una red. Todos los datos son administrados por un
solo Sistema Manejador de Bases de Datos, y los usuarios del sistema no tienen porque
percatarse de la distribución del sistema.
Ya desde 1988 Stonebraker [Stonebraker. 1988) anunciaba que las bases de datos
centralizadas se.rían obsoletas dentro de l O años. sin embargo en la actualidad aún son
populares y se emplean tanto en pequeñas como en grandes empresas.
El paso de Sistemas Manejadores de Bases de Datos Centralizados a Sistemas Manejadores de
Bases de Datos Distribuidas (SMBDD) en su forma comercial ha sido lento y parcial. Dos de las
principales causas de este retardo han sido la deficiencia en las líneas de comunicación y la
falta de transparencia en fragmentación. replicación y localización de los datos. La falta de
transparencia en sistemas comerciales deja en manos del usuario una serie de decisiones
complejas. que de no ser tomadas adecuadamente implican reingeniería y costos
adicionales.
Tanto la aparición de nuevas tecnologías de redes más confiables. como la de productos que
permiten mayor transparencia en el uso de replicas y de fragmentación, auguran una pronta
implementación masiva de SMBDD a muy corto plazo.
Este trabajo cubre los siguientes objetivos:
• Presentar algunos conceptos y técnicas especificas que las investigaciones en el área de
Sistemas Distribuidos han aportado para el desarrollo de SMBDDs.
• Hacer un análisis del estado del arte en materia de Manejadores de Bases de Datos.
10
• Presentar los diseños clásicos de Sistemas Manejadores de Bases de Datos Distribuidas y
proponer la manera como debe ser implementados. en futuras investigaciones.
• Implementar una parte del prototipo de tal forma que se provea fragmentación y
replicación transparente.
Para lograr los objetivos se han desarrollado los siguientes capítulos:
Capítulo 2. Este capítulo se divide en dos partes. la primera se dedica a los Sistemas
Distribuidos y la Segunda a los Sistemas Manejadores de Bases de Datos. En la primera parte se
hace una presentación general de los conceptos relevantes en las áreas de Sistemas
Distribuidos: visión general del área. el subsistema de comunicación. características con que
debe contar un sistema de esta clase y algunas técnicas de comunicación entre procesos. La
segunda parte, dedicada a los Sistemas Manejadores de Bases de Datos. menciona sus
objetivos. define sus características y se mencionan los principales modelos.
Capítulo 3. Considera los principales rumbos que ha tomado el manejo de información en las
últimas tres décadas y las líneas de investigación que se trabajan en la actualidad. En este
capítulo se pueden encontrar algunas referencias para ubicar el contexto de las
investigaciones en el área de Bases de Datos.
Capítulo 4. El capítulo, es una descripción de los modelos clásicos de SMBDDs. Los conceptos
principales en el área de SMBDD son desarrollados en 9 temas: ventajas y desventajas.
arquitectura. transparencia. diseño, consultas. acceso. administración de transacciones.
control de concurrencias y administración del sistema.
Capítulo 5. Este capítulo se divide en tres partes principales. La primera se refiere a la
arquitectura cliente servidor en los Sistemas Manejadores de Bases de Datos (SMBD). La
segunda presenta la forma en que trabajan los servidores SQL. Por último se describen algunas
herramientas que suelen proveerse con los servidores SQL para permitir la distribución del
sistema.
Capítulo 6. Marca tres aspectos que debe cubrir la transparencia de fragmentación y
replicación en un SMBDD: Transpaencia para el programador de las apUcaciones.
transparencia en el lenguaje de definición de datos y transparencia en los mecanismos de
lectura y escritura.
11
Capítulo 7. Trata sobre el diseño e implementación de un módulo de replicación y
fragmentación transparente. que cubre la problemática planteada en el capítulo 6. Primero
se expone el diseño del sistema y se presentan algunas tablas que sirven de ejemplo para
entender su funcionamiento. Posteriormente se describe cada uno de los componentes del
sistema y por último se presentan algunas de las rutinas que sirvieron para la implementación
de un prototipo de sistema distribuido.
Capítulo 8. Presenta resultados y conclusiones de esta investigación.
12
los servicios de información que proporcionan las computadoras. nacieron en forma
centralizada. es decir. en un principio las computadoras trabajaban para un sólo usuario.
Posteriormente se inició el trabajo con tiempo compartido y después el trabajo con pequeñas
redes. de tal forma que. en poco tiempo se han transformado en sistemas distribuidos. En este
marco los sistemas distribuidos han sido de gan interés ya que se conforman por un conjunto
de computadoras. frecuentemente heterogéneas. que se comunican a través de una red y
cooperan para realizar un trabajo común [Coulouris 1994). Estos sistemas permiten compartir
recursos e información en áreas extensas conjuntando el poder de varias computadoras para
adquirir. de esta forma. mayor capacidad de procesamiento. los Sistemas Distribuidos brindan
características como escalabilidad. autonomia. transparencia y tolerancia a follas.
Por otra parte. el procesamiento de datos estructurados. en la actualidad se realiza a través
de colecciones de datos relacionados y un conjunto de programas para acceder a esos
datos. El objetivo primordial de un Sistema Manejador de Bases de Datos (SMBD) es
proporcionar un. entorno que sea a la vez conveniente y eficiente para ser utilizado al extraer
y almacenar información de la base de datos [Korth. Silberschatz 1993). La importancia de la
información en la mayoría de las organizaciones y por tanto el valor de la base de datos. ha
llevado al desarrollo de una gran cantidad de conceptos y técnicas para la gestión eficiente
de la información. Los dos temas a tratar en este capítulo son los Sistemas Distribuidos y los
Sistemas Manejadores de Bases de Datos.
2.1 LOS SISTEMAS DISTRIBUIDOS
los sistemas distribuidos permiten compartir recursos e información en áreas extensas. de modo
que se pueden utilizar varias computadoras pequeñas para resolver grandes problemas.
Desde hace más de 20 años. los investigadores en el área de Sistemas Distribuidos han
propuesto toda clase de técnicas para diseñar software distribuido. Soluciones satisfactorias
han surgido en muchas áreas. estándares han sido establecidos y en la actualidad los sistemas
distribuidos son ampliamente usados en escuelas. fábricas y empresas [Sánchez. 1995).
A continuación se presentan algunos aspectos que han influido en la investigación y desarrollo
de Sistemas de Bases de Datos Distribuidas.
13
2.1.2 Generalidades
"Un sistema distribuido consiste en una colección de computadoras autónomas unidas por
una red computacional y equipado con software de sistema distribuido. El software de
sistema distribuido le permite a las computadoras coordinar sus actividades y compartir sus
recursos de hardware. software y datos. Los usuarios de un sistema distribuido bien diseñado
deben percibir una facilidad única e integrada de cómputo a pesar de que ésta sea
implementada por muchas computadoras en diferentes lugares" [Couloris 1994).
Podemos señalar como características ideales de un sistema distribuido. las siguientes:
• Se usa un sistema de comunicación
• Ausencia de un estado global perceptible por un observador
• Sincronización del trabajo
• Los recursos se compaten
• Permiten Apertura. Capacidad de comunicación con otros equipos de diferente
arquitectura y ofrecidos por diferentes proveedores.
• Facilitan la Concurrencia.
• Proporcionan· Escalabilidad. Aumentan la capacidad de los equipos y permite añadir
nuevas computadoras al sistema sin necesidad de modificar su estructura.
• Toleran Fallas: Permiten que el sistema siga funcionando a pesar de que una computadora
no funcione o un periférico se dañe.
• Se dan en un ambiente transparente. El usuario no requiere conocer detalles sobre la
distribución del sistema.
Los primeros intentos de desarrollo de esta tecnología inicia a finales de los 70's con sistemas
de archivos distribuidos (Xerox DFSJ. y el uso de pilas de procesadores para una red de
computadoras (Cambridge Distributed Computing System). Con la llegada de las estaciones
de trabajo y minicomputadores se logran mejores interfaces gráficas y nuevos desarrollos de
software. Sin embargo, la falta de conectividad no les permite un trabajo realmente
cooperativo.
Entre los mejores trabajos de interconectividad para equipos personales encontramos los
realizados en el Centro de Investigación de Xerox Palo Alto de 1971 a 1980. los cuales
incluyen:
• El desarrollo de un servidor de archivos e impresoras para estaciones de trabajo personal.
• La primer red local de alta velocidad (La red Ethernet).
• Varios Sistemas Distribuidos de tipo experimental.
14
Desde la década de los ochentas a la fecha, la investigación y el desarrollo de sistemas
distribuidos se ha incrementado a un ritmo acelerado generando productos como Accent.
Mach, Amoeba. Argus. V-system y Chorus.
2.1.3 Objetivos en el Diseño de Sistemas Distribuidos
Para lograr las características deseables de un sistema distribuido de tal forma que faciliten la
interacción entre las personas. computadoras y programas relacionadas con él. es necesario
considerar:
la resolución de nombres. Los nombres que se asignan a los recursos u objetos de un sistema
distribuido para ofrecer sus servicios en forma transparente. deben tener un significado global
que sea independiente de la localidad. y deben ser soportados por un sistema de
interpretación de nombres que permita a los programas accesar los recursos adecuados. Uno
meta del diseño es establecer un esquema de nombres escalables con traducción eficiente y
alto grado de desempeño.
la comunlcacló·n. El desempeño y lo disponibilidad de las técnicas de comunicación usadas
paro la implementación del sistema distribuido son críticos en el funcionamiento del mismo. En
este aspecto. la meta a alcanza es hacer óptima la implementación de las comunicaciones
en el sistema. mediante un modelo de progamación de alto nivel para su uso.
Estructura del Software. La apertura se alcanzo gracias al diseño y construcción de
componentes de software con interfaces bien definidas. La abstracción de datos es una
técnica de diseño importante para los sistemas dislribuidos. Los servicios pueden ser vistos
como los administradores de objetos de un tipo de datos; la interfaz a un servicio puede ser
vista como un conjunto de operaciones. En este caso. lo meta es estructurar un sistema en el
que se puedan introducir nuevos servicios. para trabajar en conjunto con los ya existentes. sin
duplicar elementos de los servicios establecidos.
Carga de Trabajo por Nodo. Uno de las metas en el diseño es repartir los procesos para que las
comunicaciones y el procesamiento se realicen en forma óptima.
Mantenimiento de la consistencia. Existen varios problemas relacionados con la consistencia
que surgen al trabajar con sistemas distribuidos. El mantenimiento de la consistencia puede
ser costoso y lo meta del diseño es el equilibrio entre consistencia y costo razonable.
15
2.1.4 El Subsistema de Comunicación
En esta sección veremos en una forma general el subsistema de comunicación. Este
subsistema se conforma por varios componentes de hardware (interfaces. ruteadores.
switches ... ) y software (protocolos y manejadores de comunicación). Todos estos
componentes forman la red de comunicaciones.
2.1.4.1 Parámetros de Desempeño
Entre los parámetros que afectan el desempeño de la red tenemos aquellos relacionados con
la velocidad con la que un mensaje es transmitido entre dos computadoras conectadas a
través de la red. Estos parámetros son la latencia y la tasa de transferencia de datos punto a
punto.
latencia. Es el tiempo requerido para transmitir un mensaje vacío entre dos computadoras.
Esta medida involucra tanto al acceso del transmisor y del receptor a la red. como a la red
misma. La latencia se determina principalmente por el modo de trabajo del software y rutinas
de retardo para el acceso.
la tasa de transferencia de datos punto a punto es la velocidad a la cual los datos pueden ser
transmitidos entre dos computadoras en la red, una vez que la transmisión fue iniciada. La
tasa de trasferencia esta determinada principalmente por las características físicas de la red y
se mide en bits por segundo.
Siguiendo estas definiciones. el tiempo requerido por una red para transmitir un mensaje entre
dos computadoras es:
Tiempo de transferencia de mensaje= latencia + longilud / tasa de lransferencia de dalos (2. 1 )
El ancho de banda de una red es una medida que nos indica el total del volumen de tráfico
que puede ser enviado a través de la red en un tiempo dado. En muchas tecnologías se
utiliza toda la capacidad de transmisión para enviar cualquier mensaje y el ancho de banda
es igual a la tasa de transferencia de datos. Pero en la mayoría de las redes amplias se
pueden mandar varios mensajes a través de varios canales a la vez. El desempeño de la red
se deteriora en condiciones de tráfico. cuando hay muchos mensajes en la red al mismo
tiempo. El tráfico. la latencia. la tasa de transferencia y el ancho de banda de una red
dependen de la tecnología de red empleada.
16
2.1.4.2 Requerimientos de Desempeño
Los accesos tanto a los discos. como a la red son muy lentos en comparación con la
velocidad de procesamiento del CPU. Es por esto que normalmente el procesador puede
trabajar con varias tareas a la vez. mientras espera la llegada de nuevos mensajes o
respuestas. Es deseable que los accesos a la red sean proporcionales a los de un disco. lo cual
no siempre es posible debido a la limitación en el ancho de banda de las redes y tasa de
transferencia. aunado a la sobrecarga que acompaña a los mensajes en la red. Actualmente
los disco trabajan con un tiempo de acceso de entre 1 O y 20 milisegundos, por lo que una
petición de lectura no puede ser menor a este tiempo teniendo latencias de 5 milisegundos y
tasas de 200 kb/s que incluyan información para la transmisión de los mensajes.
2.1.4.3 Requerimientos de Confiabilidad
El sistema distribuido en sí. debe ser confiable a pesar de que la red tenga problemas. El
sistema puede requerir comunicación confiable. o bien. implementar mecanismos que
detecten fallas y corrijan el problema mediante software.
2.1.4.4 Tipos de Redes
Las redes pueden ser divididas en dos grandes clases:
Redes de Área Local: conduce mensajes a una velocidad relativamente alta entre cualquiera
de las computadoras conectadas a un medio de comunicación común. como fibra óptica o
cable coaxial. localizadas en el mismo edificio o campus. El medio provee conexión directa
entre todas las máquinas por lo que no se requiere asignar rutas a los mensajes. En este tipo
de redes la latencia es baja a excepción de las ocasiones en que el tráfico es muy grande.
En la actualidad la tasa de transferencia de las redes de área local se encuentra entre 0.2 y
100 mega bits por segundo.
Redes de Álea Amplia. Conduce los mensajes a una velocidad baja (la latencia típica está en
el rango de 0.1 y 0.5 segundos con una tasa de transferencia de 20 a 500 kbits por segundo).
En este caso los mensajes se intercambian entre computadoras separadas por grandes
distancias. Cada computadora suele llamarse host y se pueden localizar en diferentes
ciudades. países o continentes. El medio de comunicación está formado por un conjunto de
circuitos de enlaces y ruteadores que manejan la red. La operación de ruteo consiste en
enviar los mensajes hacia los nodos indicados. y el tiempo total de transmisión para un
mensaje. depende de la ruta seguida.
17
la latencia y tasa de transferencia con la que trabajan actualmente las redes de área amplia
no ha cumplido satisfactoriamente los requerimientos de los sistemas distribuidos. pero se
espera un incremento de los mismos con el cambio de las redes actuales a redes ISDN
(lntegrated Sevices Digital Network) y B-ISDN que cubren velocidades desde 64 kilobits por
segundo hasta 150 megabits por segundo.
2.1.4.5 Los Paquetes
En la mayoría de las aplicaciones. las transmisiones se realizan utilizando los mensajes como
unidad de transmisión. los mensajes son unidades de longitud arbitraria. sin embargo, para
viajar por la red deben ser divididos en paquetes. la forma simple de un paquete es una
secuencia de elementos de datos en formato binario de longitud restringida, unida a
información referente a la forma de manejar el paquete como la dirección de origen y la
dirección destino.
2.1.4.6 Trabajo entre Redes
Una característica propia de los sistemas distribuidos es la apertura. la apertura debe permitir
el empleo de diferentes tipos de redes. que formen una red integrada. a pesar de contener
dispositivos diseñados por diferentes proveedores y computadoras con arquitectura
heterogénea. Con este tipo de trabajo un sistema distribuido se puede extender a un gran
número de computadoras. la forma de unir las diversas redes es mediante ruteadores y
gateways (computadoras de propósito general que controlan y dirigen el tráfico de la red). y
añadiendo protocolos que soportan el direccionamiento y transmisión a través de una gran
red virtual.
2.1.5 Comunicación entre Procesos
Para que un proceso pueda enviar mensajes a otro. se deben poner los dalos en un formato
común para cualquier tipo de máquina. El proceso que envía los datos los debe reunir para
que se manden por bloque o paquetes. Es necesario que se consideren .las funciones de
enviar mensaje y recibir mensaje. Además es necesario saber si estas funciones han de
detener el proceso (ser bloqueante) o no (no bloqueantes). Se puede suponer que la red es
confiable. por lo cual al enviar un mensaje podemos tener la certeza de que va a llegar. o
bien, puede ser que la red sea no confiable. para lo que necesitaremos implementar
protocolos que permitan trabajar en caso de fallas.
18
2.1.5.1 El Paradigma Cliente Servidor
El empleo de un modelo de comunicación cliente servidor. requiere de un protocolo
petición-respuesta; estos protocolos soportan tres operaciones fundamentales:
• RealizarOperación (PuertoServidor; mensaje_de_petición; mensaje_de_respuesta). Esta
operación manda una petición al servidor y recibe su respuesta. Puede ser implementada
usando una operación de envío de mensaje y otra de recepción. Esta operación bloquea
al cliente que la ejecuta hasta recibir respuesta. pero se acostumbra a utilizar
temporizadores para evitar bloqueos indefinidos por fallas en la red.
• ObtenerPetición (PuertoServidor; Mensaje): Esta operación la realiza el servidor para recibir
peticiones de los clientes.
• EnviarRespuesta (PuertoCliente; Mensaje): Después de recibir una petición el servidor la
procesa y envía su respuesta al cliente con esta operación.
2.1.5.2 Llamadas a Procedimientos Remotos
Las RPC son formas de implementar protocolos de comunicación. El objetivo de estas
instrucciones es dar un nivel más alto a la semántica para comunicar a los procesos. Entre los
principales aspectos de la semántica de un RPC se encuentran:
• Un RPC tiene una sintaxis parecida a la de una llamada local de procedimiento. pero la
ejecución de este procedimiento es en otra computadora.
• Al definir un RPC se especifican parámetros de entrada y de salida. Los parámetros de
entrada son enviados al servidor. mandando los valores de los argumentos en el mensaje
de petición. Los parámetros de salida son enviados al cliente en respuesta a su petición y el
valor es guardado en la variable especificada por un parámetro.
• Un RPC no puede utilizar las variables globales del proceso origen. pues se ejecuta en un
ambiente diferente.
• Los argumentos de un RPC y los resultados no pueden incluir estructuras de datos que
contengan apuntadores a localidades de memoria.
2.1.6 La Coordinación entre Procesos
La noción de tiempo es difícil de trabajar en los sistemas. pues cada máquina tiene su propio
reloj físico. Generalmente se trabaja con relojes lógicos. los cuales se basan en relaciones
"que sucedió antes" para dar un orden a los eventos.
El uso de estampillas de tiempo es un método diseñado por Leslie Lamport [Lamport1978] con
el cual se permite establecer un orden de eventos gracias a una relación de precedencia. En
19
este caso el reloj lógico asigna un valor a cada evento que es considerado como la hora. o el
tiempo. en el cual dicho evento ocurrió. Las estampillas se pueden implementar de diferentes
formas. por ejemplo:
• Cada proceso Pi va a administrar un reloj local hi.
• Todos los mensajes emitidos por Pi son sellados por el valor del número del proceso y del
reloj local.
• El comportamiento de Pi. dado un reloj local hi es el siguiente:
a) Si Pi recibe un mensaje (mensaje, hora,. j) de Pj entonces hi <- max(hj,hi)+ 1
b) Si envía un mensaje (mensaje. hora1.i) entonces hi <- hi + 1 antes de enviar el mensaje
y se considera como la hora en que se envió el mensaje.
c} hi puede ser incrementado por eventos internos. pero no es necesario si sólo nos
interesa la comunicación.
Para lograr control de concurrencias se han implementado algoritmos de exclusión mutua y
de elección que pueden o no hacer uso de relojes físicos o lógicos. Existen tres maneras de
implementar el control de concurrencias en sistemas distribuidos: Candados. control optimista
y estampillas.
2.1. 7 Transacciones
Las transacciones en los sistemas distribuidos pueden involucrar más de dos computadoras y
pueden ser planas o anidadas. Un protocolo de acuerdo atómico es un procedimiento usado
para un grupo de servidores involucrados en una transacción distribuida. que permite que
todos los servidores realicen una misma transacción o que la transacción sea rechazada. El
protocolo de compromiso a dos fases es un ejemplo de implementar transacciones
distribuidas. También juegan un papel importante para este tipo de transacciones el control
de concurrencia y el orden que establecen los relojes lógicos.
Las transacciones con datos replicados deben proveer transparencia asegurando que cada
copia guarde un orden serial. Es decir. que a pesar de ejecutar transacciones concurrentes
cada copia de datos debe tener el mismo resultado que la ejecución serial (una tras otra) de
las transacciones. Una forma de lograr esto puede ser~I permitir leer datos de cualquier
copia. pero escribir en todas las replicas llllil~ión. sin embargo esto no siempre es
posible. Ot.Ot 30
-..... 20
2.1.8 Tolerancia a Fallas
Las operaciones que trabajan en línea requieren soportar las fallas del hardware: este es uno
de los objetivos de los sistemas distribuidos. La tolerancia a fallas abarca dos aspectos: la
descripción de las características de la falla y la forma de ocultar la falla. Existen varios tipos
de fallas en los sistemas distribuidos. entre ellas podemos citar las fallas de paro y las fallas
Bizantinas. Las primeras se dan cuando uno de los componentes del sistema deja de trabajar
y el segundo. cuando el funcionamiento de algunos componentes es contradictorio con los
demás. Para cubrir las fallas se puede hacer uso de una jerarquía o de trabajo en grupo.
Cada componente en un sistema de cómputo esta construido por una colección de
programas y equipo físico. algunos de los cuales pueden fallar. El diseñador del sistema debe
considerar tanto los puntos que pueden fallar. como la forma de cubrir esa falla. La
descripción de la forma en la que puede fallar un servicio es llamada su semántica de falla
(Coulouris 1994 p. 461]. El conocimiento de una semántica de falla permite diseñar otros
servicios capaces de cubrir las fallas.
Para cubrir las posibles fallas en un sistema se utilizan dos modelos. uno enfocado a una
organización jerárquica y otro basado en el grupo. El encubrimiento jerárquico se refiere a
que los servidores dependen de niveles de servicio. El servicio de más alto nivel debe cubrir las
fallas de los servidores de menor nivel. Por su parte. el encubrimiento de grupo considera que
si un servidor cae. el resto de los servidores del grupo pueden realizar su función.
Otro aspecto a considerar es la recuperación ante las fallas. En el punto 4.7.2 se expone
como funciona la tolerancia a fallas y la recuperación en los SMBDs.
2.2 LOS SISTEMAS MANEJADORES DE BASES DE DATOS
Un Sistema Manejador de Bases de Datos (SMBD) consiste en una colección de datos
interrelacionados y un conjunto de programas para utilizar esos datos. La colección de datos.
normalmente denominada base de datos. contiene información acerca de un asunto
determinado. El objetivo primordial de una SMBD es proporcionar un entorno que sea a la vez
conveniente y eficiente para ser utilizado al extraer y almacenar información de la base datos
[Korth. Silberschatz 1993].
Los SMBD surgen para administrar grandes bloques de información. la cual consta tanto de la
generación de una estructura para el almacenamiento. como de la provisión de mecanismos
21
para insertar. modificar o eliminar datos. Además. debe mantener seguridad en la
información almacenada. pese a caídas del sistema o intentos de acceso no autorizados.
2.2.l Objetivos
• Evitar redundancia e inconsistencia. A diferencia de la programación con archivos planos.
cuando se utiliza un SMBD los datos son almacenados en un sólo lugar. donde pueden ser
consultados o actualizados por cualquier programa o aplicación.
• Facilitar acceso a los datos. Un SMBD debe ser capaz de brindar en forma rápida y
eficiente consultas relacionad.as con los datos que posee a pesar de que la consulta
especifica no esté previamente diseñada. Es decir. permiten la recuperación sencilla de
datos para uso general.
• Relacionar diversos Datos. Dado que los datos se almacenan en un sólo lugar y con un
formato predefinido. es posible realizar relaciones entre ellos.
• Permitir Acceso Concurrente. El SMBD debe permitir a varios usuarios trabajar con datos
comunes y realizar actualizaciones que den una visión global consistente.
• Asegurar la integridad de los datos. La seguridad en el SMBD puede ser controlada en base
a los usuario~. permitiendo o negando información según la identidad del usuario.
• Crear un ambiente Seguro. Al diseñar una base de datos. el SMBD puede implementar
restricciones que aseguren la integridad de los datos según un diseño predeterminado y
flexible.
2.2.2 Abstracción de Datos
El SMBD debe ser capaz de proporcionar a los usuarios una visión abstracta de los datos. Es
decir. debe esconder ciertos detalles sobre el modo de almacenamiento y su mantenimiento.
Sin embargo. para que el sistema sea manejable. los datos se deben extraer eficientemente.
Para esconder la complejidad del sistema al usuario se utilizan diversos niveles de abstracción
que simplifican la interacción usuario - sistema.
La arquitectura para estandarización de SMBD ANSI/SPARC [Tsichritzis and Klug. 1978) se basa
en la organización de los datos y propone tres niveles para el tratamiento de los datos:
• Nivel Físico. Este nivel es el más bajo de abstracción y describe cómo se almacenan
realmente los datos. Aquí se describen en detalle las estructuras de datos complejas del
nivel bajo.
• Nivel Conceptual. Es el siguiente nivel de abstracción y describe qué datos son realmente
almacenados en la base de datos y las relaciones que existen entre ellos. Este nivel es
22
usado por los administradores de bases de datos. quienes deben decidir qué información
se va a guardar en la base de datos.
• Nivel de Visión. Es el nivel más alto de abstracción y describe sólo una parte de la base de
datos completa. disminuyendo la complejidad del nivel conceptual que debe abarcar a
toda la base de datos. Un SMBD debe poder proporcionar varias vistas para la misma base
de datos.
2.2.3 Modelos de Datos
Los modelos de datos se utilizan para poder describir la estructura de una base de datos. Estos
son una colección de herramientas conceptuales para: describir la estructura de los datos,
representar las relaciones existentes entre ellos, generar una semántica asociada a los datos y
formular restricciones de consistencia. Los diversos modelos de datos que se han propuesto se
dividen en tres grupos: modelos lógicos basados en objetos. modelos lógicos basados en
registros y modelos físicos de datos.
2.2.3.1 Modelos Lógicos de Datos Basados en Objetos
Se utiliza para describir datos a nivel conceptual y de visión. Se caracterizan por el hecho de
proporcionar una capacidad de estructuración bastante flexible y permiten especificar
restricciones de datos explícitamente. Entre estos modelos aparecen:
• El modelo entidad-relación.
• El modelo orientado a objetos.
• El modelo binario.
El modelo entidad-relación ha ganado aceptación en el diseño y se utiliza ampliamente en la
práctica, al igual que el modelo orientado a objetos. Este último incluye muchos de los
conceptos del modelo entidad-relación, pero representa tanto código ejecutable como
datos.
2.2.3.2 Modelos Lógicos de Datos Basados en Registros
Estos modelos son usados para describir datos en los modelos conceptual y físico. A diferencia
de los basados en objetos. se usan para especificar la estructura lógica global de la base de
datos y para proporcionar una descripción a un nivel más alto de la implantación.
En este caso la base de datos está estructurada en registros de formato fijo de varios tipos.
Cada tipo de registro define un número fijo de campos y cada campo normalmente es de
longitud fija.
23
los modelos de datos basados en registros no incluyen un mecanismo para la representación
directa de código en la base de datos. En cambio. hay lenguajes por separado que se
asocian con el modelo para expresar consultas y actualizaciones. los modelos de este tipo
más aceptados son:
• Relacional
• De red
• Jerárquico
A diferencia de los modelos de red y jerárquico. el modelo relacional no utiliza punteros o
enlaces para conectar los registros. lo cual permite definir una base matemática formal.
[Korth 1993)
2.2.3.3 Modelos Físicos de Datos
los modelos físicos de datos se usan para describir datos en el nivel más bajo. A diferencia de
los modelos lógicos. hay muy pocos modelos físicos en uso. Dos de los más conocidos son:
• Modelo Unificador
• Memoria de Elementos
2.2.4 Instancias y Esquemas
La colección de información almacenada en la base de datos. en un determinado momento
en el tiempo. se llama una instancia de la base de datos. El diseño global de la base de datos
se llama esquema de la base de datos. los esquemas se cambian con poca frecuencia.
2.2.5 Independencia de Datos
La capacidad de modificar una definición de un esquema en un nivel. sin afectar la
definición de un esquema en el nivel superior, se llama independencia de datos. La
independencia de datos se puede dar en dos niveles:
Independencia Física de Datos es la capacidad de modificar el esquema físico sin provocar
que se vuelvan a escribir los programas de aplicación. En algunas ocasiones son necesarias
las modificaciones en el nivel físico para mejorar el funcionamiento.
Independencia lógica de Datos es la capacidad de modificar el esquema conceptual sin
provocar que se vuelvan a escribir los programas de aplicación. las modificaciones en el
24
nivel conceptual son necesarias siempre que se altere la estructura lógica de la base de
datos.
2.2.6 Lenguaje de Definición de Datos
Un esquema de base de datos se especifica por medio de un conjunto de definiciones que se
expresan mediante un lenguaje llamado lenguaje de definición de datos (LDDJ. El resultado
de la ejecución de sentencias LDD es un conjunto de tablas. las cuales se almacenan en un
archivo especial llamado diccionario de datos.
2.2. 7 Lenguaje de Manipulación de Datos
Un lenguaje de manipulación de datos se conforma por el conjunto de instrucciones para
poder manipular los datos. es decir: recuperarlos, insertarlos. suprimirlos o modificarlos. En los
niveles más altos del diseño del lenguaje de manipulación de datos {LMDJ se busca facilidad
de uso. mientras que en los niveles más bajos el objetivo es lograr accesos eficientes. Un (LMD)
es una herramienta que capacita a los usuarios a acceder o manipular información según un
modelo adecuado. Si el LMD especifica qué datos obtener y cómo obtenerlos. hablamos de
un LMD procedural. Si sólo especifica qué datos obtener sin indicar cómo. hablamos de un
LMD no procedural.
Una consulta es una sentencia que solicita la recuperación de información. La parte de un
LMD que implica recuperación de información es llamada lenguaje de consulta.
2.2.8 Manejadores de Bases de Datos
Un manejador de base de datos es un módulo de programas que proporciona la interfaz
entre los datos de bajo nivel almacenados en la base de datos y los programas de aplicación
y consultas hechas al sistema. Su responsabilidad son las siguientes tareas:
Fig. 6.1 Aplicación de sólo lectura en diferentes niveles de transparencia
Site1
SUPPLIER2 Sife3
SUPPLIER1 Sife3
El segundo nivel. que provee transparencia de localización. hace referencia a cada uno de
los fragmentos. permitiendo independencia de localización. pero no así cambios en la forma
de realizar la fragmentación. Por último. el tercer nivel requiere hacer referencia tanto del
fragmento que se desea, como del site o nodo en el cual se encuentra la información
requerida. Es por esto que la aplicación de la figura
98
En el último nivel de transparencia. se logra que cada una de las bases de datos se encargue
de localizar el medio físico en el que se encuentra la información. lo cual llega a ser de gran
utilidad en el caso de bases de datos heterogéneas.
6.1.2 Transparencia en Aplicaciones Complejas de Sólo Lectura.
El grado de complejidad en el manejo de bases distribuidas es más evidente cuando se
trabaja con varias relaciones utilizando joins. Si consideramos la siguiente aplicación sugerida
en [Ceri. Pelagatti 1984):
read(terminal,@PNUM) Select NAME into @NAME from SUPPLIER, SUPPLY where SUPPLIER.SNUM = SUPPLY.SNUM
and SUPPLY.PNUM = @PNUM; write(terminal,@NAME)
(a) Transparencia de Fragmenlación
read(terminal,@PNUM) Select NAME into @NAME from sryPPLIER1, SUPPLY1 where SUPPLIER1.SNUM = SUPPLY1.SNUM
and SUPPLY¡.PNUM = @PNUM; if not IFOUND then
Select NAME into @NAME from SUPPLIER1.SNUM = SUPPLY1.SNUM and SUPPLY2 .PNUM = @PNUM;
write(terminal,@NAME)
(b) Transparencia de Localización
read(terminal,@PNUM) Select SNUM into @SNUM from SUPPLY1 AT site3 where PNUM = @PNUM; if #FOUND then
be gin
end else
be gin
send @SNUM from site3 to sitel; Select NAME into @NAME from SUPPLIERl AT site1 where SNUM= @SNUM
Select SNUM into @snum FROM SUPPLY1 AT si te4 where PNUM=@PNUM; send @SNUM from site4 to site2; Select NAME into @NAME from SUPPLIER2 AT site2 where SNUM=@SNUM
end write(terminal, @NAME)
(c) Transparencia de mapeo local.
Fig. 6.2 Aplicación :iUPOFPART con diferentes niveles de transparencia.
99
Podemos obser. ar las siguientes características:
Fragmentación Transparente. La aplicación se escribe de la misma forma como se escribiría en
un sistema centrnlizado.
Localización Trarsparente. Si no se cuenta con transparencia de localización. la aplicación
puede ser escritc en diferentes formas con diversos grados de eficiencia. Una solución menos
eficiente que la presentada en el ejemplo de la figura 6.2 sería realizar cuatro consultas. una
por cada combinación de los fragmentos de SUPPLIER y SUPPLY. El ejemplo presentado
aprovecha el conocimiento que se tiene de la distribución de las tablas considerando sólo dos
consultas factibles. De esta forma se muestra que en un sistema que no provee transparencia
de fragmentación. el programador de la aplicación define la estrategia.
Transparencia de Mapeo Local. En el tercer nivel de transparencia es necesario indicar en
qué nodo se encuentra el fragmento requerido para las consultas. La instrucción send permite
comunicación entre los nodos que realicen la consulta. por lo cual es muy importante cuando
el resultado (en @SNUM) es un conjunto de registros. En este tipo de aplicaciones existe una
dependencia muy gande con respecto a la configuración de la base de datos. cualquier
cambio en la fragmentación o replicación afecta directamente a la aplicación.
6.1.3 Transparencia en Aplicaciones que Modifican Datos.
En este punto se consideran los diversos niveles de transparencia en la actualización de datos
distribuidos. Se tienen los mismos niveles de transparencia que en el caso de la lectura. Si un
manejador no provee transparencia de replicación y de localización. el trabajo de
actualización debe ser realizado por el programador de la aplicación.
Al proveer transparencia en una aplicación que modifica datos en una base de datos
distribuida. es necesario tomar en cuenta que las modificaciones en un registro pueden
modificar su localización en la base de datos. de tal forma que si la ciudad es un atributo que
determina el predicado de un fragmento y la ciudad es modificada en un registro. se debe
realizar un cambio de lugar de la tupla. borrándola del nodo actual y guardándola en el
nodo que le corresponda.
Nuevamente tomaremos una figura presentada por Ceri y Pelagatti para mostrar los diferentes
niveles de transparencia en aplicaciones que modifican la base de datos:
Update EMP set DEPTNUM=l5 where EMPNUM=lOO
(a) Transparencia de Fragmentación
Select NAME, SAL, TAX into @NAME,@SAL,@TAX from EMP1 where EMPNUM ~ 100;
100
Sel.ect MGRNUM into @MGRNUM from EMP2 where EMPNUM =100; In1ert into EMP1 (EMPNUM, NAME, DEPTNUM):
(100,@NAME, 15); Insert into EMP4 (EMPNUM,SAL,TAX,MGRNUM):
(100,@SAL,@TAX,@MGRNUM); Delete EMP1 where EMPNUM 100; De!ete EMP2 where EMPNUM = 100
(b' Transparencia de Localización
Select NAME, SAL, TAX into @NAME, @SAL, @TAX from EMP1 AT si tei where EMPNUN=lOO; Select MGRNUM into @MGRNUM from EMP~ AT si te2 · where EMPNUM=lOO; In~ert into EMPi(EMPNUM, NAME, DEPTNUM)
AT site1: (100,@NAME,15); Insert into EMP1 (EMPNUM, NAME, DEPTNUM)
AT site1: (100, @NUM, 15); Insert into EMP4 (EMPNUM, SAL, TAX, MGRNUM)
AT si te,: ( 100, @SAL, @'!'AX, @MGHNUM) ; In~ert into EMP1 (EMPNUM, SAL, TAX, MGRNUM)
AT sitee: (100, @SAL, @TAX, @MGRNUM); Delete EMP1 AT site I where EMPNUM=lOO; Delete EMP 1 AT site where EMPNUM=lOO; Delete EMP2 AT site 2 wherc EMPNUM=lOO; Delete EMP2 AT site 6 where EMPNUM=lOO.
(c) Transparencia de mapeo local
fig. 6.3 Aplicación de Modificación de dalos con diferentes niveles de distribución transparente.
Transparencia de Fragmentación. En este nivel la aplicación realiza la modificación del mismo
modo que lo haría con una base de datos centralizada. Las modificaciones en la estructura
de la base de datos no alteran la aplicación. La responsabilidad de realizar todas las
operaciones que la modificación implique es del sistema.
Transparencia de Localización. Cuando no se cuenta con transparencia de fragmentación. el
programador debe realizar sus aplicaciones con la estrategia adecuada para mantener la
configuración d~ los fragmentos. moviendo las tuplas a los fragmentos adecuados. En el
ejemplo de la fig~ra 6.3b se considera un caso muy específico. que en una aplicación real
debería tomar los valores de un parámetro. lo cual aumentaría la complejidad de la
aplicación.
Transparencia de mapeo local. El tercer nivel de transparencia tiene que considerar tanto la
configuración de los fragmentos como su localización entre los nodos. Las últimas cuatro
líneas de la figura 6.3 c muestran que el programador de la aplicación debe conocer en qué
nodo se encuentra cada fragmento. Cualquier modificación en la configuración de la base
de datos afecta directamente a la aplicación. Un aspecto más en el cual debe trabajar el
101
programador de este tipo de aplicaciones es en la replicación de fragmentos. La aplicación
utiliza dos instrucciones insert y dos instrucciones delete para mantener las replicas.
6.2 MODIFICACIONES EN EL LENGUAJE DE DEFINICIÓN DE DATOS
Para poder trabc.jar con una base de datos distribuida el LDD debe modificar algunas de sus
instrucciones. Éstas pueden ser diferentes si se considera que la base de datos se construye
con un enfoque descendente o ascendente según [Pazos R .. Pérez J 1995] ..
En el enfoque descendente los fragmentos heredan la estructura de la tabla global; es decir.
los fragmentos tienen las mismas columnas que la tabla global. por lo que no se presenta el
problema de incompatibilidad de datos.
Con el enfoque ascendente se complica el logro de transparencia de fragmentación. ya que
se puede dar el caso de que las columnas que forman las tablas sean de diferente tipo. Por lo
tanto. se nece!ita realizar la conversión de tipos para lograr la transparencia de
fragmentación.
6.2.1 Definición de Bases de Datos Fragmentada con Enfoque Descendente
La arquitectura ANSI/SPARC para sistemas de bases de datos define tres niveles para lograr
independencia de datos:
• Interno - Se percibe la base completa con los detalles de almacenamiento de datos.
• Conceptual - La base de datos completa se percibe en forma abstracta. ignorando los
detalles de almacenamiento.
• Externa - Se percibe la base de datos en forma conceptual y parcial.
Para obtener un correcto LDD se necesita determinar en qué nivel de la arquitectura se
ubican los esquemas de las tablas globales y de los fragmentos. Dado que las tablas globales
son representaciones abstractas. se podría ubicar en un nivel externo. pero como una tabla
global no está destinada a un usuario o un grupo de usuarios. sino a todos los usuarios de la
base de datos. debe ubicarse en un nivel conceptual. a semejanza de una tabla. Por su parte.
el esquema de los fragmentos es también una representación abstracta ya que no incluye los
detalles de almacenamiento que normalmente llegan a nivel interno. Sin embargo. el
concepto de fragmentación de datos introduce en el esquema un aspecto de repartición de
datos que puede considerarse un detalle de almacenamiento. Dado lo anterior. es
conveniente ubicar la fragmentación en un subnivel inferior del nivel conceptual. Pazos y
102
Pérez [Pazos R .. Pérez J 1995) sugieren los siguientes lineamientos para el diseño de las
instrucciones del LDD en enfoque descendente:
• Las instrucciones para la definición de tablas globales deben ser semejante a la definición
de tablas locc.les (ya que pertenecen al mismo nivel).
• La instrucción para la definición de tablas globales no debe involucrar la definición de
fragmentos (por pertenecer a diferentes subniveles).
• La instrucción para la definición de fragmentos debe parecerse a la definición de índices
para sugerir SL. proximidad al nivel interno.
De acuerdo al análisis anterior Pazos y Pérez [Pazos R .. Pérez J 1995] consideran que el LDD
debe incluir como mínimo las siguientes instrucciones para la definición de BDDs
fragmentadas: CREATE FRAGMENTED TABLE, CREATE FRAGMENT, DROP FRAGMENTED TABLE,
y DROP FRAGMENT.
Ejemplos:
Creación de la tabla global
CRl:":ATE FRAGMENTED TABLE empleados
(NwnEmp INTERGER NOT NULL,
Nombre CHAR(30),
Sueldo
Ciudad
FLOAT,
CHAR( 10))
Mandar un fragrrento de la tabla global a la máquina Alfa
CREATE FRAGMENT Empleados! ON Empleados
WHERE Sueldo<= 900 IN ceALFAE
6.2.2 Definición de Bases de Datos Fragmentdada con Enfoque Ascendente
En este enfoque de definición del esquema de la base de datos. los fragmentos se definen
primero como tablas en base de datos independientes: es decir, cada fragmento en una base
de datos diferenta. La definición de los fragmentos se hace posiblemente sin la intenciól') de
llegar a integrarlos en un esquema global. De acuerdo con esto. los fragmentos quedarían
ubicados en el nivel conceptual de la arquitectura ANSI/SPARC. ya que no deberían
distinguirse de cualquier tabla base. En el enfoque ascendente las tablas globales se definen
en términos de los fragmentos. Esto crea alguna dificultad para decidir si pertenecen al nivel
conceptual o al nivel externo. ya que poseen algunas características de las tablas base y de
103
los vistos. Por un !odo, podríamos pensar que los tablas globales pertenecen al nivel externo
yo que (o semejanza de los vistos) su existencia depende de otros tablas; pero por otro lodo {o
semejanza del esq,Jemo conceptual). los tablas globales ofrecen uno representación
completo de lo base de datos, y por consiguiente (o diferencia de las vistas). su propósito no
es limitar el acceso o ciertos usuarios.
Por lo tonto Pozos y Pérez [Pozos R .. Pérez J 1995) sugieren los siguientes lineamientos paro el
diseño de las instrucciones del LDD paro el enfoque ascendente:
• La instrucción paro la definición de fragmentos debe ser igual a la definición de tablas
base, por pertenecer al mismo nivel.
• La instrucción para lo definición de tablas globales no debe involucrar la definición de
fragmentos (ya que pertenecen a diferentes subniveles). y debe sugerir un mopeo de un
subnivel o otro.
• La instrucción para la definición de tablas globales debe parecerse o lo definición de vistas
poro sugerir S'J proximidad al nivel externo.
Por lo tanto el LDD de SQL debe incluir como mínimo las siguientes instrucciones para lo
definición de BDOs fragmentados: CREATE FRAGMENTED TABLE y DROP f"RAGMENTED
TABLE.
Ejemplos:
Se crea el fragmento empleados en la base de datos Alfa en uno máquina de la red:
CREATE TABLE empleados
(NurnErnp INTEGER NOT NULL,
Nombre CHAR(30)
Ciudad CHAR(lO)
Salario FLOAT,
CHECK CONSTRAINT Salario<= 900)
Otro fragmento en la base de datos Beta en otra máquina puede declarase de la siguiente
forma:
CREATE TABLE personal
(NurnErnp INTEGER NOT NULL,
Non.bre CHAR(30)
Sueldo CHAR(lO)
Ple za FLOAT,
CHECK CONSTRAINT Sueldo<= 900)
104
Para crear la tabla global se puede utilizar la siguiente instrucción:
ARTA = SL numpate < 201 ( ART) ART a = SL numpate > 200 (ART)
PROV n.rrprov ra,-t,e ciu:JacJ
'',,[//
~ i~j\ lnarbre [~e 1 ·---
114
Disposición de los fragmentos en los servidores:
SYBASEl
TDAS PROVA ARTA
SYBASE2
TDAS PROVB ARTB
Fig. 7.3 Ejemplo para mostrar la implementación.
SYBASE3
TDAS PROVC ARTB
Como se puede ".>bservar, la tabla TOAS se encuentra replicada en los tres nodos. PROV tiene
fragmentos en cada uno de los nodos y no cuenta con replicas en sus fragmentos. ART está
fragmentada en ARTA y ARTB: ARTA no cuenta con réplicas y ARTB se encuentra en los nodos
SYBASE2 y SYBASE3.
7.2 DISEÑO E IMPLEMENTACIÓN DE MECANISMOS PARA EL MONITOR
GLOBAL DE DISTRIBUCIÓN
En esta sección se describe el prototipo de un monitor global de distribución. el cual
desempeña las funciones de un esquema global. Este monitor se ha descompuesto en varios
módulos que pueden ser perfeccionados en base a nuevas investigaciones.
7.2.l Componentes del Monitor Global de Transacciones.
En la figura 4.6 se señala como componentes del procesador del usuario: manejador de
interfaz con el usuario. controlador de semántica, optimizador de consultas y monitor. de
ejecución. Y en la sección 4.2.1 se explica la función de cada componente.
115
Receptor de Transacciones Globales
Analizador de Semántica de Transacciones Globales
Módulo de descomposición de Transacciones
Optimizador de Consultas
Módulo Calendarizador de Transacciones .Globales
Mód Jlo Despachador Global
lntenase de Comunicación
Manejador c:ie LOO
Actualización de costos
Catálogo Global Tabla de
Ccrtdados Globales
Módulo de administración de candados Globales
Módulo de Recuperación Global
Bilócora Global
Fig. 7.4 Propuesta para la Implementación de un Monitor Global de Transacciones
Ambas figuras f1 •eron consideradas para proponer el diseño que se propone para futuras
investigaciones Pn la figura 7 .3. A continuación se presenta la función de cada módulo y la
forma en que se implementaron algunos mecanismos para su correcto desempeño.
7.2.2 Receptor de Transacciones Globales
El primer módulo tiene como objetivo principal recibir las transacciones que solicitan los
clientes por medio de la interfaz de red (08 Library en nuestro coso con las funciones de Open
Client especificadas en 5. 1 ) .
116
Cliente
Cliente
Fig. 7.5 Receptor de Transacciones
+ Hilos que reciben I peticiones. '+ Calendarizador
Analizador de Semántica de transacciones Globales
Es necesario que este módulo pueda recibir peticiones de los diferentes clientes y colocarlas
en una cola pcru su atención. Como se anotó en 5.3.4 se puede programar un servidor Open
Server que esté escuchando las peticiones de los clientes. les de formato pera su tratamiento
en el monitor global y les asigne prioridad.
Open Server cuenta con la capacidad de trabajar con procesos multi-hilos. por lo que se
puede emplear un proceso. como se muestra en el esquema de la figura 7.4. que reciba
mediante hilos 9iverscs peticiones y las coloque en una cola para su atención según los
criterios que sean convenientes al sistema.
Si se utiliza Open Server se debe considerar que los clientes mandarán la información en el
formato de Sybcse. esto es, utilizarán dbcmd ( ) para preparar su instrucción y la enviarán con
dbsqlexec () . 1:1 Servidor debe tomar la petición mediante un manejador de instrucciones
SRV_LANGUAGE (Ver punto 5.3.4).
La implementación que se presenta con este trabajo no cuente con las librerías de Open
Server. por lo que el monitor recibe las instrucciones de un archivo local. El receptor debe
abrir el archivo donde se localizan las peticiones del cliente y darle formato a las sentencias.
Dado que la sintaxis empleada en el prototipo considera uno o más espacios como un
espacio sencillo. el receptor se encarga de elimina los espacios y pasa la instrucción e un
arreglo global de palabras. De la misma forma. se eliminan las comas y se convier.te a
mayúsculas todas les palabras recibidas. por lo que el sistema no es sensible al tipo de letra. El
arreglo global q·Je conforma la instrucción a procesar será empleado por todos los otros
módulos.
117
7.2.3 Analizador de Semántica de Transacciones Globales.
El analizador revisa las peticiones para verificar que su sintaxis sea correcta y que los objetos a
los que hace referencia se encuentren en el catálogo global. Si la solicitud es correcta. se
pasa al siguiente módulo. de lo contrario se rechaza y se anuncia al usuario que la operación
no puede ser realizada.
El analizador de sintaxis requiere información del catálogo global. por lo cual se realizan
conexiones para verificar tablas y campo.
Receptor de Transacciones Globales
Analizador de Semántica de TrC"nsacciones Globales
Módulo de descomposición --de Transacciones
Manejador de LDD
Calálogo Global
Figura 7.6 Receptor. Analizador de Semántica de Solicitudes globales. Manejador de LDD y
Catálogo Global.
Este módulo fue implementado para revisar los comandos que aparecen en 7.1.1. Si la
instrucción es correcta se continúa con su procesamiento. de lo contrario se notifica al cliente
del error en la ins1rucción. Para resolver el análisis de instrucciones como:
SELECT PROV.NOHBRE, ART.NUMPARTE FROM PROV, ART WHERE PROV.NUMPROV = 20
Se consulta el catálogo global para obtener información sobre existencia de las tablas PROV y
ART. y de los campos NOMBRE y NUMPARTE. Se verifica que las condiciones correspondan al
tipo de campo, es decir. que PROV.NUMPROV sea de tipo INT. Según los resultados. se
continúa o no el procesamiento de la instrucción.
Para la mayor pcrte de consultas al catálogo global se crearon dos archivos con funciones
para el acceso a! catálogo global: cglob.h y sybacc.h. Cglob.h cuenta con funciones
118
como sbexiste _ tabla o sbexiste _ campo que devuelven el valor O si la búsqueda no es
exitosa y de lo contrario devuelven l. Además de funciones como traer_nodofrag que
devuelven una matriz con el nombre de los nodos. y los fragmentos donde existe una tabla
global.
sybacc. h cuenta con la información requerida para accesar el servidor donde se encuentre
el Monitor Global de Distribución y con rutinas para depurar problemas con lo conexión.
7.2 . .lf. Manejador del Lenguaje de Definición de Datos
Como se puede ver en la figura 7.6 el Analizador provee de información tanto al manejador
de LDD como al Módulo de Descomposición y Localización. En la implementación realizada.
las instrucciones modifican directamente las tablas del esquema global y crean las tablas
locales indicadas por las sentencias. Para crear la tabla PROV con fragmentos en SYBASE 1 y
SYBASE2 y SYBASEJ se manda la instrucción:
CREATE TABLE PROV (NUMPROV INT,
NOMBRE CHAR 20, CIUDAD CHAR 2)
FRAGMENTED PROVA AT SYBASEl WHERE FRAGMENTED PROVB AT SYBASE2 WHERE FRAGMENTED PROVC AT SYBASE2 WHERE
CIUDAD = "DF" CIUDAD= "TL"
CIUDAD= "QR"
La implementación sólo permite condiciones sencillas con tablas fragmentadas en forma
horizontal. pero puede ser extendida para fragmentación vertical y mixta en base al catálogo
global.
El archivo define. h cuenta con las funciones necesarios para tratar lo instrucción CREATE y
DROP según la sintaxis establecida en 7.1.1 y hace referencia a funciones de cglobal. h paro
dar mantenimiento al catálogo global. Paro procesar la función anterior es necesario llamar a
funciones como inserta_tabfrag () e inserta_colgls () que den mantenimiento al
catálogo global de datos. De la misma forma, la instrucción DROP TABLE PROV provoca que
el módulo de defnición de datos llame a la función borra tabla () para dar mantenimiento
al catálogo.
Para mantener consistencia al emplear las instrucciones que modifican el catálogo global se
utilizó el protocolo de compromiso a dos fases según 5.3. 1.
119
7 .2.5 Módulo de Descomposición de Transacciones.
Recibe las instrucciones que no trabajan directamente con el LDD sino con la manipulación
de datos. En este módulo se debe convertir la instrucción global en el conjunto de
instrucciones locales equivalentes. que han de procesarse en forma distribuida. Este módulo.
en la implementación, hace uso del nombre de los fragmentos. sin necesidad de especificar el
nodo que procesará la instrucción.
Al recibir una instrucción como:
SELECT PROV.NOMBRE, ART.NUMPARTE FROM PROV,ART WHERE PROV.CIUDAD = "DF"
debe descomponer la sentencia para que se pueda ejecutar en los nodos que contienen las
tables PROV y ART. El trabajo de seleccionar los nodos y eliminar las consultas no necesarias se
deja al siguiente nódulo.
La implementación contiene este módulo en un archivo llamado manipula. h, por ser el
encargado de la manipulación de la información, desde que sale del analizador sintáctico
hasta que se le presenta al usuario un resultado o se modifica la información. Manipula. h
llama a la función localiza () que se encarga de consultar el catálogo global para mostrar
una lista de los nodos que se pueden o deben utilizar en la modificación o consulta. Este
módulo puede ser modificado para observar las anotaciones presentadas en 6.3 junto con las
funciones prepara_ insert () y prepara lectura () .
Para las consultas se emplea un método basado en las inslrucciones ~ELEC'r, FROM y WHERE
siguiendo David Bell [Bell. Grimson 1992). Primero se crea una base temporal en el monitor de
distribución por cada tabla implicada en el from. Se realiza la proyección indicada en el
select de las tuplas involucradas. a cada una de las bases temporales considerando la
condición del where. Se realizan los joins en las bases temporales y se devuelve una
proyección final d usuario. Por último se borran las bases de datos temporales.
Para futuras implementaciones se propone el paso de sentencias SQL a álgebra relacional y
aplicar la teoría que se revisó en la sección 4.5 y la comunicación entre servidores.
120
7.2.6 Optimizador de Consultas.
Recibe las consultas que generó el módulo anterior y elimina los predicados redundantes. de
tal forma que se eliminen las consultas cuyos resultados serán nulos. Este módulo también
debe organizar las consultas. de tal forma que los resultados intermedios sean tan pequeños
como sea posible. En las tablas del catálogo global selecciona. según el tipo de instrucción
(lectura o escritura). aquellos fragmentos que deben ser leídos o modificados y manda a los
siguientes módulos las instrucciones que deben ser ejecutadas en la transacción.
La implementación de este módulo se encuentra en las funciones prepara_insert () y
prepara_lectura (). La primera trae a todos los fragmentos para que sean actualizados.
mientras que la segunda trae los fragmentos más accesibles para realizar consultas ágiles
según el costo que indique la tabla de nodos del catálogo global.
7.2.7 Calendarizador de Transacciones Globales.
Este módulo se encarga de asegurar la ejecución serial de las transacciones utilizando
candados globales o estampillas de tiempo. El objetivo de este módulo es mantener la
concurrencia gtobal. así como el manejo de la recuperación en caso de fallas. Los módulos
de Administración de Candados Globales y de Recuperación Global trabajan en conjunto
con este módulo.
Optimizador de Consultas
Mód· ,10 Calendarizador de
Módulo Despachador Global
Tabla de Candados
~
Módulo de Admlnlslración de Candados Globales
Módulo de Recuperación Global
Bitácora Global
Fig. 7.7 Componentes relacionados con el Calendarizador de Transacciones
121
En la implementación no se incluye este módulo, por lo cual se despachan las consultas según
lo indique el oplimizador de consultas. Sin embargo se puede crear un módulo que tome las
instrucciones que deben ser procesadas e implementar estrategias de candados o estampillas
de tiempo como las que se discutieron en los puntos 4.8 y 6.3. Por otra parte. en el punto 4.7.2
se presentan algunas estrategias a seguir en las transacciones distribuidas y el empleo de la
bitácora para brindar tolerancia a fallas.
7.2.8 Despachador Global.
El último módulo componente del monitor global. es el que se encarga de enviar las consultas
de fragmentos a cada uno de los nodos involucrados en la consulta. Espera las respuestas y
al final de las operaciones manda la respuesta al cliente que solicitó la consulta. La
instrucción dbsqlexec () trabaja en forma bloqueante (ver punto 2.1.5). esperando respuesta
del servidor con quien contacte. y obtiene los resultados de su consulta con la instrucción
dbresults(). El cliente también puede cambiar la instrucción dbsqlexe () por su
equivalente no bloqueante dbsqlsend () y dbsqlok () . Open Server envía los datos a los
clientes con la fun.:ión srv_sendrow.
Dado que la implementación trabaja con Open Client los resultados se mandan al dispositivo
de salida predeterminado con la instrucción dbprrow ( ) y para enviar mensajes de error se
utiliza printf ();
7.3 RUTINAS EMPLEADAS EN LA IMPLEMENTACIÓN
Para la programación del Monitor Global de Distribución se siguió el esquema que se presenta
en la figura 7.8. Algunas rutinas son detalladas a continuación.
7.3.1 Definiciones y Encabezados
• En el archivo moni01. h encontramos las siguientes definiciones
# define TOTINS 6
# define SELECTO # define INSERT 1
/* Numero de instrucciones que se procesan en esta version del monitor
/* Valor de cada instruccion
• Las variables globales
char palabra [100] [30]; /* Arreglo de palabras de la instruccion a procesar. char instruccion [6] [ 10) = ( "SELECT", "INSERT", "DELETE", "UPDATE", "CREATE", "DROP" J;
122
/* Instrucciones validas en esta version. int totpalabras; /* Numero de palabras a procesar en la instruccion actual.
• BlbDotecas de Sybase
# include <sybfront.h> # include <sybdb.h>
/* Bibliotecas Sybase
# include <syberror.h>
•
' # # # # # # # # #
Archivos del Monitor Global
include "receptor.h" /* Receptor de Peticiones include "analOl.h" /* Analizador de Sintaxis include "sybacc.h" /* Acceso a los nodos activos include "cglobal.h" /* Consultas al Catalogo Global include "manipula.h" /* Manejador de LMD include "define.h" /* Manejador de LDD include "2pc.h" /* Protocolo de Compromiso a dos fases include "localiza.h" /* Localizador de Fragmentos include "prepara.h" /* Optimizador de Consultas include "despacha.h" /* Despachador
r· montot.~--~.-1
L~~,~~,~-rn~. l~in~i::~ recept~i-:h .... --1 Receptor de I
lransacciones j ··- -·--------·· ... ,- J __ I
==n analOl.h }- ~-·· manipula. h .Analizador de Sintaxis __
Maneja el LMD . . . . . .
define.h I
Maneja el LDD j
l. ·----- - -- J__ ·-
localiza. h Busca fragemlos
prepara. h -1-Selecciona Fragm~
despacha.h Ejecución } resultados
: • 1 -~--- -- ' - -
' t .... r--~~~~~f!s::i-1... ... ¡
_} 1 Ca lálogo Global 1
- - ,- - - - - - - - - - - - - J
r, • 1 : 1 : 1 : 1
_:_J
1 1 1
-- 2pc.h --] : Consultas al - - ..!
.catálogo ~I~
Fig. 7.8 Esquema de la Programación del Monitor Global de Distribución
123
7.3.2 Conexiones al Monitor Global y a Nodos
Existen dos forrrcs básicas para conexión a nodos en el prototipo:
a) conexion# () Que se emplea para el monitor global y acceso al catálogo de datos. Para
permitir tolerancia a fallas se debe considerar la posibilidad de que en
caso de falla con la conexion3 () (por ejemplo) se ejecute la función
conexion2 () o conexionl () •
b)c nodo usuario(nombre,acceso,nodo[i],servidor[i]); DBSETLUSER(login,nombre); DBSETLPWD(login, acceso); dbproc mul[i] = dbopen (login, servidor[i]); if (dbproc mul[i] == NULL) ( printf ("\nProblemas en la conexion con el nodo \Is \n",nodo[i]); return (O);
El modo de acceso b llama a una función que consulta el catálogo global y devuelve
nombre. clave de acceso y servidor válido, según el nombre que se envíe en el tercer
parámetro. Una vez obtenidos los datos se arregla un registro con las funciones DBSETLUSER,
DBSETLPWD y DBSELAPP. La función dbopen ( ¡ abre la conexión y devuelve un apuntador tipo
DBPROCESS para cada conexión que se abra.
Como se puede observar en el ejemplo. se está trabajando con un arreglo de apuntadores.
ya que se puede abrir más de una conexión a la vez. lo cual es necesario cuando se trabaja
con el protocolo de compromiso a dos fases.
7.3.3 Consultas a Servidores SQL
Para explicar la ;-orma en que se realizan las consultas al catálogo global podemos ver la
estructura de la fJnción sbexiste campo () que verifica la existencia de un campo, después
de recibir el nombre de la tabla y la columna buscada:
int sbexiste_campo(char *contabla,char •concolumna) {
... conexión ...
dbcmd(dbproc,"select ncolumna, ntabla from columnas globales ó dbfcmd(ówhere ncolumna = '%s' and ntabla = ·~,s' ",contabla,concolumna); dbsqlexec(dbproc); return code = dbresults(dbproc);
if (return code == SUCCEED) { dbbind (dl,proc, 1, STRINGBIND, (DBINT) O, tabla); dbbind (dbproc, 2, STRINGBIND, (DBINT) O, columna); dbnextro~·(dbproc);
De la misma forma. cuando se borra una tabla. primero se ejecuta el DROP en todos los
fragmentos con protocolo de compromiso a dos fases y luego se emplea la función:
borra_tabla(char *pntabla) (
125
7.3.5 Protocolo de Compromiso a Dos Fases
• Se puede recibir un arreglo (nodos) que contenga hasta 10 nodos. en los cuales se ejecutarán la:- instrucciones que recibe el parámetro comandos. Tnodos recibe el número de nodos participantes.
int m2pc(char nodo[lOJ (10],char comandos[lO] [400),inl tnodos) [
for(i=O; i < tnodos; i++) 1 dbcmd(dbproc mul[i], cmdbuf); if (dbsqlexec(dbproc mul[i]) != FAIL)
remove xact(dbproc~ commid, l);
close commit(db~roc); printF( "\nTransaccion atomica completa.\n"); return (l);
En caso de que la transacción no tenga éxito debe ser abortada en todos los nodos
Aborta transaccion en 2pc: dbproc mul: Arreglo de procesos a abortar dbproc-com: Proceso coordinador del ,commit commid: identificador del 2pc parttcl.p;¡ntes: Num11ro de proce.st'1:=:; ;:i :lh,)rl"...-1,. ++•++++++++++•+++++++++++++++++++++++++++~++~+;
abortar(dbproc mul, dbproc com, commid, parlici.¡.,antc:c;) DBPROCESS -.dbproc_mul[lOJ; DBPROCESS int int [
*dbproc com; colllmid;
parti,:ipante:::;;
int i; /* Error en alguna parte de la Lran:iüc•:i,:,r, '/ aborl_xact(db¡,roc_corn, commid);
sprintf (cmdbuf, "HOLLBAC~; TRNISAC'l'ION");
for(i=O; i < participantes; i++) ( dbcmd(dbproc mul[i], cmdbuf); if (dbsqlexec(dbpruc mul(i]) !~ FAlL) remove xact (dbproc com, ,,ommid, l); ) -dbexi t (); return;
7.3.6 Lecturas y Escrituras Distribuidas
El prototipo utiliza las funciones localiza_nodofrag(), prepara_insert() y
preprara _ lectura () para la manipulación de datos. La estructuro de la función localiza es
dbfcrnd(dbproc, "where a.ntabla a.nodo=c.nodo",ptabla); dbcrnd(Oorder by nodo, costoo);
'%.s' and b.ncolumna carnpocon and
Localizo devueive los nodos y los fragmentos en donde se encuentro uno tabla global. Ei
resultado se entrego ordenado por costo de acceso poro que prepara_lectura() puedo
seleccionar sólo el nodo morcado con menor costo.
• Se recibe el número de registros localizados por localiza nodofrag y en modo. rfrag y rsal se devuelve el nombre de los nodos y fragmentos o utilizar. Regsal indico el numere de registros o -:onsideror.
Poro realizar moc:ificociones. se siguen estos pasos:
• Se creo uno base de datos temporal.
• Se leen los fragmentos requeridos y se insertan en la base temporal.
• Se modifican los fragmentos en la base de datos temporal.
~ Se borran los fragmentos leídos de sus respectivos nodos.
• Se insertan los fragmentos de la base de datos temporal en los nodos que les corresponda.
Poro crear lo bo.;e de datos temporal se empleo lo función create_tabla_trnp(J, lo cual
creo los tablas requeridos según el catálogo global. Esta función también se utilizo poro los
consultas realizoaas con la instrucción select, lo cual puede implicar el empleo de dos o
más tablas temporales.
128
7.4 EVALUACIÓN DEL SISTEMA
Al compilar el programa principal.moniO l .c. se genera un archivo ejecutable llamado moniO 1.
Este programa solicita el nombre de un archivo que contenga la instrucción SQL a ejecutar.
las instrucciones deben respetar la sintaxis expuesta en el punto 7.1.1.
El ejemplo que se expone a continuación utiliza la descripción del punto 7. 1.3
Al solicitar la instrucción:
CREATE TABLE ART (NUMPROV INT,
NUMPARTE INT, NUMTDA INT, CANTIDAD INr) FRAGMENTED ARTA AT SYBASEl WHERE NUMPARTE < 201 FRAGMENTED ARTB AT SYBASE2 WHERE NUMPARTE > 200 FRAGMENTED ARTB AT SYBASE3 WHERE NUMPARTE > 200
Se crean las tablas ARTA. ARTB la primera en el nodo SYBASE 1. y la segunda en los nodos
SYBASE2 y SYBASE3.
En cambio, al solicitar:
CREATE TABLE 'l'DA (NUMTDA IN'I',
NOMBRE CMR 20, AREA CHAR 6, NUMGTE IN'r) FRAGMENTE O TOA AT SYBASEl FRAGMENTE O TOA AT SYBASE2 FRAGMENTED TOA AT SYBASE3
Se crea la tabla TOA en los tres nodos.
Para crear la tabla global PROV se corrió la siguiente instrucción:
CREATE TABLE PKOV (NUMPROV INT, NOMBRE CHAR 20, CIUDAD CHAR 2) FRAGMENTE O PROvA AT SYBASEl WHERE CIUDAD 'DF' FRAGEMNTED PROVB AT SYBASE2 WHERE CIUDAD 'TL' FRAGMENTED PROVC AT SYBASE3 WHERE CIUDAD 'QR'
Generando tres tablas locales. PROVA en SYBASEl. PROVB en SYBASE2 y PROVC en SYBASE3.
Después de ejecutar los comandos. el catálogo global es actualizado con los nombres de las
nuevas tablas globales y las características de los fragmentos.
129
Para insertar información se corrieron las instrucciones:
Como resultado se insertó lo tupla en los tres nodos.
Al procesar
INSERT INTO ART VALUES (NUMPROV=l,NUMPARTE=203,NUMTDA=l,CANTIDAD=23)
Se obtuvo la tup;a correspondient~ tanto en SYBASE2 como en SYBASE3.
110 1)
Una vez asignadas tuplas a las tablas PROV A. PROVB y PROVC se ejecutó la instrucción:
UPDATE PROV SET CIUDAD= 'QR' WHERE CIUDAD= 'DF'
Como resultado. las tuplas de la tabla SYBASE3 se mandaron a SYBASE 1 con el valor DF en el
campo CIUDAD .
La instrucción delete se ejecutó con la siguiente sentencia:
DELETE FROM PROV WHERE NUMPROV > 6
Con la cual se borraron las tuplas correspondientes a la condición en cada nodo.
La instrucción select se ejecutó de la siguiente forma:
SELECT TOA.NOMBRE, ART.NUMPARTE, ART.CANTIDAD FROM TDA,ART WHERE TDA.NUMTDA = ART.NUMTDA
Y se obtuvo como resultado:
NOMBRE NUMPARTE CANTIDAD
TEPEYAC 1 23
7.5 COMPARA~IÓN CON OTRAS FORMAS DE DISTRIBUIR LOS DATOS
Como se puede observar. las instrucciones empleadas cuentan con transparencia de
fragmentación. y por lo tanto de localización. Si se utilizaran procedimientos almacenados
130
para realizar la jistribución. sería necesario agregar el nombre del servidor a la instrucción.
(ver punto 5.3.2). con lo cual no se brindaría transparencia de localización. Lo mismo
sucedería con el protocolo de compromiso a dos fases.
El empleo de Replication Server permitiría la copio replicada de las tablas. pero no el manejo
de fragmentación horizontal en base a predicados.
En cuanto a Navigation Server, es necesario considerar que el producto está diseñado para
máquinas paralelas. por lo cual. la posibilidad de utilizar cualquier servidor SQL no sería viable.
En algunas ocasiones se recomienda el empleo de disparadores para generar replicación.
Esta opción hace que la localización de los fragmentos dependa de las tablas y no de un
esquema global. perdiendo la oportunidad de mover de nodo las tablas que se encargan de
replicar información mediante disparadores.
7.6 PROPUESTAS PARA FUTURAS INVESTIGACIONES
• En primer lugc.r, es necesario que se consideren tanto la arquitectura propuesta en la figura
7.1 como la estructura del Monitor Global de Transacciones que se muestra en la figura 7.4.
• Se debe modificar la recepción que hace actualmente el Monitor a través de archivos
planos por la recepción de instrucciones mediante las funciones de Open Server.
• Otro módulo que puede hacer uso de los recursos de Open Server es el módulo
despachador global.
• El diseño e implementación del módulo calendarizador de transacciones, con los módulos
para la administración de transacciones y de recuperación. pueden hacer uso de los
módulos con los que se cuenta actualmente para brindar transparencia de fragmentación y
replicación. así como de la teoría expuesta en el ca.pítulo 4.
• Para hacer más eficiente el módulo optimizador se recomienda pasar de SQL a álgebra
relacional. para poder aplicar mejor la teoría que se revisó en 4.5
7. 7 CONCLUSIONES
En este capítulo se ha propuesto un SMBDD homogéneo. como modelo para brindar
transparencia en la fragmentación y distribución. Se ha seleccionada esta arquitectura
131
porque facilita el empleo de un directorio/diccionario global actualizable mediante
instrucciones del lenguaje de definición de datos. que permite transparencia de
fragmentación, de tal forma que las aplicaciones son inmunes a las modificaciones de
localización y fragmentación.
Se presentó en la fig. 7.4 una propuesta para la implementación de un Monitor Global de
Transacciones y se describe la función que debe desempeñar cada uno de sus componentes.
En el punto 7.3 se muestran las principales rutinas utilizadas para la implementación de un
prototipo del Moritor Global de Transacciones que brinda transparencia de fragmentación y
replicación.
Se presentaron los resultados de la ejecución del prototipo. demostrando que este ofrece
fragmentación y replicación transparente. Y se comparó el empleo de este mecanismo con
los que generalmente se utilizan para la distribución de datos.
132
A lo largo de este trabajo hemos revisado algunos mecanismos y técnicas que se emplean
para crear siste TICS distribuidos transparentes. escalables. tolerantes a fallas y que brinden
mayor poder d~ cómputo que los sistemas centralizados. Se han expuesto las principales
tendencias en el área del manejo de bases de datos. subrayando la importancia de los
Sistemas Manejadores de Bases de datos Distribuidos. al igual que los fundamentos teóricos
para su diseño y las principales técnicas para su implementación.
Generalmente los proveedores de Sistemas Manejadores de Bases de Datos de tipo
comercial. sólo ofrecen una serie de mecanismos aislados para trabajar con dos o más
servidores SQL como opción para distribuir la información. Estos procedimientos carecen de
transparencia en la fragmentación y replicación de datos. exponiendo las aplicaciones
desarrolladas por los programadores a modificaciones en la estructura global y a
inconsistencias.
En el documento se presentaron los principales tipos de arquitectura para la implementación
de Bases de Datos Distribuidas y se optó por desarrollar un sistema de base de datos
distribuida homogénea mediante los mecanismos de Open Client de Sybase para demostrar
que es posible crear un sistema que ofrezca transparencia en fragmentación y replicación
con inmunidad a modificaciones en la estructura global. Se propuso el diseño de este sistema
y se explicó la función que debe cumplir cada uno de los componentes del mismo. Se
implementó un prototipo que maneja las instrucciones CREATE y DROP para la definición de
datos; e INSERT, DELETE, UPDATE y SELECT para la consulta y manipulación de la
información.
Para lograr la transparencia en fragmentación y replicación fue necesario crear un Monitor
Global de Distrinución. el cual cuenta con catálogos de la estructura de los datos y los
servidores involucrados en el sistema. Esta estructura. como los mecanismos mencionados en
la sección 7.3 son la base del sistema. pero deben ser perfeccionados para desarrollar
sistemas más robustos. por lo que se espera que tanto el diseño como las implementaciones.
puedan ser retomados para futuras investigaciones.
Se apunta como de especial interés el desarollo del módulo de calendarización de
transacciones globales. con los submódulos de administración de candados o estampillas de
133
tiempo y la bitácora para recuperación de transacciones. Así como el empleo de Open
Server para optimar la recepción y devolución de información.
Los sistemas disfribuidos seguirán su desarrollo. impactando cada vez más la forma de
desarrollar sistemas. La investigación en esta área es de gran importancia. tanto para innovar
como para adaptar la tecnología que surge en productos comerciales cada vez con mayor
frecuencia.
la mejor forma d-.:, comprender los conceptos de distribución y de valorar su funcionalidad es
mediante la implementación de Sistemas Distribuidos. Open Server y Open Client de Sybase
son herramientas poderosas y diseñadas para crear ambientes distribuidos abiertos de
calidad.
Este trabajo ha tenido como inspiración la necesidad de hacer más eficientes los sistemas de
información. La globalización y el desarrollo que presentan las redes de comunicación.
agilizarán la presencia de opciones distribuidas en los SMBD. por lo cual. debemos responder
ante los requerimientos. ofreciendo técnicas y diseños adecuados a nuestro entorno. Es un
esfuerzo para mostrar un camino a seguir y una puerta que se abre para enfrentar nuevos
retos.
134
[Atkinson. Bancilhon 1989) Atkinson. M; Bancilhon. F; DeWitt. D.; Dittrich. K; Marier,D; Zdonik, S "The Object-Oriented Database System Manifesto." Proceedings of Deductive and Object Oriendte Database. Kyoto. Jopan . December 1990.
[Abósolo.Blanco.Mendieta 1994] Abósolo. José: Blanco R.: Mendieta F. "Metodología de Diseño de Bases de Datos Distribuidas y su Implantación y su Implementación sobre Oracle 7".CLEI Panel 94. Ciudad de México, septiembre de 1994.
[Bell, Grimson 1992] Bell David, Grimson Jane. "Distributed Data Base Systems" Addison-Wesley 1992.
[Belford.1982) Belford, G. "Distributed Database Techniques: An assessment", in Current Directions in Database Managment Development. New York. Auerbaeh. 1982.
[Bobak. 1993] Bot::.ak. A. "Distributed and Multi-Database Systems", Bantam Books. 1993
[Ceri. Pelagatti 1984) Ceri. S.: Pelagatti. G. "Distributed Databases Principies & Systems" McGraw Hill Computar Science Series, (1984).
[Codd 1970) Cood. E.F. "A Relational Model For larga Shared Data Banks" . Communieations of the ACM. vol 13. número 6 (junio 1970). páginas 377-387.
[Cristian 1991) Cristian. F. "Understandig Fault-Tolerant Distributed Systems" , Communieations of the ACM. vol. 34. no 2 (1991)
[Eswaran 1976) [swaran K .. et al "On th Notions of Consistency and Predieate loeks in a Relational Database System". Communication of the ACM. 19:11.1976
[Korth. Silbersehafz 1993] Korth. H & Silbersehafz. A. "Fundamentos de Bases de Datos", Sengunda Edición Me Graw Hill ( 1993).
[Lamport 1978) Lamport, Leslie. "Times. clocks and ordering of events in a Distributing System". Communieations of the ACM. Vol. 21. No. 7, (julio 1978).
[Levin y Morgan, 1975] Levin. K.O.: Morgan H.L. "Optimizing Distributed Data Bases: A Framework for Researeh".ln Proc. National Computer Conf.. 1975, pp. 473-478.
[litwin. 1988) litwin. W."From Database System to Multidatabase Systems: Why and How".ln Proe. British National Conferenee on Databases (BNCOD 6). W.A. Gray (de). Cambridge: Cambridge Unive. sity Press, 1988. pp. 16 1-188
[Mefadden.Hoffer 1994) Me Fadden. Fred; Hoffer Jeffrey "Modern Database Managment". Fourth Edition. The Benjamin/Cummings Publishings ( 199 4). [MeGoveran. Date 1992) MeGoveran O; Date C.J. "A Guide to Sybase and SQL Server". Addison-Wesley (1992).
[Pelagatti. Schreiber] G. Pelagatti and F.A. Schreiber. "A Model of an Access Strategy in a Distributed Database." Proc. IFIP TC-2 Working Conference on Data Base Architecture. G. Brancchi and G. M. Nijissen. eds .. North-Holland. 1979.
[Pazos R .. Pérez J 1995) Pazos R; Pérez J. "Extensión al Lenguaje SQL para el logro de Transparencia de Fragmentación en Bases de Datos Distribuidos" Conferencia en Zacotepec Mor. 1995 Instituto de Investigaciones Electrices.
[Rennhackkamp M. 1996) Rennhackkamp. M. "An Analysis Of The Stregths And Weaknesses Of The Big Six Databose Servers". DBMS online. november 1996.
(Silberschotz. Stonebroker 1990) M Silberschatz. A.; Stonebroker. M; Ullmon. J. "Dotabase Systems: Achievements and Opportunities." Communications of the ACM (October 1991).
[Simon 1995) Simon. A. "Strategic Dotabose Technology: monogment of the yeor 2000". Morgan Kaufmorn Publishers. lnc. (1995)
[Sinha 1992) Sinha. A. 1992 "Client-Server Computing" Comunication of the ACM 35 (July):77-98
[Stonebroker. 1988) Stonbraker. M. "Readings in Database Systems. San Mateo. Colif. Morgan Kufmann. 1988.
(Stonebral<er. Ro·Ne 1990) Algunos miembros del comité: Michael Stonebral<er de lo Universidad de California. Berkeley: Lorry Rowe de la Universisd de California. Bruce lindsay de investigación IBM: Jim Gray de Tandem; Mike Carey de la Universidad de Wisconsin y David Beech de Orocle. 1'1ird-Generotion Doto Base System Manifesto", Proceedings IFIP WG2.6 Conference on Object Oriented DAtabases. Windermere. England (juilio 1990)
[Tsichritzis and Kl;Jg, 1978) D.C. Tsichritzis ond A. Klug. "The ANSI/X3/SPARC DBMS Fromework Report of the Study Group on Database Managements Systems." lnf. Syst.(1978).1:173-191.
136
t
2PCP 2PL ATO ATL Attr BDD BOOO CP 0/DG 0/DL DF ECL ECG EIL EE EEG EEL JN LOO LMO MBDOO NJN NSJ PJ RTM(x) RPC SJ SL SMBD SMBOO UN WTM(x)
Protocolo de compromiso a dos fases Trllnsacción asegurada a dos fases Administrador de transacciones distribuidas Administrador de transacciones locales Atributo Base de datos distribuida Base de datos orientada a objetos Producto cartesiano Directorio/diccionario global Oiiectorio/diccionario local Dif '3rencia Esquema conceptual local Esquema conceptual global Esquema interno local Esquema externo Esquema externo global E!quemo externo local Join Lenguaje de definición de datos Lenguaje de manipulación de datos Manejador de bases de datos orientado a objetos Join natural Semi join natural Proyección Estampillo mayor de lectura Lla'Tlada a procedimientos remotos Semi-jo in Selección Sistema manejador de bases de datos Sistema manejador de bases de datos distribuidas Unión Estcmpilla mayor de escritura