manejo de fragmentación y replicación transparente en
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
~INl!DiC!c. IOif riij~~úll.S> ........................................................................................................................... 9
~ ilNlffiO!t>~CC.!ÓINl ............................................................................................................................... 10
2 CONIDTO ijflNlf!K<úíJL ................................................................................................................... 13
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 l05 515TCMA5 f ílM fl MfU1tJO Dt !NfOW<MílCIÓN bk!5DC rlNALE.5 DC l05 '°' J dlJ L05 so· 1 .................................................................................................................... 26
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.6 HIPERTEXT0 .............................................................................................................. 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
~ l05 SI.STU1úllS MANrJ~bO~f.5 IM:: ~~5r.5 bf b~T05 DI.SnUlf''JlbOS ....................... .34
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 TRANSPARENCIA ..................................................................................................... 44
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 ADMINISTRACIÓN ................................................................................................ 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 ~lc:W(~rAJM!lc~TrAl5 fdlJfüí~ (Ou'!J-SiTOC\\JJm \\JJ~ 5!S>UT1\rill í\\tfll~lCJIAJ!DJO~ IO)IE DrAISilr.5 ble brAIT05 bl5Tr<.l~lb0 .............................................................................................................. 11
5.1 LA ARQUITECTURA CLIENTE SERVIDOR ................................................. 77 5.2 LENGUAJES TRANSACCIONALES ................................................................... 80
5.2.1 El Nombre de los Objetos en Transact-SQL.. ....................... 80
5.2.2 Lenguaje de Definición de Datos ................................................. 80
5.2.3 Lenguaje de Manipulación de Datos .......................................... 81
5.2.4 Lenguaje de Control... ........................................................................ 82
5.2.5 Instrucciones para el Control de Flujo ................................... 83
5.2.6 Declaración de Variables .................................................................. 84
5.2. 7 Procedimientos Almacenados ........................................................ 84
5.2.8 Disparadores (TRIGGERS) ............................................................. 86
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
71 lM~r.lflJo f illi\W'l!crí\[IN!r~c~ó~ ffj¡[c 'lllNI rUOINlffO~ ~lO!g}ríll ffj¡[é rD>tSif!K\ilD~(!Ó~ ............ 109
7.1 DISEÑO DEL SISTEMA ......................................................................................... 109
7.1.l Instrucciones a Procesar ................................................................ 110
7.1.2 Catálogo de Datos ............................................................................... 112
7.1.3 Bases de Datos para Implementar Ejemplos ...................... 114 ·
7.2 DISEÑO E IMPLEMENTACIÓN DE MECANISMOS PARA EL MONITOR GLOBAL DE DISTRIBUCIÓN ............................................. 115
7.2.l Componentes del Monitor Global de Transacciones ...... 115
7.2.2 Receptor de Transacciones Globales ........................................ 116
7.2.3 Analizador de Semántica de Transacciones Globales .... 118
7.2.4 Manejador del Lenguaje de Definición de Datos ............. 119
7
rtíQIHtl
7.2.5 Módulo de Descomposición de Transacciones ................. 120
7 .2.6 Optimizador de Consultas .............................................................. 121
7.2. 7 Calendarizador de Transacciones Globales .......................... 121
7.2.8 Despachador Global... ......................................................................... 122
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
6 {01Nltl~5~ÓINl .................................................................................................................................... 133
si iylili:)l!(()qjlf(,~u,[h1! .................................................................................................................................. 13s
\\Ji~ .05ill~(~O [íllt. '.1>1(~11.«l~J ...................................................................................................................... l 3 7
8
Fig. 4.1
Fig. 4.2 Fig. 4.3 Fig. 4.4 Fig. 4.5
Fig. 4.6 Fig. 4.7 Fig. 4.8 Fig. 4.9 Fig. 4.10 Fig. 4.11 Fig. 4.12 Fig. 4.13 Fig. 4.14 Fig. 4.15 Fig. 4.16 Fig. 4.17 Fig. 4.18 Fig. 4.19 Fig. 5.1 Fig. 6.1 Fig. 6.2 Fig. 6.3
Fig. 7.1 Fig. 7.2 Fig. 7.3 Fig. 7.4
Fig. 7.5 Fig. 7.6
Fig. 7.7 Fig. 7.8
YA<UNII
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:
• Interacción con el gestor de archivos.
• Implementación de la integridad.
• Implementación de la seguridad.
• Copias de respaldo y recuperación.
• Control de concurrencias.
25
J l05 5!5T!cr'M5 rú'J~(líJ !El NINJILJO [O)[ !INJW'Omú'JC!ÓINJ [C)r,5[)¡[ rirMl[[j¡ [O)[ l05 W'J L~
l05'°' J
Alan Simon [Simon 1995) afirma que el estudio de la historia de los sistemas de información.
desde el almacenamiento en archivos. hasta la época actual es importante. porque aún en la
actualidad se hace uso de estas técnicas. Es necesario conocer el modelo con el que se está
trabajando para poder interactuar con él o para migrarlo a un sistema más eficiente. Entre los
modelos a considerar señala: modelos anteriores a los SMBD. bases de datos jerárquicas y de
redes. el modelo relacional. las bases de datos distribuidas. bases de datos orientadas a
objetos. bases de datos inteligentes. el hipertexto e hipermedia y el lenguaje de las bases de
datos.
3.1 SISTEMAS BASADOS EN ARCHIVOS
Los primeros sistemas de información almacenaban los datos en archivos que trabajaban en
forma serial. Un archivo maestro se actualizaba con un archivo de transacciones, generando
un nuevo archivo maestro. El surgimiento de los discos que permitían acceso directo tanto
para lectura como para escritura permitieron la posibilidad de realizar las 1ransacciones
directamente sobre los archivos maestros sin necesidad de regenerarlos con procesos seriales.
Los principales problemas que genera este modelo es la repetición de datos en diferentes
archivos con frecuentes inconsistencias y dificultad para compartir datos.
3.2 BASES DE DATOS JERÁRQUICAS Y DE RED
En 1968 IBM crea el lnformation Management Syslem (IMSJ con un lenguaje para el manejo de
información Data Lenguage/1 (DL/1). El modelo jerárquico en general y DL/1 en específico se
implementa mediante estructuras de árboles. con apuntadores. Una de sus desventajas es
que su esquema no corresponde al mundo real. Las bases de datos jerárquicas proveen
apuntadores entre diferentes árboles de dalos. pero el procesamiento de dalos a través de
enlaces puede ser muy complicado. Sin embargo. el modelo permite: reducir los dalos
duplicados. asociar lógicamente los datos y crear modelos del sistema de información.
Al mismo tiempo General Electric crea el sistema lntegrated Data Store (IDSJ, el cual
corresponde a un modelo de base de datos de red. La comunidad de estándares pide que
se formalice el modelo de redes y la Conference on Data Systems Languages (CODASYL)
formó el Data Base Task Group (DBTGJ el cual publica un reporte en 1969 que se actualiza en
26
1971. Una de las mayores contribuciones del modelo del DBTG fue la introducción de un LDD
y LMD. como lenguajes formales para definir y manipular respectivamente el contenido de las
bases de datos.
En contraste con las bases de datos jerárquicas. las bases de datos de red no necesitan un
nodo raíz. pero la forma de unir los datos sigue siendo mediante el uso de apuntadores.
3.3 LAS BASES DE DATOS RELACIONALES
Desde junio de 1970. el Dr. E. F. Codd publicó un documento titulado "A Relational Model of
Data for Larga Shcred Date Banks" [Codd 1970] con el cual se inicia el trabajo con modelos
relacionales para bases de datos. Entre las características más importantes del modelo. Codd
señalaba:
• Describir los datos de forma natural, sin añadir estructures para su representación en la
computadora.
• Proveer une base matemática pera el tratamiento de derivación. redundancia y
consistencia de los datos.
• Proveer independencia de los datos con respecto e su representación física.
Los puntos anteriores pretendían ayudar al desarrollador e desligarse del problema de le
estructura física de los datos. para permitirle una forma más eficiente de crear. modificar.
eliminar y consultar la información a le que hacían referencia sus programas. El elemento
básico de esta teoría fue la relación. cuya estructura resultaba familiar al trcbajcrlc como
tabla, formada por columnas y renglones: con algunas restricciones para permitir el empleo
de operaciones relacionales cuyo resultado generaba nueves relaciones. Los operadores
relacionales contaban con ciertas características como conmutatividad. distributividad y
asociatividad.
A principio de los 80' s se empezaron a comercializar algunos productos inspirados en las bases
de datos relacionales por parte de IBM. Oracle Corporation. Relational Technology. Sybase y
otras compañías. confirmando que las bases de datos relacionales podían modelar el mundo
real.
Junto con el crecimiento de las bases de datos relacionales, inicia el crecimiento de las
computadoras personales con 4 tipos de programas de aplicación básicos: procesadores de
texto. hojas de cálculo. graficadores y manejadores de bases de datos. Algunos proveedores.
como Ashton-Tate. implementaron la teoria relacional de bases de datos a productos para
27
PC. con lo que se popularizó el uso de bases de datos relacionales para actividades sencillas
como impresión de etiquetas o reportes financieros. La facilidad con la que las tablas
relacionales podían ser definidas y manejadas. dotaban de gran poder a equipos pequeños.
De esta forma las bases de datos relacionales se han empleado tanto en PC's como en
minicomputadores y Main Frames desde finales de los 80' s hasta la presente década.
3.4 MODELOS DE BASES DE DATOS DISTRIBUIDAS Y EXTENDIDAS
Dado el creciente número de computadoras y la tendencia a descentralizar la información. el
modelo relacional requiere de cierto grado de distribución. El empleo de mayor número de
equipos que atienden a menos usuarios. trae como ventajas desarrollos más adaptados a los
requerimientos en menor tiempo y la capacidad de controlar en forma local los procesos que
corresponden a cada área. Todo esto. promovido por varios esfuerzos en el área de
investigación desde 1980.
Las bases de datos distribuidas son una colección de múltiples bases de datos que están
interrelacionada:. y distribuidas en una red de computadoras. Mientras que los Manejadores
de Bases de dat9s Distribuidas son programas a través de los cuales se manejan estas bases de
datos. procurando que este manejo sea generalmente transparente al usuario [Ózsu.
Valduriez 1991). Ceri y Pelagatti [Ceri. Pelagatti 1984) distinguen dos aspectos importantes que
debe considerar un sistema de este tipo:
• La distribución. que implica que los datos no residen en la misma computadora.
• Correlación lógica. es dec¡¡., que los datos tienen algunas propiedades que los unen. de tal
forma que se pueda distinguir una base de datos distribuida (BDD) de un conjunto de bases
de datos que residen en diferentes computadoras unidas por una red.
Por lo que definen a las bases de datos distribuidas de la siguiente forma: "Una base de datos
distribuida es una colección de datos, los cuales estás distribuidos sobre las diferentes
computadoras de una red de cómputo. Cada nodo de la red tiene capacidad de
procesamiento autónomo y puede ejecutar aplicaciones locales. Cada nodo también
participa en la ejecución de por lo menos una aplicación global. la cual requiere acc.esar
datos de varios nodos usando un subsistema de comunicación".
La replicación es un mecanismo con el cual se obtienen varias copias idénticas de
información en diferentes localidades con lo cual se logra mayor disponibilidad de datos.
posibilidades de procesamiento paralelo. tolerancia a fallas y autonomía. Por otra parte la
28
fragmentación reparte la información en varias localidades. con el objetivo de ahorrar
espacio de almacenamiento en cada localidad y brindar autonomía. Una BDD debe hacer
uso de ambas técnicas para eficientar sus procesos.
Otra área de investigación promovida desde 1980 ha sido la extensión del modelo relacional
de bases de datos en respuesta a movimientos para el modelado de semántica. cuyos
investigadores exploran caminos para captar más significados que los posibles con una
estructura de base de datos relacional. las bases de datos temporales. el modelo híbrido
relacional-orientado a objetos y otros modelos se basan en los modelos extendidos.
3.5 BASES DE DATOS ORIENTADAS A OBJETOS
El modelo relacional. al trabajar con renglones y columnas. hace difícil la implementación de
algunas aplicaciones como el diseño a través de computadora y el diseño de software
asistido por computadora. la investigación sobre las bases de datos orientadas a objetos
sigue dos caminos: uno que es independiente del modelo relacional y otro que las toma
como complemento del modelo relacional.
las bases de datos orientadas a objetos (BDOO) están construidas en base a los objetos. Tanto
las BDOO como los Manejadores de Bases de Datos Orientadas a Objetos (MBDOOJ son
relativamente nuevos comparados con las bases de datos relacionales por lo que existen aún
varias divergencias en su terminología. implementación y desarrollo.
3.6 HIPERTEXTO
Hace varios años, Apple inició los trabajos en un área conocida como hipertexto
comercializando un producto Macintosh conocido como HyperCard™. El hipertexto toma un
punto de entrada en una red de datos y a través de ese punto tiene acceso a varios puntos
de donde puede obtener. insertar. actualizar o borrar información. En un ambiente hipertexto
no se requiere de accesos mediante lenguajes de programación ni lMD para trabajar con los
datos. Simplemente se selecciona un aspecto desde el cual se pueden realizar otros accesos
de acuerdo a nuevas selecciones.
3.7 BASES DE DATOS INTELIGENTES
Las Bases de Datos Inteligentes surgen por la combinación de Sistemas Expertos y Bases de
Datos. Un tipo de Bases de Datos Inteligentes son las Bases de Datos Deductivas. las cuales se
caracterizan por extender el modelo relacional. las base de datos deductivas aumentan el
29
poder de las expresiones mediante lenguajes de consultas que permiten recursión. Otro
aspecto importante de las bases deductivas es su capacidad de integrar reglas en el uso de
las bases de datos y de deducir información nueva, en base a la información existente. Para
conocer más sobre estas bases. un buen inicio es [Ózsu. Valduriez 1991) en el punto 15.3.
3.8 TRABAJOS PARA ENCAUSAR LA INVESTIGACIÓN DE SISTEMAS
MANEJADORES DE BASES DE DATOS EN LOS 90's
En los últimos años se han realizado algunos esfuerzos para dirigir las investigaciones sobre
SMBD. este apartado nos indica algunos de ellos.
3.8.l Manifiesto de los Sistemas de Bases de Datos de la Tercera Generación
En julio de 1990. el Committee for Advanced DBMS Funtion publicó un documento para un
conferencia en Windermere. Inglaterra. titulado "1hird-Generalion Data Base System
Manifesto" [Stonebraker. Rowe 1990). En la conferencia los autores consideran que existen 2
generaciones en el desarrollo de bases de datos:
La primera generación que abarca las bases de datos jerárquica y de red. las cuales forman
los primeros sistemas que unifican la definición de datos y un lenguaje para la manipulación
de los mismos.
La segunda generación. formada por las bases de datos relacionales cuyo mayor logro es la
obtención de lenguajes no procedurales para la manipulación de datos y provee un
substancial grado de independencia de datos.
En el manifiesto los autores señalan que las bases de datos relacionales no se adaptan a
ciertas aplicaciones. como las que implican Diseño Asistido por Computadora. hipertexto y
multimedia por lo que se requiere de mejores SMBD. El manifiesto cubre lo siguiente:
Las Afirmaciones
Afirmación 1. Los SMBD de la tercera generación deben brindar servicios en tres áreas:
• Administración de Datos
• Administración de Objetos
• Administración de Conocimientos
30
Afirmación 2. los SMBD de la tercera generación deben retomar los SMBD de la
segunda generación. entendiendo que la mayor contribución del mundo relacional
(los accesos no procedurales y la independencia) no deben ser comprometidos por los
sistemas de tercera generación.
Afirmación 3. los SMBD de tercera generación deben ser abiertos a otros subsistemas.
las herramientas para tomar decisiones deben tener lenguajes de cuarta generación
(4Gls). operaciones con datos remotos y capacidad distribuida.
Proposiciones
Proposición 1.1 los SMBD de la tercera generación deben tener una estructura propia
completa. A corto plazo. las características generales de la orientación a objetos son
propuestas como una extensión de las SMBD de la segunda generación más que como
un reemplazo. Las caracteristicas de la orientación a objetos son f acilitadores de una
arquitectura totalmente nueva de SMBD. más que una extensión del actual modelo.
Proposición 1.2. la herencia es una buena idea.
Proposición 1.3. las funciones (métodos. procedimientos de bases de datos) y
encapsulado son buenas ideas.
Proposición 1.4. los identificadores únicos para los registros podrían ser opcionalmente
asignados por el SMBD.
Proposición 1.5. las reglas (disparadores) llegarán a ser una de las características más
importantes en los próximos sistemas. Ellas no deberían estar asociadas con una
función o un conjunto de funciones específicas.
Las siguientes proposiciones pretenden asegurar que se preserve la integridad de los SMBD's
de la segunda generación en base a la segunda afirmación:
Proposición 2. 1. la navegación hacia un dato deseado debe ser usada sólo como un
último recurso. En otras palabras. no se debe regresar al uso de apuntadores de las
bases de datos jerárquicas o de redes.
Proposición 2.2. Debe haber por lo menos dos implementaciones por colección. una
usando enumeración de miembros y otra usando el lenguaje de consulta para
especificar los miembros.
Proposición 2.3. Las vistas actualizables son esenciales.
31
Proposición 2.4 . Se debe separar el modelo físico de los niveles conceptual y de visto al
especificar las características de la tercera generación. (Evitar índices. cluster,
buffers ... ).
Las siguientes proposiciones se refieren a los sistemas abiertos.
Proposición 3. 1. La tercera generación debe ser de soportar varios lenguajes.
Proposición 3.2. Deben concordar el tipo de sistemas de la tercera generación y el
lenguaje que estos utilicen .. pero se debe evitar los errores de resistencia que causan
palabras de SQL.
Proposición 3.3. A pesar de presentar varios defectos. SQL tendrá un papel en el mundo
de la tercera generación.
Proposición 3.4. Las consultas expresadas en SQL y sus resultados deberán ser el nivel
más bajo de comunicación entre clientes y servidores.
3.8.2 Manifiesto de los Sistemas de Bases de Datos Orientados a Objetos
Varios meses ant~s del manifiesto. tratado en el punto anterior. se publicó otro documento por
otro grupo "The Object-Oriented Database System Manifesto." (Atkinson, Bancilhon 1989). Así
como el Manifiesto de los SMBD de la tercera generación fue una defensa de los sistemas
híbridos, este manifiesto busca un modelo orientado a objetos puros. Este documento
presenta 13 puntos para las bases de datos orientadas a objetos.
3.8.3 El Grupo de Trabajo de la National Science Foundation (NSF)
En febrero de 1990 la NSF forma un grupo para identificar los factores tecnológicos que
servirán como funciones de fuerza para los avances en la tecnología de bases de datos y las
necesarias investigaciones básicas correspondientes para esa tecnología. En este grupo
participan personas que trabajaron en el Manjfiesto de los SMBD de la tercera generación y
otros que trabajaron en el Manifiesto de las bases de datos orientadas a objetos.
Hubo tres principales conclusiones acerca del futuro de las bases de datos y la administración
de información [Silberschatz. Stonebraker 1990):
1) Muchos de los avances tecnológicos del principio del siglo XXI que sostendrán la industria y
los avances tecnológicos. dependerán de una tecnología radicalmente nueva de bases de
datos. que actualmente no está bien definida y que requiere de investigación intensiva.
32
2) La próxima generación de aplicaciones de bases de datos tendrá poco en común con las
aplicaciones de procesamiento de datos actual.
3) La cooperación entre diferentes organizaciones científicas. de ingeniería y comercio
requerirán bases de datos distribuidas heterogéneas a gran escala.
Dos áreas fueron particularmente identificadas como candidatas para investigación intensiva:
a) Las aplicaciones para los SMBD de la próxima generación.
b) Las bases de datos distribuidas heterogéneas.
En el área de aplicaciones para la próxima generación. el reporte del grupo de trabajo
identificó varios aspectos:
1 Opciones para almacenamiento masivo
2 Interdependencia de las aplicaciones
3 Minería de datos
4 Aplicaciones multimedia
5 Nuevas clases de datos
6 Reglas para procesamiento
7 Nuevos modelos de datos
8 Escalabilidad de los algoritmos para SMBD
9 Paralelismo
10 Medios alternos de almacenamiento
11 Transacciones de larga duración
12 Posibilidad de mantener diferentes versiones
La otra área de investigación recomendada fue la investigación de bases de datos
heterogéneas distribuidas.
33
En el punto 3.4 se definió lo que son los Sistemas Manejadores de Bases de Datos Distribuidas
(SMBDD). Ahora profundizaremos en su clasificación. arquitectura y diseño.
En 1987 C.J. Date publicó 12 reglas para las Bases de Datos Distribuidas. las cuales son:
1) Autonomía de localización:
localmente administrados; lo
los datos locales deben tener pertenencia local y ser
cual incluye funciones de seguridad. integridad y
almacenamiento. Las excepciones se dan con restricciones distribuidas en múltiples nodos y
cuando las transacciones deben ser administradas por nodos externos.
2) No confiar en un nodo central para ningún servicio en particular: al seguir esta regla se
evitan cuellos de botella y se permite la descentralización requerida.
3) Operación Continua: no debe haber interrupciones por añadir nodos o eliminar nodos en
un ambiente distribuido.
4) Independencia de Localización: ni los usuarios, ni las aplicaciones deben necesitar conocer
el lugar donde los datos están fisicamente almacenados.
5) lndependencja de Fragmentación: Los fragmentos deben ser almacenados y administrados
por el SMBDD sin necesidad de las indicaciones de un usuario o una aplicación.
6) Independencia de replicación.
7) Procesamiento distribuido de las consultas: El procesamiento de una consulta debe ser
procesado en modo distribuido.
8) Administración de transacciones distribuidas: El principio de transacción y de concurrencia
debe ser manejado en forma dislribuida.
9) Independencia de Hardware: El mismo SMBOD debe correr en diferentes máquinas y debe
participar de la misma forma en todo el sistema.
10) Independencia del sistema operalivo.
11) Independencia de red: Los nodos deben poder ser conectados sobre una amplia
variedad de redes y ambientes de comunicación.
12) lndependenda de SMBD: Debe ser posible para un SMBD local participar en un ambiente
SMBDD.
4.1 VENTAJAS Y DESVENTAJAS
Ceri y Pelaga11i [Ceri, Pelagatti 1984) señalan que existen varias razones para desarrollar bases
de datos distribuidas y listan las siguientes motivaciones principales:
34
• Razones económicas y organizacionales.- Esto se da tanto en empresas descentralizadas.
en las cuales se requiere la administración por entidad. como en lugares donde no se
quiere comprometer la inversión en un sólo equipo dedicado al procesamiento de toda la
información.
• Interconexión de las bases de datos existentes.- Las bases de datos distribuidas son una
solución natural cuando varias bases de datos ya existen en una organización y surge la
necesidad de realizar aplicaciones globales.
• Crecimiento Incremental.- Si una organización crece mediante la creación de nuevas
organizaciones relativamente _independientes. las bases de datos distribuidas son una
opción que permite brindar servicio a las nuevas unidades con un mínimo impacto en la
estructura existente.
• Disminuir la carga de las comunicaciones.- El hecho de que varias aplicaciones se realicen
en forma local y no en una máquina remota reduce el tráfico en la red; por lo que la
maximización del uso de aplicaciones locales es uno de los objetivos primordiales en el
diseño de bases de datos distribuidas.
• Consideraciones de rendimiento.
• Disponibilidad y confiabilidad.- Gracias a que las bases de datos distribuidas se diseñan con
cierto grado de redundancia. permiten que existan datos importantes en varios puntos del
sistema. más cerca de los usuarios y con posibilidad de accesar una copia en caso de que
uno de los nodos falle.
Por otra parte Ózsu y Valduriez [Ózsu. Valduriez 1991 J citan las siguientes ventajas y
desventajas:
Ventajas: Autonomía local, mejor rendimiento. mayor disponibilidad y confiabilidad. menor
costo. escalabilidad y facilidad para compartir recursos.
Desventajas: Falta de experiencia. complejidad. inversión en comunicaciones. conlrol
distribuido. dificultad para implementar seguridad. resistencia al cambio
4.2 ARQUITECTURA DE UNA BASE DE DATOS DISTRIBUIDA (BDD)
Ózsu y Valduriez [Ózsu. Valduriez 1991) sugieren que antes de especificar una arquitectur9 de
BDD. se considere las formas en las que múltiples bases de datos pueden estar juntas
compartiendo recursos y datos. Ellos usan una figura similar a la figura 4. l para clasificar la
relación. según su grado de distribución. autonomía y heterogeneidad.
35
Distribución islemo homogéno distribuido
:- . ---...... -............... --............ -........ -... .
.. .................................... ·.
Heteroqene~Ba,e de datos heterogénea e integrado
.. . .
Autonomía
islcmo mullibase do dolos
mullibose de dolos heterogéneo y distribuido
Fig. 4. 1 Alternativas de implementación en SMBDD
Distribución. Grado en que los datos se encuentran en diferentes nodos.
Autonomía. Distribución del control y no de datos. Es el grado en que la SMBD actúa
independientemente.
Heterogeneidad: diferencia en HW. protocolos de comunicación. datos. lenguajes para
realizar consultas, protocolos de transacción.
Stefano Ceri y Giuseppe Pelagatli [Ceri. Pelagatli 1984) proponen la arquitectura que se
presenta en la figura 4.2. no como un estándar para todos los sistemas de bases de datos
distribuidas sino como una exposición de los conceptos más relevantes.
Este modelo no siempre es implementado en las bases de datos dis1ribuidas. los niveles son
conceptuales e intentan mostrar la organización de una BDD.
representados se describen a continuación:
Los componentes
Esquema Global: El esquema global define lodos los datos que están contenidos en la base de
datos para dar la imagen de una base de datos no distribuida. Por esta razón el esquema
global se define de la misma forma que una base de datos centralizada. Al utilizar el modelo
relacional el esquema global consiste en la definición de un conjunto de relaciones globales.
Esquema de Fragmentación: Cada relación global puede ser dividida en varias partes
llamadas fragmentos. El mapeo entre relaciones globales y los fragmentos se definen en el
esquema de fragmentación. El mapeo es de uno a muchos ya que varios fragmentos
36
corresponden a una relación global. Para indicar que un fragmento corresponde a la
relación R se indica con un subíndice. de tal forma que R, indica el iesimo fragmento de la
relación global R.
Esquema Global
Esquema de Fragmentación
Esquema de Localización
~squema Local de mapeo 1
SMBD DEL SERVIDOR
No 1
1
BDdel Servidor
No 1
Esquema Local de mapeo2
SMBD DEL SERVIDOR
No2
1
BDdel Servidor
No2
Fig. 4.2 Arquitectura Referencial para una BDD
Esquema independiente del nodo
Otros
Esquema de Localización: Un fragmento se puede encontrar en uno o varios nodos de una
red. El esquema de localización define el lugar donde se encuentra cada fragmento. La
localización puede ser redundante o no. Si es redundante la relación es uno a muchos,
mientras que si no lo es muchos a muchos.
Imagen Física: Todos los fragmentos que corresponden a la misma relación global R ·y se
localizan en el mismo nodo j forma la imagen física de la relación global R en el nodo j. Por lo
que existe un mapeo de uno a uno entre una imagen física y un par (relación global. nodo).
Una imagen física puede ser señalada por el nombre de la relación global y el índice del nodo
37
en que se encuentra. Para distinguir una imagen física de un fragmento se emplean
superíndices de tal forma que Ri es la imagen física de la relación R en el nodo j.
Copla de un Fragmento: Una copia de un fragmento, es el fragmento que se localiza en un
determinado nodo. La notación u: significa la copia del fragmento R2 en el nodo 3.
En la figura 4.3 se presenta en forma esquemática la relación entre esquema global, esquema
de fragmentación y esquema de localización.
- '
,, (R;)
111;)
(u:)
Relación Global Fragmentos Imagen Física
Fig. 4.3 Fragmentos e imágenes físicas para una relación global.
Esquema de Mapeo Local: Regresando a la arquitectura de la BDD podemos observar que los
tres primeros niveles son independientes del nodo, por lo cual no dependen del modelo de
datos de la base de datos local. El sistema local debe mapear las estructuras superiores
mediante el esquema de mapeo local.
Esta arquitectura permite lograr tres objetivos:
1. Separar el concepto de fragmentación del concepto de localización. Con esta división
encontramos dos tipos de transparencia, transparencia de fragmentación y transparencia
de localización. La transparencia de fragmentación es de nivel superior a la transparencia
de localización y consiste en el hecho de que los usuarios o programadores trabajen con
38
relaciones globales. Por su parte la transparencia de localización requiere que el usuario o
programador trabaje con fragmentos y no con el esquema global. Se habla de
transparencia porque los usuarios o programadores no se preocupan por conocer el nodo
en que se encuentran los fragmentos.
2. Control explícHo de la redundancia. La arquitectura referida provee de un control
explícito de la redundancia a nivel fragmentos.
3. Independencia de las bases de datos locales. Esta característica es nombrada
transparencia de mapeo local y permite estudiar varios problemas de administración sin
tener la necesidad de adaptarse a cada base local.
Esta arquitectura realiza la misma función que la arquitectura ANSI/SPARC en los SMBDs
tradicionales mostrando que niveles y esquemas son realmente relevantes.
4.2.1 Arquitectura de un Sistema Manejador de Bases de Datos Distribuidas
Ozsu y Valduriez [Ózsu. Volduriez 1991) presentan algunos esquemas en los que resaltan los
conceptos del esquema interno local (Ell) y el esquema conceptual global (ECG). El Ell surge
de la necesidad de tener un esquema en cado una de los nodos. lo cual le da autonomía y
organización local : y el ECG corresponde a la vista a nivel organizacional de todos los datos.
El hecho de tener datos replicados y fragmentados en una BDD hace que se requiera de un
esquema conceptual local (ECL) en cada nodo, de tal forma que la unión de ECL generen el
ECG. Finalmente. los aplicaciones de usuario accesan a los bases de datos por medio de
esquemas externos (EEs). Un SMBDD pueden presentar la arquitectura que se presenta en la
figura 4.4
EE Esquema Ellterno ECG Esquema Conceptual Global ECl Esquema Conceptual local Ell Esquema Interno local
IELl ~
EIL,,
Fig. 4.4 Arquitectura de Esquemas paro una un Base de Datos Distribuida.
39
Esta arquitectura está basada en el modelo ANSI/SPARC. el cual. para pasar de bases
centralizadas a distribuidas requiere de un directorio/diccionario global (D/DG) que permita
satisfacer los requerimientos del mapeo global. Mientras el mapeo local se hace con un
directorio/diccionario local (D/DL). Los autores lo representan con la figura 4.5.
Como se puede ver los esquemas conceptuales locales son mapeados del esquema global a
cada nodo. Más aún. cada base de datos es diseñada en una modalidad descendente, de
tal forma que todas las vistas externas son realizadas en forma global. En el esquema también
se puede ver un administrador . de base de datos local, cuya existencia puede ser
controvertida. pero se justifica si recordamos que una de las principales motivaciones de una
base de datos distribuida. es el deseo de tener control local sobre la administración de los
datos.
l\f.lmiri.trallll' dr l• lM' de l:>.1,-.<J,-AW
,\ .. niniNn11kw do i-...., de ..,,oo loa,I
,,_...,_ ...... -... ......... ..,_ ... ....,......,,.
T,..tmnr,;...., 1rs11r....,.;11n • .......,.,. • -
.. "*21'11Tieilo i'*"-'--- ele mio, it1tm1
Aollniri ........... t'll'pliJ'.a:i,'ln
1o.,. ..... ....-..... b.c de .. _.. CU1-.oq111 Atlmiri,tnd..11'• l!l'li&m,11 .. - ...........
A ~i,.-..... -h-... - ... -.-.r.-... -... ~ ~· i-.i.drl,•cola,.,
&:;,qa.,•dcl1h9rde tlllotCC'IIIOrflll ..
(IR~)fll
,._,.m..-i,\n WftL'qltl .. 1 l-.e dodllt.mida'I•
tr.•íonnUffl • lll91Kalllnicnloit*m.•
Fig. 4.5 Esquema funcional de un Sistema Manejador de Bases de Datos Distribuido.
40
Los componentes de un SMBDD que corresponden a este esquema son los siguientes:
COMPONENTES DEL PROCESADOR DE USUARIO
Manejador de la Interfaz del usuario. Es responsable de interpretar las ordenes del usuario.
según las recibe, y dar forma a los resultados para entregarlos al usuario.
Controlador de la semántica de datos. Utiliza las restricciones de integridad y autorizaciones
que se definan como parte del esquema conceptual global para revisar si la consulta puede
ser procesada.
Optimizador de consuffas globales. Determina una ejecución que minimice el costo del
funcionamiento y traduzca consultas globales o locales usando esquemas conceptuales
globales y locales así como el directorio/diccionario global.
El monHor para ejecución distribuida. Coordina la ejecución de peticiones del usuario.
También es llamado administrador de transacciones distribuidas. Este monitor se comunica
con los monitores de las otras bases de datos para ejecutar las consultas distribuidas.
Usuario
Respuesla del sistema Pelición del usuario
Procesador del usuario
Procesador de datos
Manejador de la interfaz de usuario
Conlrolador de la semántica de dalos
Oplimizador de Consultas Globales
Monilor de ejecución Global
Esquema exlemo
Esquema concepluat
Global
Optimizador de consultas locales
Esquema i.-----t conceptual local ---~--...,
Adminislrador de Recuperación local -----.i
Procesador de soporle en liempo real
Logdel sistema
Fig. 4.6 Componentes de un Sistema Manejador de Bases de Datos Distribuido.
41
COMPONENTES DEL PROCESADOR DE DATOS
Optimizador de consuffas locales. Selecciona los algoritmos y estructuras a utilizar para tener
acceso a los datos de la mejor forma posible.
Administrador de recuperación local. Es responsable de asegurar que la base de datos local
mantendrá su consistencia a pesar de fallas en el sistema.
Procesador de soporte en tiempo real. Utiliza físicamente la base de datos de acuerdo a los
comandos referidos por el optimizador de consultas.
4.2.2 Arquitectura de los Sistemas Multi Base de Datos
Retomando la figura 4. 1 se puede considerar otro tipo de arquitecturas. éstas son las que se
refieren a los Sistemas Multi Base de Datos. Como se puede observar. la principal diferencia en
este tipo de sistemas con respecto a los SMBDD es su autonomía. lo cual se refleja en el ECG.
En los SMBDD integados, el esquema global conceptual define la visión de la base de datos
completa. mientras que en los Sistemas Mutli Base de Datos representa sólo la colección de
algunos datos locales que el SMBD quiere compartr. Por lo tanto en los SMBDD la base de
datos global corresponde a la unión de las bases de datos locales. y en los Sistemas Multi Base
de Datos. la bas.e de datos sólo es un subconjunto de la bases de datos locales. Existen dos
formas de arquitectura de una Sistema Multi Base de Datos. una que utiliza ECG y otra que no.
Modelos que utillzan Esquema Conceptual Global. En estos modelos, los usuarios pueden
utilizar sus propios esquemas conceptuales locales (ECL). Para diseñar un ECG en un Sistema
Multi Base de Datos, a diferencia de un SMBDD. se mapea de un esquema conceptual local a
un esquema conceptual global. con un ascendente. Una vez definido el ECG. se pueden
definir vistas sobre éste para los usuarios qüe requieran accesos globales. Así. los aplicaciones
tienen accesos tanto al esquema externo local (EEL) como al esquema externo global (EEG).
que pueden ser independientes.
,----------- --------EEL ECG EEG Ell ECl
Esquema Exlerno local Esquema Conceplual Global Esquema Externo Global Esquema Interno local Esquema Conceptual local
Fig. 4.7 Arquitectura de Sistemas Multi Base de Datos con ECG
42
Modelos que no utmzan Esquema Conceptual Global. litwin [litwin, 1988] define los Sistemas
Multi Base de Datos como aquellos que administran varias bases de datos sin un ECG. En la
siguiente figura se identifican dos capas: la capa de sistema local y la capa multi base de
datos. la primera consiste en varios Sistemas Multi Base de Datos que presentan a la capa
multi base de datos la parte de sus bases locales que quieren compartir con los usuarios de
otras bases. Estos datos se presentan como esquemas conceptuales locales (ECL) con
modelos de datos posiblemente diferentes.
I EE1 1 LEE2 1 EEn I Capa mulli base de / ·~ /.,,... \
~~~º~-----------/~---- ~~- __ / _________ \~---------· C~o de IECLil ~ ~CL:i sislemalocal ~ ~
I EIL, 1 1 Elb I EIG
Fig. 4.8 Arquitectura de Sistemas Multi Base de Datos sin ECG (Litwin. 1998)
Sobre esta capa. son construidas vistas externas donde cada vista puede ser definida sobre un
esquema conceptual global o varios esquemas conceptuales. Así. la responsabilidad de
proveer acceso a múltiples bases de datos es delegada al mapeo entre el esquema externo
(EE) y el esquema conceptual local. De esta forma. el acceso a las multi bases de datos se
provee por un lenguaje en el cual se escriben las aplicaciones de usuario. Esto implica
diferencia entre los componentes de un SMBDD y un Sistemas Multi Base de Datos. Un Sistema
Multi Base de Datos debe proveer una capa de software que corra sobre el SMBD local que
provea a los usuarios de la capacidad de acceso a varios Sistemas Multi Base de Datos.
4.2.3 El Directorio Global
El directorio global se utiliza sólo en SMBDD o Sistema Multi Base de Datos con esquema
conceptual global. El directorio global es una extensión del directorio de un Sistema Multi Base
de Datos que debe incluir información sobre los fragmentos de las bases de datos y su
localización. Puede existir un directorio global que se localice en un nodo específico para
todo el sistema. o bien, un directorio local repcrtido en diferentes Sistemas Multi Base de Datos.
Ambas opciones pueden considerar réplicas.
43
La figura 4.9 representa un Sistema Multi Base de Datos no distribuido. Si se busca un sistema
distribuido se debe replica lo copa multi base de datos a cada nodo. donde exista un
Manejador de Base de datos que participe en el sistema.
Usuario
Respuesla del sislema Petición del usuario
Procesador de consullas
Adminislrador de Transacciones
Calend<Jrizadol
Administrador de Recuperación local
Procesador de soporte en liempo real
Capa Multi-Base de Datos
SMBD Procesador de consultas
Administrador de Transacciones
Calendalizado,
Administrador de Recuperación local
Procesado, de soporle en tiempo real
Fig. 4.9 Componentes de un Sistema Multi Base de Datos
4.3 TRANSPARENCIA
SMBD
La transparencia en una BDD se refiere a la separación entre la semántica que utilizo el usuario
en el nivel más alto y los detalles de implementación. Así. la transparencia oculta los detalles
de implementación a los usuarios.
Las independencias es una forma fundamental de transparencia y se refiere a que una
aplicación de usuario sea inmune a las modificaciones realizadas en la definición y
organización de los datos y viceversa. La definición de los datos puede darse en dos niveles.
en uno se especifica la estructura lógica de los datos. en el otro se especifica la estructura
física de los datos. Así la independencia lógico de los datos. se refiere a la inmunidad de las
aplicaciones de usuario ante cambios en la estructura lógica de la base de datos y la
independencia físico a inmunidad ante cambios en la estructura física.
44
4.3.l Transparencia de Red
En un sistemas de bases de datos distribuidas. además de brindar transparencia en los datos.
se debe brindar transparencia de red. Para el usuario no debe haber diferencia entre trabajar
con un sistema centralizado o distribuido.
Existen dos conceptos sobre este punto: Transparencia de localización. que se refiere al
hecho de que el comando utilizado es independiente de la localización de los datos y del
sistema en el cual se ejecute. Y transparencia de nomenclatura. lo cual significa que existe un
nombre exclusivo para cada objeto en la base de datos.
4.3.2 Transparencia de Replicación
Si los datos han sido replicados en varias máquinas de la red. es deseable que la
administración de estas copias sea realizada por el sistema. de tal forma que el usuario trabaje
como si almacenara la información en un sólo lugar.
4.3.3 Transparencia de Fragmentación
Cuando los datos están fragmentados, es necesario buscar técnicas para manejar las
consultas que realice la aplicación del usuario. Es decir. se debe encontrar una forma de
realizar el procesamiento de la consulta basada principalmente en los fragmentos y no en la
relación. como veremos en el punto 4.5 es deseable que este proceso sea transparente al
usuario.
4.4 DISEÑO DE BASES DE DATOS DISTRIBUIDAS
Levin y Morgan [Levin y Morgan. 1975) sugieren que la organización de un sistema distribuido
puede ser investigado en tres dimensiones ortogonales:
1 Nivel en que se comparte
2 Comportamiento del modelo de acceso
3 Nivel de conocimiento sobre el comportamiento del modelo de acceso.
la representación de estas dimensiones aparece en la figura 4.10.
Como objetivos del diseño Ceri y Pelagatti [Ceri. Pelagatti 1984] señalan:
• Distribuir los datos para lograr el máximo proceso local. de esta forma el procesamiento se
realizará en un nodo cercano a la petición del usuario.
45
• Disponibilidad y confiabilidad de los datos.
• Distribución de la carga de trabajo.
• Optimar el costo de almacenamiento y la disponibilidad
Modelo de Acce5o
Dinámico
................... ---...... -............ -.. :•
.. ~..... . . . . . ................................... . . . . . . . . . ......... ~ .......... .
Eslólico
. --............................ -: --~~~~~~--é~-----,r--.....
Nivel de Conocimiento Solo dolos
: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ·: .. ·:·
.. ·~·····························-~:
~Comporlir dolos y programas
Compartir
Fig. 4.10 Direccio_nes en el diseño de la Distribución.
El diseño consta de cuatro fases:
1 Diseño del esquema global
2 Diseño de fragmentación
3 Diseño de localización
4 Diseño de la estructura física en cada nodo
Información completo
4.4.1 El Diseño Ascendente y Descendente del Esquema Global
Como se mencionó anteriormente. existen dos allernalivas para el diseño. ascendente
(utilizado por la SMBDD) y de descendente (que se adapta a Sistema Multi Base de Datos). En
el diseño ascendente se inicia formando el esquema global. luego la fragmentación, después
la localización de estos fragmentos en forma replicada o no. creando imágenes físicas.
El diseño descendente se crea como la unión de varios datos contenidos en las bases
existentes. el esquema global (cuando existe). es creado como un compromiso entre las
descripciones de los datos existentes. Este tipo de diseños se basa en la integación de los
esquemas existentes en un solo esquema global. Por integración se ha de entender la unión
46
de las definiciones de datos y la resolución de conflictos entre las diferentes representaciones
dadas a los mismos datos.
Cuando las bases de datos se unen en un Sistema Multi Base de Datos mediante un diseño
ascendente se requiere:
1.- La selección de un modelo de base de datos común para describir el esquema global de
la base de datos.
2.- La traducción de cada esque"!la local en el modelo de datos común.
3.- La integración de los esquemas locales a un esquema global común.
4.4.2 Diseño de Fragmentación
La fragmentación consiste en dividir una relación y agruparla en tuplas (si la fragmentación es
horizontal) o atributos (si la fragmentación es vertical) o en forma mixta (tuplas y atributos)
según sus propiedades desde el punto de vista de su localización. Los fragmentos son la
unidad de agrupamiento con las mismas propiedades; de tal forma que al tener dos
elementos con lc;is mismas propiedades. éstos sean localizados en el mismo lugar. Por lo tanto.
si una relación r está fragmentada, r se dividirá en varios fragmentos r,. r2 ..... rn de tal forma
que al retomar todos los fragmentos podamos reconstruir r.
fragmentación Horl.zontal. Cada tupla de r es asignada a uno o más fragmentos. Un
fragmento puede definirse como una selección en la relación global r. Es decir. se utiliza un
predicado P1 paro construir el fragmento n de la siguiente manero:
r1 = cr p1 (r) (4, l)
La reconstrucción de r puede obtenerse al calcular la unión de todos los fragmentos. es decir:
r = ÍI U r2 U ••• U rn (4,2)
fragmentación Vertical. Divide la relación r descomponiendo su esquema. de forma que los
atributos queden en diferentes fragmentos.
La fragmentación vertical de r involucra la definición de varios subconjuntos. R, . R2 ..... R_n.
donde R es el esquema de r. tales que:
R= R1 uR2u ... uRn (4,3)
Por lo tanto:
n=nR1(r) (4,4)
47
Es decir. la relación n se da de la proyección del esquema Ri que forma parte de la relación r.
Para obtener r necesitamos el siguiente producto natural:
r = ri IX I r2 1 X 1 •.. 1 XI rn (4,5)
Para realizar la fragmentación vertical se añade un atributo que identifique a la tupla en el
esquema R
fragmentación Mixta. La relación r se divide en varios fragmentos. donde cada fragmento de r
se obtiene por la aplicación de un esquema de fragmentación horizontal o vertical. sobre la
relación r. o sobre un fragmento de r que haya sido obtenido con anterioridad.
4.4.3 Diseño de Localización de Fragmentos
Se debe distinguir entre el diseño no redundante y diseño redundante (replicación) de
localización. El diseño no redundante es más sencillo y se obtiene mediante la asignación de
un peso asociado a la localización de un fragmento en cada nodo. el fragmento se debe
localizar en el nodo que mejor peso le brinde. Esta aproximación por peso descuida la
relación existente entre fragmentos.
El uso de replicación implica que el grado de replicación de cada fragmento se convierta en
una variable del problema, además de que. tanto la lectura como la escrituro deba de
considerar las diversas copias del fragmento. Para diseñar la replicación se puede partir de
dos aproximaciones:
a) Determinar el conjunto de nodos donde el beneficio de localizar una copia del fragmento
sea mayor que el costo de mantenerla ahí.
b) Determinar en primer lugar una solución sin réplicas y progresivamente introducir réplicas
comenzando por las más benéficas hasta que no sea necesario añadir réplicas.
4.5 PASO DE CONSULTAS GLOBALES A CONSULTAS EN FRAGMENTOS
Para realizar este tipo de operaciones tomaremos como referencia el álgebra relacional de la
forma que la presenta Ceri y Pelagalli [Ceri. Pelagatti 1984):
Las operaciones unarlas toman sólo una relación como operando e incluyen a la selección y a
la proyección.
48
la selecclón, se denota Sl,R. donde R es el operando al cual se le aplica la función de
selección F. la función Fes una fórmula que expresa un predicado. que produce una nueva
relación con el mismo esquema que R y un subconjunto de tuplas que satisfacen el predicado
F.
la proyección, se denota PJ Allr R. donde Attr denota un subconjunto de atributos de la
relación operando. Produce un resultado que contiene las tuplas del operando con los
atributos señalados en Attr. Las tuplas repetidas que se generen después de aplicar la
operación son eliminadas.
Las operaciones binarias toman dos relaciones como operandos:
la unión, se denota R UN S. tiene significado sólo entre dos relaciones R y S con esquemas
idénticos. arrojando un esquema similar y la unión de las tuplas de R y S. (Esto es. todas la
tuplas que aparecen en R y en So en ambas).
La diferencia, se denota, R DF S requiere que R y S tengan el mismo esquema dando como
resultado el mismo esquema que los operandos, y todas las tuplas de R que no estén en S.
El producto cartesiano, se denota, R CP S produce una relación cuyo esquema incluye todos
los atributos de R y S . para evitar ambigüedad en el caso de que resulten atributos con el
mismo nombre se debe añadir el nombre de la relación como prefijo separado por un punto
al nombre de cada atributo. Cada tupla de R es combinada con cada tupla de S para
formar las tuplas resultantes.
El Joln, se denota. R JN, S. donde F es una formula que especifica el predicado del join. genera
como esquema todos los atributos de R y de S. y las tuplas que satisfagan el predicado. Un
join se deriva de la selección y el producto cartesiano:
R JN, S = m(R CP S) (4,6)
El Joln natural, se denota R NJN S. es un join en el cual todos los atributos con el mismo nombre
son comparados. Si los a lributos que tienen los mismos nombres en ambas relaciones
coinciden en los valores en todas las tuplas del resultado. sólo una de las tuplas _será
considerada.
El semi-join. se denota R SJ, S. se deriva de una proyección y un join de la siguiente forma:
R SJF S = P J Allr(R) (R JNF S) (4,7)
49
donde Attr(RJ es el conjunto de todos los atributos de R.
El semi-join natural. se denota R NSJ S. se obtiene considerando un semi-join con el mismo
predicado que utiliza el join natural.
Las consultas pueden realizarse sobre relaciones globales. que impliquen varios nodos
(consultas globales) o sobre fragmentos localizados en un solo nodo (consultas de fragmento).
El concepto de transformación de equivalencias para consultas es de gran utilidad para
mejorar el desempeño. Dos expresiones con la misma semántica pueden describir dos
secuencias diferentes de operaciones. como primero seleccionar y después proyectar o
viceversa. Al expresar dos secuencias diferentes y obtener los mismos resultados. decimos que
las expresiones son equivalentes.
Un árbol de operaciones representa el orden en que estas se deben realizar. de tal forma que
si la consulta 1 es :
Q,: P J PNUM SL AREA = "Noria" (PROV JN OEPINUM = OEPINUM DEPT)
Su árbol de operaciones se representa como sigue:
PJrNUM
SL AREA="Norle"
JN OEPTNUM=OEPINUM
/ ""' PROV DEP
Fig. 4.11 Árbol de operaciones.
En el árbol podemos observar que las hojas son relaciones globales. cada nodo representa
operaciones unarias o binarias y el árbol indica un orden en el cual se deben realizar las
operaciones de abajo hacia arriba.
50
lo siguiente gramático es sugerido por Ceri y Pelogotti [Ceri. Pelogotti 1984]
R -> Identificador
R-> (RJ
R-> op_un R
R -> R op_bin R
op_un -> Su= 1 P JA
bin_op -> CP I UN I DF I JNF I NJNF I SJF I NSJF
En cuanto o expresiones equivalentes podemos decir que si E, y E2 son equivalentes (se
escribe E1 <-> fa) al sustituirlos obte_nemos los mismos resultados.
Si U y B denotan operaciones algebraicos unorios y binarios respectivamente. podemos
obtener los siguientes categorías de equivalencia de acuerdo con sus operadores:
• Conmutotividod de operaciones unorios
• Conmutotividod de operandos de
operaciones binarios
• Asociotividod de operaciones binarios
• ldempotencio de operaciones unorios
• Distributividod de operaciones unorios con
respecto o operaciones binarios
U1U2R <->U2U1UR
RBS <->SBR
RB(SBT) <->(RBSJBT
UR <->U1U2R
U(RBSJ -> U(R)BU(S)
• Foctorizoción de operaciones unorios U(R) BU (S) -> U(RBSJ
Estas propiedades son presentados por Ceri y Pelogotti en los siguientes tablas. en los que se
indico con Attr(R) el conjunto de atributos de lo relación R. los tablas contienen en codo
posición un indicador de validez donde N significo que no se puede aplicar. Y que se puede
aplicar siempre y SNC condición específica necesaria. las condiciones especificas se
presentan debajo de codo tablo.
Tablo 4.1 Conmulotividod de operaciones unorios
Sl n PJA2
Sln (*(R)) Y Y
-> *(Slr,(R))
PJAl(*(R))
->. (PJ Al (RJJ
SNC1: Attr(F2) e;;;; A 1
SNC2: Al= A2
SNC1
51
Tabla 4.2 Conmutatividad de operandos y asociatividad de operaciones binarias. -
UN DF CP JNF SJF ·-- ----- --·--- ~~--·--· ··- ~-- ...
R•s y l'I y y y
-> S * R
(R • S) '"T y N y SNC1 N
-> R * (S * T)
SNC1: Para (R JN,, S) JN n T-> R JN r, (S JN n T): Atlr (F2) <;:; Atlr(S) U Attr(T)
Tabla 4.3 ldempotencia de operaciones unarias
p JA(RJ -> p JA1 p J A2 (RJ
Slr(RJ -> SlflLSn(R)
SNC: A = A 1. A <;:; A2
SNC: F = F l " F2
Tabla 4.4 Dislributividad de operaciones unarias con respecto a operaciones binarias
UN DF CP JNFJ SJFJ
Sls:(R•S)-> y y SNC1 SNC, y
Sls:R(R) *Sls:s(S) FR = F. FS = F FR=F. FS=F FR= Fl. FS=F2 FR=Fl. FS=F2 FR=F.FS=true
PJA(R*S) -> y y SNC2 SNC2
p JAR (RtP JAS(S) AR=A.AS=A N AR=A-Atlr(S) AR=A-Attr(S) AR=A-Altr(S)
AS=A-Attr(R) AR=Attr(R) AS=Altr(S) r, Atfr(F3)
SNC,: 3 Fl.F2:(F=Fl /\ F2) /\ (Allr(FJ) <;:; At1r(R)) /\ (Attr(F2) <;:; A1tr(SJ)
SNC2: Attr(F3) <;:; A
Tabla 4.5 Factonzación de operaciones unarias desde operaciones binarias
Slrn(RJ • Sls:s(S)
-> Sls:(R*SJ
p JAR(RJ*P JAS(SJ
-> PJA(R*SJ
UN
SNC,
F=FR=FS
SNCJ
A=AR=AS
SNC1: FR = FS
SNC2: FR => FS
DF
SNC2
F=FR
N
CP JNr,
y y
F=FR" FS F=FR" FS
y y
A=AR u AS A= AR u AS
SNCJ: Altr(R) = Allr(SI
SNC4: FS = true
SJFr
SNC4
F=FR
y
A=AR
52
Y presentan los siguientes criterios para aplicar transformaciones de operaciones equivalentes:
Criterio 1 Usar idempotencia de selección y proyección para generar selecciones y
proyecciones apropiadas para cada operador relacional.
Criterio 2 Mandar selecciones y proyecciones a la parte más baja posible del árbol para tratar
de reducir el tamaño de los operandos en operaciones binarias.
Criterio 3 Enviar las selecciones hacia abajo. cerca de las hojas del árbol. y aplicarlas usando
el álgebra de relaciones calificadas; substituir el resultado de la selección con relaciones
vacías si el calificador del resultado es contradictorio.
Criterio 4 Usar el álgebra de relaciones calificadas para evaluar la calificación de operandos
de joins; substituir los subárboles. incluyendo el join y sus operandos. con la relación vacía si los
calificadores del resultado de los joins es contradictorio.
Criterio 5 Para distribuir joins que aparezcan en consultas globales. las uniones (que
representan colecciones de fragmentos) deben mandarse hacia arriba. más allá de los joins
que se quieran distribuir.
Criterio 6 Para distribuir agrupamientos y funciones de grupo que aparecen en consultas
globales. las uniones (que representan colecciones de fragmentos) deben ser mandadas
hacia arriba. más allá de la operación de agrupamiento.
Para comprender mejor estos criterios se presentan los siguientes conceptos:
a) Propiedades para slmpliflcar un árbol de operaciones.
Las subexpresiones comunes permiten ahorrar posos en el análisis de una expresión.
ejecutando una solo vez aquellas operaciones que se repiten en una consulto. Los siguientes
propiedades pueden ser utilizadas paro simplificar un árbol de operaciones:
R NJN R <-> R
R UN R <-> R
R DF R <-> 0 R
R NJN SL,:R <-> SL,:R
R UN SL,:R <-> R
DF SL,:R <-> SL NOT F R
b) Expresiones canónicos.
(SLFI R) NJN SL F2 R) <-> SL A ANO F2 R
(SL,:, R) UN SL F2 R) <-> SL F1 OR F2 R
(SL,:, R) DF SL F2 R) <-> SL FI AND NOT F2 R
53
Dada una expresión sobre el esquema global. su expresión canónica se obtiene sustituyendo
cada relación global por las expresiones que la forman. mediante fragmentos. Normalmente
una expresión canónica no es eficiente y debe transformarse en una expresión equivalente
siguiendo los criterios 1 y 2.
c) Algebra relacional calificada.
Una relación calificada es un relación extendida por una calificación; la calificación puede
ser vista como una propiedad intencionalmente poseída por todas las tuplas de una relación.
La relación calificada se denota por el par [R:qR] donde R es la relación llamada cuerpo. y q,
es un predicado llamado calificación. La fragmentación horizontal es un ejemplo típico de
relaciones calificadas en las cuales la calificación corresponde al predicado de partición.
Reglas del Álgebra Relacional Calificada:
1 Su= [R:qR) => [Su=R:F ANO qR)
2 P JA[R:qR] => [P JAR:qR]
3 [R:qR] CP [S:qs] => [R CP S:qR ANO qs]
4 [R:qR) DF [S:qs] => [R DF S:qR]
5 [R:qR) UN [S:qs) => [R UN S:qR OR qs)
6 [R:qR) JNF [S:qs) => [R JNF S:qR ANO qs ANO F]
7 [R:qR] SJF [S:qs) => [R SJF S:qR ANO qs ANO F]
Toda transformación de equivalencia del álgebra relacional se mantiene para el álgebra de
relaciones calificadas. Las relaciones calificadas con calificadores contradictorios son
intrínsecamente vacías. Al reconocer una subexpresión como vacía se pueden realizar las
siguientes simplificaciones:
Su:(0) <-> 0
PJA(0} <-> 0
RCP0<->0
R UN 0 <-> R
R DF 0 <-> R
d} Estrategias para realizar joins.
0 DF R <-> 0
R JNF 0 <-> 0
R SNF 0 <-> 0
0 SJFR <-> 0
Se puede pensar en dos tipos de estrategias para realizar un join. La primera realiza el join
entre fragmentos y después recopila la información de los diversos nodos. La segunda. forma
las relaciones recopilando los fragmentos y después realiza el join. El primer caso es mejor
54
cuando se involucran pocos pares de fragmentos, mientras que el segundo coso es preferible
si los condiciones de fragmentación son altamente selectivas.
Tonto el conocimiento del sistema, como saber las características particulares de la
localización de fragmentos. se puede utilizar para inferir contradicciones que permitan
eliminar subexpresiones. En el coso de fragmentaciones verticales se debe seleccionar el
subconjunto de fragmentos necesarios poro resolver los consultas y después eliminar todos los
demás fragmentos de la expresión.
e) Empleo de semi-joins.
El uso de semi-joins puede ser de gan beneficio paro lo optimización de consultas distribuidos
yo que un join puede ser mopeado en un programa semi-join. formado por un conjunto de
operaciones que producen el mismo join. Dado un Join R JN A•11 S. donde A y B son atributos
o conjuntos de atributos de R y S. el programo semi-join está dado por:
s JN A•B (R SJ A~II PJ B S)
Formando el siguiente árbol de operaciones:
JN .._.a
SJ:: \ / \. R p JB
\. s
El beneficio se obtiene si S y R se encuentran en diferentes nodos. yo que al realizar un semi
join en R se eliminan tuplas que no requieren ser enviados por lo red.
f) Agrupamientos y funciones de grupo.
Otro aspecto o considerar son los funciones de agrupamiento y evaluación. El criterio 6 se
obtiene de que:
55
Con la condición siguiente: Para cada i.j (Gi ~ Rj) o (G1 r. R1 = 0 )
donde G son los atributos que determinan el agrupamiento y AF son las funciones de
agrupamiento que serán evaluadas para cada grupo. Si la condición no se cumple. se puede
considerar la siguiente propiedad: Una función de agrupamiento F tiene computabilidad
distribuida si para un multiconjunto S y una descomposición de Sen múltiples Si. S2 •.... Sn es
posible determinar un conjunto de funciones de agrupamiento F1. F2 •.... Fm y una expresión
E(Fl. ... Fm) tal que:
F(SJ = E(F 1 (S 1 J ....• F 1 (Sn).F2(S 1 J .... F2(Sn).Fm(S 1 J •.... Fm(SnJ J
Como en los siguientes casos:
AVG(SJ= SUM ISUM IS1l. SUMIS2l. .... SUM ISnll
SUM(COUNT(S¡J.COUNT(S2).COUNT(Sn))
MIN(S) = MIN(MIN(S1).MIN(S2J ....• MIN(Sn))
MAX(SJ = MAX(MAX(Si).MAX(S2) ..... MAX(Sn))
COUNT(SJ = SUM(COUNT(S1).COUNT(S2J ..... COUNT(Sn))
SUM(S) = SUM(SUM(Si).SUM(S2) ..... SUM(SJ))
4.6 ESTRATEGIAS DE ACCESO
(4,8)
(4,9)
(4, 1 O)
(4, 11)
(4, 12)
Factorizar subexpresiones comunes y eliminar subexpresiones no requeridas por una consulta
son ejemplos de modificaciones que son benéficas. así como enviar las operaciones unarias
hacia arriba del árbol de operaciones para evitar costos de transmisión. Al considerar tanto la
conmutatividad de los joins y las uniones. como la transformación de joins en programas semi
joins. se generan consultas que deben evaluarse en base a su costo.
Es necesario tomar en cuenta los siguientes puntos para poder realizar una adecuada
evaluación de una consulta:
• Determinar la copia física de los fragmentos que utilizará la consulta (materialización)
• Seleccionar el orden de ejecución de las operaciones
• Seleccionar el método para ejecuta cada operación.
Sin embargo. en la práctica, el primer y tercer problema se dejan, el primero a la
administración del sistema. y el segundo al diseño de la base de datos. Por lo tanto se hace
énfasis en la selección del orden de ejecución.
56
Los objetivos en la optimización del procesamiento de consultas en los sistemas centralizados
se basan en el número de operaciones de entrada/solida y el uso del CPU; mientras que en los
sistemas distribuidos se busca optimizar la transmisión de datos entre nodos. Los requerimientos
de transmisión se pueden evaluar en base al costo de transmisión (cantidad de información
que se debe transmitir. tanto de datos como información de control) y retardo (tiempo que
transcurre entre la activación y la terminación de una aplicación).
TC(x)=Co + x XC,
TD(x)=Do + x X 01
Donde: TC = Costo de transmisión
TO = Retardo de Transmisión
(4.13)
(4.14)
x = Tamaño de los datos a transmitir
Co = Costo de iniciar una transmisión
e,= Costo unitario de transmisión sobre la red Do= Costo de establecer conexión
D, = Tasa de transferencia unilaria sobre la
red
4.6.l Modelado de Consultas para su Análisis
En esta sección se consideran las operaciones críticas para el procesamiento de consultas y se
añade información cuantitativa que puede servir para evaluar estrategias de
implementación. El perfil de una base de datos es una descripción de los fragmentos y
contiene la siguiente información:
• Número de tuplas de codo fragmento R, => card(R,)
• El número de bytes de cada atributo size(A) y el número de bytes de un fragmento size (R,)
• Por cada atributo A en un fragmento R,. el número de los distintos valores que aparecen en
Ri denotado por val(A(R,])
Esta información puede ser utilizado tanto por relaciones globales como por fragmentos. La
estimación del perfil de la base de datos es útil para evaluar alternativas de optimización.
Si S denota el resultado de ejecutar una operación unaria sobre una relación R. y sea T el
resultado de aplicar una operación a las dos relaciones R y S; entonces encontramos los
siguientes valores para las operaciones de:
57
SELECCIÓN
1. Cardinalidad. Para cada selección se asocia una p selectiva, la cual es la fracción de tuplas
que la satisfacen. En una selección sencilla atributo= valor (A=v). r puede ser estimada como
1 /val(A[R)), asumiendo que los valores se distribuyen en forma homogénea y que v si aparece
en R obtenemos:
card(S) = r X card(R) (4, 15)
2. Tamaño. la selección no afecta el tamaño de las relaciones. por lo que:
size(S)=size(R) (4, 16)
3. Valores Distintos. Si el atributo B no se utiliza en la fórmula de selección ni influye en la
determinación de val(B[S]) se reduce al siguiente problema: Dados n=card(R) objetos
uniformemente distribuidos sobre m=val(B[R,]) colores. ¿cuántos colores c=val(B[R1) son
seleccionados si tomamos r=cad(R1) objetos?
la solución según Ceri y Schreiber [Pelagatti. Schreiber] es:
c(n, m, r):
PROYECCIÓN
1.- Cardinalidad.
r. para r < m/2
(r+m)/3. para m/2 s r < 2m
m, para r 2m ~ 2m
a) Si la proyección involucra un atributo simple A:
card(S)=val(A[R))
(4, 17)
(4, 18)
b) Si el producto nA1eA11rrs1val(Ai(RJ) es menor que card(R), donde Attr(S)
son atributos en el resultado de la proyección:
card(S) = n val(Ai(R)) Ai E Allr(SI
(4, 19)
c) Si la proyección incluye una llave de R
card(S) = card(R) (4,20)
58
2.- Tamaño. Suma de los atributos especificados.
3.- Valores distintos: Son los mismos que la relación operando.
GROUP-BY
GBc.AF Donde G= Atributo sobre el cual se agrupa y AF = función de agrupamiento a evaluar.
1.- Cardinalidad.
card(S) :;; n val(A[R)) ¡,.j G G(SJ
(4,21)
La card(S) puede ser mayor en el ·caso de que cada valor del grupo especificado combine
con cada valor de todos los atributos del otro grupo.
2.-Tamaño. Para todos los atributos A que aparezcan en G:
size(A(S)=val(A[R)) (4,22)
El tamaño de S está dado por la suma de los tamaños de los atributos en G y AF.
3.-Valores Distintos. Para todo A que aparezca en G
val(A[SJ=val(A[RJ) (4,23)
UNIÓN
1.- Cardinalidad.
card(T) :;; card(R) +card(S) (4,24)
2.-Tamaño.
size(T) = size(R) = size(S) (4,25)
3.- Valores Distintos.
val(A[T)) :;; val (A[R)) + val (A[SJ) (4,26)
59
DIFERENCIA
1.- Cardinalidad
2.-Tamaño.
3.- Valores Distintos.
PRODUCTO CARTESIANO 1.- Cardinalidad
2.-Tamaño
3.- Valores Distintos
max(O.card(R) - card(S)) ~ card(T) ~ card(R)
size(T) = size(R)= size(S)
val(A[T)) ~ val(A[R])
card(T) = card(R) X card(S)
size(T) = Size(R) + size(S)
Iguales a los que existan en las relaciones operandos
JOIN T=RJNA=BS
1.- CARDINALIDAD
(4,27)
(4,28)
(4,29)
(4,30)
(4,31)
card(T) ~ card (R) X card(S) Sin embargo. si asumimos que todo valor de A en R aparece como
valor de B en S y viceversa val(A[R])= val(B[S)) y que ambos atributos están uniformemente
distribuidos sobre R y S
card(T)=(card(R) X card(S))/val(A[R)) (4,32)
Si uno de los atributos. como A. es una llave de R
card(T)=card(S) (4,33)
2.-TAMAÑO
size(T) = size(R) + size(S) (4,34)
3.- VALORES DISTINTOS
val(A[T)) ~ min(val(A[R)).val(B[S])) (4,35)
Si A no es un atributo join
val(A[T)) ~ val(A[R))+val(B[S)) (4,36)
SEMI-JOIN T=R SJ A=B S
60
1.- CARDINALIDAD. Si utilizamos p como en el caso de la selección
p= val(A[S]) /val(dom(Al)
2.-TAMAÑO
dom(A)=número de valores distintos del dominio A
card(T)= p X card(R)
Es el mismo tamaño que el del primer operando.
3.- VALORES DISTINTOS
Con n = card(R) m = val{A[R]) r = card {T)
c(n.m.r) ::: r para r < m/2
( r+m ) / 3 para m/2 ::;; r < 2m
m parar::?: 2m
Si A es el único atributo que aparece con el semi-join
val (A[T)) = p X val(A(R))
4.6.2 Modelo para Optimar Consultas
(4,37)
(4,38)
(4,39)
(4,40)
Seguiremos el modelo de grafos de optimización sugerido por Ceri y Pelagatti [Ceri. Pelagatti
1984] utilizando sólo las operaciones más comunes. Los operadores unarios que se aplican al
mismo fragmento se pueden reunir en la aplicación y ejecutarse antes de ejecutar
operaciones binarias. con lo cual generalmente se reduce la transmisión de datos. Las
operaciones binarias son críticas por la posibilidad de que los operadores aparezcan en
distintos nodos y por lo tanto se requiere la transmisión de dalos. Para el modelo no se
consideran producto cartesiano ni diferencia. y se presta especial atención a las uniones y
joins. En el modelo. los nodos representan fragmentos reducidos. los joins se representan por
arcos entre nodos etiquetados con la especificación del join. y las uniones son representadas
por hipernodos que contienen sus operandos.
El modelo considera las siguientes suposiciones:
1.- Por cada consulta se asume una materialización dada y se opera sobre los fragmentos
localizados.
2.- Se considera inicialmente sólo los requerimientos de transmisión.
3.- Los costos de transmisión no dependen de los nodos que intervienen en la comunicación.
61
4.- Para evaluar el perfil. se asume que los valores son uniformemente distribuidos sobre las
tuplas de los fragmentos y que todos los atributos son indep~ndientes.
5.- No se consideran consultas que incluyan producto cartesiano ni diferencia.
6.- Se tratará por separado el caso de consultas que sólo requieren joins y las consultas que
requieren joins y uniones.
ConsuHas que sólo requieren Jolns
En esta parte del modelo no se emplean fragmentos. sino relaciones para denotar relaciones
tanto fragmentadas como no fragmentadas. Los algoritmos se puede clasificar en aquellos
que utilizan semi-joins. y los que no los utilizan.
Programas que utilizan semi-joins.- Un programa semi-join entre dos relaciones R y S sobre los
atributos A y B se define como (R SJA=B SJ JNA=BS y equivale a RJNA=aS. Si R y S se localizan en los
nodos r y s respectivamente la ejecución de un programa semi-join corresponde a:
1. Enviar P Ja(S) al nodo r. con un costo de:
CO+ClXsize(B) X val(B[S))
2. Calcular el semi-join en r. sin costo de transmisión
R'=R SJA=BS
3. Enviar R' a s. con el siguiente costo:
Co+C, X size(R) X card(R')
4. Se calcula el join en s. sin costo.
Por lo tanto el costo total es el siguiente:
CSJ = 2 X Co + C, X (size(BJ X val(B[S]+size(R)Xcard(R'))
(4,41)
(4,42)
(4,43)
(4,44)
El semi-join no es simétrico. por lo que se requeriría el cálculo de (S SJ R)JN R para conocer el
semi-join más eficiente. o bien. decidir en base al lugar de la requisición. También se puede
considerar el empleo del join directo. transmitiendo un operando de un nodo al otro:
CJN=Co+C, X size(R) X card(R) (4,45)
Ceri y Pelagatti citan algunas estrategias para modelar las consultas con los algoritmos
utilizados por: a)SDD-1. b)Apers. Hevner y Yao. c) R•
Consultas que ufllizan Jolns y uniones
El criterio básico que se ha utilizado en este tipo de consultas es la conmutatividad de los joins
y las uniones. El problema principal es realizar los joins entre fragmentos. ya que las uniones no
requieren de una secuencia especifica para su ejecución.
62
Los joins y uniones se pueden conmutar en las siguientes formas:
1. Join no distribuido.- Es la forma más sencilla. Se determinan los nodos a utilizar y se ejecutan
las operaciones tratando de reducir los joins.
o Fragmento de la o R, relación R1
~ R2 D Fragmento de la u
relación S1 () RJ o Hipernodo representando unión
Fig. 4.12 Join no distribuido.
2. Join Distribuido.- Se puede realizar primero una unión para obtener la relación resultante. y
en base al conocimiento que se tenga de los fragmentos realizar joins como se indica en las
consultas que sólo requieren joins.
R, ~S, R2 \___ S2
,----..._
\ RJ '-- SJ \
-· ./
Fig. 4.13 Join Distribuido
Se pueden realizar uniones parciales. con lo que el grafo puede presentar la siguiente forma:
/----/,'R, Q \
:: 64~~1 ,.....____ __ _
Fig. 4. 14 Uniones parciales.
4. 7 ADMINISTRACIÓN DE TRANSACCIONES
Una transacción es un conjunto de operaciones que deben ser ejecutadas. en este caso en
forma distribuida. Debe contar con las siguientes características:
63
Atomicidad. Se deben realizar todas las operaciones o ninguna. Algunas causas por las
cuales una transacción debe ser rechazada son: un nodo abortó la transacción. uno de los
nodo no responde. sobrecarga en las líneas de comunicación. el uso de candados para
proteger la información en uno de los nodos. La atomicidad hace que las transacciones sean
acordadas o abortadas. Normalmente el conjunto de operaciones que enmarcan una
transacción son begin-transaction, comrni t o abort.
DurabWdad. Una vez que el sistema señala que una transacción fue acordada. se debe
garantizar que el valor de la transacción no se va a perder a pesar de fallas futuras. La
actividad que provee durabilidad en caso de fallas se llama recuperación de la base de
datos.
SeriabWdad. Si varias transacciones se ejecutan concurrentemente, el resultado debe ser el
mismo al que se llegaría si su ejecución fuera serial. Esto se loga mediante el control de
concurrencias. que veremos más adelante y en el punto 4.8.
Alslamlento. Una transacción incompleta no debe mostra sus resultados a otra transacción
antes de ser acordada. Esta propiedad se requiere para evitar el problema de abortar en
cascada. la cual puede surgir al abortar una transacción que afectó valores requeridos por
otras transacciones. las cuales deberán ser igualmente abortadas.
4. 7.1 Objetivos en la Administración de Transacciones.
Se consideran como objetivos la eficiencia. conflabffldad y concurrencia de transacciones.
Los objetivos están fuertemente interrelacionados y su implementación puede afectar
sensiblemente el desempeño. En los puntos 4.5 y 4.6 se consideraron estrategias para accesar
en forma eficiente la base de datos distribuida. además se debe tomar en cuenta: a) La
utilización del CPU y memoria principal de cada uno de los nodos. b) El tipo de mensajes de
control que utilizarán para coordinar las transacciones c) El tiempo de respuesta que. ofrece la
transacción d) La disponibilidad del sistema en general.
La administración de las transacciones debe controlar la ejecución de las mismas cubriendo
los siguientes puntos:
1.- Las transacciones deben ser atómicas. durables. seriables. y aisladas.
2.- Se deben reducir los costos de memoria. el uso del CPU. las señales de control y el tiempo
de respuesta.
64
3.- Se debe maximizar la disponibilidad del sistema.
4. 7.2 Las Transacciones Distribuidas
Una transacción es un subconjunto de operaciones realizadas por una aplicación. Se suele
delimitar el grupo de operaciones por los indicadores begin_transaction y comrnit o
abort. El uso de este tipo de transacciones requiere del empleo de agentes. es decir.
procesos que se comuniquen mediante mensajes. Para que dichos agentes logren atomicidad
es necesario que:
1.- Exista un agente raíz que inicie la transacción
2.- El agente raiz tenga la responsabilidad de ejecutar la sentencia begin_transaction y
comrni t o abort
3.- Sólo el agente raíz tenga la capacidad de crear nuevos agentes.
Las primitivas begin_ transaction, conuni t y abort que surgen del agente raíz no son
locales. sino que afectan a todos los agentes involucrados en la transacción. Es conveniente
que cada nodo cuente con un administrador de transacciones local (ATLJ capaz de
implementar las transacciones locales y utilizar técnicas centralizadas. con la capacidad de
recuperación después de fallas.
Empleo de BHácor~s
Las fallas con las que se puede presentar un nodo son a) fallas sin pérdida de información. b)
fallas con pérdida de información en almacenamiento volátil y c) fallas con pérdida de
información en almacenamiento no volátil. Una técnica común para la implementación de
transacciones que toleren fallas es el uso de bitácoras de operaciones. La bitácora permite
deshacer las operaciones de una transacción y volverlas a realizar con las primitivas undoing
y redoing respectivamente. Si la bitácora de un nodo después de una caída. señala que una
transacción no llegó al commit, ésto se debe deshacer. Si lo transacción llegó al comrnit,
entonces se debe rehacer. Por lo tonto una bitácora debe contar con lo siguiente
inf ormoción:
1. Identificador de la transacción.
2. Identificador del registro.
3. Tipo de acción (insertar. borrar. modificar).
4. El valor anterior del registro
5. El valor nuevo del registro
65
6 Información auxiliar para el proceso de recuperación. generalmente un apuntador al
registro previo de bitácora que corresponda a la misma transacción.
los reglas básicas poro el uso de la bitácora se pueden resumir en:
1.- Antes de realizar uno acfualizoción en lo base de datos. se debe registrar la operación en
la bitácora en forma estable.
2.- Antes de acordar una transacción. todos los registros de la bitácora correspondientes o la
transacción deben ser almacenados en registro estable.
El procedimiento de recuperación. que se utiliza con las bitácoras cuando existe pérdida de
memoria volátil es el siguiente:
1. Se determinan todas las transacciones sin commit que deben deshacerse. Estas se
reconocen por tener un begin_transaction sin comrnit ni abort.
2. Se determinan las transacciones a rehacer. En principio aquellas que tienen registros con
comrni t en la bitácora. a menos que se utilicen puntos de registro.
3. Deshacer o rehacer las transacciones determinados en los puntos 1 y 2.
Para la recuperación de las transacciones distribuidas se asume que cada nodo cuenta con
el mecanismo de recuperación de transacciones de sistema centralizado. Cada agente
genera primitivas begin_transaction. commit y aborta su ATL y sus primitivas son local_begin.
local_commit y locol_obort. ejecutando subtransacciones. En lo transacción distribuida se
requiere que todos los nodos ejecuten la transacción o que ninguno la ejecute.
El Protocolo de Compromiso a Dos Fases (2 Phase Commltment Protocol -2PCP·)
En el 2PCP básico existe un agente administrador de transacciones distribuidas (agente ATD)
con un papel especial de coordinador. Los demás agentes son llamados participantes. El
agente ATD es quien decide si la transacción debe ser abortada o acordada. Cada
participante se encuenlra en un nodo diferenle y la idea básico del 2PCP es realiza una
decisión paa todos los porticipanles.
Fase l. El coordinador escribe en su bilácora un registro llamado prepare. donde graba los
identificadores de los participantes. luego prepara a los participantes para realizar un comrni t •
Después el coordinador activa un mecanismo temporizador. el cual interrumpe al coordinador
después de cierto tiempo. Los participantes envían un READY comprometiéndose a
almacenar en forma estable a)Todo la información requerida para hacer el comrnit local de
la subtransacción b) un registro de bitácora llamado ready. Si el coordinador recibe todos
66
los READY decidirá por un cornmi t. pero si recibe un ABORT o no recibe respuesta de un nodo
después de que expire su temporizador decidirá abortar la transacción.
Fase 2. El coordinador inicia esta fase grabando su decisión en la bitácora como un registro
global-cornmit o global-abort. Luego informa a todos los participantes su decisión con un
mensaje. Los participantes escriben commi t o abort en su bitácora según el mensaje que
reciban del coordinador. Finalmente. todos los participantes mondan un ACK al coordinador
y ejecutan los acciones requeridas para acordar o abortar lo subtronsacción. Cuando el
coordinador recibe el ACK de todos los participantes escribe un registro en la bitácora
llamado complete. Después de escribir este registro. el coordinador puede olvidar la
transacción.
Coordinador Participante
1 Prepara el acuerdo
2 Preparar poro acuerdo
3 Acordar
3 Acordar
Finalizar
Fig. 4.15 Comunicación en el Protocolo de Compromiso a dos Fases.
Arquitectura para las transacciones distribuidas
La arquitectura en este tipo de transacciones debe considerar el sistema operativo sobre el
que se trabajo. especialmente lo administración de los procesos y lo intercomunicación entre
ellos: así como las características de comunicación sobre la red. La comunicación entre
nodos se puede realizar mediante el establecimiento de sesiones. o bien mediante
datagramas. Además se ha de considerar lo estructura que tomará el sistema. que puede ser
de dos formas básicos: centralizado o jerárquico.
67
Estructura Centralizada.- el agente raíz activa y controla a los agentes
Fig. 4.16 Transacciones Distribuidas con Estructura Centralizada
Estructura Jerárquica.- Cada agente puede activar otros agentes formando un árbol de
agentes.
Fig. 4. 17 Transacciones Distribuidas con Estructura Jerárquica
Estructura lineal.-
Fig. 4.18 Transacciones Distribuidas con Estructura Linear
Estructura distribuida.-
Fig. 4.19 Transacciones Distribuidas con Estructura Distribuida
La estructura que se adopte depende del tipo de comunicación que se requiera y debe
considerar los costos en cuanto número de mensajes requeridos y el tiempo.
68
4.8 CONTROL DE CONCURRENCIAS
Dos de los principales mecanismos que se utilizan para controlar las concurrencias en los
sistemas distribuidos son los candados. y las estampillas de tiempo. En esta sección se presenta
el mecanismo de candados a dos fases. la detección y prevención de abrazos mortales.
mecanismos de estampillas de tiempo y el método optimista para el control de concurrencias.
El concepto de seriablidad tiene un papel primordial en el control de concurrencias. Para
presentarlo utilizaremos los siguientes elementos:
R1(x): que significa una operación de lectura de x ejecutada por lo transacción i.
W1(x): operación de escritura de x ejecutada por la transacción i.
read-set: conjunto de lecturas.
write-set: conjunto de escrituras .
Itinerario (S): es la secuencia de operaciones ejecutadas por la transacción.
T1: Transacción i.
Decimos que TI y Tj son dos transacciones ejecutadas serialmente en un itinerario S si la última
operación de Ti precede a la primera de Tj en S y viceversa. De otra forma la operación es
concurrente (En un sistema centralizado). Es posible ejecutar itinerarios concurrentemente con
los mismo efectos que una ejecución serial. Se llama itinerario correcto a aquel que es
equivalente a una ejecución serial. Dos itinerarios son equivalentes si:
• Condición 1. Cada operación de lectura lee los valores de los datos que son producidos
por la misma operación de escritura en ambos itinerarios.
• Condición 2. La operación de escritura final de cada dato es la misma en ambos itinerarios.
S1 y S2 son equivalentes si para cada par de operaciones conflictivas Oi y Ox tales que Oi
preceda a Ox en S1. entonces también Oi precede a Ox en S2.
Dos operaciones están en conflicto si ambas operan sobre el mismo dato. y una de ellas es
una operación de escritura. siendo que las operaciones provienen de diferentes
transacciones.
Si aplicamos un mecanismo de control de concurrencias local a cada nodo. podemos
asegurar que todos los itinerarios locales están serializados. Pero esto no es suficiente, se
requiere que:
1.- Cada itinerario local Sk sea serializable
69
2.- Exista un ordenamiento total de T1 .... Tn tal que si Th < T1 en el ordenamiento total. entonces
exista un itinerario serial Sk· tal que Sk sea equivalente a Sk· y Th < T1 en el itinerario serial Sk·,
para cada nodo k donde ambas transacciones ejecuten alguna acción.
Proposición: Sean T1 .... .Tn un conjunto de transacciones. y E una ejecución de las
transacciones modeladas por los itinerarios S 1 ... Sm . E es serialmente correcta si existe un orden
total de las transacciones tal que para cada par de operaciones conflictivas Oh y 01 de las
transacciones T h y T1 respectivamente Oh precede Oi en cualquier itinerario S1 ..... Sm si y sólo si
T h precede a T1 en el ordenamiento_ total.
4.8.1 Candados a dos Fases
El uso de candados consiste en que si una transacción toma un registro. le debe poner un
candado para que nadie pueda hacer uso de él. hasta que la misma transacción quite el
candado. Los candados pueden ser compartidos cuando se usa lectura. o exclusivo cuando
requieren escritura. Una transacción bien formada es aquella que siempre pone candados de
modo compartiao antes de realizar una lectura. y pone candados de modo exclusivo en los
datos antes de. escribir sobre ellos. Para que una transacción utilice correctamente el
mecanismo de candados debe emplear transacciones bien formadas.
Las siguientes reglas de compatibilidad son necesarias para el uso de candados:
1. Una transacción puede poner candados a datos en modo compartido si el dato no tiene
otro candado. o si el dato tiene candado de tipo compartido que corresponda a otra
transacción.
2. Una transacción puede poner candados exclusivos sólo si el dalo no tiene candado de
ningún tipo.
Dos transacciones están en conflicto si tratan de poner candado al mismo dato con dos
modos incompatibles: exclusivo-compartido o exclusivo-exclusivo. K. Eswara en [Eswaran 1976]
prueba que la ejecución de transacciones concurrentes es correcta si se observan tas
siguientes reglas:
1. Las transacciones son bien formadas
2. Se observan las reglas de compatibilidad
3. Cada transacción no pide nuevos candados después de haber liberado alguno.
La última regla define las transacciones aseguradas a dos fases (2-phase-locked 2PLJ. porque
para cada transacción hay una primera fase en la que se ponen candados. y una segunda
fase en la que se liberan.
70
Para asegurar la propiedad de aislamiento de una transacción debe mantener sus candados
exclusivos hasta realizar el commit. Un problema a superar en el uso de los candados son los
abrazos mortales que se verá en el punto 4.8.2.
El uso de candados en las bases de datos distribuidas pueden utilizar el mecanismo 2PL. En
este caso el agente administrador de transacciones distribuidas debe considerar que se
puede estar trat'iajando con varias copias (replicaciones) de datos. lo cual se puede resolver
con uno de los siguientes esquemas:
1. Candado de escritura en todas las copias, candados de lectura en una copia.
2. La mayoría de las copias con candado.
3. Copia primaria con candado.
4.8.2 Detección y Prevención de Abrazos Mortales
Los abrazos mortales se dan cuando entre dos transacciones. cada una tiene bloqueado un
dato y se encuentra esperando obtener un dato diferente. el cual esta bloqueado por la otra
transacción con un conflicto de modo de candado. En este conflicto las transacciones se
quedan bloqueodas hasta que se realice una intervención del sistema para suspenderlas.
Al detectar un candado mortal se debe abortar una o más transacciones y reiniciarlas, por lo
cual se ha de minimizar el costo de esta operación. El primer paso es detectar el deadlock, lo
cual se puede realizar con diferentes métodos, centralizado o jerárquico, con procesos que se
encarguen de controlar la situación de espera y que detecten que procesos se pueden
abortar para obtener el menor costo.
Un problema con la detección de los dcadlock es que su ejecución se basa en tiempos de
respuesta. por lo que el retardo se pude confundir con un deadlock. Una segunda opción
para evitar los abrazos mortales es prevenirlos, no dejando correr procesos que pudieran
realizar transacciones con posibilidad de generar abrazos mortales
4.8.3 Estampillas de Tiempo
En este método se asigna una estampilla de tiempo única a cada transacción. Las
transacciones se procesan en base a la estampilla, con lo que se llega a una ejecución
equivalente a una ejecución en orden a las estampillas. El control permite a una transacción
leer o escribir el dato x sólo si x ha sido escrito por una transacción más antigua: de lo contrario
ignora la operación e inicia nuevamente la transacción.
71
Mecanismo Básl-:o
1 Cada transac.ción recibe una estampilla de tiempo cuando es inicializada en su nodo
origen.
2 Cada lectura o escritura requerida por una transacción tiene la estampilla de la transacción.
3 Para cada dato x. la mayor estampilla de lectura y la mayor estampilla de escritura son
registradas como RTM(x) y WTM(x) respectivamente.
4 Sea TS la estampilla de la operación de lectura sobre x. Si TS < WTM(x) se desecha la
operación de lectura y la nueva transacción se genera con una nueva estampilla. De lo
contrario. se ejecuta la operación de lectura y la nueva transacción se genera con una nueva
estampilla. De no ser así se ejecuta la operación de lectura y RTM(x) se modifica por
max(RTM(x).TS).
5. Sea TS la estampilla de una operación de escritura y TS < RTM(x) o TS < WTM(x) se desecha la
operación. en caso contrario se ejecula y WTM(x) cambia a TS.
La ventaja de este método sobre los candados. es que no genera abrazos mortales.
4.8.4 Método Optimista para el Control de Concurrencias.
En lugar de suspender o rechazar operaciones desde un principio como 2PL y las estampillas.
siempre ejecuta la transacción completa. Después de ejecutar la transacción realiza una
prueba para ver si las operaciones no tienen problema. La prueba es de seríabílidad. si una
transacción no la pasa. esa transacción debe ser iniciada nuevamente.
Este método sigue tres fases:
l Fase de Lectura. Se leen valores de la base. se determinan nuevos valores. se calcula y se
predefinen nuevos valores a escribir.
2 Fase de Validación. Se verifica que la transacción no tenga inconsistencias.
3 Fase de Escritura. Se aplican los cambios si la validación no encontró problemas. de lo
contrario inicia nuevamente la transacción.
4.9 ADMINISTRACIÓN
La administración de la base de datos involucra tanto aspectos técnicos como políticas
odminislrativas. Sólo se tratará la parte técnica. principalmente lo relacionado con el
catálogo de información. El tema principal en la administración de los SMBDD es el grado de
autonomía que se de a cada nodo. Las soluciones extremas son. la ausencia de autonomía y
la administración completamente autónoma.
72
4.9.1.3 Nombre de Objetos y Administración Autónoma
Al utilizar nodos autónomos surgen algunos problemas con respecto a la asignación de
nombres. En este los usuarios de cada nodo manejan, crean y nombran sus datos en forma
independiente de cualquier control global. al tiempo que permiten a varios usuarios compartir
datos. Por lo tanto
1 la definición de datos debe ser ejecutada localmente.
2 Diferentes usuarios deben poder dar el mismo nombre a datos diferentes.
3 Usuarios diferentes, en nodos diferentes, deben poder hacer referencia a los mismos datos.
El sistema R* utiliza cuatro componentes para los nombres:
a) Identificador del usuario que creó el objeto
b) Nodo del usucrio
c) Nombre del objeto
d) El lugar donde se creo el objeto
Por ejemplo:
[email protected]@cuba
En este caso el usuario es 01302032. de mexico. creó la relación global EMP en cuba. Es
recomendable que el sistema permita definir sinónimos que mapeen los nombres simples a
nombres del sistema global. los sinónimos se deben crear por un usuario específico en un
nodo específico.
4.10 CONCLUSIONES
los SMBDD ofrecen múltiples ventajas en comparación a los SMBD. Para su diseño se siguen
cualro fases:
1 J Diseño del esquema global.
En esta fase se define el tipo de esquema que debe utilizarse. los diccionarios o catálogos
globales, y el tipo de sistema que puede ser distribuido o multi base de datos.
2) Diseño de fragmentación.
La fragmentación se puede realizar en forma horizontal. en base a predicados. O bien en
forma vertical, dividiendo el esquema de una relación global de tal forma que el esquema
queda dividido en fragmentos. Para reconstruir las relaciones, en el primer caso se recurre a
la unión de fragmentos. y en el segundo al producto cartesiano.
3) Diseño de localización.
73
4.9.1.3 Nombre de Objetos y Administración Autónoma
Al utilizar nodos autónomos surgen algunos problemas con respecto a la asignación de
nombres. En este los usuarios de cada nodo manejan. crean y nombran sus datos en forma
independiente de cualquier control global, al tiempo que permiten a varios usuarios compartir
datos. Por lo tanto
1 La definición de datos debe ser ejecutada localmente.
2 Diferentes usuarios deben poder dar el mismo nombre a datos diferentes.
3 Usuarios diferentes, en nodos diferentes. deben poder hacer referencia a los mismos datos.
El sistema R• utiliza cuatro componentes paro los nombres:
o) Identificador del usuario que creó el objeto
b) Nodo del usuario
c) Nombre del objeto
d) El lugar donde se creo el objeto
Por ejemplo:
[email protected]@cuba
En este caso el usuario es 01302032. de mexico, creó la relación global EMP en cubo. Es
recomendable que el sistema permito definir sinónimos que mapeen los nombres simples a
nombres del sistema global. Los sinónimos se deben crear por un usuario especifico en un
nodo especifico.
4.10 CONCLUSIONES DEL CAPÍTULO 4
Los SMBDD ofrecen múltiples ventajas en comparación a los SMBD. Para su diseño se siguen
cuatro fases:
1) Diseño del esquema global.
En esta fase se define el tipo de esquema que debe utilizarse. los diccionarios o catálogos
globales, y el tipo de sistema que puede ser distribuido o multi base de datos.
2) Diseño de fragmentación.
La fragmentación se puede realizar en forma horizontal. en base a predicados. O bien en
forma vertical. dividiendo el esquema de una relación global de tal forma que el esquema
queda dividido en fragmentos. Para reconstruir las relaciones, en el primer caso se recurre a
la unión de fragrr.entos. y en el segundo al producto cartesiano.
3) Diseño de localización.
74
La localización de fragmentos puede permitir redundancia o replicas de fragmentos. Las
réplicas permiten mayor disponibilidad para la lectura de información. pero requieren formas
más complejas para la modificación de datos. En esta fase se debe considerar el beneficio
de localizar los fragmentos en un nodo. contra el costo de su mantenimiento.
4) Diseño de la estructura física.
La última etapa del diseño especifica la estructura que debe mostrar el sistema. los
mecanismos que se emplean para comunicación y los recursos con los que se cuenta.
Los sistemas distribuidos homogéneos se distinguen de los heterogéneos por la forma en que
trabajan los conceptos que podemos observar en el siguiente cuadro:
Esquema Conceptual Global Tipo de Arquitectura
Sistemas Homogéneos Necesario SMBDD
Sistemas Heterogéneos Opcional Sistema Multi Base de Datos
La figura 4.5 muestra el papel de un directorio/diccionario global en un SMBDD. este elemento
es el que permite manejar en forma transparente y uniforme la fragmentación y replicación
transparente en el prototipo que se presenta en el capítulo 7. En la misma figura se puede
observar cómo el esquema local trabaja de la misma forma que un SMBD centralizado. con
administración local. por lo que se utilizaron servidores de SMBD para implementar el
prototipo.
La figura 4.6 muestra los componentes que debe considerar un SMBDD. enlre los cuales
encontramos el optimizador de consultas globales y el monitor de ejecución global. Estos dos
módulos deben encargase de las siguienles actividades:
a) Paso de consultas globales a consultas fragmenladm.
Es recomendable el trabajo con álgebra relacional para poder seguir los 6 criterios expuesto
en el punto 4.5.
b) Selección de las estrategias de acceso(4.6)
Considerando el costo de transmisión.
75
c) La administración de transacciones (4.7)
Las cuales deben cumplir con las cualidades de atomicidad. durabilidad. seriabilidad y
aislamiento.
e) El control de concurrencias(4.8).
Que puede ser tratado mediante candados. estampillas de tiempo o bien con el método
optimista para el control de concurrencias.
Ventajas Desventajas
Candados Asegura seriabilidad Bloqueante
Abrazos Mortales
Estampillas Evita Abrazos Mortales Las transacciones pueden ser
abortadas fácilmente
Método Optimista Siempre ejecuta la Sólo se recomienda, si es
transacción completa y mayor la probabilidad de
después analiza los resultados. tener éxito en el analisis de
resultados
La administración del sistema (4.9) se realiza con el diccionario/directorio global desde el
catálogo del esquema global.
76
.5 ~lc~l64JIMl!flt'lff d'J5 f '1íl~d'J CO!t'lJ.5>1!1~m ~INJ .~1.5>1~ liilbU'JlcJd'JID)OW( !Dile ~6~51c.5 ID)f ID)~ffO,)J
lM5n<l[¡)l~mo
En la actualidad existe una gran variedad de marcas comerciales que se dedican al
desarrollo de Sistemas Manejadores de Bases de Datos. Para el desarrollo de este trabajo se
optó por el SMBD Sybase SQL Server y las bibliotecas Open Client y Open Server. Sybase ha
sido calificado. junto con Oracle. lnformix. SQL Server, CA-Open lngres y DB2 como uno de los
6 grandes Servidores de Bases de Datos [Rennhackkamp M. 1996). De estos manejadores.
Sybase, 082 y CA-Open lngres permiten el empleo del protocolo de compromiso a dos fases
con servidores de diferentes proveedores en forma transparente.
Por otra parte. Open Client y Open Server son dos productos excepcionales por su
portabilidad y capacidaq para manejar el paradigma cliente servidor. La arquitectura de
estos productos soporta nuevas tecnologías de comunicación y estándares. manteniendo
compatibilidad con versiones anteriores.
A lo largo de esté capítulo veremos las características de las herramientas que brinda Sybase.
5.1 LA ARQUITECTURA CLIENTE SERVIDOR
En esta arquitectura las operaciones que realizan las aplicaciones se dividen entre el cliente y
el servidor. El cliente es el responsable de administrar la interfaz del usuario (presentar y
manipular datos). mientras que el servidor de la base de datos es el responsable del
almacenamiento y acceso a la base de datos. En la arquitectura cliente servidor. la
recuperación de datos. seguridad y administración de transacciones se centraliza en el
servidor. Las funciones del SMBD son ejecutadas por el servidor en un ambiente cliente
servidor.
Según Sinha [Sinha 1992) un cliente es un proceso que interactúa con el usuario y tiene las
siguientes características:
• El cliente presenla la interfaz de usuario; que es el programa de aplicación que controla las
pantallas del usuario, interpreta los dalos recibidos del servidor y presenta los resultados de
las consultas.
77
• El cliente forma consultas o comandos en un lenguaje específico. generalmente SQL. para
reunir los datos que requiera la aplicación y enviar estas consultas al servidor:
frecuentemente. la preparación de consultas es transparente al usuario.
• Las funciones del cliente son ejecutadas en una computadora diferente a la que ejecuta
las funciones de servidor de base de datos.
El servidor tiene las siguientes características:
• El servidor responde a las consultas del cliente. verifica la sintaxis de las instrucciones. revisa
los derechos de acceso. ejecuta las instrucciones y responde con los datos requeridos o
con mensajes de error.
• El servidor se oculta del cliente y del usuario final. de tal forma que el usuario no advierta su
existencia como software ni hardware.
La relación cliente servidor se puede ejecutar aún entre diferentes tipos de sistemas operativos.
Fred McFadden y Jeffrey Hoffer [McFadden.Hoffer 1994) señalan las siguientes ventajas de la
arquitectura Cliente/Servidor en las bases de datos:
• Permite a las compañías hacer uso de los beneficios de las microcomputadoras.
• Permite que un mayor número de procesos sean ejecutados más cerca de donde se
originaron. reduciendo el tráfico en la red.
• Facilita el uso de recursos gráficos
• Permite y motiva la aceptación de sistemas abiertos.
Y menciona algunos proveedores de esta tecnología:
• 082/2 de IBM Corporation
• Oracle Server de Oracle Corpora tion
• SQLBase Server de Gupta T echonlogies
• Microsoft's SQL Server
• SQL Server de: Sybase, lnc.
• Borland's lnterbase Client/Server DBMS
La diferencia principal entre una base de datos con arquitectura cliente servidor y otra
totalmente centralizada radica en el cliente como entidad capaz de realizar procesos en el
sistema.
Open Client y Open Server utilizan esta tecnología. Open Server se describe en 5.4.1. Open
Client es una interfaz 3GL que trabaja tanto con SQL Sever de Sybase como con algunos otros
78
Servidores. Se basa en las bibliotecas DB-Library. un conjunto de rutinas y macros que le
permiten a una aplicación interactuar con un Servidor. Maneja comunicación y transferencia
de datos entre el Servidor y la aplicación. Provee una interfaz consistente para programas
escritos en C.
DB-Library permite habilitar la base de datos para que sea parte de una aplicación integral.
Las instrucciones T-SQL (ver punto 5.2) son incorporadas en aplicaciones escritas en lenguaje
C. de tal forma que éstas pueden traer y modificar valores de la base de datos. Los valores de
las bases de datos pueden ser guardados en variables del programa para su manipulación en
una aplicación de la misma forma en que se pueden utilizar variables para modificar la base
de datos.
La figura 5. 1 muestra las principales funciones que provee Open Client para que un cliente
pueda comunicarse con un Servidor SQL.
dblogin ()
dbopen ()
dbcmd()
dbsqlexec ()
1/batch
dbresults()
1 /stmt
dbclose () dbexit ()
Obtener estructura de acceso
Establecer conexión con el servidor
Mandar instrucciones SQL al buffer cmd
Enviar las instrucciones al servidor
Obtener el siguiente resultado
Procesar los datos obtenidos
Terminar
Falla Password erróneo
Falla Error al
compilar sentencias
Falla Error por falta de permisos
Fig. 5.1 Funciones de Comunicación Cliente -Servidor en Sybase.
79
5.2 LENGUAJES TRANSACCIONALES
SQL ha sido hasta la fecha el estándar para consultas en bases de datos. Sin embargo, los
proveedores han complementado el estándar con lenguajes extendidos. Sybase utilizado
Transact-SQL{T-SQL). que es una extensión del SQL ANSI. En él se incluyen definiciones de
datos. manipulación de datos. control de datos. instrucciones para control de flujo. tipos de
datos que pueden ser definidos por el usuario. procedimientos y disparadores. A continuación
se muestran las instrucciones básicas que brinda el servidor SQL de Sybase.
5.2.1 El Nombre de los Objetos en Transact-SQL
El nombre que se dé a los objetos debe ser menor a 30 caracteres. La sintaxis es la siguiente:
[[base_de_datos].dueño.]objeto[.columna]
5.2.2 Lenguaje de Definición de Datos
Comando:
Sintaxis:
Comando:
Sintaxis:
Comando:
Sintaxis:
create database
crea te database nombre_basededatos
on devicename =tamaño[. devicenome =tamaño •... )
[log on devicename = tamaño]
El tamaño se define en Megabytes y los dispositivos (devices) se crean con la
instrucción disk init.
Como el manejador utiliza varias bases de datos. se puede cambiar de base de
datos de trabajo utilizando el comando use nombre_basededatos
create table
crea te table nombre_fab/a
( columna tipo_columna not null/null
[ .... ))
alter table
al ter table nombre_tabla
add columna tipo_columna not null/null
[ .... ]
80
Comando:
Sintaxis:
Comando:
Sintaxis:
drop table
drop table_name
c.::eate rule
create rule nomJule
as @campo proposición
Después. la regla debe ser asociada a una columna de una tabla
sp_bindrule 'nomJule','Tabla.columna·
Para borrar una regla. es necesario primero quitar la asociación
sp __ unbindruel 'fabla.columna·
y después borrarla
drop rule nomJule
5.2.3 Lenguaje de Manipulación de Datos
COMANDO: in.sert
SINTAXIS: insert into tabla [(columna, columna .... )]
values (valor[.valor ... ])
COMANDO: update
SINTAXIS: update tabla
set columna = valor
[where expresión]
COMANDO: delete
SINTAXIS: dclete tabla
[where expresión]
La extensión de T-SQL permite que la cláusula where realice un join con otras tablas. Por
ejemplo:
delete autor
from autor. titulo
whe re autor.au_id = titulo.au_id
81
Sybase permite el uso de tablas temporales. las cuales pueden ser creadas por cualquier
usuario y son eliminadas al terminar la sesión. El sistema considera como tablas temporales
aquéllas cuyo nombre inicie con el carácter #.
Para las consultas T-SQL utiliza SQL ANSI y cuenta con varias extensiones como:
Uso de equivalencias del tipo% y utilizando la cláusula like estándar:
[x-z] Equivale a cualquier carácter que se encuentre en el rango x-z.
(Ax-z] Excluye a cualquier carácter en el rango x-z.
[xyz) Compara con los caractere~ xyz.
Empleo de concatenación con el carácter + y funciones como substring (), right (),
upper(), convert().
El uso de order by permite utilizar más de una columna para la ordenación. y se puede
ordenar en base a columnas que no aparecen en el select. También permite el uso de dos
instrucciones compute y computeby que muestran un gran total y subtotales respectivamente.
5.2.4 Lenguaj~ de Control
Un usuario que desee accesar al servidor debe tener una cuenta. la cual sólo puede ser
creada por el Administrador del sistema desde la base de datos master, en la cual se
almacena información general del sistema. con el siguiente procedimiento:
sp_addlogin nombre[.password(,base_por_omisión]J
El acceso al servidor no basta para accesar una base de datos. Para lograr el acceso de
datos el administrador. o el dueño de la base de datos. debe ejecutar el siguiente proceso
desde la base de datos que debe accesar el usuario:
sp _ adduser nombre
los comandos grant y revoke toman los siguientes esquemas para controlar acceso:
grant / revoke create database to / from usuorio[.usuario .... ]
create default
create procedure
create rule
create table
crea.te view
dump da.ta.base
dump tra.nsaction
all
82
grant/revoke select
insert
on object to /from usuario[,usuario .... ]
delete
update
execute
all
5.2.5 Instrucciones para el Control de Flujo
Ejecución Condicional. lf ... else.
Sintaxis: i f expresión_booleana
instrucción a ejecutar si la expresión es verdadera
[ else [ i f expresión_boo/eana ... ]
r else instrucción a ejecutar si la expresión es falsa]
Agrupación de Instrucciones. begin / end
Sintaxis: begin
bloque de instrucciones
end
Verificación de Existencia de registros. If exist ...
Sintaxis: i f exis t ( sel e et ... )
ins1rucción a realizar
Detener el flujo de ejecución en forma incondicional. Re turn
Ejecución repetida en base a una condición. while ... break ... con tinue
Sintaxis: while expresión_booleana
bloque de instrucciones a ejecutar
Suspender la actividad hasta que ocurra un evento. waitfor
Sintaxis de algunos eventos:
waitfor (delay 'tiempo' 1 time 'hora' 1 processexit 1 ... )
83
5.2.6 Declaración de Variables
Sintaxis: declare @nombre_variable tipo_varible[,@nombre_variable ... ]
Las variables pueden utilizarse tanto en procedimientos almacenados (5.3.7). como en bloques
de instrucciones. Al declarar una variable se inicializa en null. A una variable se le puede
asignar el resultado de una consulta. Por ejemplo:
select @venta= total
f rom factura
where id=" 12321"
En estos casos. el resultado no se muestra al usuario. Si el resultado de la consulta es nulo. la
variable no se altera. y si existe más de un registro con el valor. la variable toma el valor del
atributo en el último registro.
El sistema utiliza variables predefinidas. las cuales se denominan variables globales y que
guardan valores .como:
@@error
@@rowcount
@@servername
Número de error generado por el último error
Número de registros afectados por la última instrucción
Nombre del servidor SQL.
5.2. 7 Procedimientos Almacenados
Un procedimiento almacenado es un conjunto de instrucciones SQL que residen en el servidor
SQL y que pueden ser ejecutadas por cualquier usuario a quien se le otorgue el permiso
correspondiente. Estos procedimientos pueden recibir y enviar parámetros. valores y mensajes,
así como llamar a otros procedimientos.
Sybase provee algunos procedimientos almacenados y el usuario puede crear sus propios
procedimientos. Algunos de los procedimientos que provee Sybase son:
84
PROCEDIMIENTO USUARIO FUNCIÓN
sp_who Cualquier Señala quienes están conectados al SMBD. que
usuario están haciendo y que base están accesando.
sp_helpuser Cualquier Obtiene nombre, id. Grupo. Login_name. y Base
usuario de datos predeterminada para cada usuario.
sp_helpgroup Cualquier Señala los grupos existentes y los nombres de los
usuario miembros de un grupo.
sp_adduser Administrador Añade un nuevo usuario a la base de datos y
del systema o permite darle un nombre en la base de datos y
dueño de la un grupo.
base de datos.
sp_changedbowner Administrador Cambia el dueño de la base de datos por otro
del syslema o usuario.
dueño de la
base de datos.
sp_help Cualquier Obtiene una lista de todos los objetos, dueños y
usuario tipos de la base de datos actual.
Los usuarios pueden crear sus propios procedimientos con T-SQL y definiendo parámetros y
manejadores de errores. Los procedimientos almacenados son compilados y el código reside
en el servidor SQL. por lo cual se ejecutan más rápidamente que las instrucciones ordenadas
en forma interactiva. Mediante el uso de procedimientos almacenados se reduce el tráfico en
la red.
Para crear un procedimiento almacenado se emplea la estructura
crea te proc <nombre_procedimienlo>
[(@parametro tipo .... ) )
as <procedimiento T-SQL>
El procedimiento puede devolver valores con la cláusula return y el valor numérico a
devolver como parámetro.
Para ejecutar un procedimiento se utiliza la siguiente sintaxis:
[exec] nombre_procedimienlo [parametro[=vo/or]. parametro ... J
85
Los procedimientos almacenados no pueden utilizar las instrucciones:
Create View
Create Default
Create Rule
Create Trigger
Create Procedure
Para el mantenimiento de procedimientos. existen los siguientes procedimientos que provee
Sybase:
sp _ rename nombre_onterior . nuevo_nombre
drop proc nombre
5.2.8 Disparadores (TRIGGERS)
Los disparadores son procedimientos almacenados que se refieren a una tabla específica y se
definen para ser ejecutados al actualizar. insertar o borrar datos de la misma. Se puede
disponer de uno de ellos por cada tabla. La activación de un disparador se puede deber a la
activación de otro disparador generando anidamientos hasta de 16 llamadas. después de las
cuales las transacciones son abortadas. Los disparadores generalmente se utilizan para validar
información.
Cualquier sentencia de T-SQL puede ser utilizada para crear disparadores. sin embargo no es
posible que un disparador reciba parámetros y tenga las mismas restricciones de un
procedimiento almacenado. Los disparadores pueden utilizar la instrucción IF UPDATE para
determinar si una columna fue modificada.
Sintaxis:
CREATE TRIGGER nombre_disparador
ON nombre_tabla
FOR{insert/update/delete}
AS
Sentencias T-SQL...
86
5.2.9 Manejo de Transacciones
Una transacción se forma por una serie de instrucciones T-SQL que deben ser manejadas
como se vio en 4.7. La transacción debe garantizar que todos las operaciones fueron
ejecutadas. o que ninguna lo fue. En Sybase se proveen tres componentes para su
administración: Instrucciones para el control. el registro en una bitácora de todas las
modificaciones y el uso de registros de candados.
Normalmente cualquier modificación. adición o eliminación en la base de dato es tratada
como una transacción. pero se puede agrupar un conjunto de instrucciones T-SQL para que
estas también se manejen como transacciones. La sintaxis de las instrucciones de
agrupamiento son: begin tcansaction nombre_transacción
save tcansaction nombre_2
collback transaction [nombre_transacción o nombre_2]
commit transaction
Desde el begin hasta el corrunit, ningún proceso podrá ver los cambios realizados por la
transacción. Una transacción no puede realizar las siguientes actividades:
crear bases de d:itos
alterar un base de datos o tabla
borrar objetos
realizar la instrucción select into
otorgar o revocar permisos
La llamada a procedimientos remotos con una 1ransacción no puede ser reiniciada
( collback) por u11a transacción.
Los candados son la principal forma en que Sybase trabaja el problema que causa,:-i las
transacciones concurrentes. Los candados en este sistema se colocan en forma automática
por SQL con el fin de permitir transparencia a los usuarios. En Sybase se pueden bloquear
registros. páginas. tablas o índices y existen candados exclusivos y compartidos (ver punto 3.8).
Los candados exclusivos se mantienen durante la 1ransacción. mientras que los compartidos se
liberan tan pronto como se lea la página.
87
Es posible utilizar candados en forma explícita con el siguiente esquema:
begin transaction
declare @variable
select @varible = atributo
frorn tabla holdlock
where atributo = 'valor'
cornrnit transaction
El procedimiento sp _ lock permite conocer los candados que están bloqueando datos en la
base y muestra el tipo de candado colocado. El servidor SQL de Sybase detecta los abrazos
mortales automáticamente y aborta la transacción en base al menor tiempo de CPU
ocupado por la transacción (el código de error generado es el 1205).
5.3 HERRAMIENTAS PARA EL TRABAJO DISTRIBUIDO
Para el desarrollo de este tema seguiremos los aspectos que señalan McGoveran y Date
[McGoveran. Date 1992) como los más representativos en la arquitectura de Sybase.
5.3.1 Protocolo de Compromiso a Dos Fases.
El protocolo de compromiso a dos fases y su importancia fue tratado en 3.7.2. Sybase permite
que se realice este protocolo entre servidores Sybase y aún entre servidores Sybase con otros
servidores ofrecidos por diversos proveedores como 082. de tal forma que uno transacción es
acordada en todc-s los servidores o se aborta.
Sybase utiliza el producto Open Client para coordinar a los servidores que intervendrán en la
transacción. El cliente ejecuta una transacción que se comunica con cada uno de los
servidores de la siguiente forma:
1.- La aplicación debe comunicarse con los servicios de transacción de cada servidor" en
cada fase de protocolo. Una conexión con los servicios de transacción se inicia con la
función open_ commi t ( ) y se termina con la función el ose_ xact ( ) . La transacción se inicia
con la función start_xact (), se acuerda con cornrnit_xact () y se aborta con
abort_xact().
88
2.- La aplicación debe utilizar un identificador único en cada uno de los servidores. éste
identificador se asigna con la función build _ xact _ string () .
3.- Para realizar la primera fase del protocolo se emplea la instrucción PREPARE TRANSACTION.
5.- Los servidores deben informar a la aplicación cada comrnit o rollback que ejecuten
mediante la función remove _ xact ( ) .
5.3.2 Manipulación de Datos Distribuidos
Manejo de Bases de Datos Múfflples
En Sybase se puede accesar a múltiples bases de datos. simplemente haciendo referencia a
las tablas con el nombre que indica la base de datos a la que pertenece. esto es posible si las
bases de datos pertenecen al mismo servidor (a menos de que se trabaje con el protocolo de
compromiso a dos fases). La referencia a objetos que pertenecen a diferentes bases de datos
utiliza la siguiente nomenclatura:
nombre_servidor.nombre_base_de_datos.nombre_esquema.dueño.objeto
Así se pueden realizar consultas como ésta:
select
from
P.•. s.•
partes_db.dueño.tabla P.
proveedor 3s_db.dueño. tabla S
Accesando diferentes bases de datos. e incluso modificándolas. El mecanismo y protocolo
que coordina estas operaciones es el de compromiso a dos fases. pero en forma transparente
al usuario.
Procedimientos Almacenados Remotos
Los procedimientos almacenados que se trataron en el punto 5.3.7 pueden realizarse en forma
remota desde otro servidor. Para realizar estas operaciones es necesario que el Administrador
de la base de datos. añada a la base maestra el nombre del servidor remoto que va a
accesar su servidor mediante las siguientes instrucciones:
89
use master
go
sp _ addserver SERVIDOR
go
También se requiere dar de alta usuarios remotos con los procedimientos:
sp_addlong
sp_addremotelogin
Para ejecutar el procedimiento remoto se especifica el nombre del procedimiento y el nombre
del servidor. Por P.jemplo:
execute rcmotcscrver.pubs.dbo.sp_storeprocedur ... 9----,procedirnicnlo
I Base de Datos 1 / "" l p,op;eia,;o
5.3.3 Servicios de Replicación de Datos
Companlon Servers
Un servidor acompañante se utiliza para proteger un sistema de fallas en el procesador. En el
sistema existen varios procesadores, los procesadores o servidores activos y el servidor
acompañante. Estos servidores unidos por una red comparten sus discos. El servidor
acompañante permanece en espera, hasta que un servidor activo se dañe: en ese momento.
el servidor acompañante realiza las funciones del servidor activo dañado.
Dispositivos Espejo
Sybase puede trabajar con procesos que generen réplicas de los datos almacenados en un
dispositivo auxiliar llamado espejo. Cada dato almacenado en el dispositivo primario es
almacenado automáticamente y en forma transparente en el espejo. En caso de que el
dispositivo primario sufra algún daño, el espejo toma inmediatamente su lugar y la copia
primaria es desactivada sin que el usuario note cambios. Una vez que el dispositivo primario es
arreglado. este puede recibir la información del espejo para volver a ocupar su lugar.
90
5.3.4 Open Se:rver
Open Server es una biblioteca de programación que cuenta con varias funciones en lenguaje
C que se ligan a los programas para convertirlos en servidores. Estas librerías coexisten con DB
Library.
El Open Server puede unificar la forma en que una aplicación se comunique con múltiples
bases de datos de tal forma que provea:
• Transparencia en la distribución del manejo de datos.
• Un mecanismo para accesar funciones que no sean de bases de datos.
• Una interfaz estándar a otros nodos y sistemas.
Una aplicación Open Server trabaja a través de manejadores de eventos; una vez que se
encuentra en ejecución (srv_run) espera a que un cliente le haga una petición. Toda
petición es manejada como un evento. Cada evento tiene un manejador de eventos por
default. pero se pueden escribir manejadores propios.
Los eventos pue.den ser disparados por la petición de un cliente o por el código del Open
Server. algunos de los eventos posibles son:
PETICIÓN DEL CLIENTE
dbopen ()
dbsqlexec ()
dbexit ()
Ejemplo:
#include <sybfront.h>
#include <sybdb.h>
#include <srv.h>
EVENTO EN EL SERVIDOR
SRV CONNECT
SRV LANGUAGE
SRV DISCONNECT
/*Declaraci~n del manejador my start */
int mystart();
main()
SRV CONFIG *config;
SRV SERVER
91
/*Configuraci~n e inicializaci~n del Server*/
config
server
srv_config_alloc();
srv_init(config,óMYNAMEó,SRV_NULLTERM);
/*Instalar un manejador de inicio*/
srv_handle(server,SRV_START,mystart)
/*Iniciar la cjecuci~ndel servidor*/
srv_run(server);
exit (STDEXIT);
/* Definici~n del manejador de eventos*/
int mystart(server)
SRV SERVER *server;
printf(óhi \nó);
return(SRV_CONTINUE);
Arquitectura
Los clientes y servidores Sybase se comunican mediante interfaces Cliente/Servidor (CS/1) que
se compone de tres bibliotecas:
• Net-Library
• Open Client
• Server Library
Las bibliotecas de red son una serie de funciones para:
• Inicializar y terminar la comunicación • Transferir datos
por la red • Mandar mensajes de Control
• Soportar el multiproceso • Manejar errores
• Direccionar servidores • Administrar Recursos
• Inicializar y terminar conexiones • Diagnosticar
Las bibliotecas Server-Library proveen las siguientes funciones:
• Multi-hilos • Mensajes entre hilos
• Manejo de eventos • Procedimientos Almacenados
• Flujo entre Cliente y Servidor • Opciones de Configuración
92
Tanto Open Client como Open Servar manejan la comunicación tipo cliente/servidor. Cada
una de estas bibliotecas usa un protocolo de bajo nivel llamado Tabular Data Streem (TOS). La
comunicación en un nivel más alto tiene tres formas: lenguaje de peticiones . RPC' s y
resultados.
lenguaje de Peticiones
El lenguaje de peticiones consiste en texto que se manda a través del Open Servar a los
usuarios sin realizar interpretación alguna, dejando a las aplicaciones que realicen la
interpretación.
RPC's
Los RPC de Sybase están formados por procedimientos y parámetros. Los procedimientos son
semejantes a los procedimientos almacenados ya tratados. pero en este caso no se utiliza SQL.
Las peticiones de RPC's pueden ser enviadas tanto a un Open Servar como a un SQL Servar. Si
el RPC es enviado a un SQL Servar. el nombre del RPC es analizado para determinar el servidor
remoto al que hace referencia. El Servidor SQL manda la petición al servidor remoto
apropiado. El servidor remoto puede ser tanto un SQL Servar como una aplicación Open
Server.
RESULTADOS
Los resultados pueden ser estados, mensajes. y datos que envía el Open Server a quien se lo
solicite (Open Client. SQL Server u Open Server). mediante el formato TOS.
5.3.5 Replication Server
El Replication Server es un producto de Sybase que se utiliza para crear. mantener y usar
aplicaciones que utilizan datos replicados. El Replication Server mantiene copias actualizadas
en múltiples nodos de tal forma que los clientes pueden accesar datos locales en lugar de
tener que accesar a datos remotos. con lo cual se incrementa la disponibilidad y disminuye el
tráfico a nodos remotos. Entre las funciones que provee Replication Server se encuentra:
• Permite definir los datos y los procedimientos almacenados que pueden ser replicados.
• Permite Inicializar los datos en una tabla que se replique en otro nodo.
• Realiza actualizaciones periódicas de las tablas primarias en cada réplica.
• Permite a los clientes remotos actualizar las copias primarias a través de procedimientos
almacenados replicados.
93
• Soporta accesos seguros mediante password tanto a SQL Servers como a Replication
Servers.
• Se realizan bitácoras de las modificaciones que se deben realizar. lo cual permite la
recuperación en caso de fallas.
Replication Server utiliza como unidad de replicación las tablas. y éstas pueden ser replicadas
en uno o varios nodos; la réplica puede ser un fragmento horizontal en base a un predicado
específico. Une copia de la tabla es designada copia primaria y todas las demás se llaman
copias replicadas.
Para realizar las transacciones. Replication Server depende de los SQL Servers. asegurando:
atomicidad y durabilidad (ver punto 4.7). Su participación en el control de concurrencias se
realiza cuando las transacciones intentan modificar tablas primarias. El método que utiliza
este producto para el control de concurrencias es el optimista (ver punto 4.8.4)
5.3.6 Navigation Server
Este producto provee de acceso paralelo a tablas y esquemas que estén fragmentados en un
sistema distribuic;Jo. Emplea fragmentación horizontal, vertical y mixta mediante el empleo de
los siguientes componentes: Servidor de Control. Servidores de Datos. Servidor Administrador
de Bases de Datos, Administrador Navigation Server.
El Servidor de Control procesa peticiones de los clientes. Inicia la compilación y ejecución de
SQL y de procesos almacenados.
Un servidor de datos es la unidad de almacenamiento para el funcionamiento de una base
en paralelo. El número de estas unidad es configurable.
El Servidor encargado de la administración de bases de datos es un servidor de control con la
posibilidad de compilar operaciones paralelas. verificar seguridad y manejar la definición de
datos. Este servidor detecta los abrazos mortale. monitorea a los demás servidores y reinicia el
sistema en caso de fallas.
El administrador Navigation Server provee interfaces de administración y configuración
94
5.4 CONCLUSIONES
Para construir un SMBDD como el presentado en la figura 4.5, se requiere conocer las
herramientas con que cuenta el SMBD local. En este capítulo se revisó. la forma en la que el
servidor SQL de Sybose nombra los objetos. cómo maneja el lenguaje de definición de datos.
el de manipulación de datos y el de control. También se dió a concer la forma en la que
trabajan las transacciones locales. los disparadores y procedimientos almacenados.
Además de los servidores SQL. existen en el mercado diversas herramientas para facilitar el
trabajo distribuido. este es el caso de:
a) Protocolos de compromiso a dos fases.
Estos mecanismos permiten realizar transacciones atómicas entre varios servidores aún de
diferentes marca,¡ comerciales.
b) Manipulación de datos distribuidos.
Sybase permite ~ealizar transacciones entre diferentes bases de datos que se encuentren en el
mismo servidor con protocolo de compromiso a dos fases en forma transparente al usuario.
Esto permite al usuario ejecutar sus operaciones sin especificar que está utilizando el
protocolo. También es posible que un servidor solicite la ejecución de procedimientos
almacenados en otros servidores.
c) Servicios de replicación.
Sybase utiliza productos que permiten tanto la redundancia en HW como en datos para
solucionar problamas en el sistema. Companion Server es un servidor de respaldo que
funciona en caso de que un servidor del sistema falle y los dispositivos de espejo generan
réplicas de los datos en dispositivos auxiliares.
d) Arquitectura cliente servidor
Sybase cuenta con una serie de bibliotecas para programar en C. tanto clientes como
servidores. Estas bibliotecas permiten a los programadores gran flexibilidad para accesar
servidores SQL y desarrollar mecanismos distribuidos.
95
e) Replication Server y Navigation Server
Son dos produc•os que ofrece Sybase. el primero para copiar tablas en múltiples bases de
datos y dejar la información lo más cerca posible del cliente. Navigation Sever. por su parte.
permite la ejecución de consultas en paralelo mediante la fragmentación de tablas.
Las herramientas que se ofrecen a los desarrolladores para realizar actividades distribuidas no
son lo suficientemente transparentes como para no involucrarlos en la configuración del
sistema. Es decir. si un desarrollador necesita un procedimiento remoto. debe conocer el
nombre del servidor que utilizará y _los parámetros que emplea el procedimiento. De la mismo
formo. si se emplea una tabla que pertenezca a otra base de datos dentro del mismo servidor.
es necesario hacer referencia a ella con el nombre de la base de datos.
En el capitulo 7 se muestra como se pueden utilizar las bibliotecas de Open Client y Open
Server para construir un SMBDD basado en conexiones a un catálgo global y a varios
servidores SQL. El protocolo de compromiso a dos fases también se muestra en ese capítulo y
es el mecanismo con el cual se logra obtener transacciones globales atómicas.
96
' f~O~l!U'MTK~ f~~'41 fl loit,<r~ffeJW(!K<OLlO ~t <!JI~ MÓl!)<!JllO ~lé rW('4JijM!Etff '4J(~]Ó~ 1
W([fUtdllt~Ó~ ffltAJN~f dll~IE~lt
Hasta este punto. se han revisado características y mecanismo que utiliza Sybase para realizar
comunicación entre clientes y servidores. No se han considerado mecanismos que provean:
• Transparencia en consultas
• El empleo de catálogos globales a través de un LOO especifico
., Aplicaciones inmunes a cambios en la configuración de lo 800
En este capítulo ve;emos la importancia de los tres puntos señalados. sus característicos
deseables y la problemática que implico su implementación.
6.1 NIVELES DE TRANSPARENCIA EN LA DISTRIBUCIÓN
Ceri y Pelagatti [Ceri. Pelagatti 1984) enmarcan el problema de los niveles de transparencia en
las bases de datos distribuidas en dos casos principales: la transparencia en aplicaciones de
lectura y lo transparencia en los aplicaciones que modifican información. lo transparencia en
aplicaciones de sólo lectura puede ser dividido en aplicaciones simples y complejos.
6.1.l Transparencia en Aplicaciones Simples de Sólo Lectura.
Considerando SQL como el lenguaje de acceso a la base de datos y a las variables
precedidas por el símbolo @ como variables definidas por el usuario. una consulto puede
presentar esta forma:
select NOMBRE into @NOMBRE
from PROVEEDOR
where SNUM =@SNUM
En algunos ocasiones se requiere de variables que nos den información de control. Estas
variables se presentarán precedidas por#. Ceri y Pelagatti presentan la figura 6.1 que muestra
los distintos niveles de transparencia en que se puede realizar una consulta simple.
Apffcaclón de Sólo lectura con diferentes nlveles de transparencia.
El primer nivel provee transparencia de fragmentación. En este coso la petición SQL al SMBOO
se realiza sin considerar lo existencia ni la localización de los fragmentos. de tal forma que la
aplicación es inmune a cambios en la estructura de la base de datos.
97
read(terminal, @SNUM); Select N,"\ME into @NAME from SUPPLIER where SNUM = @SNUM
write(terminal, @NAME) .
(a) Nivel 1. Transparencia de Fragmentación
read(terminal, @SNUM); Select NAME into @NAME from SUPPLIER1
where SNJM = @SNUM if not #found then
Select NAME into @NAME from SUPPLIER2
where SNUM = @SNUM write(terminal, @NAME) .
(b) Nivel 2. Transparencia de Localización
read(terminal, @SNUM); Select NAME into @NAME from SUPPLIER1 AT SITE1
where SNUM = @SNUM if not #found then
Select NAME into @NAME from SUPPLIER2 AT SITE3
where SNUM = @SNUM write(terminal, @NAME) .
(b) Nivel 2. Transparencia de Localización
DBMS
-----~ - - - - - - ------... ... ...... ... ... ... ... ...
DBMS -----eilher ___ ..._ _____________ _
... ... ... ... ... ... or ', ...
DBMS -----
---
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:
CREATE FRAGMENTED TABLE empleado
(N;.unErnp INTEGER NOT NULL,
Nombre
Sueldo
Cil·dad
AS UNION OF
CHAR(30),
FLOAT,
CHAR(lO) I
Alfa.Ernpleados(NurnErnp, Nombre, Salario, Ciudad),
Beta.Personal(NurnErnp, Nombre, Sueldo,Plaza)
Al ejecutar esta instrucción. el manejador de bases de datos debe verificar que cada uno de
los fragmentos exista. que tenga cláusula de fragmentación y que su definición sea
compatible con la de la tabla global (es decir. que tenga el mismo número de columnas que
la tabla global y que el tipo de dato de cada columna del fragmento coincida con el tipo de
dato de la colur.1na correspondiente de la tabla global). Si se satisfacen estas condiciones. el
manejador debe grabar la definición de la tabla global en el diccionario de datos. pero no
debe crearla físicamente.
6.3 MECANISMOS PARA LECTURA Y ESCRITURA EN FRAGMENTOS
REPLICADOS
Al carecer tanto de LDD como de transparencia en fragmentación el problema de lectura y
escritura en los distintos fragmentos recae en las aplicaciones Sybase. Es importante
considerar los dif1=rentes mecanismos que se pueden implementar para realizar estas. funciones
en fragmentos replicados. ya que cuando una copia se modifica. es necesario difundir la
modificación a las otras coplas. Esta difusión sincrónica es necesaria cuando. en forma
simultánea. se pueden estar dirigiendo consultas y/o modificaciones a las diferentes copias de
datos. Abásolo. Blanco y Mendieta [Abásolo. Blanco. Mendieta 1994) presentan los siguientes
esquemas de replicación:
6.3.l Copias Sincrónicas: se lee una copia, se actualizan todas.
Se actualizan todas las copias en la misma transacción. o ninguna. Requiere de validación en
dos etapas (ver punto 5.3. l J. En lectura se puede utilizar cualquier copia. En caso de fallas. si
al menos una copia sobrevive, se tiene la última versión del dato. En este caso se tiene gran
disponibilidad para lectura. pero disminuye la disponibilidad para escritura. ya que si una
copia no esta disponible. ya no se puede realizar la modificación.
105
6.3.2 Copias Sincrónicas: lectura y actualización basadas en quórum.
Se propone para tres copias. A cada una de las copias se le asocia un número de versión. En
consulta. se leen dos copias. se compara su número de versión. y se devuelve la que lo tenga
mayor. En actualización . se modifican sólo dos copias. con validación en dos etapas.
incrementando su número de versión. Una copia siempre estará desactualizada. Este
esquema disminuye la disponibilidad en escritura en comparación con 6.3. 1 y aumenta la
disponibilidad de lectura.
6.3.3 Copia!. Sincrónicas: actualización de una o todas las copias,
dependiendo del tipo y monto de la operación.
Este esquema se puede utilizar con datos numéricos que no pueden caer por debajo de un
valor mínimo. y que solo se actualizan con operaciones de suma y resta. Se basa en la
conmutatividad de dichas operaciones. Trabaja con dos copias. Ciertas operaciones se
pueden aplicar sobre una sola de ellas registrándose además en una bitácora local. Otras .
operaciones requieren sincronización. A intervalos regulares (por ej. cada hora). se hace
sincronización general. Las sincronizaciones requieren validación en dos etapas. Para cada
copia se tiene. además de su valor local actual (VLA). el valor que tenía la última vez que se
sincronizó (VUS). un valor por debajo del cual el dato lógico no puede descender (VL). y un
porcentaje local (PL). que toma valores entre O y l. La suma de los porcentajes de las dos
copias debe sumar 1. Las operaciones de adición se hacen sobre una sola copia. y se
registran en la bitácora. Las sustracciones, si la condición ( ( (O<PL < 1) and (VLA - valor a sustraer
J >= (VUS + VL) • ( 1 - PL) or (PL = 1 and (VLA - valor a sustraer) >= VL) or (PL=O and (VLA - valor a
sustraer) >= VUS)) se cumple. se tratan igual que las adiciones. En caso contrario. requieren
sincronización. 1.1 sincronizar. a cada copia se le aplican las operaciones que aparecen en la
bitácora de la otra. Si la sincronización fue iniciada por una operación de la sincronización.
igual que en el esquema 6. 1.1. En caso de destrucción de una copia. es posible que la otra no
esté actualizada. y haya que replicarle manualmente las modificaciones hechas a la copia
destruida después de la última sincronización. Las lecturas no necesariamente dan la versión
más actualizada del dato. a menos que para ello se force una sincronización. Dependiendo
del tipo y monto de las operaciones. algunas o muchas de éstas pueden hacerse sin aumentar
la disponibilidad.
106
6.3.4. Copias Asincrónicas: primaria actualizable, secundarias de lectura;
datos no voluminosos.
En este esquema de replicación se tiene una copia primaria sobre la cual se realizan las
modificaciones. y varias copias secundari~s que sólo se consultan. La difusión de
modificaciones se hace en diferido. No requiere validación en dos etapas. Las lecturas. si se
hacen a copias secundarias. pueden obtener una versión desactualizada. Este esquema
aumenta la localidad y la disponibilidad de las lecturas. Al mantener múltiples copias.
disminuye la probabilidad de pérdida por destrucción.
6.3.5 Copias Asincrónicas: todas actualizables.
En este esquema todas las copias pueden ser leídas o modificadas. Los cambios se difunden.
si es posible. inmediatamente. por un mecanismo de "store and forward". que no requiere
validación en dos etapas. Pueden presentarse conflictos de actualización. que deben ser
resueltos.
6.3.6 Copias Asincrónicas: primarias actualizables, secundarias de lectura;
datos voluminosos.
Este esquema se propone para datos voluminosos tales como firmas. fotos. videos. etc. Se
tienen una o dos copias primarias actualizables. De haber dos. su actualización será
asincrónica. como en 6.3.5. Cada copia tiene un número de versión. Cuando un sitio requiere
el dato. buscará una copia local del mismo. Si no la encuentra. leerá una de las primarias. y
creará una copia local no actualizable (caché). En accesos posteriores. al buscar una copia
local y encontrar un caché. verificará la versiÓh con una copia primaria. Si las versiones no
coinciden. leerá nuevamente la copia primaria y reemplazará el caché local. En cada sitio.
periódicamente. se eliminarán los cachés menos recientemente utilizados. Con este esquema
se busca disminuir el tráfico de datos voluminosos a través de la red de comunicaciones,
replicando únicamente en los sitios donde el dato es utilizado.
6.4 CONCLUSIONES
Existen tres niveles de transparencia que puede proveer un SMBDD:
a) Transparencia de fragmentación. El desarrollador escribe sus aplicaciones de la misma
forma en que las oscribiría si trabajara en un sistema centralizado.
b) Transparencia de localización. Es necesario agregar a las aplicaciones el nombre de los
fragmentos que deben ser utilizados.
107
c) Transparencia de mapeo local. La aplicación debe indicar el nombre de los fragmentos y
el nodo en que éstos se encuentran.
Si se trabaja con rransparencia de mapeo local o de localización únicamente. las
aplicaciones deberán ser modificadas cada vez que los fragmentos sean cambiados de
nodo. Para evitar este problema se debe lograr que el SMBDD brinde transparencia de
fragmentación.
Para el desarrollador. la fragmentación y localización deben ser transparentes. Sin embargo.
el administrador del sistema requiere de instrucciones especificas que le permitan realizar la
fragmentación y ,a localización de los fragmentos. según el diseño especifico del sistema. El
punto 6.2 muestra algunas sugerencias que debe considerar el LDO.
Al trabajar con fragmentos replicados se facilita la lectura. al poder seleccionar de entre
varios nodos. el más apropiado. Sin embargo, es necesario considerar que para la escritura es
necesario actualizar cada una de las replicas. Los puntos 6.3. 1 a 6.3.5 proponen diferentes
mecanismos para realizar las actualizaciones.
108
Tomando como referencia los capítulos anteriores. se realizó el diseño de la arquitectura que
puede presentar un Sistema Manejador de Bases de Datos Distribuidas Homogéneas. Esta
arquitectura se muestra como prototipo para futuras investigaciones que utilicen las
herramientas que ofrece Sybase con los productos de SQL Server. Open Server y Open Client.
También es posible la implementación de algunos módulos en forma aislada para el desarrollo
de sistemas diferentes al sistema global que se presenta.
7.1 DISEÑO DEL SISTEMA
La figura 7.1 mue~tra la arquitectura del sistema propuesto.
I Open Server + Open Client
¡cliente . ._____ ~ ----... MONITOR GLOBAL ~l'--------1
!Cliente 1 '4 • DE ..... __ _, TRANSACCIONES Catálogo ~ Global
j....--Clien----..te j \ ...._____..,,
Open Clienl SOL Server
Sistema de Base de Datos
Local
Fig. 7.1 Componerites del Sistema
Sistema de Base de Datos
Local
Sistema de Base de Datos
Local SQL Server
Como se puede observar, se propone el uso de las bibliotecas de Open Client para cada uno
de los clientes que requieran de la base de datos distribuida. El Monitor Global de
Transacciones es un proceso que debe ser capaz de recibir instrucciones de los clientes y
realizar peticiones a los Servidores. por lo que se propone Open Server para recibir las
instrucciones y Open Client para contactar Servidores SQL de Sybase o de algún otro
proveedor. Las bl.lses de datos locales trabajan de la misma forma que trabaja un Servidor
SQL centralizado.
109
7.1.1 Instrucciones a Procesar
Se sugiere que el sistema pueda recibir cualquier sentencia SQL y una ampliación al lenguaje
de definición de datos. considerando la transparencia de fragmentción tratada en el
capítulo anteri0t·. el empleo de fragmentación en las instrucciones de definición de datos y la
necesidad de actualizar las réplicas que existen en el sistema. Para mostrar la forma en que
debe funcionar el sistema. se implementaron las siguientes instrucciones en el prototipo que
propone este do::umento:
INSTRUCCIÓN:
SINTAXIS:
CREATE
CREATE TABLE nombre_tab/a
(campo tipo_campo .
....... )
FRAGMENTED nombre_fragmento AT nodo WHERE condición
Lo instrucción se implementó poro poder crear fragmentación horizontal. Los tipos que se
pueden utilizar sen CHAR n. donde n es el número de caracteres máximo poro el campo; e
INT. que corresponde o los enteros en Sybase. Al utilizar la instrucción se deben definir los
fragmentos y el nodo en el que residirá cado fragmento. Esta instrucción provee de lo
posibilidad de d1,;plicar fragmentos al repetir el nombre_fragmento en diferentes nodos con la
misma condición.
INSTRUCCIÓN:
SINTAXIS:
DEL ET E
DELETE
FROM nombre_tab/a
WHERE campo= valor
El prototipo maneja todas los instrucciones con condiciones simples. por ser su objetivo mostrar
los mecanismos c;ue se involucran en cada una de las instrucciones, dependiendo del tipo de
condición. Uno condición simple es la que involucra sólo un campo y un valor. pudiendo
estar involucrado. o no. el campo al que hace referencia el predicado de fragmentación.
INSTRUCCIÓN: DROP
SINTAXIS: DROP TABLE nombre_tabla
110
Drop Y create fL•eron diseñadas para dar mantenimiento a la estructura de la base de datos.
y para mostrar la importancia que tiene el manejo del catálogo global en la coordinación del
sistema.
INSTRUCCIÓN:
SINTAXIS:
INSERT
INSERT INTO nombre_tabla
VALUES(campo == valor . ... )
La instrucción insert puede involucrar tantos campos como existan en la tabla y realiza
copias sincrónicos en todos los fragmentos, utilizando el protocolo de compromiso a dos fases,
según lo indicad:, en 6.3.1.
INSTRUCCIÓN:
SINTAXIS:
SELECT
SELECT nombre_tab/a.campo, nombre_toblo.compo ...
FROM nombre_tab/o,nombre_tabla
WHERE nombre_tob/o.compo == valor
Tanto select como update utilizan la lectura selectiva de fragmentos en base al costo de
acceso a las tablas. Los mecanismos se describen más adelante.
INSTRUCCIÓN:
SINTAXIS:
UPDATE
UPDATE nombre_tab/a
SET campo== valor
WHERE campo = valor
Las instrucciones insert, delete, update y select fueron implementadas para mostrar los
mecanismos que se deben desarrollar para el mantenimiento a los datos y las consultas. La
sintaxis. a pesar de ser sencilla, permite observar los mecanismos con que pueden ser
implementadas ir strucciones SQL más robustas.
111
7.1.2 Catálo~o de Datos
Para implementar el catálogo global se sugiere el modelo que presenta A. Bobok[Bobak, 1993]
que se presenta en la figura 7.2. Como se puede observar el catálogo está dividido en dos
esquemas:
1. Esquema Global
2. Esquema de Fragmentos
El esquema global contiene la definición de las relaciones globales usadas para crear la vista
global de los usuarios y se compone de la siguiente manera:
Tabla: VISTAS_G•OBALES
NVISTA Nombre de vista externa del usuario
SQLG_SELECT Sentencia SQL empleada para construir la vista
ESQUEMA GLOBAL
ESQUEMA DE FRAGMENTOS
VISTAS_ GLOBALES
! NVIST A ! SQLG_SELECT !
TABLAS_ GLOBALES
I NTABLA! NODO I TIPO I COLUMNAS_GLOBALES
INCOLUMNA I NT ABLA I TIPO I LON
TABLAS FRAGMENTADAS
I SITEI N~ABLA I NOMFRAGI NRENGLON
COLUMNAS FRAGMENTADAS
I NOMCOL ,~OMFRAª TIPO, LON
Fig. 7.2 Catálogc Global de la Base de Datos
Tabla: TABLAS_GLOBALES
NTABLA Nombre de la relación Global
NODO
TIPO
Nombre del nodo donde la tabla está distribuida
Tipo: vista o tabla.
112
Si la tabla está distribuida en múltiples nodos. se creará un registro por cada nodo en donde se
encuentre un fragmento de la tabla. Este mecanismo debe ser considerado en las
instrucciones del LDD para actualizar el catálogo global cada vez que se realice uno
modificación.
Tabla: COLUMNAS_GLOBALES
NCOLUMNA: NC'mbre de lo columna
NTABLA:
TIPO:
LON:
Tablo o la que pertenece la columna
Tipo de datos que contiene la columna
Longitud en bytes de lo columna
El esquema de fragmentos. por su parte. contiene información que utilizarán las consultas para
lo localización de los fragmentos. Las dos tablas que contiene este esquema son:
Tabla: Tablas_fragmentadas
NODO Nombre del nodo que contiene la tabla fragmentada
NTABLA Nombre de la tablo de la cual se derivo el fragmento
NOMFRAG No"Tlbre de este fragmento de tablo
NRENGLON Número de renglones contenidos en lo tabla fragmentada. Este dato se emplea
para optimar las consultas distribuidos.
Tabla: Columnas_rragmentadas
Nombre de la columna NOMCOL
NOMFRAG
TIPO
Nombre del fragmento de tabla al que pertenece lo columna
Tipo de dato de la columna
LON Lor.gitud de lo columna
En la implementación se utilizan las tablas:
TABLAS_GLOBALES COLUMNAS_GLOBALES T ABLAS_FRAGMENT ADAS
NODOS
La tabla de nodos se ha añadido con los campos:
NODO Nombre que se le da al nodo. para obtener independencia del nombre real del
servidor.
SERVIDOR Nombre del servidor SQL de Sybase.
113
Usuario que tiene derechos para establecer una sesión con el servidor.
Password de acceso al servidor según el usuario.
USUARIO
ACCESO
COSTO Grado de dificultad para accesar un nodo. Este campo permite accesar a los
nudos que se encuentren en mejor disposición desde el monitor.
El prototipo utiliza esta estructura para que se puedan obtener datos de diferentes servidores y
de diferentes bases, es decir, mantener independencia del nombre del servidor. Si por algún
motivo no se puede contar con un servidor. se pueden cambiar los datos a otro servidor. sin
modificar las aplicaciones. lo único que se debe hacer es cambiar el nombre del servidor para
el nodo en la tabla de nodos.
Se añadieron tres campos a la tabla T ABLAS_FRAGMENT ADAS para poder establecer los
fragmentos que deben ser leídos para modificaciones o consultas.
7.1.3 Bases de Datos para Implementar Ejemplos
Para implementar algunos ejemplos del modo de trabajo del Monitor Global utilizaremos la
siguiente Base qe Datos.
Esquemas Globales TDA(numtda. nombre. área. numgte) PROV(numprov. nombre. ciudad) ART(numprov.numtda. numparte. cantidad)
Fragmentos:
PRQV ,.= SL ciudad= DF (PROV) PROVa= SL ciudad,, TL (PROV) PROVc= SL ciudad" QR (PROV)
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);
124
} dbexit ();
if(!strcmp(tabla,contabla)) if(!strcmp(columna,concolumna))
return(l); else
return(O);
dbcmd(proceso, 1'1strucclon) Guarda en un una zona de almacenamiento la instrucción que se
quiera ejecutar por la conexión apuntado en la variable proceso. dbfcmd ( l es semejante.
pero permite incluir variables en la instrucción. del mismo modo que trabaja un printf ("
Constante %s %i ".varl.var2).
dbsqlexe(dbproc) Manda la petición de ejecución de lo que se encuentra en la zona de
almacenamiento por la conexión apuntada por dbproc.
El resultado de le. consulta se obtiene con dbresults(proceso) cuyos resultados pueden ser
succEED o FAIL. dbbind () Manda el valor de cada campo seleccionado a una variable del
programa. y cada vez que se ejecuta dbnextrow() cambia su valor por el de la siguiente
tupla.
dbexi t () Cierra todas las conexiones que se encuentren abiertas en el momento.
7.3.4 Modifica<:iones en el LDD
El prototipo manl:3ja las instrucciones CREATE y DROP para definición de datos. Cuando se
genera un create se deben crear las tablas con la estructura que se definió en el punto 7.3.3.
Es preciso que esta transacción se realice en forma atómica. por lo que se implementó el
protocolo de compromiso a dos fases tratado en 5.3. 1 para accesar en forma dinámica varios
nodos. Si la creación se realiza sin problemas. se procede a actualizar el catálogo global con
las funciones:
inserta_tabgls( char *pntabla,char nodo[lO) (10),char tipo[l),int nregs) int inserta colgls(char pncolumna[lOJ [30),char *pntabla,char ptipo[lO] (15),int lon[lO), int nregs) inserta_tabfrag(char pnodos[lOJ [10),char *pntabla,char pnomfrag[lO] [30),char pcampocon[lO] [30],char psimbcon [10) [2),char pvalorcon[lO] [40],int nregs) {
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) [
xact_string[128J; char char servidor[lO] [l0]~{"'',"","","",'1
",''1',''",'
1",''",''''J;
concxion3();
• Con esta rutina se conecta a todos los nodos participantes.
for(i~O; i < tnodo:s; iH) 1 e_ nodo_ uuuac io ( nombr·c, accc:;ú, ri0d, • I i 1, :_~,: r v j,-J, ,r I i 1 ) ;
dbproc mul[i] = dbopen (login, servidor(i)); if (dbproc mul[i] == NULL) 1
printf (~\nProblemas en la concxion con el nodo %s \n",nodo(i] ); return (0);
• El protocolo r~quiere que se prepare el nodo coordinador (el monitor global)
commid = start_xacl(dbproc, "demo", "Lesl", 2);
/* Dar nombrea a la trsnsaccion*/ build __ xact_ string ("test", /\LUMNOS, comm ld, ;,.a,·! ,;l ,·inq);
• Inicio de la Transacción
sprint f ( cmdbu f, "ElE:GIN TRJ\NS/V:T ION
%s",xacl sl.rirvJ); tor ( i~O; i < Lnodo,;; i 1 1) (
spr intf ( cmdbuf, comandos [ i J J; dbcmd(dbproc mulfl), cmdbuf); ret server =-dbsqle,rnc (dbproc mu] ( i J ) ; if (ret_server == FAIL) -
• Preparar
•·L-ir1I f("\nl-;L-L'"'l p.,1;1 .iniciar l.L~111:.:,11.·,_·i, __ ,11. ::3r.'td .11 .. _.1.Ladd\11 11 );
alJ·~·1l.:1L (dbf-•ti.:.i'-· ___ rnul, db(i[oc, comniid, Lr1r.Jd• i:;);
relurr, ( ü);
sprintf(cmdb,1f, "PREPARE 'l'RANSACTION"); prir11 r ( 11 \11 Er1 . ..-·1r: cr1 1., preparacion del ;'p,--:. Se ab(lrtar;.1\n");
for (i=O; i< tnodos; i++) 1 dbcmd(dbproc mul[i], cmdbuf); ret server =-dbsqlexec(dbproc m11l[i) ); if (ret_server == E'AIL) 1 -
• Acordar
abortar(dbproc_mul, dbproc, commid, tnc,dos);
ret11rn(O);
126
/*Acordarla transaccion */ if (commit xact (dbproc, commid) =~ FAJ L) ( /* Al fallar el acuerdo en el agente coo1di1Hdor se al,,,rta. •¡
printf( "\nTransaccion abortada en -- commil xact fnllcd\n"); abortar(dbp!'oc mul, dbproc, commld,tnodc,:::;); · return(O); -
sprintf ( cmdbuf, "COMMIT TRNlSACTION");
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
la siguiente:
localiza nodofrag(char *ptabla,char pnodos[lO] [10],char pfragrnentos[lO] (30], char pcampo[lO] [30], char psimbolo[10][2]. char pvalor[lOJ [40].char ptipo[10][15],int *can_reg){
dbcrnd(dbproc,"select a.nodo,nornfrag,carnpocon,simbcon,valorcon,tipo "); dbcmd(dbproc,"from tablas_fragrnentadas a,colurnnas_globales b, nodos e");
127
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.
prepara insert( regen,val_ins,tipo,frags,nodo,carnpos,valor,sirnbolos,rnodo,rfrag,regsal)
if ( ! strcmp (sirnbolos [i), "<")) { if(!strcrnp(tipo,"CHAR")) {
strcat(ctrnp,"'"); strcat(ctrnp,valor[i]); strcat(ctrnp,"'"); if (st::crnp(val ins,ctmp) < O)(
strcpy(rnodo[contador) ,nodo[i)); strcpy(rfrag[contador],frags[i)); contartor++;
.strcpy(c::trnp, "");
el.se( if (atoi(val ins) < atoi(valor[i])) {
strcpy(rnodo[contador),nodo[i) ); strcpy(rfrag[contador],frags[i)); contador++;
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:
INSERT INTO TDA VALUES(NUMTDA = 'l',AREA = 'TEPEYAC',AREA = 'NORTE', CANTIDAD
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.
[Coulouris 1994]Coulouris. Dellimore & Kindberg. "Distributed Systems: Coneepts and Desing". Addison Wesley. 2nd. Edition (1994).
[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).
135
[Ózsu. Valduriez 1991) Ózsu M.T.: Valduriez.P. "Principies of Distributed Database Systems". Prentice-Hall (1991 J
[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.
[Sánchez. 1995). "Sistemas Distribuidos". ITESM-CEM 1995.
(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
/j ((' _: ) '/ - I ~-· )
137