View
104
Download
6
Category
Preview:
Citation preview
Bases de Datos Distribuidas
Introducción
A lo largo de los años la información se ha convertido en una herramienta
indispensable en la toma de decisiones, y el hecho de almacenar y administrar
esta información a tomado mayor importancia día con día.
En los años 70's, cuando las computadoras comenzaron a ser usadas no solo
para realizar cálculos, sino también para almacenar información, nació una nueva
área dentro de la informática, el diseño e implementación de sistemas de bases de
datos.
Estas bases de datos en sus inicios funcionaban en una sola
computadora, donde se realizaban todos los procesos de almacenamiento,
consulta y actualización de la información. Con el surgimiento de las redes de
área local el procesamiento de la información fue más fácil y rápido, aun cuando
se tenia un nuevo problema, cada vez era mayor el volumen de la información que
se tenia que almacenar en el único servidor central.
Con el crecimiento económico mundial, aparecieron las grandes empresas
transnacionales, con plantas y oficinas en diferentes ciudades y países, por tanto,
con diferentes redes de área local en cada una de las áreas geográficas de la
empresa. Es así como aparece un nuevo concepto en el área de las bases de
datos, las bases de datos distribuidas.
Las bases de datos distribuidas surgen a partir de la necesidad de poder
almacenar y administrar información en cada área geográfica, tener una red de
computo en cada una de ellas, y poder compartir dicha información de manera
transparente a todos y cada uno de los usuarios de las redes, formando a si una
gigantesca base de datos distribuida.
I
Bases de Datos Distribuidas
Objetivo
Este trabajo es realizado con la intención de proveer al alumno de un
documento de consulta basado en el plan de estudio de la materia, lo que
permitirá un fácil acceso a la información requerida de una manera rápida y
concisa, logrando así una fácil comprensión de los temas tratados en clase. Esto
sin intentar sustituir a los libros existentes de bases de datos centralizadas y bases
de datos distribuidas.
II
Bases de Datos Distribuidas
Bases de datos distribuidas
Contenido
Capitulo 1 Fundamentos de las bases de datos distribuidas1.1 Diferencias entre las bases de datos distribuidas y las bases de datos
centralizadas ....................................................................... .............1
1.2 Ventajas de las bases de datos distribuidas contra las bases dedatos centralizadas................................................................. .............4
1.3 Los doce objetivos de una base de datos distribuidas...........................6
1.4 Arquitectura cliente/servidor.................................................................111.4.1 Paradigma cliente/servidor.................................................................111.4.2 Procesamiento cliente/servidor...........................................................111.4.3 Ventajas de la arquitectura cliente/servidor........................................111.4.4 Desventajas de la arquitectura cliente/servidor..................................121.4.5 Características del cliente...................................................................121.4.6 Funciones del cliente..........................................................................131.4.7 Interfaz grafica de usuario estándar....................................................131.4.8 Características de[ servido.........................r.......................................141.4.9 Funciones del servidor........................................................................151.4.10 El sistema X Windows.......................................................................18
1.5 Problemas de los sistemas distribuidos.................................................19
1.6 Soporte para bases de datos distribuidas..............................................23
1.7 Resumen del capitulo.............................................................................24
1.8 Preguntas de repaso..............................................................................31
Bibliografía...................................................................................................32
Capitulo II Bases de datos en múltiples servidores2.1 Consideraciones para distribuir bases de datos....................................342.1.1 Objetivo del diseño de los datos distribuidos .....................................35
2.2 Diseño de bases de datos distribuidas ................................................362.2.1 Técnicas de diseño Top-Down y Bottom-Up de bases de datos
distribuidas ................................................................................... 362.2.2 Diseño de los fragmentos de la base de datos...................................372.2.3 Correctez de la fragmentación...........................................................372.2.4 Fragmentación Horizontal...................................................................38
III
Bases de Datos Distribuidas
2.2.5 Fragmentación Horizontal derivada...................................................402.2.6 Fragmentación Vertical......................................................................422.2.7 Fragmentación Mixta.........................................................................462.2.8 Distribución de los fragmentos...........................................................482.2.9 Criterios generales para la distribución de los fragmentos.................
48
2.3 Procesamiento de consultas distribuidas..............................................492.3.1 Árbol de operadores de una consulta................................................492.3.2 Ejemplos de consultas distribuidas....................................................50
2.4. Resumen del capitulo...........................................................................57
2.5. Preguntas de repaso............................................................................60
2.6. Ejercicios..............................................................................................60
Bibliografía..................................................................................................62
Capitulo III Optimización de estrategias de acceso3.1 Importancia de la optimización de consultas........................................63
3.2 Transformaciones equivalentes.........................................................653.2.1 Transformaciones equivalentes por álgebra relacional....................663.2.2 Determinación de subexpresiones comunes...................................68
3.3 Métodos de ejecución de JOIN..........................................................703.3.1 Iteración simple...............................................................................713.3.2 Iteración orientada a bloques..........................................................723.3.3 Merge - Join .................................................................................733.3.4 Uso de índices................................................................................753.3.5 Hash Join .................................................................................763.3.6 Tree - way join................................................................................783.3.7 Estrategias para procesamiento paralelo........................................803.3.8 Join paralelo .................................................................................803.3.9 Pipeline multiway join......................................................................82
3.4. Principios de optímización.................................................................84
3.5. Resumen del capitulo........................................................................88
3.6. Preguntas de repaso.........................................................................93
3.7. Ejercicios............................................................................................94
Bibliografía................................................................................................94
IV
Bases de Datos Distribuidas
CapitulolV Procesamiento de transacciones en bases de datos distribuidas4.1 Control de concurrencia......................................................................954.1.1 Seriabilidad en bases de datos centralizadas..................................95
4.1.2 Seriabilidad en bases de datos distribuidas. ...................................98 4.1.3 Control de concurrencia basado en bloqueos centralizados .........100 4.1.4 Control de concurrencia basado en bloqueos distribuidos ............101 4.1.5 Bloqueo de 2 fases como un método de control de concurrencia...................................................................................104 4.1.6 Etiquetas de tiempo en una base de datos distribuida...................106 4.1.7 Deadloks distribuidos.....................................................................109
4.2 Recuperación....................................................................................1114.2.1 Transacciones...............................................................................1124.2.2 Manejo de mensajes......................................................................1134.2.3 estructura general de los registros de bitácora..............................1144.2.4 Tipos de fallas................................................................................1164.2-5 Fallas de transacción.....................................................................1174.2.6 Bitácora en línea............................................................................1184.2.7 Transacciones grandes..................................................................1184.2.8 Compresión de bitácora.................................................................1194.2.9 Fallas del sistema..........................................................................1204.2.10 Fallas en el medio de almacenamiento.......................................123
4.3 Integridad ..........................................................................................1254.3.1 Reglas de integridad de dominio...................................................1264.3.2 Reglas de integridad de relación...................................................127
4.4 Seguridad. .......................................................................................1314.4.1 Identificación y autentificación.......................................................1334.4.2 Reglas de autorización...................................................................1334.4.3 Encriptación de datos. ..................................................................1344.4.4 Encriptación por sustitución,..........................................................1354.4.5 Encriptación de llave publica.........................................................136
4.5. Resumen del capitulo.......................................................................139
4.6. Preguntas de repaso........................................................................151
4.7. Ejercicios.........................................................................................152
Bibliografía..............................................................................................153
Respuestas a preguntas de repaso y ejercicios.....................................154
V
Bases de Datos Distribuidas VI
Objetivo
El alumno conocerá las características de las bases de datos distribuidas, el
paradigma cliente / servidor, y los aspectos que se deben considerar al diseñar una
base de datos distribuida.
Introducción
En este capítulo se tratan las diferencias entre las bases de datos centralizadas
y distribuidas, las cuales proporcionan ventajas y desventajas que deberán ser
tomadas en cuenta al diseñar bases de datos distribuidas, así mismo, se tratan los
objetivos a cumplir por dichas bases de datos. Se discutirá también, una pequeña
descripción del paradigma cliente / servidor, ya que las bases de datos no
centralizadas hacen un uso extenso de éste.
1.1 Diferencias entre las bases de datos distribuidas y las bases de
datos centralizadas
Las bases de datos distribuidas no son simples implementaciones distribuidas de
bases de datos centralizadas, aun cuando presentan algunas características
semejantes, los sistemas distribuidos no podrían ser diseñados con las técnicas de
diseño de los sistemas centralizados tradicionales. Sin embargo es posible comparar
los sistemas tradicionales de bases de datos con los sistemas de bases de datos
distribuidas en base a dichas características, las cuales son: control centralizado,
independencia de datos, reducción de redundancia, estructuras físicas complejas para
un acceso eficiente y seguridad.
1
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Capítulo I
Fundamentos de las bases de datos distribuidas
Control centralizado
La posibilidad de proveer control centralizado sobre los recursos de información
puede ser considerada como una de las razones más atractivas para introducir bases
de datos; esto es considerado como la evolución de los sistemas de información, en los
cuales cada aplicación tiene sus archivos privados. En las bases de datos distribuidas,
la idea de un control centralizado tiene poco énfasis.
En las bases de datos distribuidas es posible identificar una estructura de control
jerárquico basado en un Administrador global de bases de datos, el cual tiene la
principal responsabilidad de la totalidad de la base de datos, y el Administrador local de
bases de datos, quien tiene la responsabilidad de su respectiva base de datos local.
Esto nos da como resultado una característica llamada Autonomía de sitio. Las bases
de datos distribuidas tienen diferentes grados de autonomía de sitio: desde la más
completa autonomía sin ningún administrador centralizado hasta el más completo
control centralizado.
Independencia de datos.
La independencia de datos quiere decir, que la organización actual de los datos es
transparente a las aplicaciones. Los programas son escritos teniendo una vista
conceptual de los datos, llamada esquema conceptual. La ventaja principal de la
independencia de datos es que los programas no son afectados por los cambios en la
organización física de los datos.
En las bases de datos, la independencia de los datos es tan importante como en las
bases de datos tradicionales; sin embargo, una nueva característica se agrega a la
definición de la independencia de datos, esta es la transparencia de distribución.
Gracias a la transparencia de distribución es que se pueden escribir programas como
si la base de datos no estuviera distribuida.
La independencia de datos fue introducida en las bases de datos tradicionales por
la arquitectura multinivel que tiene diferentes descripciones de los datos y mapeos
entre ellos. Las definiciones de esquema conceptual, esquema externo y esquema
interno fueron desarrolladas para esta arquitectura. De manera similar, la
transparencia de distribución es obtenida en las bases de datos distribuidas por la
introducción de nuevos niveles y esquemas.
2
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Reducción de la redundancia.
En las bases de datos tradicionales, la redundancia fue reducida en lo posible, por
dos razones: primera, la inconsistencia entre varias copias de los datos es evitada
automáticamente teniendo solo una copia de los datos; la segunda razón, la
recuperación de espacio de almacenamiento al eliminar la redundancia. La
redundancia se reduce compartiendo los datos, permitiendo que varias aplicaciones
accesen los mismos archivos.
En las bases de datos distribuidas, se tienen varias razones para considerar la
redundancia de los datos como una característica necesaria: primero, las aplicaciones
pueden verse favorecidas si los datos son replicados en todos los sitios donde la
aplicación las necesita, y segundo, la razón de disponibilidad del sistema puede
incrementarse por este medio, debido a que si el sitio en el que se encuentran los
datos fallara, la ejecución de la aplicación no se detiene porque existe una copia en
algún otro sitio.
Estructuras complejas y acceso eficiente,
Las estructuras de acceso complejas, como índices secundarios y enlaces entre
archivos, son aspectos comunes de las bases de datos tradicionales. El soporte para
estas estructuras es una de las partes más importantes del DBMS (Database Manager
System, Sistema manejador de base de datos). El objetivo de estas estructuras es el
de obtener un acceso eficiente a los datos.
Escribir un acceso distribuido es muy parecido al hacerlo en un sistema
centralizado, en el sentido de que el programador especifica de qué modo será
accesada la base de datos. De cualquier forma, el proceso es local a cada uno de los
sitios donde se encuentran los grupos de datos.
Es conveniente tomar en cuenta dos cuestiones muy importantes en el momento de
accesar una base de datos distribuida, la optimización local y la optimización global de
los accesos. La optimización global consiste en determinar qué datos serán accesados
en qué sitios y qué archivos de datos serán transmitidos entre sitios. La optimización
local consiste en decidir como llevar acabo el acceso a la base de datos local en cada
sitio.
3
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Seguridad.
En las bases de datos tradicionales, el administrador de la base de datos, tiene el
control centralizado, puede asegurarse que únicamente se tenga el acceso a los datos
autorizados.
En las bases de datos distribuidas, el administrador local enfrenta el mismo
problema que el administrador de bases de datos tradicionales. Sin embargo, vale la
pena mencionar dos aspectos peculiares de las bases de datos distribuidas: en una
base de datos distribuida con un alto nivel de autonomía, los dueños de los datos
locales pueden proteger de diferentes maneras su información, esto dependiendo del
DBMS local; y segundo, los problemas de seguridad son intrínsecos en los sistemas de
bases de datos en general, esto debido a que las comunicaciones en las redes es su
punto débil con respecto a la protección.
1.2 Ventajas de las bases de datos distribuidas sobre las bases de
datos centralizadas
Razones organizacionales
La mayor parte de las organizaciones están descentralizadas, y las bases de datos
distribuidas se acercan más a las necesidades de la estructura de la organización
distribuida.
Interconexión de las bases de datos existentes.
Las bases de datos distribuidas son la solución natural cuando se tienen varias
bases de datos existentes en la organización. En este caso, las bases de datos
distribuidas son creadas utilizando una estrategia de diseño tipo bottom-up a partir de
las bases de datos locales existentes. Este proceso requiere cierto grado de
reestructuración local; de cualquier forma, el esfuerzo requerido para esto es mucho
menor que el necesario para la creación de una base de datos local completamente
nueva.
4
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Desarrollo incremental.
Si una organización agrega una nueva unidad, relativamente autónoma, entonces
las bases de datos distribuidas soportarían este crecimiento con el menor grado de
impacto a las unidades ya existentes. En un sistema centralizado cualquier cambio en
las dimensiones del sistema tendría un impacto mayor, no solo en las nuevas
aplicaciones, sino también en las ya existentes.
Reducción en la sobrecarga de la comunicación.
En una base de datos distribuida geográficamente, el factor que las aplicaciones
locales verían claramente reducido es la sobrecarga de las comunicaciones, en
relación con bases de datos centralizadas. Por eso, en el máximo de que las
aplicaciones sean locales es uno de los objetivos primarios en el diseño de las bases
de datos distribuidas.
Consideraciones en el desempeño.
La existencia de varios procesadores autónomos dan como resultado un incremento
en el desempeño por medio de un alto grado de paralelismo. Esta consideración
puede ser aplicada a un sistema multiprocesador y no únicamente a los sistemas de
bases de datos distribuidas. Las bases de datos distribuidas tienen la ventaja en que
la descomposición de los datos permite maximizar el desempeño de las aplicaciones
locales; de esta forma es minimizada la mutua interferencia entre diferentes
procesadores.
Confiabilidad y disponibilidad.Las bases de datos distribuidas obtienen, por medio de la replica de datos, un alto
grado de confiabilidad y disponibilidad. Sin embargo, el lograr esta meta no es tan fácil, pues requiere del uso de ciertas técnicas, las cuales son difíciles de comprender. La capacidad de procesamiento autónomo en los diferentes sitios no es, por sí misma, garantía de que exista una completa confiabilidad en el sistema, pero esto generaría una fácil degradación del sistema; en otras palabras, las fallas en una base de datos distribuida pueden ser más frecuentes que en las centralizadas, debido al gran número de componentes, pero el efecto de cada falla es considerado por cada aplicación que usa los datos en sitio que falló, y por lo tanto es raro que el sistema en su totalidad falle.
5
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
1.3 Los doce objetivos de una base de datos distribuidas.
La siguiente expresión se podría considerar como el principio fundamental de los
sistemas distribuidos en general, y por tanto es aplicable a las bases de datos
distribuidas:
Desde el punto de vista del usuario, un sistema
distribuido deberá ser idéntico a un sistema no
distribuido.
Esto quiere decir que, los usuarios de un sistema distribuido deberán comportarse
exactamente como si el sistema no estuviera distribuido.
Al principio fundamental antes mencionado se le conoce como el "objetivo o regla
cero" de los sistemas distribuidos. Existen doce reglas u objetivos más, las cuales
norman la existencia de un sistema distribuido y en este caso, de una base de datos
distribuida. Dichos sistemas deberán apegarse a ellas, en la medida, en que el diseño
y la tecnología lo permitan, tales reglas son:
Autonomía local.
Los sitios de un sistema distribuido deberán ser autónomos. La autonomía local
significa que todas las operaciones en un sitio se controlan en ese sitio; ningún sitio
deberá depender de algún otro sitio para su buen funcionamiento. La autonomía local
implica también un propietario y una administración local de los datos, con
responsabilidad local: todos los datos pertenecen a una base de datos local, aunque -
sean accesibles para algún sitio remoto. Por tanto, la seguridad, integridad y
representación en almacenamiento de los datos locales permanecen bajo el control del
sitio local.
6
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
No dependencia de un sitio central.
La autonomía local implica que todos los sitios deben tratarse igual; no debe haber
dependencia de un sitio central maestro para obtener un servicio central. La no
dependencia de un sitio central es deseable por sí misma, aún si no se logra la
autonomía local completa.
La dependencia de un sitio central seria indeseable al menos por dos razones:
primero, el sitio central podría ser un cuello de botella; en segundo lugar, el sistema
sería vulnerable; si el sitio central sufriera un desperfecto, todo el sistema dejaría de
funcionar.
Operación continua.
En un sistema distribuido como en uno no distribuido, lo ideal seria que nunca
hubiera la necesidad de apagar el sistema a propósito. Es decir, el sistema nunca
deberá necesitar apagarse para que se pueda realizar alguna función, como actualizar
el DBMS de un sitio existente o añadir un nuevo sitio.
Dependencia (o Transparencia) con respecto a la localización.
La idea básica de la independencia con respecto a la localización es simple; no
debe ser necesario que los usuarios sepan donde están almacenados físicamente los
datos, sino que más bien deben comportarse (al menos desde el punto de vista lógico)
como si todos los datos estuvieran almacenados en su propio sitio local. La
independencia con respecto a la localización hace posible la migración de datos de un
sitio a otro sin anular la validez de ningún programa o actividad. Esta posibilidad de
migración es deseable porque permite modificar la distribución de los datos dentro de
la red en respuesta a cambios en las necesidades del desempeño.
Independencia con respecto a la fragmentación.
Un sistema maneja fragmentación de los datos si es posible dividir una relación en
partes o fragmentos para propósitos de almacenamiento físico. La fragmentación es
deseable por razones de desempeño: los datos pueden almacenarse en la localidad
donde se utilizan con mayor frecuencia, de manera que la mayor parte de las
operaciones sean locales y se reduzca el tráfico de la red.
Existen en esencia dos clases de fragmentación, horizontal y vertical,
7
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Un fragmento puede ser cualquier subrelación arbitraria que pueda generarse de la
relación original mediante ciertas operaciones.
Un sistema que maneja la fragmentación de los datos deberá ofrecer también una
independencia con respecto a la fragmentación (transparencia de fragmentación); es
decir, las bases de datos distribuidas deberán poder comportarse (desde el punto de
vista lógico) como si los datos no estuvieran fragmentados en realidad.
Independencia de réplica.
Un sistema maneja réplica de datos si una relación dada (o, un fragmento dado de
una relación) se puede representar en el nivel físico mediante varias copias
almacenadas o réplicas, en muchos sitios distintos.
La réplica es deseable al menos por dos razones: primero, puede producir un mejor
desempeño (las aplicaciones pueden operar sobre copias locales en vez de tener que
comunicarse con sitios remotos); En segundo lugar, también puede significar una mejor
disponibilidad. La desventaja principal de las replicas es la actualización, ya que
cuando se actualiza un objeto copiado, deben de ser actualizadas todas las replicas de
este objeto: Esto es, el problema de la propagación de actualizaciones.
La réplica, como la fragmentación, debe ser transparente al usuario. En otras
palabras, la base de datos deberá comportarse como si solo existiera una sola copia
de los datos.
Procesamiento distribuido de las consultas.
La optimización es todavía más importante en un sistema distribuido que en uno
centralizado. Lo esencial es que, en una consulta, donde están implicados varios
sitios, habrá muchas maneras de trasladar los datos en la red para satisfacer la
solicitud y es crucial encontrar una estrategia eficiente. Por ejemplo, una solicitud de
unión de una relación Rx almacenada en el sitio X y una relación Ry almacenada en un
sitio Y podría llevarse a cabo trasladando Rx a Y o trasladando Ry a X, o trasladando
las dos a un tercer sitio Z. Así, la importancia crucial de la optimización es obvia, y esto
a su vez puede verse como otra razón más por la cuál los sistemas distribuidos
siempre son relaciónales (pues las solicitudes relaciónales son optimizables).
8
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Manejo distribuido de transacciones.
El manejo de transacciones tiene dos aspectos principales, el control de
recuperación y el control de concurrencia. En un sistema distribuido, una sola
transacción puede implicar la ejecución de código en varios sitios. Por tanto, se dice
que cada transacción está compuesta de varios agentes, donde un agente es el
proceso ejecutado en nombre de una transacción dada en un sitio determinado. Y el
sistema requiere saber cuándo dos agentes son parte de la misma transacción; por
ejemplo, es obvio que no puede permitirse un bloqueo mutuo entre dos agentes que
sean de la misma transacción.
Para asegurar que una transacción dada sea atómica en el ambiente distribuido, el
sistema debe asegurarse de que todos los agentes correspondientes a esa transacción
se comprometan al unísono o retrocedan al unísono, Este efecto puede lograrse
mediante el protocolo de compromiso de dos fases.
En cuanto al control de concurrencia, esta función en un ambiente distribuido está
basada con toda seguridad en el bloqueo, como sucede en los sistemas no distribuidos
(se han estudiado otras estrategias para el control de concurrencia, pero en la práctica,
el bloqueo parece seguir siendo la técnica preferida).
Independencia con respecto al equipo.
Las instalaciones de cómputo en el mundo real por lo regular incluyen varias
máquinas diferentes y existe una verdadera necesidad de poder integrar los datos en
todos esos sistemas y presentar al usuario una sola imagen del sistema.
Independencia con respecto al sistema operativo.
Este objetivo es en parte un corolario del anterior. Resulta obvia la consecuencia no
sólo de poder ejecutar el mismo DBMS en diferentes equipos, sino también de poder
ejecutarlo en diferentes sistemas operativos (aun en diferentes sistemas operativos del
mismo equipo).
Independencia con respecto a la red.
Si el sistema ha de poder manejar múltiples sitios diferentes, con equipo distinto y
diferentes sistemas operativos, resulta obvia la conveniencia de poder manejar también
varias redes de comunicación distinta.
9
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Independencia con respecto al sistema manejador de base de datos (DBMS).
En realidad no se requiere sino que los DBMS en los diferentes sitios manejen
todos la misma interfaz; no necesitan ser por fuerza copias del mismo sistema. Por
ejemplo, si tanto INGRES como ORACLE manejaran únicamente el estándar de SQL
(ambos lo manejan pero cada uno tiene características propias que los hacen
prácticamente incompatibles), podría ser posible lograr una comunicación entre los dos
en el contexto de un sistema distribuido. Dicho de otro modo, el sistema distribuido
podría ser heterogéneo, al menos en cierto grado.
Una vez más, en la realidad las instalaciones de cómputo no solo suelen emplear
máquinas distintas, varios sistemas operativos diferentes, sino también ejecutan
diferentes DBMS; y seria agradable que todos esos DBMS distintos pudieran participar
de alguna manera en un sistema distribuido.
1.4 Arquitectura Cliente/Servidor
1.4.1 Paradigma Cliente/Servidor.
El paradigma que dispone que una aplicación espere pasivamente a que otra inicie
la comunicación permea una parte tan grande del cómputo distribuido que tiene un
nombre: paradigma de interacción cliente/servidor.
1.4.2 Procesamiento Cliente/Servidor.
El modelo de procesamiento cliente/servidor surgió como un concepto de alto nivel
de procesamiento compartido de dispositivos, típico en las redes de área local. En el
procesamiento de dispositivos compartidos en la red de área local (LAN), las
computadoras personales están enlazadas a un sistema de dispositivos que permite a
las computadoras personales (PCs) compartir recursos. En la terminología LAN, tales
dispositivos son llamados servidores (un servidor de archivos y un servidor de
impresión serían un ejemplo). El nombre de servidor es apropiado, puesto que estos
dispositivos compartidos son usados para recibir solicitudes de servicio de las
computadoras personales (PCs).
Al mismo tiempo, el rol de las estaciones de trabajo fue cambiando hasta
convertirse en clientes de los servidores. Esto es, los clientes realizan solicitudes de
servicios a los servidores.
10
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
El modelo de procesamiento cliente/servidor es una extensión natural del
procesamiento de dispositivos compartidos. En este modelo, el procesamiento de
aplicaciones esta dividido entre el cliente y el servidor. El procesamiento es inicializado
y parcialmente controlado por el solicitante del servicio (cliente) pero no es un
funcionamiento maestro-esclavo,
1.4.3 Ventajas de la arquitectura cliente/servidor.
Permite a las corporaciones obtener cada vez mejores tecnologías de computo.
En la actualidad las estaciones de trabajo tienen un rendimiento y una potencia,
la cual solo se obtenía con mainframes, que eran muy costosas.
Permite que el procesamiento de los datos se realice en el lugar en el que se
encuentran. (La arquitectura cliente/servidor es una forma especial de
procesamiento distribuido y cooperativo) Por lo tanto, el tráfico en la red se ve
reducido significativamente, y por consiguiente las necesidades de una red de
banda ancha y el costo se ven reducido.
Facilita el uso de interfaces de usuario gráficas (GUI) disponibles en estaciones
de trabajo. Estas nuevas interfaces pueden ser usadas por una gran variedad
de clientes y cuentan con diferentes técnicas para mostrar la información,
logrando con esto una fácil navegación.
Permite el uso de sistemas abiertos. Esto es, el cliente y el servidor pueden
correr en diferentes plataformas de software y hardware permitiendo a los
usuarios finales decidir libremente que arquitectura utilizar o poder utilizar la ya
existente.
1.4.4 Desventajas de la arquitectura cliente/servidor.
Si una parte significativa de la aplicación lógica es movida al servidor, el
servidor puede convertirse en cuello de botella. Los recursos del servidor
pueden verse disminuidos por el incremento de demanda debido al aumento de
usuarios.
Las aplicaciones distribuidas, especialmente las que son diseñadas para el
proceso cooperativo, son más complicadas que las no distribuidas. Esto es
verdad para las aplicaciones de desarrollo, ambientes run-time y herramientas
usadas para el mantenimiento de este ambiente distribuido.
11
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
1.4.5 Características del cliente
Es un programa de aplicación arbitrario que se vuelve cliente temporalmente
cuando necesita acceso remoto, pero también lleva a cabo otro computo local.
Lo llama directamente el usuario y se ejecuta solo durante la sesión.
Se ejecuta localmente en la computadora personal del usuario.
Inicia el contacto con el servidor.
Puede acceder a varios servicios, según se necesite, pero contacta activamente
con un servidor remoto a la vez.
No necesita hardware poderoso y un sistema operativo complicado.
1.4.6 Funciones del cliente
La Función más importante que desempeña un sistema cliente en un ambiente
cliente/servidor es la presentación y algunas funciones lógicas. El usuario final
interactúa con una aplicación desarrollada para la presentación lógica del sistema.
Las funciones tradicionales de presentación basadas en caracteres, en donde el
procesador desplegaba los caracteres recibidos secuencialmente desde una aplicación
en pantalla con caracteres de tamaño fijo. La continua evolución de las funciones de
presentación ha sido estrechamente ligada con el alto desempeño de las estaciones de
trabajo que ofrecían características gráficas.
Las características gráficas permiten al procesador controlar de manera individual
los píxeles en la pantalla, por tanto, no esta limitado a un tipo de carácter o al número
de columnas de la pantalla. Estas características permiten el desarrollo de interfaces
gráficas de usuario (GUI) capaces de manejar gráficos, imágenes, y audio-video.
1.4.7 Interfaz Gráfica de Usuario estándar
Una interfaz consistente entre el usuario y la aplicación representa un parte
importante en los sistemas abiertos. Las interfaces de presentación entre el usuario y
la aplicación son llamadas interfaces Gráficas de Usuario (GUI), y son diseñadas para
presentar la información a los usuarios de forma gráfica.
Existe una gran variedad de interfaces, pero cada nueva interfaz requiere que los
usuarios y los desarrolladores tengan una nueva capacitación en sus usos, y las
aplicaciones sean modificadas. Una nueva interfaz de usuario requiere que las
aplicaciones sean reescritas para esta nueva plataforma. Las aplicaciones escritas
12
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
para una GUI especifica no son portabas a otro ambiente GUI. Un ejemplo de
interfaces incompatibles es Linux, Windows y Unix.
Aun cuando la industria del hardware y software, aunada a asociaciones de
usuarios prefieren una GUI en particular, Se tiene una GUI estándar, la cual debe de
cumplir los siguientes requisitos:
Portabilidad.- Las aplicaciones deben de ser portabas a través de varias
plataformas de sistema abiertos. Una GUI estándar debe de proporcionar un API
estable en cualquier plataforma, de esta manera permitiría una fácil y rápida manera de
migrar de una plataforma a otra.
Flexibilidad.- Una GUI estándar debe de ser flexible y extensible, permitiendo
ajustarse a nuevos tipos de monitores y a otros dispositivos de entrada salida, que
podrían estar disponibles en un futuro.
Herramientas de desarrollo: Cualquier GUI que sea considerada un estándar debe
proporcionar un conjunto de herramientas para el desarrollo.
Internacionalización: En la actualidad, la internacionalización es otra de la
forma de lograr una portabilidad. Esto incluye otros lenguajes, números, unidades
monetarias, formatos de fecha y hora, y símbolos especiales, así como mensajes
relacionados con la cultura de esos países.
Independencia de plataforma: Para ser un verdadero sistema abierto y un estándar,
una GUI deberá ser diseñado para operar independientemente del sistema operativo o
la plataforma de hardware, en el que se esta ejecutando.
1.4.8 Características del servidor
Es un programa privilegiado de propósito especial dedicado a ofrecer un
servicio, pero puede manejar varios clientes remotos a la vez.
Se inicia automáticamente al arranque del sistema y continua ejecutándose en
varias sesiones.
Espera pasivamente el contacto de los clientes remotos.
Acepta el contacto de varios clientes, pero ofrece un solo servicio.
13
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Necesita hardware poderoso y un sistema operativo complejo.
1.4.9 Funciones de los servidores
El mejor ejemplo de servidores especializados con respecto a la funcionalidad y
diseño son los servidores de bases de datos, Básicamente, los servidores de bases de
datos nos permiten un rápido almacenamiento en disco, un significativo poder de
procesamiento, y la capacidad de interactuar con varia aplicaciones (clientes) de
manera simultánea.
Un servidor es un proceso lógico que provee servicios a solicitudes de
procesamiento. En la computación cliente/servidor, un cliente inicia la interacción
cliente/servidor para enviar las solicitudes a los servidores. La función que un servidor
debe llevar a cabo es determinada, en gran parte, por el tipo de solicitud que los
clientes puedan enviar al servidor. Si un servidor es incapaz de llevar a cabo la
solicitud de un cliente, entonces el servidor no puede participar en una interacción
cooperativa cliente/servidor. Idealmente. Un cliente no envía una solicitud que no sea
soportada por un servidor.
En general, sin embargo, una vez que un cliente y un servidor se han
interconectado a través de una red, alguna de las siguientes funciones pueden ser
solicitadas al servidor por el usuario:
Compartir archivos. En un ambiente de grupo de trabajo, los clientes tal vez
necesiten compartir los mismos archivos de datos. Estos archivos se colocan
en procesadores de archivos compartidos (Servidores de archivos) y los
clientes envían a estos sus solicitudes de 110.
Impresión compartida. En un ambiente de grupo de trabajo, una impresora de
alto desempeño puede reemplazar a todas las impresoras individuales de los
clientes. Entonces todos los clientes pueden enviar sus solicitudes de
impresión a los servidores de impresión. Un servidor de impresión mantiene
todos los archivos a ser impresos en una cola, a la cual se envían todos los
archivos de los usuarios, y en su tumo, cada una de ellos serán impresos.
14
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Servicios de comunicación. En un ambiente de grupo de trabajo que se
encuentra conectado a un host remoto, todas las comunicaciones de software y
hardware se concentran en un dispositivo especial conocido como servidor de
comunicaciones, al cual los clientes envían sus solicitudes para ser procesadas.
Servicios de Fax Esto requiere usualmente software y equipo especial,
conocido como servidor de fax. Los clientes envían y reciben documentos de
fax por medio de una apropiada solicitud del servicio al servidor de fax.
Acceso a las bases de datos. En un ambiente cliente/servidor, el
procesamiento esta dividido en el sistema cliente y el sistema servidor, El
servidor puede ejecutar una parte de la lógica de la base de datos. Algo similar
al servidor de archivos, el servidor de bases de datos provee al cliente de los
datos que residen en el servidor por medio de una solicitud, Sin embargo, el
sistema manejador de bases de datos (DBMS), es más sofisticado que los
métodos de acceso básicos. El DBMS de un acceso a los datos por medio de
varios niveles de bloqueo y de integridad de datos. El DBMS elimina la
redundancia permitiendo una transparencia de distribución de datos. Los
clientes requieren acceder ciertos datos (a diferencia de un servidor de archivos
en el cual se tiene acceso al archivo completo), y toda la manipulación
necesaria para dar respuesta a la solicitud se realiza en el servidor de bases de
datos.
Otras funciones solicitadas por los clientes pueden ser de correo electrónico, de
red, manejo de configuración y manejo de recursos, para los cuales se deberá de tener
los servidores apropiados.
Un nodo servidor dentro del modelo cliente/servidor puede ser especializado para
realizar cierta función. De cualquier forma, los servidores deben cumplir con los
siguientes requerimientos generales:
Soporte multiusuario. Aun en un pequeño grupo de trabajo, un servidor debe
de ser capaz de proporcionar servicio a múltiples usuarios concurrentes. Los
15
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
clientes ejecutan múltiples tareas esperando que el servidor sea capaz de
soportar un procesamiento multitarea.
Escalabilidad. Un servidor debe de ser capaz de satisfacer la creciente
demanda de los recursos, así como de las aplicaciones. Escalabilidad no
significa que usuarios deben comprar un sistema de servidor de mayor
capacidad de procesamiento lo cual implicaría un costo extra. Por el contrario,
el sistema debe de satisfacer los requerimientos actuales y, al mismo tiempo,
debe de permitir una fácil expansión.
Desempeño. Un sistema servidor debe proveer niveles de desempeño
satisfactorios necesarios para la empresa y los requerimientos de los usuarios
en un ambiente multiusuario cliente/servidor.
Almacenamiento. Como el número de aplicaciones ejecutándose y de usuarios
aumentan, y los avances de la tecnología de dispositivos de almacenamiento
han hecho que los costos bajen, la demanda de almacenamiento de rápido
acceso se ha convertido en un requisito esencial en un sistema servidor.
Gestión de redes. La comunicación cliente/servidor requiere de una
comunicación de red. Ambos, cliente y servidor deben de contar con
capacidades de red. Sin una red el cliente y el servidor no podrían interactuar.
Multimedia. Las nuevas aplicaciones y las nuevas tecnologías cuentan con
capacidades multimedia, es necesario dar soporte al almacenamiento y
reproducción de imagen, vídeo y sonido.
1.4.1 0 El sistema X Window
El sistema X Window permite un manejo transparente de la interfaz gráfica en
estaciones de trabajo. Conocido también como X, fue desarrollado conjuntamente por
el Instituto Tecnológico de Massachussets, IBM, y DEC en un proyecto conocido como
Athena. La arquitectura X está basada en el modelo cliente/servidor. X proporciona:
16
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Un Protocolo de comunicación transparente entre una aplicación y su
presentación lógica, la cual puede residir en una estación de trabajo
remota.
Alto desempeño en la independencia de dispositivos gráficos.
En la tecnología cliente/servidor, el nodo que despliega y recibe información, e
interactúa con el usuario, es el nodo cliente.
Los X clients contienen la aplicación lógica funcional escrita por el desarrollador,
aunque esta residiría en un sistema “servidor” en la red cliente/servidor. El X Client es
enlazado con las librerías X Window y las librerías de las herramientas basadas en X
usadas para crear una aplicación. Aun cuando la designación de X Client y X Server
pueden parecer contradictorias a la definición de cliente y servidor del modelo
cliente/servidor. De hecho:
En el sistema X Window, el X cliente inicia la interacción con su servidor, el X
Server.
El X Client solicita un X Server para las funciones de despliegue en pantalla.
Un X Server puede dar servicio a múltiples X clients.
X Client y X Server pueden estar en la misma máquina.
1.5 Problemas de los sistemas distribuidos
El mayor problema en las redes de área amplia es que son lentas. Por ejemplo
algunas redes tienen una velocidad de transferencia de 1250 bytes por segundo,
mientras que un disco duro representativo tiene un factor de transferencia de al
rededor de 1 a 2 millones de bytes por segundo. Por lo tanto, un objetivo principal de
los sistemas distribuidos es reducir el número y volumen de los mensajes. Este
objetivo a su vez da pie a problemas en varias áreas secundarias, entre ellas las
siguientes:
Procesamiento de consultas.
El objetivo de reducir al mínimo el tráfico en la red implica que el proceso mismo
de optimización de consultas debe ser distribuido, además del proceso de ejecución de
17
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
las consultas. En otras palabras, un proceso representativo consistirá en un paso de
optimización global, seguido de pasos de optimización local en cada uno de los sitios.
Por ejemplo se requiere una consulta C en el sitio X, y que C implica una reunión de
una relación Ry de cien tuplas en el sitio Y con una relación Rz de un millón de tuplas
en el sitio Z. El optimizador ubicado en el sitio X escogerá la estrategia global para
ejecutar C; y resulta evidente la importancia de que decida trasladar Ry a Z y no Rz a Y
(y ciertamente no Ry y Rz a X). Después, una vez que haya decidido trasladar Ry a Z,
el optimizador local en Z será el que decida cuál debe ser la estrategia para realizar la
unión en este sitio.
Administración del catálogo.
En un sistema distribuido, el catálogo del sistema incluirá no solo la información
usual acerca de las relaciones, índices, usuarios, etcétera; sino también toda la
información de control necesaria para que el sistema pueda ofrecer la independencia
deseada con respecto a la localización, la fragmentación y la réplica. Existen varias
técnicas para el almacenamiento de los catálogos:
1. Centralizado: El catálogo total se almacena una sola vez, en un sitio central.
2. Replicas completas: El catálogo total se almacena por completo en todos los
sitios.
3. Dividido: Cada sitio mantiene su propio catálogo para los objetos almacenados
en ese sitio. El catálogo total es la unión de todos los catálogos locales no
traslapados.
4. Combinación de 1 y 3: Cada sitio mantiene su propio catálogo local, como en el
punto 3; además, un sitio central único mantiene una copia unificada de todos los
catálogos locales, como en el punto 1.
Todos estos enfoques tienen algún problema. Es obvio que el enfoque 1 viola el
objetivo de "no depender de un sitio central": el enfoque 2 adolece de una grave falta
de autonomía, pues toda actualización del catalogo deberá de ser propagada a cada
uno de los sitios. El enfoque 3 hace muy costosas todas las operaciones no locales
(no encontrar un objeto remoto requerirá obtener acceso a la mitad de los sitios en
promedio). El enfoque 4 es más eficiente que el 3 (encontrar un objeto remoto requiere
sólo el acceso a su catálogo remoto), pero viola una vez más el objetivo de "no
18
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
dependerá de un sitio central". Por lo tanto, los sistemas en la practica casi nunca
usan ninguno de estos cuatro enfoques.
Propagación de actualizaciones.
El problema básico con la réplica de datos, como se señaló es la necesidad de
propagar cualquier modificación de un objeto lógico dado a todas las copias
almacenadas de ese objeto, Un problema que surge es algún sitio donde se mantiene
una copia del objeto podría no estar disponible en el momento de la actualización. Así,
la estrategia de propagar las actualizaciones de inmediato a todas las copias podría ser
inaceptable, porque implica que la modificación ( y la transacción) fracasara si
cualquiera de estas copias no esta disponible en el momento.
Un método para manejar este problema es el llamado método de "copia primaria", el
cual funciona de la siguiente manera:
Una de las copias del objeto se designa como copia primaria. Las demás serán
copias secundarias.
Las copias primarias de los diferentes objetos están en sitios diferentes (de
modo que, una vez más, este método es distribuido).
Las operaciones de actualización se consideran completas tan pronto como se
ha modificado la copia primaria. El sitio donde se encuentra esa copia se
encarga entonces de propagar la actualización a las copias secundarias en un
momento posterior.
Este método representa un problema, una violación al objetivo de autonomía local,
porque ahora una transacción podría fallar cuando una copia (primaria) remota de
algún objeto no estuviera disponible, aun cuando se dispusiera de una copia local.
19
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Control de recuperación.
El control de recuperación en los sistemas distribuidos se basa por lo regular en el
protocolo de dos fases. El compromiso de dos fases es obligatorio en cualquier
ambiente en el cual una sola transacción puede interactuar con vados manejadores de
recursos autónomos, pero tiene especial importancia en un sistema distribuido porque
los manejadores de recursos en cuestión (DBMS locales) operan en sitios remotos
distintos y por tanto son muy autónomos.
De acuerdo a lo anterior surgen los siguientes puntos:
1. El objetivo de "no dependencia de un sitio central' dicta que la función de
coordinador no debe asignarse a un sitio especifico de la red, sino que deben
realizaría diferentes sitios para diferentes transacciones. Por lo general se
encarga de ella el sitio en el cual se inicia la transacción en cuestión.
2. El proceso de compromiso en dos fases requiere una comunicación entre el
coordinador y todos los sitios participantes, lo cual implica más mensajes y
mayor costo.
3. El sitio Y actúa como participante en un compromiso de dos fases coordinado
por el sitio X, el sitio Y deberá hacer lo ordenado por el sitio X (compromiso o
retroceso), lo cual implica otra pérdida de autonomía local.
4. En condiciones ideales el proceso de compromiso en dos fases funcionará
aún en caso de presentarse fallas de sitios o de la red en cualquier punto.
Idealmente, el proceso debería ser capaz de soportar cualquier tipo
concebible de falla.
Control de concurrencia.
Como en mayor parte de los sistemas distribuidos el control de concurrencia se
basa en el bloqueo, tal como sucede en casi todos los sistemas no distribuidos. Pero
en un sistema distribuido, las solicitudes de prueba, establecimiento y liberación de
bloqueo se convierten en mensajes (suponiendo que el objeto en cuestión es un sitio
20
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
remoto), y los mensajes implican costos adicionales. Por ejemplo, se considerara una
transacción T que necesita poner al día un objeto del cual existen réplicas en n sitios
remotos. Si cada sitio se encarga de los bloqueos sobre los objetos almacenados en
ese sitio (como sucederá si se cumple la suposición de autonomía local), la puesta en
practica directa requerirá por lo menos de 5 mensajes por cada sitio:
solicitud de bloqueo
concesiones de bloqueo
mensajes de actualización
verificaciones
solicitudes de liberación de bloqueo
Así pues, el tiempo total invertido en la actualización podría con facilidad ser mayor
que en un sistema centralizado.
Otro problema con el bloqueo en un sistema distribuido es que puede conducir a un
bloqueo mutuo, en el cual se verían implicados varios sitios.
El problema con un bloqueo como éste es que ninguno de los sitios puede
detectarlo empleando sólo información interna de este sitio. Dicho de otro modo, no
existen ciclos en las gráficas de espera locales, aunque aparecerá un ciclo si se
combinan esas dos gráficas locales para formar una gráfica de espera global. En
consecuencia, la detección de bloqueos mutuos globales implica mayores costos
adicionales de comunicación, pues requiere juntar de alguna manera las gráficas
locales individuales.
1.6 Soporte para bases de datos distribuidas
Existen diversos Sistemas Manejadores de Bases de Datos (DBMS) comerciales,
los cuales en sus inicios fueron diseñados para el manejo de bases de datos
centralizadas, logrando un hito en el manejo de datos puesto que permitieron el diseño
de sistemas abiertos. Esto gracias al sublenguaje de datos con que trabajaban en la
realización de consultas (por lo general SQL), los programadores de aplicaciones solo
se preocupaban por generar las consultas en SQL y no por generar consultas para uno
u otro DBMS en particular.
Al aumentar la cantidad de datos y la necesidad de información, y de la misma
manera al evolucionar las bases de datos centralizadas a distribuidas, los DBMS
también tuvieron que evolucionar a lo que actualmente se conoce como Sistemas
21
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Manejadores de Bases de Datos Distribuidas (DDBMS). Estos DDBMS, además de
contar con el sublenguaje de datos deben tener nuevas características propias de las
bases de datos distribuidas como son el soporte de fragmentación, replicación, y el
procesamiento de consultas distribuidas. Sin dejar a un lado que un DDBMS debe de
ser un sistema abierto, esto debido a que el DDBMS se debe de comunicar con otro
sito en el cual tal vez no cuente con el mismo DDBMS.
Algunos de los DDBMS comerciales con los que se cuenta son INFORMIX, DB2 y
ORACLE. A continuación se presenta una tabla en la cual se muestran algunas de las
características de dichos DDBMS:
DDBMS DSL REPLICA
INFORMIX VS.07 SQL Soportada
DB2 V5 SQL Integrada
ORACLE V8 SQL Integrada
Existen muchos más DDBMS con diferentes características, por ejemplo, Sybase
ofrece las primitivas pero- las aplicaciones deben de implementar las transacciones
distribuidas por si mismas, sin embargo, es posible diseñar de manera optima una
base de datos distribuida con las herramientas que estos DDBMS comerciales
proporcionan.
22
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
1.7 Resumen
Las características que deben de tener los sistemas de bases de datos son:
Control centralizado: Un Administrador de base de datos (DBA) tiene la función de
garantizar la seguridad de los datos, el administrador local tiene la responsabilidad de
su respectiva base de datos, mientras que el administrador global tiene la principal
responsabilidad de la totalidad de los datos de la base de datos.
Independencia de datos: quiere decir que, la organización actual de los datos es
transparente a las aplicaciones y en el caso de una base de datos distribuida se refiere
también a la transparencia de distribución.
Reducción de redundancia: la redundancia debe de ser reducida, por dos razones:
evitar la inconsistencia entre varias copias de los datos, y recuperar espacio de
almacenamiento en el sistema, aún cuando en una base de datos distribuida, las
aplicaciones podrían verse favorecidas con la redundancia, ya que, debido a esta, la
razón de disponibilidad puede aumentar.
Estructuras físicas complejas y acceso eficiente: El uso de estructuras de acceso
podría ser una herramienta para el acceso eficiente a la base de datos, es conveniente
tomar en cuenta la optimización local, el acceso a las bases de datos locales, y la
optimización global, el acceso a los sitos que conforman la base de datos, de las
consultas.
Seguridad: En las bases de datos tradicionales, el administrador de la base de
datos, tiene el control centralizado. En las bases de datos distribuidas, se tienen,
además, que considerar dos aspectos, el grado de autonomía y la seguridad en los
accesos de los usuarios.
Las bases de datos distribuidas tienen algunas ventajas sobre las no distribuidas,
estas son:
23
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Razones organizacionales: La mayor parte de las organizaciones están ya
descentralizadas.
Interconexión de las bases de datos existentes: Las bases de datos distribuidas son
la solución cuando se tiene varias bases de datos en la organización.
Desarrollo incrementar: Es posible agregar una nueva unidad en una base de datos
distribuida si afectar a las ya existentes.
Reducción de la sobrecarga de la comunicación: En una base de datos distribuida
geográficamente, se vería reducida la sobrecarga de las comunicaciones en
comparación con una base de datos no distribuida.
Consideraciones en el desempeño: La existencia de varios procesadores
autónomos da como resultado un alto grado de procesamiento en paralelo.
Confiabilidad y disponibilidad: Por medio de la repica de datos, se logra un alto
grado de contabilidad y disponibilidad.
Existe un principio fundamental en los sistemas distribuidos, el cual es aplicable a
las bases de datos distribuidas:
Desde el punto de vista del usuario, un sistema distribuido deberá ser idéntico a un
sistema no distribuido.
Hay además de este, 12 reglas para los sistemas distribuidos:
1. Autonomía local: Significa que todas las operaciones en un sitio se controlan en
ese sitio.
2. No dependencia de un sitio central: Todos los sitios son iguales y no dependen
de ningún otro sitio.
3. Operación continua: Un sistema distribuido siempre esta disponible.
24
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
4. Independencia con respecto a la localización: Los usuarios nunca sabrán la
localización real de los datos.
5. Independencia con respecto a la fragmentación: Un sistema distribuido deberá
dar la apariencia de que se encuentra en una sola pieza.
6. Independencia de replica: Un sistema deberá comportarse como si solo
e)dstiera una sola copia de los datos.
7. Procesamiento distribuido de consulta: En una consulta, la cual involucro a más
de un sitio, siempre habrá varias maneras de trasladar en la información para
satisfacer la petición y encontrar la estrategia más eficiente.
8. Manejo distribuido de transacciones: Deberá poder procesar una transacción a
través de varios sitios.
9. Independencia con respecto al equipo: Deberá poder procesar una transacción a
través de diferentes plataformas de hardware y aparentar ante el usuario como
si fuera uno solo.
10. Independencia con respecto al sistema operativo: Deberá de ser capaz de
trabajar en cualquier sistema operativo.
11. Independencia con respecto a la red: Deberá de ser capaz de trabajar en
diferentes redes.
12. Independencia con respecto al DBMS: Varios DBMS deberán trabajar en
conjunto y procesar las transacciones.
El paradigma que dispone que una aplicación debe esperar pasivamente a que otra
aplicación inicie la comunicación, tiene el nombre de interacción cliente/servidor.
25
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
El modelo de procesamiento cliente/servidor surgió del concepto de procesamiento
compartido de las redes de área local. Así, las computadoras personales conectadas a
un sistema pueden compartir recursos, la computadora que solicita el recurso pasa a
ser un cliente, mientras que aquella que comparte el recurso y recibe la petición se
convierte en servidor.
Esta arquitectura provee ciertas ventajas:
Permite integrar mejores tecnologías al sistema.
Permite que el procesamiento de los datos se realice en el lugar en el que
estos residen
Facilita el uso de interfaces gráficas de usuario.
Permite el uso de sistemas abiertos.
A pesar de todo esto, también cuenta con algunas desventajas:
El servidor puede convertirse en cuello de botella, al verse disminuidos los
recursos del servidor.
El desarrollo de aplicaciones distribuidas es más complicado que el de las no
distribuidas.
Tanto el cliente como el servidor, deben de cumplir con ciertas características para
ser considerados como tales:
Cliente
Es un programa de aplicación arbitrario que se vuelve cliente temporalmente
cuando necesita acceso remoto, pero también lleva a cabo otro computo local.
Lo llama directamente el usuario y se ejecuta solo durante la sesión.
Se ejecuta localmente en la computadora personal del usuario.
Inicia el contacto con el servidor.
Puede acceder a varios servicios, según se necesite, pero contacta activamente
con un servidor remoto a la vez.
No necesita hardware poderoso y un sistema operativo complicado.
26
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Servidor
Es un programa privilegiado de propósito especial dedicado a ofrecer un
servicio, pero puede manejar varios clientes remotos a la vez.
Se inicia automáticamente al arranque del sistema y continua ejecutándose
en varias sesiones.
Opera en una computadora compartida (es decir, no en una computadora
personal).
Espera pasivamente el contacto de los clientes remotos.
Acepta el contacto de varios clientes, pero ofrece un solo servicio.
Necesita hardware poderoso y un sistema operativo complejo.
El cliente debe de cumplir con la función de presentar la información al usuario,
así como de realizar algunas funciones lógicas en el procesamiento de dicha
información. Por su parte el servidor debe de proveer servicios a solicitudes de
procesamiento, el cliente inicia la interacción cliente/servidor enviando solicitudes a los
servidores, la función de un servidor debe llevar a cabo una determinada acción, de
acuerdo a la solicitud enviada por el cliente. Algunas funciones que un servidor pudría
realizar seria:
Compartir archivos.
Compartir impresoras.
Servicios de comunicación.
Servicios de fax.
Accesos a las bases de datos.
Un servidor deberá, también, cumplir con ciertos requerimientos generales:
Soporte multiusuario: Debe de ser capaz de proporcionar servicio a múltiples
clientes.
Escalabilidad: Debe de ser capaz de satisfacer la creciente demanda de los
recursos y las aplicaciones.
Desempeño: Un servidor debe proveer niveles de desempeño satisfactorios.
Almacenamiento: Debe de ser capaz de almacenar tanto aplicaciones, como los
archivos generados por estas y los usuarios.
27
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Gestión de red: Tanto el servidor como el cliente deben de contar con
capacidades de red.
Multimedia: En la actualidad la necesidad de que un servidor soporte datos,
vídeo y sonido son esenciales.
Debido a que un sistema distribuido involucro el procesamiento cooperativo entre
vados servidores y clientes, se presentan algunos problemas que se deben de tomar
en cuenta para ser solucionados:
Procesamiento de consultas: El proceso deberá de ser distribuido, por lo tanto, un
proceso representativo consistirá en una actualización global seguida de
optimizaciones locales en cada sitio.
Administración del catalogo: En un sistema distribuido, el catalogo del sistema incluirá
la información a cerca de las relaciones, los índices, los usuarios, y la localización de
fragmentos y replicas de los datos.
Propagación de las actualizaciones: Es necesario propagar cualquier actualización de
un objeto dado, en todas las copias existentes de ese objeto en el sistema.
Control de recuperación: Es necesario que un sistema distribuido cuente con un
método de recuperación, esto, en caso de caídas del sistema. El control de
recuperación en los sistemas distribuidos se basa por lo regular en el protocolo de dos
fases. El compromiso de dos fases es obligatorio en cualquier ambiente en el cual una
sola transacción puede interactuar con varios manejadores de recursos autónomos.
Control de concurrencia: el control de concurrencia se basa en el bloqueo, las
solicitudes de prueba, establecimiento y liberación de bloqueo, los cuales se convierten
en mensajes, y por lo tanto implica costos adicionales. La puesta en practica directa
requerirá por lo menos de 5 mensajes por cada sitio involucrado en la transacción:
solicitud de bloqueo, concesiones de bloqueo, mensajes de actualización,
verificaciones, solicitudes de liberación de bloqueo.
28
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Al aumentar la cantidad de datos y la necesidad de información, y de la misma
manera al evolucionar las bases de datos centralizadas a distribuidas, los DBMS
también tuvieron que evolucionar a lo que actualmente se conoce como Sistemas
Manejadores de Bases de Datos Distribuidas (DDBMS). Estos DDBMS deberán contar
con: el sublenguaje de consultas, el soporte de fragmentación, replicación, y el
procesamiento de consultas distribuidas. Sin dejar a un lado que un DDBMS debe de
ser un sistema abierto capaz de interactuar con otros DDBMS.
1.8 Preguntas de repaso
1.-¿Cuales son las características sobre las cuales, es posible hacer una
comparación entre bases de datos centralizadas y bases de datos distribuidas?
2.-¿Cuales son las ventajas que tienen las bases de datos distribuidas sobre las
centralizadas?
3.-¿Cuál es la regla cero de los sistemas distribuidos?
4.-¿Por qué la regla cero de los sistemas distribuidos es considerada el
principio de las bases de datos distribuidas?
5.-¿A que se refiere la autonomía en el enfoque de las bases de datos distribuidas?
6.-¿Que significa transparencia dentro del entorno de las bases de datos
distribuidas?
7.-¿Cómo describe la arquitectura cliente - servidor?
8.- ¿Cuales deben ser las características de un cliente?
9.-¿Cuáles deben ser las caracteristic as de un servidop
10.-¿Que requerimientos son necesarios para un servidor?
11.- ¿Cuales son los principales problemas a los que se enfrentan los diseñadores de
bases de datos distribuidas?
29
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Bibliografía
[1] Date, C.J.; "An lntroduction to Databases Systems"; Volume 1-1 Fifth Edition;
Addison-Wesley Publishing Company; U.S.A.; Reprinted July, 1990
[2] Date, C.J-; "An Introduction to Databases Systems"; Volume li; Addison-Wesley
Publishing Company; U.S.A.; Reprinted July, 1995
[3] Korth, Henry F. Silberschatz, Abraham; "Database System Concepts"; Second
Edition; McGraw-Hill; U.S.A-; Internacional Edition 1991
[4] Berson, Alex - "Client/ServerArchitecture'; McGraw-Hill; U.S.A.-, 1992
[5] Renuad, Paul E.; "Introduction to Client/Server Systems A practicar guide for
systems professionals"; Wiley Professional Computing; U.S.A.; 1993
30
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Objetivo
El alumno comprenderá las técnicas de diseño de bases de datos distribuidas, así
como cada uno de los tipos de fragmentación existentes y las operaciones necesarias
para realizarla.
Introducción
En este capítulo se tratarán las consideraciones que se deberán tener al diseñar la
distribución de la base de datos, así como los tipos de fragmentaciones que existen y
como se obtienen. También se expondrá la forma en como se deberán llevar a cabo el
procesamiento de las consultas en un sistema con datos distribuidos y los costos de
dicho procesamiento,
A continuación se presenta una tabla con las operaciones del álgebra relaciona¡ que se
utilizarán a lo largo del capítulo:
Operación Abreviación Símbolo
Select SL
Projecion Pi
Join JN
Semi-join Si
Union UN
Producto cartesiano CP X
Natural Join NJN
Natural Semi-join NSJ
Diferencia DF
31
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Capítulo II
Bases de Datos en múltiples servidores
2.1 Consideraciones en la distribución de bases de datos
Desde la primera etapa de las bases de datos distribuidas a la actualidad, se han
desarrollado varias técnicas para su diseño. De cualquier forma esta claro que el
diseño de bases de datos distribuidas no es fácil, ya que por si mismas, las técnicas y
organización, en el diseño de un sitio sencillo son complicadas, éstas se vuelven más
complicadas en el diseño de un sistema multisitio. Desde el punto de vista técnico, los
nuevos problemas que se presentan son la interconexión entre los sitios por medio de
la red, y la distribución optima de los datos y aplicaciones en los sitios para lograr un
desempeño óptimo del sistema. Desde el punto de vista organizacional, la
descentralización es crucial, puesto que se sustituirá por un sistema distribuido al típico
y extenso sistema centralizado, y en el caso de la distribución de una aplicación tendría
un gran impacto en la organización.
El diseño de una base de datos centralizada consiste en:
1. Diseñar el "esquema conceptual", el cual describe la base de datos-
2. Diseñar el 'esquema físico", mapeando el esquema conceptual con las áreas de
almacenamiento y determinando los métodos de acceso.
En las bases de datos distribuidas estos dos puntos son utilizados para diseñar el
esquema global y diseñar las bases de datos locales en cada sitio. La distribución de
las bases de datos requiere agregar dos nuevos puntos:
3. Diseñar la fragmentación de los datos, determinando como las relaciones
globales serán divididas, horizontalmente, verticalmente o en fragmentos
mixtos.
4. Diseñar la distribución de los fragmentos, determinando como se mapearán los
fragmentos, con las imágenes físicas. En este punto son determinadas las
replicas de los fragmentos.
Estos dos puntos son característicos en el diseño de datos distribuidos.
32
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
2.1.1 Objetivos del diseño de los datos distribuidos
En el diseño de los datos distribuidos, los siguientes objetivos deberán ser tomados
en cuenta:
Procesamiento local.
La distribución de los datos aumenta el procesamiento local, esto correspondiendo a
un principio básico de que los datos son colocados lo más cercano a las aplicaciones
que los utilizan. Una manera simple de ejemplificar el procesamiento local, es
considerar dos tipos de referencias a los datos: referencias "locales" y referencias
"remotas". Claramente, una vez que los sitios de origen de las aplicaciones conocen la
localización local y remota de los datos, la referencia depende únicamente de la
distribución de los mismos.
Se deberá, también, tomar en cuenta cuando una aplicación tiene un procesamiento
local completo, es decir la aplicación se ejecuta completamente en el lugar de origen.
La ventaja del procesamiento local completo no solamente reduce los accesos
remotos, sino que además, incremento la simplicidad en el control de la ejecución de la
aplicación.
Disponibilidad y confiabilidad de los datos distribuidos.
El almacenamiento de múltiples copias de la información permite lograr un alto
grado de disponibilidad para las aplicaciones que solo leen o muestran los datos; el
sistema puede conmutar a una copia alternativa, cuando la copia que comúnmente era
accesada no se encuentra disponible.
La Confiabilidad se logra por medio del almacenamiento de múltiples copias de la
información permitiendo recuperarla, de caídas del sistema o de daños físicos en
alguna de las copias, usando cualquier otra copia disponible.
Distribución de la carga del trabajo.
La distribución de la carga del trabajo en los sitios es una característica importante
de los sistemas distribuidos. La distribución de la carga del trabajo es hecha en
relación con el poder de cómputo y utilización del equipo de cada sitio, y para
33
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
maximizar el grado de paralelismo en la ejecución de las aplicaciones. La distribución
de la carga del trabajo puede provocar un efecto negativo en la ejecución local.
Disponibilidad y costo del almacenamiento.
La distribución de las bases de datos se refleja en el costo y disponibilidad del
medio de almacenamiento en los diferentes sitios. Esto es posible teniendo sitios
especializados en la red para el almacenamiento de datos. Por lo general, el costo del
almacenamiento de los datos nos es tan relevante, comparado con el costo de CPU,
I/O, y el costo de la transmisión de las aplicaciones.
2.2 Diseño de bases de datos distribuidas
2.2.1 Técnicas de diseño Top-Down y Bottom-Up de bases de datos
distribuidas
Se tiene dos alternativas en el diseño de las bases de datos distribuidas, las
técnicas Top-Down y Bottom-Up.
En la técnica top-down, se comienza diseñando el esquema global, y se procede
con el diseño de la fragmentación de los datos, después se distribuyen los fragmentos
en los sitios, creando las imágenes físicas. Esta técnica es complementada con la
construcción, en cada sitio, del "diseño físico" de los datos que estarán almacenados
ahí.
Cuando la base de datos distribuida es desarrollada como un complemento de una
base de datos existente, no es tan fácil lograr esto con la técnica top-down- De hecho,
en este caso el esquema global está, por lo general, comprometido con los datos
existentes.
Cuando una nueva base de datos va a ser agregada a una ya existente, la técnica
de diseño bottom-up puede ser utilizada. Esta técnica consiste en la integración de
esquemas existentes en un solo esquema global. Para la integración, se deberá de
unir definiciones de datos comunes y resolver conflictos entre diferentes
representaciones del mismo dato.
En resumen, la técnica bottom-up requiere:
34
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
1. La selección de un modelo de base de datos común para diseñar el esquema
global de la base de datos.
2. La traducción de cada esquema local al modelo de datos común.
3. La integración de los esquemas locales en el esquema global común.
2.2.2 Diseño de los fragmentos de la base de datos
El diseño de los fragmentos es la primera parte dentro de la técnica top-down. El
propósito de la fragmentación es determinar fragmentos no traslapados, los cuales
serán “unidades lógicas de distribución”.
Se podrá ver que, las tuplas y atributos de la relación no podrán ser considerados
como "unidades individuales de distribución'. El diseño de fragmentos consiste en
agrupar tuplas (en el caso de la fragmentación horizontal) o atributos (en el caso de la
fragmentación vertical), las cuales tienen las "mismas propiedades" desde el punto de
vista de la distribución. Cada grupo de tuplas o atributos que tienen las "mismas
propiedades" puede constituir un fragmento. La idea básica es que si dos elementos
cualquiera de un mismo fragmento tiene las mismas propiedades" desde el punto de \
Asta de la distribución, cualquier método usado para localizar un dato puede entonces
localizar a cualquiera.
2.2.3 Correctez de la fragmentación
Para que una fragmentación sea correcta, esta deberá de cumplir con las siguientes
características:
Completez
La descomposición de una relación R en fragmentos RI,R2, ... ,Rn, es completa si y
solo si cada elemento de datos en R puede ser encontrado en algún Ri
Reconstrucción
Si la relación R es descompuesta en fragmentos Rl,R2, ... , Rn, debiera existir un
operador relacional tal que: R Ri
Exclúyete
35
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Si la relación R es descompuesta, en fragmentos Rl,R2, .... Rn, y datos de]
elemento di están en Rj entonces di no debiera estar en algún otro fragmento Rk k).
2.2.4 Fragmentación horizontal
La fragmentación horizontal consiste en particionar las tuplas o registros de una
Tabla global en subconjuntos de tuplas o registros; esto es muy utilizado en las bases
de datos distribuidas, donde cada subconjunto pueden contener datos con propiedades
geográficamente comunes.
Es importante, dentro de la fragmentación horizontal, considerar las siguientes
definiciones:
Predicado simple
Dado R[Al,A2, ... A.], un predicado simple pj es:
pj: Ai Valor
donde {, , , ≤, <, >}, Valor Di y Di es el dominio de A¡.
Se tendrá entonces R[pl,P2,P3,---,PMI
Predicados minitermino
Dado Ri y Pti = {p1,p2, ... pj definir M = {mi1, mi2, ... miz} como:
Mi = {mij l mij = ^pik pri pik*}, 1 ≤ k ≤ m, 1 ≤ j ≤ z donde pi*= pi o pi* = ~pi
selectividad de miniterminos sel(mj)
Número de tuplas de la relación que sería accesada por una consulta de usuario la
cual es especificada acorde a un predicado minitermino mj dado.
frecuencias de acceso: acc(qj)
Frecuencia con la cual la aplicación qj accesa datos.
La frecuencia de acceso por una predicado minitermino puede también ser definida.
Considérese la siguiente relación global:
Proveedor(pclave, nombre, cveciudad)
36
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
pClave Nombre cveciudad
P01 John Smith SF
P02 José Sanchéz LA
P03 Juan Pérez LA
P04 Steven Freeman SF
P05 Alex SD
P06 Tere SD
Para la cual se tiene la siguiente aplicación:
q: Obtener la clave y el nombre de los proveedores de cada ciudad.
Se tendrán los siguientes predicados simples:
P1 = {cveciudad = "SF" }
P2 = { cveciudad = "LA" }
P3 = { cveciudad = "SD" }
Dando como resultado los siguientes predicados miniterminos, los cuales se
obtienen de las combinaciones de los predicados simples:
m1 = {SF ^ LA ^ SD} contradictorio
m2 = {SF ^ ~LA ^ SD} contradictorio
m3 = {SF ^ ~LA ^ ~SD}
..
M6 = {~SF ^ ~LA ^ ~SD} contradictorio
..
M7 = {~SF ^ LA ^ ~SD}
M8 = {~SF ^ ~LA ^ SD}
Eliminando los miniterminos contradictorios se obtiene el siguiente resultado, donde
cada uno de estos miniterminos representa un fragmento de la relación global:
M3 = {SF ^ ~LA ^ ~SD}
M7 = {~SF ^ LA ^ ~SD}
M8 = {~SF ^ ~LA ^ SD}
37
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Entonces la fragmentación horizontal estaría dada de la siguiente forma:
Proveedor1 = SL cveciudad = “SF” Proveedor
Select pclave, nombre, cveCiudad into Proveedor1
from Proveedor Where cveCiudad = ‘SF’
Pclave Nombre Cveciudad
P01 John Smith SF
P04 Steven Freeman SF
Proveedor2 = SL cveciudad = “LA” Proveedor
Select pclave, nombre, cveCiudad into Proveedor2
from Proveedor Where cveCiudad = ‘LA’
Pclave Nombre Cveciudad
P02 José Sanchéz LA
P03 Juan Pérez LA
Proveedor3 = SL cveciudad = “SD” Proveedor
Select pclave, nombre, cveCiudad into Proveedor3
from Proveedor Where cveCiudad = ‘SD’
Pclave Nombre Cveciudad
P05 Alex SD
P06 Tere SD
Las condiciones anteriores cumplirían con la definición de fragmentación, si los
únicos valores posibles para el atributo Cveciudad fueran "SF", "LA" y “SD”; de otro
modo no se sabría a que fragmento corresponden las tuplas que contengan otro valor.
38
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
La reconstrucción de la Tabla global Proveedor se logra fácilmente, por medio de la
siguiente condición:
Proveedor = Proveedor1 UN Proveedor2 UN Proveedor3
Create View ReconstruccionProveedorAs
Select * from Proveedor1Union AllSelect * from Proveedor2Union AllSelect * from Proveedor3
La reconstrucción de la relación global siempre se lleva a cabo, por medio de la
operación de unión.
2.2.5 Fragmentación horizontal derivada
En algunas ocasiones, la fragmentación horizontal de una tabla no se puede basar
en alguna propiedad de sus propios atributos, pero se deriva de la fragmentación
horizontal de otra tabla. Considérese el siguiente ejemplo:
Pedido(pclave, cveProducto, cant)
Pclave cveProducto Cant
P01 2325 123
P01 2547 21
P02 3298 98
P03 7895 87
P04 741 0 53
P04 2589 10
Donde pclave es la clave del proveedor. Esto es significativo para la partición
de esta relación ya que un fragmento contiene las tuplas para los proveedores con los
cuales se obtiene la cveciudad. No obstante que cveciudad no es un atributo de la
39
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
tabla Pedido, sino que es un atributo de la tabla Proveedor. Por lo tanto, se necesita
una operación de semi-join para determinar las tuplas de Pedido que corresponden con
los proveedores en cierta cveciudad. Esto se logra de la siguiente manera:
Pedido1 = Pedido SJ pclave = pclave Proveedor1
Select A.* into Pedido1 From Pedido A Inner Join Proveedor1 B on (A.pclave=B.pclave)
Pclave Pnum Depto CantP01 2325 Compras 123P01 2547 Compras 21P04 7410 Ventas 53P04 2589 Sistemas 10
Pedido2 = Pedido SJ pclave = pclave Proveedor2
Select A.* into Pedido2 From Pedido A Inner Join Proveedor2 B on (A.pclave=B.pclave)
Pclave Pnum Depto CantP02 3298 Ventas 98P03 7895 Finanzas 87
Pedido3 = Pedido SJ pclave = pclave Proveedor3
Select A.* into Pedido3 From Pedido A Inner Join Proveedor3 B on (A.pclave=B.pclave)
El efecto de la operación semi-join nos permite seleccionar de Pedido las tuplas que
satisfacen la condición de unión entre Proveedor1, o Proveedor2, o Proveedor3 y
Pedido, de esta manera se determinaran aquéllas tuplas de la Table Pedido que hacen
referencia a proveedores en San Francisco, Los Ángeles o San Diego,
respectivamente.
La reconstrucción de la Table global Pedido puede lograrse por medio de una
operación de unión como en el caso de la table Proveedor.
La integridad de un fragmento requiere que no existan claves de proveedores en la
Table Pedido, los cuales no estén dentro de la tabla Proveedor. Esto es una
restricción típica dentro de las bases de datos conocida como integridad referencial.
40
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
2.2.6 Fragmentación vertical
La fragmentación vertical de una tabla global es la subdivisión de sus atributos en
grupos, los fragmentos son obtenidos al proyectar la tabla global sobre cada grupo.
La fragmentación es correcta si cada atributo es mapeado por lo menos con un atributo
de los demás fragmentos; por otra parte, es posible reconstruir la tabla original por
medio de uniones de todos los fragmentos a la vez. Considérese el siguiente ejemplo:
Emp(Cvemp, Nom, Sal, lmp, Depto)
Cvemp Nom Sal Imp Depto
E12 Juan Pérez 4500 15 15
E56 José Hernández 756 15 9
E78 Luis Pérez 9254 15 17
E98 Maria Solís- 2345 25 22
E32 John Smith 5489 2-5 22
Egl Rocio Sánchez 4600 15 8
E73 Carmen Campos 753 15 15
Considérese las siguientes aplicaciones:
q1: Obtener el nombre y departamento de todos los empleados
q2: Obtener el clave, salado y tasa de impuestos por departamento
q3:Obtener la clave, nombre y departamento de los empleados con salado mayor a
10,000
Se tiene la siguiente matriz de accesos:
Total de
S1 S2 S3 accesos
q1 2 3 2 7
q2 2 1 2 5
q3 1 2 1 4
41
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Las aplicaciones se traducirían de la manera siguiente:
q1= Select nom, depto
From empleados
q2= Select cvemp, sal, imp
From empleados
Where depto = X
q3= Select cvemp, nom, depto
From empleados
Where sal > 10000
Con esto se podrá obtener la matriz de uso, en la cual se colocara, de acuerdo con
los atributos accesados en cada una de las aplicaciones, colocando en cada casilla un
1 si el atributo A¡ es reverenciado en la aplicación qj.
A1 (cvemp) A2 (nom) A3 (sal) A4 (imp) A5 (depto)
q1 0 1 0 0 1
q2 1 0 1 1 1
q3 1 1 1 0 1
Ahora se construirá la matriz de afinidad, la cual se obtiene por medio de la siguiente
formula
aff(Ai,Aj) = todas las consultas que accesan A¡ y Aj (accesos en consultas) accesos
en consulta = todos los sitios frecuencia de accesos de una consulta
aff(A1, A1)= (2+1+2)(1) + (1+2+1)(1) = 9
aff(A1, A2)= (1+2+1)(1) = 4
aff(A1, A3)= (2+1+2)(1) + (1+2+1)(1) = 9
aff(A1, A4)= (2 +1+2)(1) = 5
aff(A1, A5)= (2+1+2)(1) + (1+2+1)(1) = 9
aff(A2, A1)= (1 +2+ 1)(1) = 4
aff(A2, A2)= (2+3+2)(1) + (1+2+ 1)(1) = 11
42
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
aff(A2, A3)= (1+2+1)(1) = 4
aff(A2, A4)= 0
aff(A2, A5)= (2+3+2)(1) + (1 +2+ 1)(1) = 11
A1 A2 A3 A4 A5
Al 9 4 9 5 9
A2 4 11 4 0 11
A3 9 4 9 5 9
A4 5 0 5 5 5
A5 9 11 9 5 16
En la diagonal deberán aparecer los valores más altos de cada columna, de no ser
así, será necesario reordenar dichas columnas para logrado.
El paso restante será seleccionar los campos necesarios para cada fragmento, esto,
de acuerdo al orden en que las columnas se encuentran en la tabla.
Emp= {A1, A2, A3, A4, A5}
Emp1 { A1, A2), Emp2= { A1, A3, A4, A5)
Emp1 = PJcvemp, Nom, Emp
Emp2 = PJCemp, Sal, Imp, Depto Emp
Emp1(Cvemp, Nom)
Emp2(Cvemp, Sal, lmp, Depto)
o en otro caso
Emp1= { A1, A2, A3} Emp2= { A1, A4, A5}
43
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Emp1 = PJcvemp, Nom, Depto Emp
Emp2 = PJCemp, Sal, Imp Emp
Emp1(Cvemp, Nom, Sal)
Emp2(Cvemp, Imp, Depto)
El atributo A1 aparece en ambos fragmentos debido a que es la llave primaria de la
relación global. La manera de seleccionar que atributos irían en cada fragmento
depende de las necesidades del sistema.
La reconstrucción de la relación Emp se puede obtener por medio de:
Emp = Emp1 JNcvemp = cvemp Emp2
Esto dado que Cvemp es la llave de la relación global Emp. En general, la inclusión
de la llave de la relación en cada uno de los fragmentos es lo que hace posible la
reconstrucción por medio de la operación de join.
2.2.7 Fragmentación mixta
Los fragmentos son obtenidos por medio de las operaciones de fragmentación, que
pueden relacionarse precedentemente, es posible aplicar la operación de
fragmentación (vertical y horizontal) de manera recursiva, dando como resultado las
condiciones necesarias para la fragmentación. La reconstrucción se logra aplicando
las reglas de reconstrucción en orden inverso de acuerdo a la fragmentación.
44
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Para realizar la fragmentación mixta se deberá considerar la necesidad de
información de cada uno de los sitios dentro de la base de datos distribuida, esto es
considérese la siguiente tabla:
Emp(Cvemp, Nom, Sal, lmp, Depto)
Se tiene un sitio en el departamento fiscal el cual se encarga del cálculo de los
impuestos, y tres sitios más, uno por cada uno de los tres departamentos restantes
dentro de la empresa. Para el departamento fiscal, el nombre y el departamento del
trabajador no son relevantes, necesitando únicamente los campos de clave del
empleado, salario y tasa de impuesto. Por tanto, es conveniente realizar una
fragmentación vertical para obtener un fragmento con los campos necesarios (cvemp,
sal y imp) para este departamento. El resto de la tabla global podría fragmentarse
horizontalmente de acuerdo a cada departamento, obteniendo tres tablas, las cuales se
situarían en cada uno de los tres sitios restantes dentro del sistema distribuido.
Por medio de las siguientes operaciones se realizará una fragmentación mixta,
donde se aplica la fragmentación vertical, seguida por una fragmentación horizontal por
Depto:
Vertical
Emp1 = PJcvemp, Sal. Imp Emp
Select cvemp, Sal, Imp Into Emp1 From Emp
Horizontal
Depto10 = SLdepto=10 PJ Cvemp, Nom, Depto Emp
Select cvemp, nom, depto Into Depto10 from Emp Where depto=10
Depto20 = SLdepto=20 PJ Cvemp, Nom, Depto Emp
Select cvemp, nom, depto Into Depto20 from Emp Where depto=20
Depto30 = SLdepto=30 PJ Cvemp, Nom, Depto Emp
Select cvemp, nom, depto Into Depto30 from Emp Where depto=30
La reconstrucción de la tabla Emp se define de la siguiente forma:
45
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Emp = UN(Depto10, Depto20, Depto30) JNCvemp = Cvemp PJCvemp, Sal, Imp Emp1
Reconstruccion Horizontal
Create View ReconstruccionHorizontal
As
Select * from Depto10
Union All
Select * from Depto20
Union All
Select * From Depto30
Reconstruccion Vertical
Create View ReconstruccionVertical
as
Select A.cvemp, nom, imp, depto
From ReconstruccionHorizontal A inner join Emp1 B On
(A.cvemp=B.cvemp)
La fragmentación mixta se representa generalmente por medio de un árbol de
fragmentación. En el árbol de fragmentación, la raíz corresponde a la tabla global, las
hojas corresponden a los fragmentos, y los nodos intermedios corresponden a los
fragmentos intermedios, resultantes de las operaciones. A continuación se presenta el
árbol de distribución del ejemplo anterior:
Emp
Emp1
Depto10 Depto20 Depto30
46
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
H
V
Es importante tomar en cuenta que el orden en el cual se realiza la fragmentación
horizontal y vertical afecta a la fragmentación final.
fragmentación vertical seguida de fragmentación horizontal
fragmentación horizontal seguida de fragmentación vertical
2.2.8 Distribución de los fragmentos
La manera más fácil para realizar la distribución de los fragmentos es considerar
cada fragmento como un archivo separado; sin embargo, este enfoque no es
conveniente, por las siguientes razones:
1 . Los fragmentos no son modelados propiamente como archivos individuales, ya
que de esta manera no se podría tomar en cuenta el hecho, de que tienen la
misma estructura.
2. Hay muchos más fragmentos que relaciones globales, y muchos modelos
analíticos no pueden procesar la solución de problemas que involucran
demasiadas variables.
3. El modelado del comportamiento de las aplicaciones en sistema de archivos es
muy simple (típicamente, las aplicaciones hacen un "acceso remoto a
archivos"), mientras que en aplicaciones de bases de datos distribuidas pueden
hacer un uso más complejo de los datos.
Algunos de estos problemas no tienen una solución satisfactoria; por ejemplo el
punto 3 es particularmente difícil, puesto que el correcto enfoque permitiría evaluar la
distribución de los datos mediante cómo las aplicaciones pueden optimizar el acceso.
47
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
2.2.9 Criterios generales para la distribución de fragmentos.
En la distribución de los fragmentos, es importante distinguir entre si se va a
diseñar una distribución redundante o no redundante.
La replicación introduce una amplia complejidad en el diseño, porque:
1. El grado de replicación de cada fragmento llega a ser una variable del problema.
1. El diseño de los módulos de lectura en las aplicaciones es complicado por el hecho
que las aplicaciones deben de seleccionar entre varios sitios alternativos, en cual
accesarán el mismo fragmento replicado en estos sitios.
Para determinar la redundancia en la distribución de fragmentos, cualquiera de los
dos métodos siguientes puede ser utilizado:
1 . Determinar el conjunto de todos los sitios donde el beneficio de colocar una
copia del fragmento es mayor que el costo, y colocar un fragmento en cada uno
de los sitios de este conjunto; este método selecciona "todos los sitios
benéficos'.
2. Determinar primero la solución del problema sin réplica, y posteriormente
introducir réplicas iniciando por las más benéficas; el proceso termina cuando
una 'réplica adicional' no es benéfica.
Ambos métodos tienen algunas desventajas. En el caso del método de "los sitios
benéficos”, el hecho de cuantificar el costo y el beneficio para cada fragmento es más
crítico que en el caso no redundante. El método de "la réplica adicional' es un típico
enfoque heurística; con este método, es posible tomar en cuenta que el incremento en
el grado de redundancia es cada vez menos benéfico. La disponibilidad y la
confiabilidad del sistema se ve incrementado si se tienen dos o tres copias de un
fragmento.
48
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
2.3 Procesamiento de consultas distribuidas
2.3.1 Árbol de operadores de una consulta
Una manera de representar la secuencia en que se realizarán las operaciones de
una consulta, es un árbol de operadores. Considérese la siguiente consulta:
PJSNUM SL área = “Norte” (Prevee JNNumdepto = Numdepto Depto
Un ejemplo de un árbol de operadores para la consulta sería el que aparece en la
figura siguiente. Obsérvese que las hojas del árbol son relaciones globales y cada
nodo representa una operación binaria o unitaria. Un árbol define un orden parcial en
como las operaciones deben ser aplicadas para obtener el resultado deseado en la
consulta, esto es, de abajo hacia arriba. Un orden diferente de operaciones -
correspondería un árbol también diferente, obteniendo una transformación equivalente.
PJSNUM
SLAREA="Norte"
JNNumdepto=Numdepto
PROVEE DEPTO
El árbol de operadores de una expresión de álgebra relaciona] puede verse como
un árbol gramatical, asumiendo la siguiente forma:
R -> identificador
R -> ( R )
R -> op_uni R
R -> R op_bin R
49
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
op_uni -> SLF | PJA
op_bin CP | UN | DF | JNF | NJNF | SJF | NSJF
2.3.2 Ejemplos de consultas distribuidas
Supóngase una universidad, que cuenta con las carreras de derecho, contaduría y
administración- Dicha universidad tiene una base de datos distribuida con fragmentos
en cada uno de los departamentos concernientes a cada carrera de la manera
siguiente:
Tabla global
Alumnos(no-control, nombre, domicilio, ciudad, edad, especialidad)
No-control nombre Domicilio ciudad edad especialidad
D12 Pedro H. Hidalgo 100 Celaya 1-9 derecho
A32 José L. Morelos 23-4 Salamanca 20 Administración
C54 Juan J. Revolución 987 Irapuato 21 Contaduría
C78 Mario V. A. L. Mateos 2345 Celaya 21 contaduría
A29 Adolfo A Juárez 199 Celaya 21 administración
D90 Adriana A Guerrero 987 Irapuato 21 derecho
D73 Sandra F. Revolución 200 Salamanca 20 derecho
A99 Carmen G. A. 1. Mateos 234 Celaya 19 administración
C34 Rocio S. Guerrero 987 Celaya 20 contaduría
Debido a que cada departamento requiere tener la información de sus alumnos, se
realizaría una fragmentación horizontal utilizando la siguiente aplicación:
50
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Q: Seleccionar el número de control, nombre, domicilio, ciudad, edad, especialidad
para los alumnos de cada área.
Esto daría como resultado los siguientes tres fragmentos horizontales:
Alumnos1 = SLespecialidad = “derecho” Alumnos
No-control nombre domicilio ciudad Edad Especialidad
D12 Pedro H. Hidalgo 100 Celaya 19 Derecho
D90 Adriana A. Guerrero 987 Irapuato 21 Derecho
D73 Sandra F. Revolución Salamanca 20 Derecho
Alumnos2 = SL especialidad = “contaduría” Alumnos
No-control Nombre domicilio ciudad edad especialidad
C54 Juan J. Revolución 987 Irapuato 21 contaduría
C78 Mario V. A. L. Mateos 2345 Celaya 2-1 contaduría
C34 Roció S. Guerrero 987 Celaya 2-0 contaduría
Alumnos3 = SL especialidad = “administración” Alumnos
No-control Nombre domicilio ciudad edad especialidad
A32 José L. Morelos 234 Salamanca 20 administración
A29 Adolfo A Juárez 199 Celaya 21 administración
A99 Carmen G. A. L. Mateos 234 Celaya 19 administración
51
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Como se puede observar cada departamento es un sitio dentro de nuestra base de
datos distribuida, conteniendo un fragmento horizontal de la tabla global de acuerdo a
la especialidad.
Considérese, que se requiere una consulta en el departamento de administración en
la cual se deben de obtener el nombre y domicilio de los alumnos de la carrera de
administración que viven en la ciudad de Celaya, dicha consulta no tendría mayor
complicación para el sistema de bases de datos, dado que el proceso se realizaría de
manera local en el sitio de administración.
Por lo tanto el DBMS local deberá detectar que el procesamiento de la consulta se
debe de realizar sobre los datos locales y, que no hay necesidad de efectuar consultas
en otros sitios, esto seria como sigue:
PJ nombre, domicilio SL especialidad = “administración” AND ciudad = "Celaya” Alumnos
La cual seña traducida por el DBMS local, en el departamento de administración a:
PJ nombre, domicilio SL ciudad = "Celaya” Alumnos3
nombre Domicilio
Adolfo A. Juárez 199
Carmen G. A. L. Mateos 234
Ahora supóngase el caso de que el departamento de contabilidad requiere el nombre,
número de control y especialidad de los alumnos que tienen 21 años o más. Esta
consulta involucro a todos los fragmentos que se encuentran distribuidos en el sistema.
La consulta global sería de la siguiente manera:
PJ no-control, nombre, especialidad SL edad>=21 Alumnos
La cual se traduciría en el sistema distribuido de la siguiente manera:
52
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
PJ no-control, nombre, especialidad SL edad>=21 (Alumnos1 UN Alumnos2 UN Alumnos3)
no control nombre especialidad
C54 Juan J. contaduría
C78 Mario V. contaduría
A29 Ádolfo A. administración
D90 Adriana A. derecho
En la consulta es necesario realizar una unión entre los tres fragmentos existentes para
reconstruir la relación global y así poder ejecutar la selección sobre totalidad de las
tuplas existentes en al base de datos.
El árbol de operaciones quedaría de esta manera:
PJNO CONTROL, NOMBRE. ESPECIALIDAD
SLEDAD >= ”21”
UN
ALUMNOS1 ALUMNOS2 ALUMNOS3
En este punto se debe de considerar un aspecto muy importante en el
procesamiento de las consultas, ésta no es la única forma de realizar la consulta.
Existen varias formas de realizar la misma consulta, esto es, se podría variar el orden
de ejecución de las operaciones o reemplazarlas por un conjunto de operaciones
equivalentes. Por ejemplo el siguiente árbol arroja el mismo resultado que el anterior:
53
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
PJNO CONTROL, NOMBRE. ESPECIALIDAD
UN
SLEDAD >= ”21” SLEDAD >= ”21” SLEDAD >= ”21”
ALUMNOS1 ALUMNOS2 ALUMNOS3
La diferencia que existe entre este árbol y el anterior no radica en el resultado de
las operaciones, sino en el costo de la ejecución de las mismas. Es decir en el árbol
anterior los fragmentos eran transmitidos íntegramente a un sitio, por lo general es el
sitio que lanzó la consulta, y en él se realizan todas las operaciones.
En este punto se debe de consideras el costo de la transmisión de los fragmentos y
el costa en la ejecución de cada una de las operaciones dentro del sitio.
En el caso del segundo árbol, el costo de transmisión se reduce considerablemente
al transmitir únicamente los datos del fragmento que cumplen con la condición del
select, y el costo de la ejecución de las operaciones se distribuye en cada uno de los
sitios de la base de datos distribuida, ya que el select se realizaría de manera local en
cada uno de los sitios, y la proyección, así como la unión, se realizarían en el sitio que
lanzó la consulta.
Considérese ahora otro árbol de operaciones, en el cual se puede observar que la
mayor parte del proceso se realiza en los sitios y se deja al sitio que lanzó la consulta
únicamente el trabajo de buscar en su fragmento y unir todos los datos que le sean
enviados por cada uno de los otros sitios. Obsérvese también que el costo de
transmisión se reduce considerablemente ya que no solo se envían únicamente los
dato que cumplen con la condición del select, sino que también se reduce el número de
atributos de la relación que se envían ( no se estarían enviando los atributos de
domicilio, ciudad y edad).
UN
54
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
PJno_CONTROL, PJno_CONTROL, PJno_CONTROL,
NOMBRE, ESPECIALIDAD NOMBRE, ESPECIALIDAD NOMBRE, ESPECIALIDAD
SLEDAD >= ”21” SLEDAD >= ”21” SLEDAD >= ”21”
ALUMNOS1 ALUMNOS2 ALUMNOS3
Aún cuando se tienen menos operaciones que realizar en el sitio que lanzó la consulta,
se debe de considerar que se está generando una carga de trabajo para los demás
sitios, los cuales, posiblemente estén ejecutando sus propias consultas.
Por lo tanto, en el diseño de consultas se debe de considerar los costos en la
ejecución de las operaciones, tanto locales como las que se ejecutarán en otros sitios,
esto quiere decir que, si existen sitios con mucha mayor potencia de computo que el
sitio en el cual se generó la consulta, y existe poca carga de trabajo en estos sitios,
convendrá más, que la mayor parte de las operaciones se realicen en dichos sitios y no
en el que generó la consulta-
También se debe considerar el que posiblemente sea el costo más importante en
una base de datos distribuida, el costo de la transmisión de los datos entre sitios, esto
dado que, los costos de transmisión son mucho mayores al transmitir dentro de una red
WAN, en la que tal vez se involucren transmisiones vía telefónica o vía satélite, que
entre sitios de una red LAN, la cual involucro transmisiones por medio de cables que
interconectan directamente los sitios.
55
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
2.4 Resumen
El diseño de una base de datos distribuida requiere de una planeación de las
técnicas y de la organización de dicha base de datos, esto, en cuanto al diseño de los
múltiples sitios. Los problemas principales serían la interconexión de los diferentes
sitios, así como la distribución de los datos en dichos sitios.
El diseño de una base de datos distribuida consiste en:
1. Diseñar el esquema conceptual.
2. Diseñar el esquema físico.
3. Diseñar la fragmentación de los datos.
4. Diseñar la distribución de los fragmentos.
Existen varios objetivos que una base de datos distribuida deberá de lograr:
Procesamiento local: Debido a que los datos son colocados donde se necesitan, el
procesamiento local aumenta.
Disponibilidad y confiabilidad de los datos distribuidos: El almacenamiento de
múltiples copias en el sistema permite que las aplicaciones utilicen a cualquier otra
copia cuando la copia que era accesada normalmente no esté disponible.
56
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Distribución de la carga de trabajo: La distribución de la carga de trabajo se da a la
par de la distribución de los datos y esto permite que exista un alto grado de
paralelismo en la ejecución de las aplicaciones.
Disponibilidad y costo del almacenamiento: la distribución de las bases de datos
refleja una reducción en el costo del almacenamiento en los sitios.
Existen dos técnicas de diseño de bases de datos distribuidas: La técnica topdown y
la técnica bottom-up. En la técnica top-down se inicia diseñando el esquema global y
la fragmentación de los datos, continuando con la distribución de los fragmentos en los
diferentes sitios, esta técnica es utilizada cuando no existe base de datos alguna.
Cuando una base de datos distribuida se va a agregar a una base de datos ya
existente, la técnica que se utiliza es bottom-top. Esta técnica consiste en:
1. La selección del modelo de datos, para el diseño del esquema global de la base
de datos.
2. La traducción de cada esquema local a un modelo de datos común.
3. La integración de los esquemas locales en el esquema global común.
La fragmentación permite determinar cuales serán las unidades lógicas de
distribución. Las tuplas y atributos de la relación por si mismos, no podrán ser
considerados como unidades lógicas de distribución. El diseño de los fragmentos
consiste en agrupar tuplas y atributos que tengan las mismas propiedades lógicas.
Existen dos tipos básicos de fragmentación, la horizontal y la vertical, existe un
tercer método de fragmentación, el cual es la combinación de los dos anteriores.
La fragmentación horizontal consiste en dividir las tuplas de la relación global en
subconjuntos de tuplas, donde cada subconjunto puede contener datos con
propiedades geográficamente comunes. La fragmentación se realiza, por lo general
por medios de una operación select, mientras que la reconstrucción de la relación
global siempre se llevara a cabo por medio de una operación de union. Existe un
subtipo de fragmentación horizontal conocida como fragmentación horizontal derivada,
esta consiste en la fragmentación de una relación que no se puede basar en sus
propios atributos, pero se deriva de la fragmentación de otra relación.
57
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
La fragmentación vertical de una relación global es la subdivisión de sus atributos
en grupos; la fragmentación se obtiene al proyectar la relación global sobre cada
grupo. La reconstrucción de la relación global se obtiene por medio de la operación
join.
El tercer tipo de fragmentación es la mixta, esta es obtenida por medio de
operaciones de fragmentación realizadas de manera recursiva, y la reconstrucción se
realizaría aplicando las operaciones respectivas en orden inverso de acuerdo a la
fragmentación.
Después de que se ha realizado la fragmentación de los datos, es necesario
analizar la forma en como se distribuirán dichos fragmentos, la manera más fácil de
realizar esta operación seria considerar cada fragmento como archivos separados,
pero este enfoque no es conveniente, por las siguientes razones:
1. Los fragmentos no son modelados propiamente como archivos individuales.
2. Habría más fragmentos que relaciones globales, y seria difícil procesar la
solución del problema al involucrar demasiadas variables.
3. El modelado del comportamiento de las aplicaciones en sistemas de archivos
difiere en demasía con relación a las aplicaciones de bases de datos.
En la distribución de los fragmentos es importante decidir si se va diseñar una
distribución redundante o no redundante. La replicación introduce una amplia
complejidad en el diseño, porque:
1. El grado de replicación de cada fragmento llega a ser una variable del
problema.
2. El diseño de los módulos de lectura de las aplicaciones es complicado por el
hecho de que las aplicaciones deben de seleccionar entre varios sitios para el
acceso del mismo fragmento.
Existen dos métodos para determinar la redundancia en la distribución de
fragmentos:
58
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Determinar el conjunto de todos los sitios donde el beneficio de colocar una
copia del fragmento es mayor que el costo, y colocar un fragmento en cada
uno de los sitios de este conjunto.
Determinar primero la solución sin replica del problema, y posteriormente
introducir replicas iniciando por las más benéficas; este proceso termina
cuando una replica no es benéfica.
En el análisis del procesamiento de consultas distribuidas, existe una herramienta
muy útil llamada árbol de operadores, este árbol representa la secuencia en que se
realizan las operaciones de una consulta, en este árbol, las hojas son las relaciones
globales y cada nodo representa una operación binaria o unitaria. Un árbol define un
orden parcial en como las operaciones se deben de aplicar para obtener el resultado
deseado en la consulta, esto es de abajo hacia arriba.
2.5 Preguntas de repaso
1.- ¿Cuales son los cuatro pasos en el diseño de una base de datos distribuida?2.- Mencione y describa los objetivos del diseño de datos distribuidos.3.- ¿Cuándo es conveniente utilizar la técnica bottom-up para diseñar una base de
datos distribuida?4.- Explique brevemente en que consiste cada uno de los tipos de fragmentación
que existen.5.- ¿Que representa y que partes conforman a un árbol de operadores?
2.6 Ejercicios
1.- Usando la tabla de clientes, realizar una fragmentación horizontal, si las aplicaciones son las siguientes:
q1: Obtener los nombres de todos los clientes.q2: Obtener el número del cliente por estado.q3: Obtener el nombre del cliente por empresa.
No_cli Nom_cli Empresa EstadoC01 Juárez Gamesa GtoC02 Vidal Lara QroC03 Ávila Gamesa Jal
59
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
C04 Mejía Lara JalC05 Herrera Lara GtoC06 Cervantes Gamesa Qro
2.- Fragmentar horizontalmente la siguiente base de datos.Clientes Productos
No_cli Nom_cli Edo No_p Nom_p PrecioC01 Ávila Gto P1 Lápiz 1.20C02 Soria Gto P2 Libreta 3.50C03 Avalos Qro P3 Lapicero 3.20C04 Medina Mich P4 Borrador 1.50C05 Trajo P5 Escuadra 3.10C06 Ávila Qro P6 Plumones 15.20
Compras
No_cli Nom_cli CantC02 Pl 2C01 P3 1C02 P4 2C01 P5 2C03 P1 2C03 P5 3
q1: Obtener el número del cliente por estado.q2: Obtener el número y nombre de los clientes del estado de Jalisco.q3: Obtener el estado de los clientes cuyo nombre sea Ávila,
3.- Usando la tabla de dientes, realizar una fragmentación vertical, si las aplicaciones son las siguientes:
q1: Obtener los nombres de todos los clientes.q2: Obtener el número y nombre de los clientes por estado.q3: Obtener el nombre de los clientes por empresa.
Matriz de accesos
S1 S2
q1 3 2
q2 2 1
q3 1 1
4.- Fragmentar verticalmente la siguiente tabla
A1 A2 A3 A4 A5 A6 A7 A8
No_al Nom_al Edad Dir Ciudad Sem Esp PromAL1 Aguilar 19 Rev. 115 Celaya 3 Química 85.7
60
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
AL2 Jiménez 18 Hgo. 120 Irapuato 1 Electrónica 83.2AL3 Trejo 18 Rev. 315 Celaya 1 Sistemas 75.2AL4 Soria 20 Hgo. 422 León 4 Química 89.7
q1: Obtener el número de alumno por especialidad.q2: Obtener número y nombre del alumno por ciudad.q3: Obtener el nombre y edad por promedio.q4: Obtener el número y semestre del alumno por dirección.
Matriz de accesos.
S1 S2 S3
q1 3 1 1
q2 2 0 1
q3 2 1 2
q4 3 5 1
Bibliografía
[1] Ceri, Stefano. Pelaggati, Giuseppe; 'Distributed Databases Principles and
systems'; lntemational Edition; MeGraw-Hill; U.S.A.; 1985
[2] Date, C,J.; "An Introduction to Databases Systems"; Volume 1; Fifth Edition;
Addison-Wesley Publishing Company; U.S.A.; Reprinted July, 1990
[3] Date, C.J.; "An lntroduction to Databases Systems"; Volume li; Addison-Wesley
Publishing Company; U.S.A.; Reprinted July, 1995
61
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Objetivo
El alumno comprenderá el concepto optimización de consultas distribuidas y
entenderá las técnicas para la ejecución de la operación join.
Introducción
En este capítulo se analizará el hecho de que aún cuando se cuente con una buena
estrategia de fragmentación o un buen procesamiento de consultas, no implica que se
tenga un funcionamiento correcto del sistema. Además se tratara el concepto de
62
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Capítulo III
Optimización de estrategias de accesos
optimización de consultas, lo cual implica reducidas a una forma equivalente más
pequeña y fácil de manejar para el sistema, esto es, a su forma canónica. También se
analizaran los diferentes métodos de ejecución de la operación Join.
3.1 Importancia de la optimización de consultas
El término “optimización” es algo inapropiado, puesto que las' técnicas para
optimizar la ejecución de una consulta generalmente no lo logran y únicamente se
obtienen estrategias para un "buen” acceso. Por eso, al referirse a este hecho como
optimización se debe de ser muy cuidadoso.
El desarrollo de una estrategia "buena" en el procesamiento de una consulta es
necesaria en un ambiente distribuido, pero también pueden existir estrategias para el
procesamiento de consultas "muy malas', las cuales se deben evitar. De esta manera,
la eficiencia del sistema final depende en mucho de la calidad del optimizador de
consultas, de la ausencia de un optimizador, y en la habilidad del programador de las
aplicaciones.
Puntos para estrategia de consultas.
1. La selección de estrategias alternativas para la ejecución de las consultas, tanto
en ambientes centralizados como distribuidos, es hecha de acuerdo al
desempeño requerido.
2. Las medidas típicas asumidas en un sistema centralizado de bases de datos son
el número de operaciones I/O y el tiempo de uso del CPU requerido para realizar
las consultas.
3. En bases de datos distribuidas de debe considerar además, el costo de la
transmisión de datos entre los sitios participantes de la consulta. No obstante,
no existe ningún convenio en la importancia relativa del costo de transmisión
contra I/O local. A pesar de esto, se deberá de encontrar la sentencia que
minimice el costo de transmisión, lo cual es nuestra meta más importante.
La selección de una estrategia de procesamiento de consultas involucro:
1 . Determinar las copias físicas de los fragmentos sobre los cuales se ejecutará la
consulta, obteniendo una expresión de consulta sobre fragmentos..
63
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
2. Seleccionar el orden de ejecución de las operaciones; como se puede ver, esto
involucro la determinación de una buena secuencia de operaciones join, semi-
join y unión.
3. Seleccionar el método para la ejecución de cada operación; esto involucro el
cambio de ejecución de algunas operaciones algebraicas.
Los problemas anteriores no son independientes, por ejemplo, la elección de la
mejor materialización para una consulta depende del orden en el cual son ejecutadas
las operaciones; por lo tanto, utilizar procedimientos para resolverlos de manera
independiente produciría errores. No obstante, una manera fácil de obtener métodos
de optimización consiste exactamente en considerar estos problemas como
independientes; de esta manera:
1. Una consulta dada se ejecuta sobre una sola copia no redundante de la base de
datos distribuida.
2. El orden de ejecución de las operaciones es óptima.
3. Las operaciones son agrupadas en los programas locales.
En la práctica, el primer problema no es tomado en cuenta, el tercer problema es
despreciable; por lo tanto solo se hace énfasis en el segundo problema.
3.2 Transformaciones equivalentes
Una consulta relacional puede expresarse utilizando diferentes lenguajes, para fines
de estudio, se utilizará álgebra relacionar y SQL, esto debido a que es posible
transformar una consulta SQL en expresiones equivalentes de álgebra relacional y
viceversa. Además, no solo se pude interpretar una expresión de álgebra relacional
por sus especificaciones semánticas de una consulta, sino que además se deberá de
tomar en cuanta la secuencia de las operaciones. Desde este punto de vista, dos
expresiones con la misma semántica pueden describirse por medio de dos secuencias
de operaciones diferentes. Por ejemplo, considérese la siguiente relación:
Emp(Cvemp, Nom, Sal, Imp, Depto)
64
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Cvemp Nom Sal Imp Depto
E12 Juan Pérez 4500 15 15
E56 José Hernández 8756 15 9
E78 Luis Pérez 9254 15 17
E98 Maria Solís 12345 25 22
E32 John Smith 25489 25 22
E91 Roció Sánchez 4600 15 8
E73 Carmen Campos 8753 15 15
Se tiene las siguientes consultas:
Select Nom, Depto
From Emp
Where Depto = 15
PJ Nom, depto SL depto=15 Emp
Nom Depto
Juan Pérez 15
Carmen Campos 15
y
SL depto = 15 PJ Nom, depto Emp
Nom Depto
Juan Pérez 15
Carmen Campos 15
65
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Son dos expresiones equivalentes, las cuales arrojan el mismo resultado, pero
definidas por dos secuencias de operadores diferentes.
Transformaciones equivalentes por álgebra relacional
Dos relaciones son equivalentes cuando sus tuplas representan el mismo mapeo
de los atributos a los valores, incluso si el orden de los atributos es diferente.
Considérense dos expresiones E1 y E2 de álgebra relacional, la equivalencia de dos
expresiones se representa E1 ↔ E2.
Se podrán obtener transformaciones equivalentes sistemáticamente más pequeñas,
es decir expresiones de dos o tres operadores relacionases. Estas transformaciones
son clasificadas en categorías de acuerdo a las operaciones que involucro. Sean U y
B operaciones unitarias y binaria respectivamente, R y S relaciones, entonces se
tienen las siguientes propiedades:
Conmutatividad de operaciones unitarias:
U1 U2 R ↔ U2 U1 R
Conmutatividad de operaciones binarias:
Una operación binaria es conmutativa cuando el resultado de la operación es el
mismo, cualquiera que sea el orden de los elementos con los que se opera.
R B S ↔ S B R
Asociatividad de operaciones binarias:
Propiedad asociatividad: para cualesquiera elementos del conjunto A no importa
el orden en que se operen las parejas de elementos, mientras no se cambie el
orden de los elementos siempre dará el mismo resultado
R B (S B T) ↔ (R B S) B T
Idempotencia de operaciones unitarias:
66
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
El término idempotente se usa para describir una operación que produce los mismos resultados si se ejecuta una o varias veces. Ésta es una propiedad muy útil en numerosas situaciones, ya que su empleo hace que una operación pueda ser repetida tantas veces como sea necesario sin causar efectos involuntarios. Con operaciones no idempotentes, el algoritmo podría tener que mantener un registro de si la operación ya hubo sido realizada o no.
Estrictamente, una secuencia que nunca produce efectos secundarios puede ser considerada idempotente (siempre y cuando no haya operaciones concurrentes sobre el mismo conjunto de recursos)1
UN EJEMPLO DE IDEMPOTENCIA ES LA MULTIPLICACION DE 1*1 = 1 o de 0*0 = 0 ASI COMO TAMBIEN LA MULTIPLICACION DE 1*1*1*1*1*1*1*1*1 = 1
U R ↔U1 U2 R
Distributividad de operaciones unitarias con respecto a operaciones binarias:
U ( R B S) → U ( R ) B U (S)
Factorización de operaciones unitarias:
U(R)BU(S) →U(RBS)
Las siguientes son propiedades que también pueden ser aplicadas dentro de la
transformación de expresiones:
R NJN R ↔ R
R UN R ↔ R
R DF R ↔ 0
R NJN SLF R ↔ SLF R
R UN SLF R ↔ R
R DF SLF R ↔ SLNOT F R
(SLF1 R) NJN (SLF2 R) ↔ SL F1 AND F2 R
(SLF1 R) UN (SLF2 R) ↔SL F1 OR F2 R
67
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
(SLF1, R) DF (SLF2 R) <-> SL F1 AND NOT F2 R
3.2.2 Determinación de subexpresiones comunes
Una parte importante en la transformación de expresiones equivalentes es el
descubrir las subexpresiones comunes; las cuales aparecen en más de una vez en la
consulta, esto es importante, ya que de esta manera solo se evaluara una sola vez
dicha expresión. Una forma de reconocer la existencia de dichas expresiones, consiste
en transformar la consulta en su correspondiente árbol de operadores. De esta
manera es posible localizar las subexpresiónes iguales, las cuales utilizan las mismas
operaciones y operandos, enseguida se unen tanto los nodos y las hojas en una sola
hoja o nodo.
En el siguiente ejemplo se ilustrara este método. Considérese las siguientes tablas
de una base de datos:
EMP(id-emp, nom, sal, deptnum, edad)
DEPT(deptnum, descr, gtenum)
Se requieren los nombres de los empleados que trabajan en cierto departamento y
cuyo gerente tiene el número de 373 pero que no ganan más de $35,000. Una
expresión para dicha consulta seria:
Select A.nom
From A EMP inner JOIN B DEPT in (A.deptnum = B.deptnum)
Where B.gtenum = ‘373’ < 35001
PJEMP.Nom((EMP JN DEPTNUM = DEPTNUM SL GTENUM=373 DEPT) DF
(SL SAL>35000 EMP JN DEPTNUM=DEPTNUM SL GTENUM=373 DEPT))
68
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
A simple vista se puede deducir que existe una subexpresión repetida en la
consulta, esta es:
EMP JN DEPTNUM=DEPTNUM SL GTENUM=373 DEPT
Pero véase el árbol de operadores:
PJ EMP_NOM
DF
JNDEPTNUM=DEPTNUM JN DEPTNUM=DEPTNUM
EMP SLGETNUM=373 SLSAL>35000 SLGETNUM=373
DEPT EMP DEPT
Se comienza factorizando el select sobre SAL con respecto al join (al hacer esto, el
select es desplazado hacia arriba).
PJ EMP_NOM
DF
JNDEPTNUM=DEPTNUM SL SAL>35000
EMP SLGETNUM=373 JNDEPTNUM=DEPTNUM
DEPT EMP SLGETNUM=373
DEPT
69
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
A continuación se unen los nodos correspondientes al select sobre GTENUM, el
nodo correspondiente al join y finalmente, uniendo las hojas correspondientes a las
relaciones de EMP y DEPT. El resultado de esto seria un árbol de operadores
simplificado como se muestra a continuación:
PJEMP-NOM
EMP SLGTENUM=373
DEPT
3.3 Métodos de ejecución de JOIN
En la ejecución de una operación join, se debe de considerar el costo de
procesamiento. En este punto influyen varios factores que se deben de tomar en
cuenta, para lograr la elección de la estrategia correcta, dichos factores son:
El orden físico de las tuplas en la relación.
La presencia de índices y el tipo de estos.
El costo de creación de un índice temporal para el procesamiento de una
consulta
Para el resto de la sección se considerará la siguiente expresión:
deposito JN cliente
Y se asumirá que la relación depósito cuenta con 10,000 tuplas y clientes consta de
200 clientes.
70
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
SLSAL>35000
DF
JNDEPTNUM=DEPTNUM
Métodos de ejecución del Join Existen diferentes algoritmos que pueden obtener transformaciones eficientes en el procesamiento de consultas. Join en bucles (ciclos) anidados Join en bucles anidados por bloques Join por mezcla Join por asociación. Join por asociación híbrida Join Complejos Outer Join (Join externos)
3.3.1 Iteración simple (Join en bucles (ciclos) anidados)
Supóngase que no se cuentan con índices, y que es necesario examinar todos los
pares posibles de tuplas td en depositas y tc en cliente. De esta manera, se
examinarla 10000 * 200 = 2000000 pares de tuplas.
Si se ejecutará esta consulta de una manera más optima, se reduciría
significativamente el número de bloques accesados ( considérese un bloque como un
conjunto físico de tuplas ). Supóngase que se utiliza el siguiente procedimiento para
procesar el join. En él se lee cada tupla de la relación deposito, esto requeriría accesar
10000 bloques de almacenamiento físico bajo el peor de los casos, considerando que
cada una de las tuplas de la relación deposito se encuentran en bloques diferentes. Si
se consideran que 20 tuplas de la relación deposito se encuentran almacenadas en un
bloque, entonces se tendrán 10000120 = 500 bloques distintos accesados.
for each tupla d in deposito do
begin
for each tupla c in cliente do
begin
compara el par (d, c) para ver si alguna tupla es agregada
al resultado final
end
end
71
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Si se compara cada tupla de clientes con cada una de las tuplas de la relación
deposito, esto llevará a hacer 10,000 referencias a cada tupla de clientes. El número
exacto de accesos a disco depende del tamaño del buffer y de otros factores. En el
peor de los casos cada consulta requerirá de un acceso a disco. Puesto que se tienen
200 tuplas en la relación de clientes, se tendrán que hacer 2,000,000 lecturas a la
relación de clientes. Si se asume que 20 tuplas de la relación clientes son
almacenadas en un bloque, entonces se requieren de 10 accesos para leer la relación
completa, Por lo tanto, solo se requieren 10 accesos en lugar de 200. Esto implica que
se accesarán 100,000 bloques de la tupla clientes para procesar la consulta.
El costo de esta técnica es de 500 accesos a depósitos más 100,000 accesos a
clientes para un total de 100,500 bloques accesados.
3.3.2 Iteración orientada a bloques
Se obtiene un mayor ahorro en el acceso si se procesa la relación en base a un
proceso por bloques en vez de un proceso basado en tuplas. Nuevamente, se asume
que las tuplas de la relación depósitos y de la relación clientes son almacenadas de
manera continua también, Se usará el procedimiento siguiente para procesar depósitos
JN clientes.
For each bloque Bd of deposito do
begin
for each bloque Be of dientes do
begin
for each tupla d in Bd do
begin
for cach tupla e in Be do begin
compara el par (d,c) para ver sí una tupla
puede ser tomada para el resultado
end
end
end
end.
72
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Este procedimiento desarrolla el join considerando un bloque entero de tuplas de la
relación deposito en vez de una tupla individual- Aún, se leerá completa la relación
deposito a un costo de 500 accesos. Sin embargo, en lugar de realizar una lectura a la
relación cliente por cada tupla de la relación depósito, se leerá la relación cliente por
cada bloque de la relación depósito. Entonces, se tienen 500 bloques de la relación
deposito y 10 bloques de la relación diente, requieren 10*500= 5000 bloques
accesados. De esta manera, el costo en términos de bloques accesados es de 5500
accesos (5000 accesos a clientes más 500 accesos a depósitos). Claramente se
puede ver un significativo ahorro en el número de accesos necesarios en comparación
con la técnica anterior.
3.3.3 Merge - Join
En aquellos casos en los cuales ninguna relación se encuentra en la memoria
principal, es posible realizar un join eficientemente si ambas relaciones se encuentran
almacenadas en orden de acuerdo a un atributo por medio del cual se realizara el join.
Supóngase que ambas relaciones, clientes y depósitos, están ordenados por
nombre-cliente. Se podrá entonces realizar una operación merge-join.
Para ejecutar un merge-join, se requiere de un punto de asociación en cada
relación, Estos puntos son direccionados a la primera tupla de cada relación. Los
punteros son movidos a lo largo de la relación y si un grupo de tuplas de la relación
contiene el mismo valor que el atributo del join, se leen dichas tuplas, puesto que las
tuplas están ordenadas, el conjunto de tuplas con el mismo valor estarán consecutivas.
Esto permite leer cada tupla una sola vez y en el caso de que las tuplas estén
almacenadas de manera ordenada, entonces se leerá cada bloque exactamente una
vez.
A continuación se muestra el esquema del merge-join aplicado al ejemplo de
deposito JN cliente.
73
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Pd := dirección de la primera tupla de deposito;
Pc:= dirección de la primera tupla de clientes;
while (pc ≠ null) do
begin
tc:= tupla a la cual pc apunta;
sc {tc}
mueve pc a la siguiente tupla en cliente;
done := falso;
while (not done and pc ≠ nuil ) do
begin
tc' := tupla a la cual pc apunta;
if tc[nombre-Cliente] = tc'[nombre-Cliente]
then begin si := se u {tc'};
mover pc a la siguiente tupla de cliente;
end
else done:= verdad;
end
td := tupla a la cual pd apunta;
mueve pd a la siguiente tupla;
while ( td[nombre-Cliente] < tc[nombre-Cliente]) do
begin
td := tupla a la cual pd apunta;
mueve pd a la siguiente tupla de deposito;
end
while (td[nombre-Clientel = tc[nombre-Cliente]) do
begin
for each t in sc do
begin
ejecuta t JN td y agrega esto al resultado final;
end
mueve pd a la siguiente tupla de deposito;
td := tupla a la cual pd apunta; end
end.
74
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Una desventaja de este método es que ambas relaciones deben de estar ordenadas
físicamente, es decir en el medio de almacenamientos.
3.3.4 Uso de índices
Las tres estrategias que se han considerando dependen de la técnica usada para
almacenar físicamente las relaciones. El merge-join requiere de un almacenamiento
en orden. La iteración orientada a bloques requiere que las tuplas de cada relación
estén ordenadas físicamente. Únicamente la iteración simple, puede ser aplicada sin
importar la forma en como están almacenadas las tuplas de las relaciones. El costo de
la iteración simple para el ejemplo deposito JN diente es de 2 millones de accesos a
bloques. Cuando se utiliza un índice, sin importar la manera en como fueron
almacenadas físicamente las tuplas de las relaciones, el join puede ser ejecutado con
una reducción de accesos significativa.
Frecuentemente los atributos del join forman parte de la llave del índice de una
relación. En estos casos se puede considerar una estrategia de join que utiliza estos
índices. La iteración simple puede ser más eficiente si existe un índice en la relación
cliente para el atributo nombre ~ cliente. Cuando se tiene una tupla d de la relación
deposito no es necesario recorrer la relación clientes completa. El índice es usado
para buscar las tuplas en clientes para los cuales el nombre-cliente sea igual a
d[nombre-cliente].
Se requieren 10000 accesos para leer la relación depósito. Si se asume que la
relación clientes tiene 200 tuplas, y que se almacenan 20 apuntadores por bloque,
entonces, se requieren en promedio 2 accesos a bloques más un bloque accesado
para leer la relación cliente. Con esto, son necesarios 3 accesos a bloques en la
relación deposito en lugar de 200. Entonces, si por cada tupla de la relación depósito
son necesarios 3 accesos a bloques darían como resultado un total de 30000 accesos,
más los 10000 de la relación depósito.
Aunque un costo de 40000 accesos pareciera alto, se debe tomar en cuenta que se
obtendría un mejor resultado solo si las tuplas están ordenadas físicamente, También
se debe recordar que inicialmente, esta estrategia, tiene un costo de 2 millones de
accesos a bloques.
75
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Entonces el hecho de obtener un ahorro tan alto de accesos es suficiente para
justificar la creación de índices.
3.3.5 Hash join
La construcción de un índice para la ejecución de un join, convendría, si este índice
es un árbol B+. Dicho índice sera usado una sola vez para la ejecución de un simple
join.
Una función hash h es usada sobre las tuplas de ambas relaciones sobre los
atributos básicos del join. Si d es una tupla de la relación deposito y en c es una tupla
de la relación clientes entonces d y c serán comparados solo si h(c) = h(d). Si h( c ) ≠
h( d ) , entonces d y c tendrán valores diferentes para nombre-cliente. Sin embargo es
posible que d y c tengan valores diferentes para nombre-cliente a pesar de que sus
valores en la función hash sean iguales.
A continuación se muestra el algoritmo usado para el hash join que se aplicara en el
ejemplo deposito JN cliente.
for each tupla c in cliente do
begin
i := h(c[nombre-Cliente]);
Hci := Hci u {apuntador a c},
end
for each tupla d in deposito do
begin
i := h(d[nombre-cliente]);
Hdi := Hdi @ {apuntador a d};
end
for i := 0 to max do
begin
76
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
rc:= 0;
rd:= 0;
for each apuntador pc in Hci do
begin
c:= tupla a la cual apunta pc;
rc:= rc u {c ç;
end
for each apuntador pd in Hdi do
begin
d:= tupla a la cual apunta pd;
rd := rd u {d};
end
for each tupla d in rd do
begin
for each tupla c in rc do
begin
compara el par (d,c) para ver si una tupla puede ser agregada al resultado
end
end
end
En el algoritmo anterior, se asume que:
h es una función hash que mapea valores de nombre-cliente con {0,1,2,...,max)
77
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Hc0, Hc1, ... , Hcmax denotan el contenedor del apuntador a las tuplas de la
relación diente, cada uno vacío al inicio.
Hd0, Hd1, ... , Hdmax denotan el contenedor del apuntador a las tuplas de la
relación deposito, cada uno vacío al inicio.
Se usarán estas propiedades para estimar el costo del desempeño de un hash join.
La asignación de apuntadores a los contenedores hash en los primeros dos ciclos
for del algoritmo generan una lectura completa de ambas relaciones.
El costo de esta operación es de 510 accesos a bloques si las tuplas de ambas
relaciones, clientes y deposito, son almacenadas de forma continua físicamente.
Desde el momento en que los contenedores almacenan solo apuntadores se asumirá
que se encuentran en la memoria principal, y por lo tanto no es necesario ningún
acceso a disco para leer dichos contenedores.
En la parte final del algoritmo se itera sobre el rango de h. Donde i es un valor del
rango de h. El ciclo for final ejecuta:
rd JN rc
Donde el conjunto rd es el conjunto de las tuplas de la relación deposito en el
contenedor i y rc es el conjunto de tuplas de la relación clientes localizadas en el
contenedor i. Este join es procesado utilizando una iteración simple, ya que rd y rc son
lo suficientemente pequeños, ambos pueden estar en la memoria principal. Desde el
momento que se aplico una función hash a una tupla y esta se coloco en un
contenedor, cada tupla es leída una sola vez por el for final en el algoritmo.
Cabe hacer notar que lo anterior requiere 510 accesos a bloques inicialmente. Así,
el costo total estimado de un hash join es de 1020 accesos, se requiere una lectura
para la función hash, y una segunda lectura dentro de los contenedores. Es necesario
78
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
elegir una función hash cuyo rango sea lo suficientemente extenso para que cada
contenedor almacene la menor cantidad de apuntadores posible.
3.3.6 Tree - way join
Ahora supóngase que un join envuelve tres relaciones:
sucursal JN deposito JN cliente
Se asume que ndd. = 10000, n,ii,,t, = 200 y n....., = 50. No solo se tiene que
considerar la estrategia para procesar el join; sino que ahora se debe ver cual se
realizara primero- Hay varias estrategias posibles a utilizar.
Estrategia 1: Se procesa el join deposito JN cliente usando alguna de las
técnicas antes mencionadas. Considerando que nombre - cliente es la
llave para la relación clientes. Es posible saber que el resultado de este
join, tiene a lo más 10000 tuplas ( número de tuplas en la relación
deposito). Si es posible construir un índice para sucursal sobre el atributo
nombre-sucursal, se podría procesar lo siguiente:
sucursal JN (deposito JN cliente)
Considerando que nombre - sucursal es la llave para sucursal es posible
saber que se examinarán únicamente una tupla de la relación sucursal
para cada una de las 10000 tuplas de la operación deposito JN cliente. El
número exacto de bloques accesados en esta estrategia depende de la
manera en que la operación deposito JN cliente es ejecutada, y la forma
en que la relación sucursal es almacenada físicamente.
79
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Estrategia 2: Es posible ejecutar el join con las tres relaciones sin utilizar índices. Esto
requerirá el acceso de 50 * 10000 * 200 posibilidades, es decir un total de
10000000.
Estrategia 3: En lugar de procesar dos joins, es posible hacer el proceso de un par de
joins en uno solo. La técnica primero requiere la construcción de dos
índices:
En sucursal con nombre-sucursal.
En cliente con nombre-cliente.
A continuación se considera para cada tupla t en la relación deposito,
las correspondientes tuplas dentro de las relaciones clientes y sucursal.
Así, se examinará por cada tupla en deposito - una sola en las otras
dos relaciones.
La estrategia 3 presenta una forma de realizar una operación que no tiene una
correspondencia directa dentro del álgebra relacionar. En cambio, combina 2
operaciones dentro de una operación especial. El costo relativo depende de la forma
en como las relaciones son almacenadas físicamente.
3.3.7 Estrategias para procesamiento paralelo
Las estrategias antes consideradas asumen que un solo procesador esta disponible
para procesar un join. Ahora se vera el caso donde varios procesadores están
disponibles para el procesamiento paralelo de un join.
80
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Antes que nada se debe considerar que:
Todos los procesadores tienen acceso a todos los discos.
Todos los procesadores comparten la memoria principal.
Las técnicas que se presentarán a continuación pueden ser adaptadas en otras
arquitecturas en las cuales cada procesador tiene su propia memoria privada.
3.3.8 Join paralelo
En las técnicas antes mencionadas para el procesamiento de un join en un
procesador solo, la eficiencia se logra reduciendo el número de pares de tuplas que
son comparadas. La meta de un algoritmo de join paralelo es dividir los pares de
tuplas entre varios procesadores. Cada procesador entonces ejecuta una parte del
join. En un paso final, el resultado individual de cada procesador es recolectado para
producir el resultado final.
Idealmente, el trabajo global para procesar el join es dividido equivalente sobre
todos los procesadores. Esto sin que ningún procesador caiga en un overhead. Un
join paralelo que utiliza N procesadores, tomará 1/N del tiempo que se tardaría en
ejecutar el mismo join en un solo procesador. En la practica la velocidad es más
dramática por varias razones:
Un overhead ocurre en la partición del trabajo entre procesadores.
Un overhead ocurre en la recolección de los resultados arrojados por cada uno
de los procesadores, para producir el resultado final.
El esfuerzo hecho para dividir el trabajo equitativamente es una aproximación,
ya que algunos procesadores, tienen más trabajo que otros. El resultado final
obtenido hasta que el último procesador haya terminado.
El procesador tal vez tenga que competir por recursos compartidos del sistema.
El resultado se retrasa debido a que un procesador espera a que otro
procesador libere los recursos.
Considerando nuevamente el ejemplo deposito JN cliente, se asume que se tiene N
procesadores P1, P2, ..., PN. Se divide la relación de deposito en N partes de igual
81
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
tamaño; deposito1, deposito2, ..., depositoN Se supone, por facilidad, que el tamaño de
la relación deposito es múltiplo de N, entonces cada procesador P i procesa depositoi
JN cliente en paralelo. En el paso final, se realizara la unión de los resultados
parciales obtenidos por cada procesador.
El costo de esta estrategia depende de vados factores:
La selección del algoritmo usado para cada procesador.
El costo de la construcción del resultado final.
El retraso generado por la retención de recursos. Aunque cada procesador
accesa su propia partición de la relación deposito, todos los procesadores
accesan a la relación cliente. Si la memoria principal no es suficientemente
grande para almacenar la relación cliente, el procesador necesita sincronizar
sus accesos a la relación cliente con otros procesadores para reducir el número
de accesos a disco.
Se sugiere que se utilice alguna técnica para realizar la división del trabajo entre
procesadores para reducir el espacio utilizado de memoria. Una técnica simple es la
de utilizar una versión de hash-join para trabajar en paralelo. En donde se escogerá
una función hash cuyo rango sea { 1, 2, ..., N }. Esto daría como resultado, que cada
procesados trabaje con exactamente un contenedor hash.
3.3.9 Pipeline multiway join
Existe la posibilidad del procesamiento de varios joins en paralelo. Esto es un uso
importante en algunos queries que se realizan en el mundo real, particularmente
cuando se tienen vistas, que involucran a varias relaciones.
Considere el siguiente join entre cuatro relaciones:
r1 JN r2 JN r3 JN r4
Es posible ejecutar t1 (r1 JN r2) en paralelo con t2 (r3 JN r4) y cuando este proceso
termine se ejecutará:
t1 JN t2
82
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Se puede lograr un alto grado de paralelismo si se tiene un "pipeline" que permita a
los tres join ejecutarse en paralelo. Se asigna al procesador P1 la ejecución de r1 JN r2
y al procesador P2 se asigna r3 JN r4.
Como las tuplas resultantes del proceso de P1 están disponibles para P3 , así como
las tuplas resultantes del procesador P2 , entonces P3 podrá comenzar el proceso ( r1
JN r2) JN (r3 JN r4 ) antes de que r1 JN r2 y r3 JN r4 hallan terminado.
A continuación se muestra el algoritmo utilizado por el procesador P3 para procesar
el join. Las tuplas resultantes de P1 y P2 son colocadas en una cola para ser
procesados por P3, P1 y P2 pueden haber utilizado cualquier técnica para el
procesamiento del join. La única modificación sería que cuando una tupla t es
adicionada al resultado, debe de colocarse como disponible para P3 en la cola. Se
deberá considerar también, entradas especiales en la cola que consisten ENDP1 y
ENDP2, que indican la finalización del procesamiento del join en los procesadores P1 y
P2 respectivamente. Para ejemplo se utilizo un 4-way join pero pude extenderse para
procesar N-way join.
83
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
r1
r2
r3
r4
P1
P3
P2
done1:= falso;
done2:= falso;
from1:= 0;
from2:= 0;
result := 0 ;
while not donel or not done2 do
begin
if la cola esta vacía then esperar hasta que no este vacía;
t:= primer elemento de la cola;
if t = ENDP1 then donel := verdadero
else if t = ENDP2 then done2:= verdadero
else if t proviene de Pl then
begin
from1:= from1 {t};
result:= result ({t} JN from2);
end
else /* t proviene de P2 */
begin
from2 := from2 {t};
result := result (from1 JN {t});
end
end
3.4 Principios de optimización
Se pueden identificar cuatro pasos generales para el proceso de optimización de
una consulta.
84
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
1.- Convertir la consulta en alguna representación interna.
El primer paso en el proceso de una consulta es convertirla en alguna
representación interna que sea más apropiada para la manipulación de la
computadora, eliminando así, las consideraciones del nivel externo (tales como los
rasgos concretos de la sintaxis de un lenguaje de consulta), preparando así el
camino para los subsecuentes pasos de la optimización.
Se deberá hacer una elección de manera que se represente a la consulta por
medio del lenguaje que pueda manejar el sistema de manera que los pasos
subsecuentes no se vean afectados. Por ejemplo, se tiene la consulta "obtener los
nombre de los proveedores que surten la pieza P2', es posible representar esto en
un árbol de operadores:
PJPnombre
SLprovee.prod=’P2’
JN
Proveedor Provee
Esto da como resultado una expresión, dentro del álgebra relacional que se puede
manejar más fácilmente por el sistema:
PJ ( SL ( Proveedor JN Provee ) provee.prod=’P2’ ) nombre
2.- Convertir a forma canónica.
La definición de forma canónica es el punto central en muchas áreas de las
matemáticas y disciplinas relacionadas. Es posible definirla como sigue: Se tiene un
conjunto Q de objetos (Queries) y la definición de equivalencia entre ellos (dos queries
85
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
son equivalentes, si y solo si, producen el mismo resultado), se tiene también un
subconjunto C de Q, el cual se llama conjunto de formas canónicas de Q ( bajo la
definición de equivalencia ), si y solo si, algún objeto q en Q es equivalente a solo un
objeto c en C. El objeto c es llamado la forma canónica de q. Todas las propiedades
que se aplican a q se aplican a la forma canónica c; Así, es suficiente realizar el
estudio del pequeño conjunto de formas canónicas, y no del gran conjunto de Q.
Durante este paso, el optimizador ejecuta un número de transformaciones que son
"garantizadas para ser correctas', en relación con los datos actuales y las rutas de
acceso que existen en la base de datos. El punto es que la mayoría de los lenguajes
de consulta permiten que hasta la más simple consulta pueda ser expresada en una
variedad de formas distintas. Tan solo en SQL, la consulta de la sección anterior tiene
ocho posibles representaciones.
La obtención de expresiones equivalentes se logra por medio de reglas de
transformación bien definidas y permitidas dentro del álgebra relacionar.
3.- Elegir el procedimiento de bajo nivel.
Habiendo convertido la representación interna de la consulta en alguna forma más
deseable (forma canónica), se debe decidir como se evaluará la consulta, representada
por su forma canónica.
En este paso se debe considerar la existencia de índices, rutas de acceso,
distribución de los datos almacenados, almacenamiento físico de los registros, etc.
La estrategia básica es considerar la consulta como una serie de operaciones de
"bajo nivel" join, select, project, etc.), con cierta interdependencia entre ellos. Para
cada operación de bajo nivel, se tendrá un conjunto de procedimientos predefinidos;
Por ejemplo, un conjunto de procedimientos para la selección sería, un procedimiento
para cuando los campos están indexados, y otro para cuando no lo están, pero están
almacenados físicamente en orden, etc. Cada procedimiento tiene asociado un costo.
4.- Seleccionar el procedimiento más económico.
86
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
El paso final del proceso de optimización involucro la construcción de un conjunto
de planes de ejecución de consultas candidatas seguido de la elección del mejor (más
económico) de estos planes.
Cada plan es construido con la implementación de los procedimientos necesarios
para ejecutar la consulta. Será necesario un procedimiento por cada operación de bajo
nivel en la consulta. No es necesario construir todos los planes posibles, basta con
generar una cantidad razonable de procedimientos y realizar combinaciones entre ellos
y seleccionar el conjunto más económico para la ejecución de la consulta. La
asignación del costo a algún plan involucrará el número de accesos a disco, la
utilización del CPU, etc.
Dentro del costo de una consulta también deberá tomar en cuenta la transmisión de
los datos dentro del sistema en el cual se lleva a cabo dicha consulta. Es importante
recordar que dentro de un sistema de bases de datos distribuidas, la información se
encuentra dispersa dentro de varios servidores y es utilizada por muchos clientes, los
cuales pueden estar a corta distancia de los servidores o muy alejados de estos.
Cuando una consulta es lanzada en un sistema de bases de datos distribuidos, en ese
momento es posible saber que información se requiere y en que sitio se encuentra.
Entonces se debe decidir la forma en que se realizará el proceso de recolección de
datos. Es decir, la tabla es enviada íntegramente al sitio que lanzo la consulta o solo
los registros que cumplen con la condición, tal vez es necesario que otro sitio realice el
proceso de recolección de resultados parciales y solo se reciba el resultado final o si el
sitio que lanzo la consulta, realice el proceso integro, etc.
En un sistema distribuido de bases de datos, el costo más alto es el de la
comunicación, por ello es necesario utilizar estrategias para reducirlo. Como se vio en
el capítulo anterior (Ejemplos de consultas distribuidas), es necesario considerar, de
cierta forma, la capacidad de procesamiento de los equipos para decidir que equipo o
equipos realizaran los procesos más demandantes.
El problema de optimización de consultas es minimizar una función de costo tal que función de costo total = costo deI/O + costo de CPU + costo de comunicación.
87
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
3.5 Resumen
El desarrollo de una buena estrategia en el procesamiento de una consulta es
necesario en un ambiente distribuido, la eficiencia del sistema final depende mucho de
la calidad del optimizador de consultas. La selección de estrategias alternativas para la
ejecución de las consultas, tanto en ambientes centralizados como distribuidos, es
hecha de acuerdo al desempeño requerido. Las medidas típicas asumidas en un
sistema centralizado de bases de datos son el número de operaciones I/O y el tiempo
de uso del CPU requerido para realizar las consultas. En bases de datos distribuidas
88
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
se debe considerar además, el costo de la transmisión de datos entre los sitios
participantes de la consulta.
La selección de una estrategia de procesamiento de consultas involucro:
1. Determinar el número de copias de los fragmentos sobre los cuales se
ejecutara la consulta, obteniendo una expresión de consulta sobre
fragmentos.
2. Seleccionar el orden de ejecución de las operaciones.
3. Seleccionar el método para la ejecución de cada operación.
Una expresión de álgebra relacional no solo se expresa por medio de sus
especificaciones semánticas, sino también por medio de una secuencia de operadores,
y desde este punto de vista dos expresiones con la misma semántica se pueden
expresar por medio de dos secuencias de operadores diferente, esto conlleva a decir
que estas dos expresiones son equivalentes. Dos expresiones son equivalentes
cuando sus tuplas representan el mismo mapeo de los atributos a los valores, aun
cuando el orden de los atributos no sea el mismo. La equivalencia de dos expresiones
se representa por E1 ↔ E2.
Es posible obtener expresiones equivalentes pequeñas aplicando ciertas
propiedades de operadores y conjuntos de operadores. Sea U y B operaciones
unitaria y binaria respectivamente, R y S relaciones. Se tienen las siguientes
propiedades:
Conmutatividad de operaciones unitarias:
U1 U2 R ↔ U2 U1 R
Conmutatividad de operaciones binarias:
R B S ↔ S B R
Asociatividad de operaciones binarias:
R B (S B T) ↔ (R B S) B T
89
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Idempotencia de operaciones unitarias:
U R ↔ U1 U2 R
Distributividad de operaciones unitarias con respecto a operaciones binarias:
U(RBS) → U(R)BU(S)
Factorización de operaciones unitarias:
U ( R ) B U ( S U R B S
Las siguientes son propiedades que también pueden ser aplicadas dentro de la
transformación de expresiones:
R NJN R ↔ R
R UN R ↔ R
R DF R ↔ 0
R NJN SLF R ↔ SLF R
R UN SLF R ↔ R
R DF SLF R ↔ SLNOT F R
(SLF1 R) NJN (SLF2 R) ↔ SL F1 AND F2 R
(SLF1 R) UN (SLF2 R) ↔SL F1 OR F2 R
(SLF, R) DF (SLF2 R) <-> SL F1 AND NOT P2 R
Una parte importante en la transformación de expresiones equivalentes es el
descubrir subexpresiones comunes, las cuales podrían aparecer más de una vez en la
consulta, esto es importante, dado que, solo se tendrían que evaluar una sola vez,
ahorrando así, tiempo. Una manera de reconocer la existencia de dichas expresiones,
consiste en transformar la consulta en su correspondiente árbol de operadores, de esta
manera es posible localizar las subexpresiones iguales, que en este caso serían ramas
similares, las cuales se convertirán en una sola rama.
Algo que también se debe de considerar es el costo de procesamiento de las
operaciones join. En esta parte influyen varios factores, los cuales se deberán tomar
en cuenta:
90
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
El orden físico de las tuplas en la relación.
La presencia de índices y el tipo de los mismos.
El costo de procesamiento de un índice temporal para el procesamiento de una
consulta.
Dentro de las técnicas de ejecución de join se tiene las siguientes:
Iteración simple: Cada una de las tuplas de una relación es comparada con todas las
tuplas de la otra relación.
Iteración orientada a bloques: Se asume que las tuplas de la relación están
almacenadas en orden y de manera continua. Esta técnica leerá un bloque de tuplas
en lugar de una tupla individual, así se compara un bloque de una relación contra los
bloques de la otra relación.
Merge-join: Esta técnica requiere que las tuplas están almacenadas de forma ordenada
de acuerdo al atributo por el cual se va a realizar el join. Cada relación tendrá un
puntero que indica la posición de lectura para el join, al ir leyendo, dichos punteros
avanzarán. Al encontrarse la tupla que tiene el mismo valor que la tupla con la que se
esta ejecutando el join, el recorrido sobre la relación se detiene y el puntero se coloca
de nuevo en la primera posición, esto debido a que las tuplas están ordenadas y no
debe existir otro valor más allá de la posición del puntero. Se repetirá este proceso
hasta que se recorran todas las tuplas de la primera relación.
Hash-join: Una función hash h es usada sobre las tuplas de ambas relaciones
sobre los atributos básicos del join. Si d es una tupla de la relación deposito y en c es
una tupla de la relación clientes entonces d y c serán comparados solo sí h(c) = h(d). Si
h(c) ≠ h(d), entonces d y c tendrán valores diferentes para los atributos básicos del
join. Sin embargo es posible que d y c tengan valores diferentes para los atributos
básicos del join a pesar de que sus valores en la función hash sean iguales.
Three-way join: Si se tiene que un join envuelve tres relaciones, se podrían utilizar
algunas de las siguientes estrategias:
91
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
1 . Se procesa el join con cualquier técnica, si es posible se deberá construir un
índice sobre los atributos básicos del join, se procesarán primero un par de
relaciones y el resultado de este join se procesara con la tercer relación,
obteniendo así el resultado final.
2. Es posible ejecutar el join con las tres relaciones sin utilizar índices.
3. En lugar de procesar dos joins, es posible hacer el proceso de un par de joins
en uno solo.El resultado final será la combinación de los resultados de las
relaciones. Esto requerirá la utilización de índices.
Join paralelo: La meta de un algoritmo de join paralelo es la de dividir los pares de
tuplas entre varios procesadores. Cada procesador ejecutará una parte del join. En un
paso final, el resultado individual de cada procesador es recolectado para producir el
resultado final. El trabajo global para procesar el join será dividido lo más
equitativamente posible, tratando de que ningún procesador caiga en un overhead.
Pipeline multiway join: Existe la posibilidad de procesar varios joins en paralelo.
Considérese el siguiente join entre cuatro relaciones:
r1 JN r2 JN r3 JN r4
Es posible ejecutar t1 (r1 JN r2) en paralelo con t2 (r3 JN r4) y cuando este proceso
termine se ejecutará:
t1 JN t2
Se puede lograr un alto grado de paralelismo si se tiene un "pipeline" que permita a
los tres join ejecutarse en paralelo. Se asigna al procesador P1 la ejecución de r1 JN r2
y al procesador P2 se asigna r3 JN r4.
92
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Como las tuplas resultantes del proceso de P1 están disponibles para P3 , así como
las tuplas resultantes del procesador P2 , entonces P3 podrá comenzar el proceso (r1 JN
r2 ) JN (r3 JN r4 ) antes de que r1 JN r2 y r3 JN r4 hallan terminado. Las tuplas
resultantes de P1 Y P2 son colocadas en una cola para ser procesadas por P3 , para
obtener el resultado final.
Se tienen cuatro pasos generales en el proceso de optimización de una consulta:
1. Convertir la consulta en alguna representación interna: El primer paso en el
proceso de una consulta es convertirla en una representación interna que sea
más apropiada para la manipulación de la información, esto de manera que los
pasos subsecuentes no se vean afectados.
2. Convertir a una forma canónica: Se tiene un conjunto Q de objetos (Queries) y
la definición de equivalencia entre ellos (dos queries son equivalentes, si y
solo si, producen el mismo resultado), se tiene también un subconjunto C de
Q, el cual se llama conjunto de formas canónicas de Q (bajo la definición de
equivalencia), si y solo si, algún objeto q en Q es equivalente a solo un
objeto c en C. El objeto c es llamado la forma canónica de q. Lo importante
en este punto, es que, la mayoría de los lenguajes de consulta permiten
representar una consulta en varias formas distintas. Así, la obtención de
expresiones equivalentes se logra por medio de reglas de transformación
definidas y permitidas dentro del álgebra relacional.
3. Elegir el procedimiento de bajo nivel: Se deberá decidir como se evaluara la
consulta, representada por su forma canónica, aquí, la estrategia básica es
considerar la consulta como una serie de operaciones de bajo nivel, para
cada operación se tendrá un conjunto de procedimientos predefinidos.
4. Seleccionar el procedimiento más económico: El paso final es la contracción de
un conjunto de planes de ejecución de consultas candidatas seguidas de la
elección del mejor de los planes. Dentro del costo de una consulta también
deberá tomarse en cuenta la transmisión de los datos dentro del sistema en
el cual se llevara a cabo la consulta. Cuando una consulta es lanzada
dentro de un sistema de bases de datos distribuidas, es posible saber que
información se requiere y en que sitio se encuentra. Entonces se deberá de
93
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
diseñar una estrategia de recolección de datos. Es necesario recodar que
dentro de un sistema de bases de datos distribuidas el costo más alto es el
de la comunicación, por lo tanto de deben de utilizar las estrategias que
minimicen este costo en lo posible.
3.6 Preguntas de repaso
1.- ¿Cuales son los tres puntos que se deben tomar en cuenta en la optimización
de una consulta?
2.- ¿Mencione que se debe de considerar para seleccionar una estrategia de
procesamiento de consultas?
3.- ¿Que condición deben cumplir dos expresiones para que sean consideradas
equivalentes?
4.- ¿Que es una subexpresión común?
5.- ¿Que puntos se deberá tomar en cuenta para seleccionar una buena
estrategia de ejecución de join?
6.- ¿Que métodos de ejecución de join existen?
7.- Explique brevemente el funcionamiento de la estrategia de join paralelo.
8.- Explique brevemente los pasos para el proceso de optimización de una
consulta.
3.7 Ejercicios
Para los siguientes ejercicios, se utilizaran las tablas EMP y DEPT del ejemplo de la
sección 3.2.2 y la siguiente consulta:
EMP(id-emp, nom, sal, deptnum, edad)
DEPT(deptnum, descr, gtenum)
94
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Obténgase el nombre de los empleados mayores de 40 años del departamento
sistemas con sueldo mayor a $11,000.
l.- Dibuje el árbol de operadores de la consulta.
2.- Obtenga las subexpresiones comunes que contenga la consulta.
3.- Dibuje el árbol de operadores optimizado de la consulta.
4.- Considérese que las tablas de EMP y DEPT se encuentran en diferentes
sitios, y que el sitio en el cual se encuentra la tabla EMP tiene una capacidad de
procesamiento muy reducida. Dibuje el árbol de operadores más recomendable para
este caso.
Bibliografia
[1] Ceri, Stefano. Pelaggati, Giuseppe; "Distributed Databases Principies and
systems'; Internacional Edition; McGraw-Hill; U.S.A.; 1985
[2) Date, C.J.; "An Introduction lo Databases Systems"; Volume 1; Fifth Edition;
Addison-Wesley Publishing Company; U.S.A.; Repñnted Juiy, 1990
[3] Date, C.J.; "An lntroduction lo Databases Systems"; Volume li; Addison-Wesley
Publishing Company-, U.S.A.; Reprinted July, 1995
95
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Objetivo
El alumno comprenderá y manejara los conceptos de control de concurrencia,
seguridad y recuperación dentro del ámbito de las bases de datos distribuidas
Introducción
Este capítulo trata el aspecto del control de concurrencia, de cómo con etiquetas de
tiempo o bloqueos de registros, es posible mantener la integridad de la base de datos
en un ambiente multiusuario. También se habla a cerca de los métodos de
recuperación del sistema en base a bitácoras, check-points y respaldos. Por ultimo, el
capítulo expone algunas técnicas para garantizar la seguridad del sistema, por medio
de matrices de autorización, evitando así el acceso a usuarios no autorizados.
4.1 Control de concurrencia
4.1.1 Seriabilidad en bases de datos centralizadas
Una transacción accesa la base de datos usando primitivas de lectura y escritura.
Sean Rj(x) y Wi(x) las operaciones de lectura y escritura respectivamente, usadas en la
transacción Ti para el elemento de datos X. X puede ser una tupla o un fragmento
completo. El conjunto de elementos de lectura de datos para T i es llamado conjunto
lector y el conjunto de elementos de escritura de datos para T i es llamado conjunto
escritor. El conjunto lector y el conjunto escritor de una transacción no están
separados sino por el contrario, trabajan en conjunto.
96
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Capítulo IV
Procesamiento de transacciones en bases de datos distribuidas
Una entrada de bitácora es una secuencia de operaciones hechas por una
transacción. Por ejemplo, la siguiente serie de operaciones sería una planificación:
S1: Rj (x) Rj (x) Wi (y) Rk (X) Wj (X)
Dos transacciones Ti y Tj se ejecutan en sede dentro de una planificación S, si la
ultima operación de Ti precede a la primera operación de Tj en S o viceversa); En otro
caso las transacciones se ejecutarían concurrentemente.
Una planificación es serial si las transacciones no se ejecutan concurrentemente, es
decir, una detrás de otra. Por ejemplo, la siguiente planificación S2 es serial:
S2: Ri (x) Wi (y) Ri (y) Rj (x) Wj (y) Rk (y) Wk (X)
Ti Tj Tk
R(x)
W(y)
R(y)
R(x)
W(y)
R(y)
W(x)
Esto sería
S2: Ti Tj Tk
En una planificación, si la operación Oi precede a la operación Oj, se indica como
Oi < Oj, es decir Oi se ejecuta primero que Oj, entonces en S2 Ti < Tj y Tj < Tk.
97
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
La ejecución serial de una transacción puede ser descrita por una planificación
señal (denominada por Serial (S1) ). De cualquier forma no es posible forzar a las
transacciones a ejecutarse serialmente. Algo ideal sería que las transacciones se
ejecutaran lo más concurrentemente posible, cuidando que esta ejecución sea
correcta. La definición más aceptada de correcto en una planificación es basada en la
seriabilidad:
Una planificación es correcta si esta es seriabilizable, esto es, que el
resultado obtenido por esta sea equivalente al resultado de una
planificación serial.
Teniendo el concepto de seriabilidad, es posible decir que un mecanismo de control
de concurrencia es correcto si permite a las transacciones ejecutarse en una secuencia
tal que solo una bitácora serializable podría producir. Un mecanismo de control de
concurrencia restringe las posibles secuencias de operación ejecutados por una
transacción que fuerza a otra transacción a esperar mientras la primera termina de
realizar sus operaciones. Un ejemplo es el bloqueo de registros, ya que fuerza a otras
transacciones a esperar hasta que esta termine de realizar las operaciones sobre los
datos.
Las siguientes dos condiciones son suficientes para decir que dos planificaciones
son equivalentes:
1. Cada operación de lectura lee los mismos valores que fueron producidos por
las mismas operaciones de escritura en ambas planificaciones.
2. La operación de escritura final es igual en ambas planificaciones.
Estas dos condiciones son suficientes ya que ambas transacciones leen y escriben
los mismos datos. Es importante también considerar el hecho de que dos operaciones
pueden llegar a caer en conflicto:
Dos operaciones están en conflicto si, ellas procesan el mismo dato y al
menos una de estas operaciones es una operación de escritura, y estas
operaciones pertenecen a diferentes transacciones.
98
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Por ejemplo, [ Rj (x), Wj (x) ] y [ Wi (X), Wj (X) ] son pares de operaciones en conflicto
mientras que [ Ri(x), Rj(x) Wi(x), Wj(y) ], y [ Wi(x), Rj(y) ] son pares que no se
encuentran en conflicto.
Usando este concepto es posible obtener una definición de planificación equivalente
de otra manera:
Dos planificaciones S1 y S2 son equivalentes si por cada par de
operaciones en conflicto Oi y Oj, donde Oi < Oj en S1, entonces Oi
deberá preceder a Oj en S2.
Por ejemplo, la estructura S3 es equivalente a la planificación S4:
S3: Ri(x) Ri(x) Wj(y) Wi(x)
S4: Rj(x) Wj(y) Ri(x) Wi(x)
S3 S4
Ti Tj Ti Tj
R(x) R(x)
R(x) W(y)
W(x) R(x)
W(x) W(x)
4.1.2 Seriabilidad en una base de datos distribuida
En una base de datos distribuida, cada transacción ejecuta operaciones en varios
sitios. La secuencia de operaciones procesada por las transacciones en un sitio es
una planificación local. Una ejecución de n transacciones distribuidas T1, T2, .... Tn en
m sitios es modelado por un conjunto de entradas de bitácora Sl, S2, .... Sm.
99
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Si se aplica en cada sitio un mecanismo de control de concurrencia se aseguraría que
todas las planificaciones locales son serializables. Sin embargo, la seriabilidad local no
es suficiente para asegurar la exactitud de la ejecución de un conjunto de
transacciones distribuidas. Considere los siguientes ejemplos:
S1 (Sitio 1): Ri(x) Wj(x) Ri(x) Wi(x)
S2 (Sitio 2): Rj(y) Wi(y) Ri(y) Wj(y)
S1 S2
Ti Tj Ti Tj
R(x) R(y)
W(x) W(y)
R(x) R(y)
W(x) W(y)
Ambas planificaciones son seriales, sin embargo, no hay una secuencia señal global
de ejecución de ambas transacciones porque Ti < Tj en Serial(S1) y Tj < Ti en
Serial(S2). Para generalizar, la seriabilidad de transacciones distribuidas, es necesaria
una condición más fuerte que la seriabilidad local.
La ejecución de las transacciones T1, ..., Tn es correcta si:
1. Cada entrada local Sk es serializable.
2. Existe un orden total de T1, ..., Tn tal que, si Ti < Tj en el orden total, entonces
hay una planificación serial Sk’ tal que, Sk es equivalente a Sk’ y Ti < Tj en el
Serial(Sk’), para cada sitio k donde ambas transacciones tienen algún proceso en
ejecución.
La anterior definición puede ser explicada usando la definición de conflicto:
Sea T1, ..., Tn un conjunto de transacciones, y sea E una ejecución
de estas transacciones, modelado por el conjunto de planificaciones
100
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
S1, ..., Sm E es correcto (serializable) si existe un orden total de las
transacciones, y además para cada par de operaciones en conflicto Oi y
Oj de las transacciones Ti y Tj respectivamente, Oi precede a Oj en
cualquier entrada S1, ..., Sn si y solo si Ti precede Ti en el orden total.
Esta condición determina si una ejecución de una transacción distribuida es
correcta. Un mecanismo de control de concurrencia es correcto si permite solo la
ejecución de transacciones distribuidas.
4.1.3 Control de concurrencia basado en bloqueos centralizados
La idea básica del bloqueo (lock) es que cuando una transacción requiera accesar
un registro, esta bloquee dicho registro antes de intentar el acceso, y cuando una
transacción intente bloquear un registro que anteriormente ya fue bloqueado por otra
transacción, la primera deberá esperar a que la otra transacción libere dicho bloqueo
(unlock).
De hecho, los mecanismos típicos de bloqueo son más complejos, debido al
concepto de modo de bloqueo: una transacción puede bloquear un registro en modo
compartido (shared) si únicamente se desea leerlo y en modo exclusivo (exclusiva) si
se va a escribir en él. Una transacción siempre deberá bloquear un registro de forma
compartida antes de leer el contenido, y bloquear de modo exclusivo antes de escribir.
Existen dos reglas de compatibilidad entre los modos de bloqueo:
1. Una transacción puede bloquear un registro, si este no esta bloqueado o si lo
esta de manera compartida.
2. Una transacción puede bloquear de manera exclusiva, solo si el registro no esta
bloqueado.
101
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Otro aspecto importante en el bloqueo es la granularidad. Esto se refiere al tamaño
del "objeto" que se bloquea con una operación simple, esto es, se puede bloquear un
registro o un archivo con una sola instrucción.
Otra condición que se deberá de tener en cuenta es que, una transacción no debe
de requerir de un nuevo bloque después de que se libere algún registro, esto quiere
decir que la transacción debe de tener un bloqueo de dos fases (2PC), esto porque la
primera fase sería el bloqueo de todos los registros necesarios para realizar la
transacción, y la segunda fase es en la cual se hace la liberación de todos los registros
antes bloqueados.
Teniendo en cuenta lo anterior, se podría asumir que las transacciones están
estructuradas de la siguiente forma:
Inicia transacción
Se realizan todos los bloqueos para escritura o lectura
Se hace todo el proceso de la transacción (Commit)
Se liberan todos los bloqueos
Un problema que se puede presentar al usar los mecanismos de bloqueo es el
deadlock. Un deadlock entre dos transacciones surge cuando cada una de las
transacciones tiene bloqueado un registro y están esperando para bloquear el registro
que la otra transacción ya tiene bloqueado. Ambas transacciones pueden quedar
esperando a la otra para siempre. El sistema debe de ser capaz de detectar el
deadlock y forzar a alguna de las dos transacciones a liberar el registro que se tenia
bloqueado y a que se reinice posteriormente, permitiendo que la otra transacción
termine correctamente.
4.14 Control de concurrencia basado en bloqueos distribuidos
Se asume que, el manejador local de transacciones (LTM, Local Transaction
Manager) permite al agente local realizar los bloqueos y liberaciones de registros
locales, y el proceso de la transacción se lleva acabo de acuerdo con la siguiente
figura:
102
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
ROOTAGENT AGENT AGENT
Mensaje Mensaje Transacción Distribuida
Interface 1': Bloqueo local compartido, Bloqueo local exclusivo, desbloqueo local
Interface 2': Bloqueo compartido, Bloqueo exclusivo, desbloqueo
Entonces, los LTMs interpretan las primitivas locales de bloqueo (bloqueo local
compartido, bloqueo local exclusivo y, liberación local), mientras que los agentes de la
transacción procesan las primitivas globales (bloqueo compartido, bloqueo exclusivo, y
liberación). Entender los aspectos peculiares del control distribuido de concurrencia es
equivalente a comprender lo que el manejador distribuido de transacciones (DTM,
Distributed Transaction Manager) tiene que hacer para garantizar que la transacción
global tenga las características de seriabilidad y aislamiento.
Un problema principal que se presenta es la administración de múltiples copias de
datos, el cual, el DTM debe resolver.
Los mecanismos de bloqueo fueron desarrollados para bases de datos
centralizadas con la suposición implícita de que solo existe una copia única de los
datos; de esta manera, una transacción se da cuenta de que otra transacción está
trabajando con un registro al momento de intentar accesarla. En las bases de datos
distribuidas, la redundancia que existe entre los datos es almacenada en diferentes
sitios puede generar un conflicto de bloqueo entre dos transacciones, al accesar dos
103
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
DTM-AGENT
DTM-AGENT
LTMen
sitio k
LTMen
sitio j
DTM-AGENT
LTMen
sitio i
Mensaje Mensaje
2’ 2’ 2’
1’1’1’
Manejador distribuido de transacciones
Manejadores de transacciones locales
copias del mismo dato almacenados en diferentes sitios, para los cuales la existencia
mutua es inadvertida para dichas transacciones.
Una manera de evitar este problema seria que el DTM tiene que traducir la primitiva
de bloqueo emitida por un agente en un registro de tal manera que sea imposible que
un bloqueo pase inadvertido por una transacción. Esta es una manera sencilla de
hacer que de manera local, los LTMS, realicen todos los bloqueos en cada uno de los
sitios en donde se encuentran almacenadas las copias de los datos; de esta manera,
una primitiva de bloqueo es traducida en varias primitivas de bloqueo, tantas como
copias de datos se deseen bloquear. Este enfoque trabajaría, porque dos
transacciones en conflicto de bloqueo podrían darse cuenta de esto en todos los sitios
donde se encuentren copias de los mismos datos.
Existen esquemas alternativos para lograr evitar conflictos en los bloqueos:
1. Write-locks-all, read-locks-one. En este esquema los bloqueos exclusivos son
adquiridos en todas las copias, mientras que los bloqueos compartidos son
adquiridos únicamente en alguna copia arbitrada. Un conflicto es siempre
detectado, porque un bloqueo compartido - exclusivo es detectado en el sitio
donde este se encuentra o es requerido el bloqueo compartido, y un bloqueo
exclusivo - exclusivo es detectado en todos los sitios.
2. Mayoría de bloqueos. En ambos bloqueos compartido y exclusivo son
requeridos en una mayoría de las copias de los registros (el número de copias
que se bloquean son estrictamente más grande que el número de copias que
no se bloquean); de esta manera si dos transacciones requieren bloquear el
mismo registro, hay por lo menos una copia de él en donde se descubriría el
conflicto.
3. Bloqueo de copia primaria. Una de las copias de cada dato es privilegiada
(llamada copia primaria); todos los bloqueos son solicitados a esta copia, y así
es descubierto el conflicto en el sitio en donde se encuentra esta copia.
4.1.5 Bloqueo de 2 fases como un método de control de concurrencia
104
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Considérese primero que, si todas las transacciones logran un bloqueo de 2 fases,
entonces todas las entradas de bitácora son serializables. Considérese también un sitio
donde una transacción ejecuta alguna operación, la cual es únicamente una parte de]
conjunto total de operaciones ejecutadas por la transacción distribuida, entonces se
tendrá que, si una transacción distribuida logra un bloqueo de dos fases entonces
todas las subtransacciones en los diferentes sitios, lograrán separadamente un
bloqueo de dos fases. En el momento que el bloqueo de 2 fases es un método
correcto para el control de concurrencia para una base de datos centralizada, la
ejecución de las subtransacciones es serializable.
Considérese ahora que, las transacciones T1, T2, ..., Tn requieren de un bloqueo de
dos fases, esto tal vez no llegue a ocurrir. Considere el estado intermedio en el
conjunto T1 tiene bloqueado a X, T2 tiene bloqueado Y, ..., Tn-1 tiene bloqueado V y Tn
tiene bloqueado Z. Cada una de estas transacciones requieren de bloquear un dato el
cual, ya esta bloqueado por otra transacción; por lo tanto cada una de ellas tendrá que
esperar hasta que otra transacción libere el bloqueo. Sin embargo, desde el momento
en que las transacciones utilizan el bloqueo de dos fases, estas no pueden liberar el
bloqueo, sino hasta que se logran todos los bloqueos requeridos por dicha transacción.
Por lo tanto n transacciones alcanzarán un estado de deadlock, y pueden estar
esperando por siempre. Entonces, una de estas transacciones deberá ser abortada
por algún algoritmo de solución de deadlock. En cualquier caso, el conjunto de
transacciones no podrá ocurrir.
Lo anterior es independiente del número de transacciones y de la secuencia de
ejecución, pero sí depende únicamente del orden de los pares de operaciones en
conflicto. Por tanto, un algoritmo de detección y resolución de deadlock es necesario
en un bloqueo de dos fases.
Considérense dos transacciones Ti y Tj, las cuales transfieren fondos de una cuenta
x localizada en el sitio 1 a una cuenta localizada en el sitio 2. Dichas transacciones
pueden ser descritas por la siguiente secuencia de operaciones:
Ti : Ri1(x) Wi1(x) Ri2(Y) Wi2(Y)
Tj : Rj1(x) Wj1(x) Rj2(Y) Wj2(Y)
105
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Ti Ti
Ri(x) Ri(x)
Wi(x) Wi(x)
R2(Y) R2(Y)
W2(Y) W2(Y)
Se asume que cada transacción lee X, decrementa su valor, escribe el nuevo valor,
lee Y, incremento su valor, y escribe su nuevo valor.
Supóngase que ambas transacciones son activadas de manera simultánea. Un
bloqueo de 2 fases asegura la ejecución serializable de estas transacciones, y habría
un orden total en el que Ti < Tj o Tj < Ti; esto significaría que W i1(x) < Rj1(x) y
Wi2(y) < Rj2(y) o que Wj1(x) < Ri1(x) y Wj2(y) < Ri2(y)- Dado que existe una simetría, se
podrá considerar cualquiera de los dos casos. Para ejemplo considérese Ti < Tj.
Para lograr un análisis del grado de concurrencia que es permitido por el algoritmo
de control de concurrencia, es necesario incluir en el modelo de ejecución la noción de
"operaciones concurrentes" en diferentes sitios. Se representarán dos operaciones
concurrentes colocándolas una sobre otra, en la ejecución concurrente de
transacciones. Por ejemplo:
Sl: Ri(x) Wi(x) Ri(y) Wi(y)
S2: Rj(x) Wj(x) Rj(y) Wi(y)
S1 S2
Ri(x)
Wi(X)
Ri(y) Rj(x)
Wi(Y) Wi(X)
Rj(y)
Wi(Y)
106
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
En esta representación de la ejecución, el hecho de que la operación Ri(y) aparezca
abajo de Rj(x) significa que estas dos operaciones inician al mismo tiempo. Por lo
tanto, Tj inicia leyendo x, e inmediatamente Tj tiene que escribir x, aunque Ti no
termine aun. Esta ejecución de E es serializable y permite el má)dmo grado de
concurrencia.
4.1.6 Etiquetas de tiempo en una base de datos distribuida
En un sistema distribuido, es necesario, algunas veces, conocer si un evento A en
algún sitio ocurrió antes o después que un evento B en un sitio diferente. Determinar el
orden de los eventos es sencillo en un sistema centralizado, ya que es posible utilizar
el mismo reloj para determinar el tiempo en que cada uno ocurre. En un sistema
distribuido, en cambio, no es práctico asumir que los relojes disponibles en todos los
sitios están perfectamente sincronizados.
Varios métodos de control de concurrencia y algoritmos de prevención de deadlock
requieren determinar el orden en que se realizarán los eventos. La determinación de
un orden de eventos consiste en asumir que a cada evento A, el cual ocurre en un
sistema distribuido, se asigna una etiqueta de tiempo TS(A) (timestamp) con las
siguientes propiedades:
1. TS(A) identifica de manera Unica a A (diferentes eventos tienen diferentes
etiquetas de tiempo).
2. Para dos eventos cualquiera A y B, si A ocurre antes que B, entonces TS(A) <
TS(B).
El principal inconveniente de la definición anterior es que el manejo de la relación
"ocurre antes" no está definida, de manera precisa, si dos eventos A y B ocurren en
dos diferentes sitios, esto, debido a que no se tiene un "reloj global" para medir el
tiempo exacto de ocurrencia de todos los eventos en el sistema distribuido.
Una definición precisa de la relación "ocurre antes" en un sistema distribuido es la
siguiente. Se asume que se conoce el significado de la declaración " el evento A
ocurrió antes que el evento B en el sitio i", La relación "ocurre antes", denotada por →
puede ser generalizada en un sistema distribuido por medio de las siguientes reglas:
107
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
1. Si A y B son dos eventos en el mismo sito y A ocurre antes que B, entonces
A → B.
2. Si el evento A consiste en enviar un mensaje y el evento B consiste en recibir el
mensaje de A, entonces A → B.
3. Si A → B y B → C, entonces A → C.
La relación → es parcialmente ordenada. Se puede llamar a dos eventos A y B
pseudosimultáneos debido a que en ocasiones no es posible saber cual de los casos
ocurre realmente A → B o B → A.
Considérese el siguiente ejemplo, Los eventos A y D, B y E, B y F, C y E, C y F son
pseudosimultáneos. La relación de tiempo entre dos eventos pseudosimultáneos no
puede ser determinada.
La segunda propiedad de la definición de estampa del tiempo se puede ver de una
manera precisa como sigue:
Nótese que, si Ay B son pseudosimultáneos, es posible que TS(timestamp) (A) <
TS(B) o
108
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Sitio 1 Sitio 2
B
A
CF
E
D
Mensaje M2
TiempoLocal
TiempoLocal
Mensaje M1
que TS(B) < TS(A). De cualquier forma, Cuando se tienen asignadas las etiquetas a
los eventos, el orden es definido entre ellos, aun si algunos son pseudosimultáneos.
Considérese ahora la generación de las etiquetas de tiempo. El primer requisito,
que sean únicas, se puede satisfacer de manera sencilla en un sistema distribuido. Es
suficiente con que cada sitio agregue a cada etiqueta de tiempo local única, el
identificador del sitio en el cual fue generada, en la posición menos significativa. Lo
anterior es necesario para evitar que las etiquetas generadas por un sitio sean
consideradas como mayores a las generadas en otros sitios.
El segundo requerimiento es el más complicado de satisfacer. Primero, es
necesario utilizar en cada sitio un contador, el cual será incrementado cada vez que se
genere una nueva etiqueta, esto con el fin de mantener un orden de estas dentro de un
mismo sitio. Sin embargo, la sincronización entre los contadores de diferentes sitios
podría llegar a ser difícil. Es posible que el sitio 1 genere más etiquetas que el sitio 2, y
por lo tanto el contador del sitio 1 se incrementaría más rápido.
Los contadores de dos sitios se pueden mantener aproximadamente alineados, esto
se logra, añadiendo a cada mensaje el valor del contador del sitio que lo envía. Si un
sitio recibe un mensaje con una etiqueta con valor TS mayor al actual en este sitio,
este incremento su contador a TS + 1. De esta manera los contadores de sitios
cooperativos se mantendrán aproximadamente sincronizados; en el caso de que los
dos sitios no sean sitios cooperativos, no es muy importante la sincronización de sus
contadores.
Considérese el ejemplo anterior, se asume que el contador en el sitio 1 tiene un
valor inicial de 0 y el sitio 2 tiene un valor inicial de 10 en su contador. (x,y) representa
al sitio y, el cual tiene un contador con valor x. Por lo tanto, inicialmente se tiene que
TS(A)=(0,1) y TS(B)=(10,2). A y B son seudo simultáneas con un orden arbitrario.
Cuando el mensaje M2 llega al sitio 1, este genera la etiqueta de tiempo B; Ahora el
contador local 1 es incrementado 4y pasa a ser TS(A)=(1 1, l). Cuando el mensaje Ml
llega al sitio 2, y dado que la etiqueta de tiempo es menor en este sitio, el contador es
simplemente incrementado y pasaría a ser TS(B)=(1 1,2). Nótese que TS(A) y TS(B)
difieren únicamente en el identificador del sitio en donde se generaron.
109
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Finalmente, se vera que se tendrán que usar siempre contadores y no relojes, en la
implementación de etiquetas de tiempo. Sin embargo, en algunas implementaciones
será conveniente usar relojes en lugar de contadores. De esta manera se reflejará de
manera más real la secuencia en la ocurrencia de eventos.
4.1.7 Deadlocks distribuidos
La detección y solución de deadlocks constituye una actividad importante de un
sistema manejador de bases de datos. La detección de deadlocks es más difícil en un
sistema distribuido que un centralizado, esto, debido a un ciclo de espera involucro
varios sitios.
En la siguiente figura se muestra una gráfica wait-for distribuido (Distributed Wait-for
Graphics, DWFG) el cual contiene un ciclo y este corresponde a un deadlock. La
notación TAj hace referencia al agente A¡ de la transacción Ti.
En la figura, hay dos sitios y dos transacciones Ti y T2, cada una consiste de dos
agentes. Por simplicidad, se asumirá que cada transacción tiene solo un agente en
cada sitio donde esta se ejecuta. Una flecha directa de] agente TAj a un agente TA,
significa que TAj es bloqueado y espera al agente TrAs. Hay dos razones por las cuales
un agente esperaría a otro:
110
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
T1A1
T2A1
Sitio 1
T1A2
T2A2
Sitio 2
T1A1
T2A1
Sitio 1
T1A2
T2A2
1. El agente TAj espera que el agente TAj libere un recurso que él
necesita; en este caso, Ti es una transacción diferente de T r, y los dos agentes
están en el mismo sitio, porque los agentes requieren únicamente recursos
locales. En la figura de ejemplo, TIA, espera que T2A, libere recursos en el sitio
1. Este tipo de espera se representa por una flecha continua en la gráfica.
2. El agente TiAj espera por el agente TiA, para realizar alguna solicitud de
función; En este caso, los dos agentes pertenecen a la misma transacción, y el
agente TAj requiere que el agente TjA, ejecute alguna función en un sitio
diferente. Este tipo de espera es representado por una flecha discontinuo en la
gráfica.
La porción de una DWFG que contiene únicamente los nodos y flechas
concernientes a un solo sitio se llama gráfica wait-for local (Local Wait-For Graphics,
LWFG). Dichas LWFG se extienden con flechas, desde y hacia los nodos los cuales
representan a agentes que tienen conexión con el nodo local. En el ejemplo, la
segunda figura representa una LWFG, los nodos cuadrados son llamados puertos de
entrada si tienen una flecha hacia dentro de la gráfica, y puertos de salida si las flechas
salen.
Un deadlock es local si es causado por un ciclo en una LWFG o distribuido si es
causado por un ciclo en una DWFG el cual no esta contenido en una LWFG. La
detección de un deadlock distribuido es una tarea que requiere el intercambio de
información entre los diferentes sitios del sistema.
La solución a un deadlock involucro la selección de una o más transacciones que
pueden se abortadas y reiniciadas. Cuando la transacción es abortada, esta libera los
recursos, para que otras transacciones puedan ser procesadas. Un criterio para
seleccionar que transacción será abortada, pudiera ser el que se aborte la transacción
que implique el menor costo en dicha operación (él abortar una transacción requiere de
operaciones de deshacer). Otros criterios podrían ser, el abortar la transacción más
joven; abortar la transacción que tiene la menor cantidad de recursos; o abortar la
transacción que requiere más tiempo para terminar.
La redundancia incremento la posibilidad de un deadlock. Considérense, por
ejemplo, dos transacciones Ti y T2, ambas bloquean de manera exclusiva el mismo
dato X. Si X no esta replicada, entonces una transacción obtendría el bloqueo y se
111
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
ejecutaría mientras que la otra tendría que esperar. En el otro caso, X esta replicado,
se tiene dos copias X, Y X2 en los sitios 1 y 2 y ambas transacciones utilizan la
estrategia write-locks-all, entonces, la siguiente secuencia de eventos en los sitios 1 y 2
determina un deadlock:
Sitio 1: T1 bloquea X1 ; T2 espera
Sitio2 : T2 bloquea X2; T1 espera
En este punto la DWFG contiene un ciclo, y por lo tanto un deadlock.
4.2 Recuperación
Nada trabaja perfectamente el 100% de las veces. Esta simple observación al
parecer trivial, tiene grandes consecuencias en el diseño de sistemas para
computadoras, en general, y para sistemas de bases de datos, en particular. Tales
sistemas deben incorporar, no solamente una variedad de verificaciones y controles
para reducir la posibilidad de una falla, sino además y de manera más significativa un
conjunto exacto de procedimientos para recuperación de las fallas que,
inevitablemente, ocurren a pesar de estas verificaciones y controles.
La recuperación en un sistema de bases de datos, significa, primero que nada
recuperar la propia base de datos, esto es, restaurar la base de datos a un estado que
se sabe es correcto, después de que una falla la ha llevado a un estado incorrecto o al
menos incierto. Existen muchas causas de falla, por ejemplo, errores en la
programación en una aplicación, en el sistema operativo de apoyo, en el propio
manejador de bases de datos, errores en el hardware en un dispositivo, virus, ete.
El principio en el cual se basa la recuperación se puede resumir en una sola
palabra, redundancia. Esto es la forma de proteger la base de datos y asegurarla de
manera de que cualquier parte de la información almacenada en ella pueda ser
reconstruida de alguna otra información almacenada redundantemente en alguna parte
del sistema, aunque, el hecho de incluir algún método de procesamiento o
almacenamiento en espejo, no nos garantiza que no ocurra alguna falla, por lo que de
cualquier manera se debe incluir algún procedimiento de recuperación, el cual puede
consistir en forma general de lo siguiente:
112
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
1. Periódicamente, tal vez diario, hacer una copia de respaldo de la base de datos
completa.
2. Cada vez que se haga un cambio en la base de datos, se escribe un registro
que contiene los valores anteriores y los nuevos del registro modificado en un
conjunto de datos especial llamado bitácora.
3. Si ocurre una falla hay dos posibilidades:
a) Que la base de datos no se halla dañado pero su contenido es incierto (por
ejemplo, la terminación anormal de un programa en medio de una
secuencia de actualizaciones lógicamente relacionadas) en este caso la
base de datos se restaura a un estado correcto utilizando la bitácora para
deshacer todas las actualizaciones "INCIERTAS' que hayan sido realizadas
en ese programa.
b) La base de datos se daña físicamente (por ejemplo, debido a algún
problema de hardware) la solución en este caso, consiste en recuperar la
base de datos utilizándola copia de respaldo más reciente, y después
aplicándole la bitácora para hacer los cambio hechos desde el momento en
que se hizo el respaldo hasta el momento en el que ocurrió la falla.
4.2.1 Transacciones
El propósito fundamental de un sistema de bases de datos es realizar
transacciones. Una transacción es una unidad de trabajo, que consiste de la ejecución
de una secuencia de operaciones lógicamente relacionadas de una aplicación
especifica que inicia con el operador especial "BEGIN TRANSACTION” y termina con
la operación “COMMIT” o “ROLLBACK”. El commit se usa para indicar una
terminación exitosa (la unidad de trabajo ha terminado con éxito), el rollback se utiliza
para indicar una terminación no exitosa, es decir, la unidad de trabajo no puede ser
terminada completamente debido a que ha ocurrido una condición excepcional. La
ejecución de un programa puede corresponder a una secuencia de vanas
transacciones, una detrás de otra.
113
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Las transacciones no se pueden anidar, esto es el begin transaction puede ser
ejecutado solamente cuando la aplicación no tiene una transacción en progreso, por
otro lado el commit y el rollback se pueden ejecutar solamente cuando se esta
ejecutando una transacción. Todas las acciones recuperables deben ser ejecutadas
dentro de los limites de una transacción, una operación recuperable es una operación
que puede ser deshecha o rehecha en el caso de alguna falla, es decir son las
operaciones que se deben registrar en la bitácora. Las actualizaciones en la base de
datos y los mensajes de entrada-salida son operaciones recuperables.
Las transacciones son proposiciones de todo o nada, se debe garantizar al usuario
que cada transacción es ejecutada completamente o no se ejecuta en lo absoluto. El
requerimiento es que el sistema considerado como procesador de transacciones
deberá ser confiable, las transacciones no se deberán perder o ser hechas
parcialmente o hechas más de una vez. Al aceptar el mensaje de entrada deberá
garantizar que una transacción se ejecute una vez que cualquier actualización sobre la
base de datos producida por la transacción sea aplicada una vez y que cualquier
mensaje de salida producido por la transacción sea transmitido al usuario solamente
una vez, el manejador de recuperación es el responsable de proveer esa confiabilidad.
4.2.2 Manejo de mensajes
La recuperación tiene varias aplicaciones tanto con el manejo de mensajes como de
la base de datos, considerando el aspecto del manejo de mensajes de una transacción,
esta no solo actualiza la base de datos sino que además envía mensajes al usuario
final, si la transacción llega a su terminación planeada (commit o rollback explícito) se
debe enviar un mensaje al usuario. Si la transacción falla, es decir, no llega a su
terminación planeada a causa de un error, entonces el sistema debe deshacerla
automáticamente, el efecto en este caso será como si la transacción nunca se hubiera
iniciado, sus actualizaciones en la base de datos deberán ser deshechas y ningún
mensaje generado por la transacción deberá ser mostrado. Los mensajes de salida
deberán ser transmitidos al usuario hasta que ocurra una terminación planeada en la
transacción. El componente responsable del manejo de los mensajes es el manejador
114
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
de comunicaciones de datos (DC manager), este manejador recibe el mensaje de
entrada inicial dado por el usuario y al recibir el mensaje escribe un registro de bitácora
que contiene el texto del mensaje. La transacción utiliza una operación get para
obtener una copia del mensaje de una cola de entrada y una operación put para
colocar un mensaje de salida en una cola de mensajes de salida. Las operaciones
commit y rollback explícitos, es decir planeados, provocan que el DC Manager escriba
un registro en la bitácora. Para los mensajes contenidos en la cola de salida, realiza la
transmisión de estos mensajes al usuario y remueve el mensaje de entrada de la cola
de correspondiente. Si la transacción falla, el sistema automáticamente genera un
rollback (implícito) y esto provoca que el DC Manager descarte los mensajes de la cola
de salida.
4.2.3 Estructura general de los registros de bitácora
Registro de control
Identificadores (id, transacción, fecha y hora, usuario, id. equipo, etc.)
Comandos (Begin transaction, Commit, Rollback)
Mensajes
ldentificadores
Tipo de mensaje (entrada o salida)
Texto de mensaje
Operaciones
identificadores
Id. del registro
Valores anteriores
Valores actuales
Considérese la siguiente tabla y transacciones para ejemplo:
T1 Transferir 400 pesos de la cuenta Cl a C4
T2 Depositar a la cuenta C5, 3000 pesos
T3 Dar de alta la cuenta C7 con 5000 pesos
115
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
T4 Transferir 1000 pesos de la cuenta Cl a C3
Id cuenta Saldo
C1 1000
C2 500
C3 3200
C4 8000
C5 1532
C6 4553
En la bitácora se almacenan los mensajes de entrada y salida, las operaciones de
alta, baja, depósito y retiro, así como los registros de control para cada una de las
transacciones:
T1 usr23 Begin transaction
T1 usr23 MsgEntrada Transferencia C1 C4 400
T1 usr23 (Retiro) C1 1000 C1 600
T1 usr23 (Deposito) C4 8000 C4 8400
T1 usr23 (mensaje) Transferencia Completada
T1 usr23 Commit
T2 usrO2 Begin Transaction
T2 usrO2 ME Deposito C5 3000
T2 usrO2 D C5 1532 C5 4532
T2 usrO2 MS Deposito Completado
T2 usr02 Commit
T3 usr45 Begin Transaction
T3 usr45 ME Alta C7 5000
T3 usr45 A C7 5000
T3 usr45 ms Registro Completado
T3 usr45 Commit
T4 usr87 Begin Transaction
T4 usr87 ME Transferencia C1 C3 1000
T4 usr87 R C1 600 C1 -400
T4 usr87 MS Fondos Insuficientes
116
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
T4 usr87 Rollback
Dando como resultado siguiente la tabla:
Id cuenta Saldo
C1 600
C2 500
C3 3200
C4 8400
C5 4532
C6 4553
C7 5000
4.2.4 Tipos de fallas
Una operación rollback permite asegurarse de que una falla no corrompa la base de
datos, en el caso de que la transacción por si misma descubra la condición de la falla,
desafortunadamente la mayor parte de las fallas no se pueden anticipar fácilmente y no
se puede dejar al programador de la aplicación el manejarlas de esta manera. Los
tipos de fallas que pueden ocurrir, caen en las siguientes categorías:
1. Fallas locales de la transacción, que son detectadas por el código de la
aplicación (Por ejemplo, una condición de fondos insuficientes en una
transacción bancaria).
2. Fallas locales de transacción, que no son explícitamente manejadas por el
código de la misma, por ejemplo un overflow aritmético, una división entre cero,
una violación de seguridad, etc.
117
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
3. Fallas del sistema que afectan a todas las transacciones que se encuentran en
ejecución, pero que no dañan la base de datos (por ejemplo, una falla en el
CPU).
4. Fallas en el medio que dañan la base de datos o alguna porción de esta y
afectan a todas las transacciones que están utilizando esta parte (Por ejemplo,
un aterrizaje de las cabezas de un disco duro).
4.2.5 Fallas de transacción
Este término se usa para indicar una falla causada por una terminación no planeada
y anormal de un programa. Las condiciones que pueden causar esta terminación no
planeada, incluyen overflow aritmético, división entre cero, Colaciones de seguridad, lo
que ocurre cuando se da una condición de este tipo, por regla general es lo siguiente:
1. Cuando se presenta una condición de error, el sistema enciende una condición
para ese tipo de error en particular por ejemplo, división entre cero. El
programador tiene la opción de incluir explícitamente el código correspondiente
para manejar esta condición, si no se incluye este código, el sistema realiza la
siguiente acción.
2. El sistema enciende una condición de error generalizada, de nuevo el
programador tiene la opción de incluir el código correspondiente para manejar
esta condición o permitir que el sistema tome la siguiente acción.
3. En este punto el sistema provoca la terminación anormal del programa y envía el
mensaje correspondiente al usuario, y es solamente en este punto que se dice
que a ocurrido una falla de transacción.
En general se dice que una falla de transacción ocurre si y solo si el programa
termina de manera no planeada, es decir, si ocurre un error para el cual no hay un
código incluido en la aplicación que maneje explícitamente ese error. La ejecución de
un rollback explícito no esta considerado como una falla de transacción, sino como una
terminación anormal planeada de la transacción, no del programa.
Una falla de transacción significa que la transacción no ha llegado a su terminación
planeada, por lo que es necesario que el sistema force un rollback, esto es, que
118
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
deshaga cualquier cambio que haya hecho la transacción en la base de datos y que
cancele cualquier mensaje de salida que se haya producido para hacer como si nunca
se hubiera iniciado. Deshacer los cambios involucro el trabajar hacia atrás en la
bitácora leyendo todos aquellos registros de bitácora generados por la transacción
hasta que se encuentre un registro de inicio de transacción (begin transaction) para
cada registro localizado en la base de datos. El cambio que representa un registro de
bitácora se deshace reemplazando los nuevos valores en la base de datos por los
valores antiguos registrados en la bitácora.
4.2.6 Bitácora en línea
De la descripción del procedimiento para deshacer una transacción dada
anteriormente se puede observar que el manejador de recuperación necesita tener la
posibilidad de accesar los registros de bitácora de una manera selectiva en lugar de
una manera secuencias, por lo tanto, es conveniente que la bitácora se pueda guardar
en un dispositivo de acceso directo, sin embargo, un sistema de base de datos grande
puede generar al orden de varios gigabites de bitácora al día, por lo que es claramente
inconveniente el mantener la bitácora completa en línea. Una posible solución podría
ser lo siguiente:
La bitácora activa es mantenida en el dispositivo de acceso directo. Cuando el
archivo de bitácora se llena, el administrador de la bitácora, activa otro archivo de
bitácora, donde se almacenaran los siguientes registros de bitácora, mientras que el
otro archivo se respalda en algún medio. Si una transacción es muy larga y en dado
momento el archivo de bitácora se llena y esta transacción aun no termina, el sistema
provoca un rollback y todas las operaciones realizadas por esta se deshacen, y es
reiniciada posteriormente, cuando el nuevo archivo de bitácora este activo.
4.2.7 Transacciones grandes
119
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Una transacción es tanto una unidad de recuperación como una unidad de trabajo,
esto sugiere que, una transacción debe de ser corta con el fin de reducir la cantidad de
trabajo que se tiene que deshacer y quizás, posteriormente rehacer en el caso de una
falla, esta, además reduce la posibilidad de que una transacción falle debido a un
overflow en la bitácora. Si una aplicación es muy grande, lo más adecuado es
subdividirla en varia transacciones sin afectar el concepto de transacción.
4.2.8 Compresión de bitácora
Al momento de hacer el respaldo de la bitácora se puede eliminar parte de la
información contenida en la misma. Con el fin de ocupar menor cantidad de espacio
de almacenamiento posible, sin perjudicar el proceso de recuperación, este proceso se
puede realizar de la siguiente manera:
1. Debido a que la bitácora en cinta (respaldo) solo se utiliza para rehacer
transacciones en el caso de que ocurra una falla en el medio, se pueden
eliminar los registros de las transacciones que terminaron con rollback.
2. Se pueden eliminar tanto los mensajes de entrada como los de salida.
3. Se pueden eliminar los registros de control, debido a que no es necesario hacer
la recuperación, transacción por transacción, pues se hace un barrido y se
rehacen todas.
4. Se puede eliminar el identificador de la transacción, el del usuario, fecha, hora,
etc. (identificador de transacción no es lo mismo que tipo de transacción).
5. Se puede eliminar la parte UNDO de cada registro que representa una
actualización sobre la base de datos.
6. Se eliminan los apuntadores al registro anterior y registro siguiente.
7. Se eliminan los registros de la bitácora que modifican el mismo registro de la
base de datos quedando registrado únicamente la última actualización.
Considerando la bitácora de la sección 4, 2, 3, la cual después de la compresión,
quedaría como sigue:
T1 R C1 600
T1 D C4 8400
T2 D C5 4532
120
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
T3 A C7 5'000
Con el fin de optimizar el proceso de recuperación se puede ordenar los registros de
la bitácora de acuerdo con el orden físico que tienen los registros en la base de datos,
cuya actualización representan los registros de la bitácora.
4.2.9 Fallas del sistema
"Fallas del sistema” significa que algún evento causó que el sistema se detuviera y
esto requerirá un subsecuente reinicio del sistema: El contenido del almacenamiento
primario, en particular el contenido de todo los buffers de entrada/salida (I/O), se
pierde, pero la base de datos no sufre daño alguno. Así, las transacciones que en el
momento de la falla se estuvieran ejecutando, se deberán de deshacer, esto, si es que
estas no habían terminado. Pero, como podría el manejador de recuperación saber al
momento del restablecimiento, que transacciones deshacer.
Esto se puede resolver buscando en la bitácora desde el principio, identificando
aquellas transacciones para las cuales hay un registro de inicio de transacción (BT),
pero no un registro de terminación (commit o rollback). Sin embargo, tal búsqueda
podría consumir demasiado tiempo. Se puede reducir fuertemente la cantidad de
búsqueda, introduciendo el principio de punto de verificación (Checkpoint).
El principio de check-point es muy simple:
A cierto intervalos preestablecidos, por ejemplo, cada cierto tiempo o número de
entradas de bitácora, el sistema realiza un check-point que consiste en los siguientes
pasos:
1. Forza el contenido de los buffers de bitácora hacia la bitácora física. Esto obliga
la escritura de cualquier registro de bitácora que aun permanezca en la memoria
principal.
2. Forza la escritura de un registro de check-point en la bitácora.
121
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
3. Forza la escritura del contenido de los buffers de la base de datos, en la base de
datos almacenada físicamente. Esto obligará la escritura de cualquier
actualización que aun se encuentre en la memoria principal.
4. Escribe la dirección del registro de check-point incluido en la bitácora en un
archivo de restablecimiento.
El registro de check-point contiene la siguiente información:
1. Una lista de todas las transacciones activas al momento del check-point.
2. La dirección del registro de bitácora más reciente de cada una de estas
transacciones.
Al momento del restablecimiento, el manejador de recuperación obtiene la dirección
del registro de check-point más reciente del archivo de restablecimiento, localiza este
registro de bitácora y procede a buscar adelante en la bitácora, desde este punto hasta
el final.
Como resultado de este proceso el manejador de recuperación tiene la posibilidad
de determinar, tanto las transacciones que tiene que deshacer, como las transacciones
que tienen que ser rehechas, con el fin de llevar la base de datos a un estado correcto.
Para el propósito del restablecimiento, las transacciones pueden ser clasificadas en 5
categorías:
Tipo Descripción
T1 Terminan antes del check-point
T2 Inician antes del check-point y terminan después de este
T3 Inician antes del check-point, sin embargo no han terminado al
momento de la falla.
T4 Inician después del check-point y terminan antes de que ocurra la falla
T5 Inician después del check-point, pero no termina porque se presenta la
falla.
122
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
T1
T2
T3
T4
T5
Check Point Momento
de la falla
Al momento del restablecimiento, las transacciones del tipo T3 y T5 se deben
deshacer y las del tipo T2 y T4 deberán ser rehechas, ya aunque las transacciones se
realizaron completas, no hay garantía de que sus actualizaciones hayan sido escritas
en la base de datos. Las transacciones del tipo Tl no se consideran en al proceso de
recuperación, ya que al realizar el paso 3 del check-point sus actualizaciones se
escribieron en la base de datos.
Para la recuperación se procede a deshacer todos los cambios hechos por las
transacciones que están en la lista UNDO de la siguiente manera:
1. Se lee hacia atrás, secuencialmente la bitácora desde el final hasta el registro de
check-point, sí el registro recuperado pertenece a una transacción de la lista
UNDO, se deshace el movimiento que este representa.
2. A partir del registro de check-point se hace una lectura selectiva de las
transacciones que están tanto listadas en el registro de check-point como en la
lista de UNDO, hasta localizar el begin transaction de cada una de ellas.
3. Para rehacer las transacciones del tipo T2 y T4, es necesario iniciar una lectura
secuencial de la bitácora a partir del registro de check-point y rehacer el cambio
123
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
que representa cada registro de la bitácora que pertenezca a las transacciones
de la lista REDO.
4.2.10 Fallas en el medio de almacenamiento
Este tipo de falla en el que se daña el medio de almacenamiento, daña parte o toda
la base de datos, y las transacciones que estaban usando esa parte se ven afectadas,
en este caso, los respaldos realizados periódicamente, juegan un papel fundamental, el
proceso de recuperación consiste en lo siguiente:
Una vez detectada la falla se procede a reemplazar el medio de almacenamiento y
se restaura la base de datos a partir del ultimo respaldo, y enseguida se le aplican los
movimientos registrados en la bitácora de las transacciones que terminaron con
commit. La bitácora debe contener todos los movimientos efectuados desde que se
hizo el ultimo respaldo hasta el momento de la falla. La bitácora implica todos los
movimientos que se encuentran en la parte activa, como las partes que se respaldaron.
Considérese la tabla de la sección 4.2.3. La tabla cuentas fue respaldada antes de
que se realizaran las transacciones Tl, T2, T3 y T4, dichas transacciones fueron
registradas en la bitácora, la cual fue sometida a un proceso de compactación y
respaldo. Supóngase que el disco duro en el cual estaba almacenada la tabla de
cuentas se daña, y es necesario recuperarla a partir del respaldo en el disco duro
nuevo, siguiendo el proceso de recuperación.
1.- Se restaura la base de datos del medio de respaldo.
Cuentas
Id_cuenta Saldo
C1 1000
C2 500
124
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
C3 3200'
C4 8000
C5 1532
C6 4553
2.- Se aplican los movimientos almacenados en la bitácora, substituyendo directamente
el valor almacenado en la tabla por el valor obtenido de la bitácora.
Bitácora
T1 R C1 600
T1 D C4 8400
T2 D C5 4532
T3 A C7 5000
Id_cuenta Saldo
C1 600
C2 500
C3 3200
C4 8400
C5 1532
C6 4553
Id_cuenta Saldo
C1 600
C2 50
C3 3200
125
Id_cuenta Saldo
C1 600
C2 500
C3 3200
C4 8000
C5 1532
C6 4553
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
C4 8400
C5 4532
C6 4553
Id_cuenta Saldo
C1 600
C2 500
C3 3200
C4 8400
C5 4532
C6 4553
C7 5000
La tabla que resulta de la operación de recuperación es ahora idéntica a la tabla que
se tenía antes de la falla del disco duro.
4.3 Integridad
El término integridad se usa en el contexto de la base de datos con el significado de
correctez o validez, el problema de la integridad es el asegurarse que la base de datos
sea correcta, esto es, proteger la base de datos de transacciones invalidas que pueden
126
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
ser provocadas por errores al introducir los datos, por errores por parte del operador o
del programador de la aplicación, por fallas del sistema, y aun por falsificación
deliberada. El ultimo caso, sin embargo, no tiene que ver con la integridad, sino con la
seguridad- El proteger la base de datos de operaciones que son ¡legales es
responsabilidad del subsistema de seguridad, por lo tanto, se asume que el usuario
esta autorizado para la actualización en cuestión y que la actualización es valida.
Se asume la existencia de un subsistema de integridad con las siguientes
responsabilidades:
1. Monitorear las transacciones especialmente, operaciones de actualización y
detección de violaciones a la integridad de la base de datos.
2. En el caso de una violación, tomar la acción apropiada, por ejemplo,
rechazando la operación, reportando la violación o corrigiendo el error.
Con el fin de ejecutar estas acciones, se le debe de proveer al subsistema de
integridad, un conjunto de reglas que define que errores debe verificar y que hacer si
se detecta el error.
La estructura general de una regla de integridad es la siguiente:
Etiqueta: [condición de activación]
Restricción
[ELSE respuesta en caso de violación]
La condición de activación define el momento en el que se verifica que se cumpla la
regla.
Una restricción indica las acciones que se deben de realizar para que la base de
datos cumpla con la regia, y la respuesta en caso de violación, corresponde a un
conjunto de instrucciones que se van a ejecutar en el caso de que no se cumpla con la
restricción. Las reglas de integridad se expresan en lenguajes de alto nivel, por
ejemplo SQL, y son compilada y almacenadas en el diccionario de datos de la base de
datos. La mayor ventaja de esto es que las validaciones son manejadas por el DBMS,
en lugar de las aplicaciones individuales. Otra de las ventajas es que las reglas se
127
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
concentran en el diccionario de datos en lugar de estar distribuidas en los programas
de aplicación, por lo que es más fácil entenderlas en su totalidad, y por lo tanto
modificarlas en caso de ser necesario. Se tiene, además, mayor oportunidad de
detectar contradicciones y redundancias en ellas, así como también conseguir que el
proceso de validación se ejecute más eficientemente.
Debido a que las reglas son almacenadas en el diccionario de datos, es posible
utilizar el lenguaje de consulta normal del sistema para hacer preguntas con respecto a
las mismas.
Las reglas de integridad se pueden dividir en dos categorías:
Reglas de integridad de dominio.
Reglas de integridad de relación.
Las reglas de integridad de dominio conciernen a la admisibilidad de un valor
determinado como valor candidato para un atributo determinado, considerado de
manera aislada, esto es, independientemente de su relación con otros valores en la
base de datos. Las reglas de integridad de relación conciernen a la admisibilidad de
una tupla determinada como candidato para la inserción en una relación determinada o
la asociación entre tuplas de una relación con otra.
4.3.1 Reglas de integridad de dominio
Cada atributo de cada relación esta definido sobre un dominio identificado en la
definición de la relación, para el atributo A de la relación R que se define sobre el
dominio D, cualquier valor dado como candidato del atributo A debe pertenecer a D. La
definición del dominio D entonces constituye una importante regla de integridad, la cual
deberá verificar en todas las operaciones de inserción y actualización que involucran
cualquier atributo definido sobre D. La regla de integridad de dominio, no es otra que,
la definición de ese dominio. Las violaciones a las reglas de integridad de dominio
ocurren lo suficientemente seguido como para justificar algunas utilerías especiales
para facilitar su manejo-
Cada dominio es un subconjunto de un dominio base y hereda por lo tanto, las
características de ese dominio base (los dominios base son el conjunto de todas las
128
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
cadenas de caracteres, el conjunto de todos los números enteros, el conjunto de todos
los números reales, etc.).
La sintaxis de una definición de dominio puede ser la siguiente:
DLC nombre del dominio [PRIMARY] DOMAIN
Tipo de datos [PREDICADO]
[ELSE respuesta en caso de violación]
4.3.2 Reglas de integridad de relación
La sintaxis de una regla de integridad de relación puede ser la siguiente:
Etiqueta: [Condición de activación]
restricción
[ELSE respuesta en caso de violación de la regia]
Condición de activación:
WHEN COMMITING
BEFORE INSERTING nombre-del-registro [FROM estructura]
BEFORE UPDATING nombre-del_registro [FROM estructura]
BEFORE UPDATING nombre-de-columna [FROM nombre-de-campol
BEFORE DELETING nombre del registro
AFTER INSERTING nombre-del-registro
AFTER UPDATING nombre-del-registro
AFTER UPDATING nombre-de-columna
AFTER DELETING nombre-del-registro
Las siguientes notas explican la sintaxis de las reglas de integridad:
1. La condición de activación, si se especifica, consiste de una sola cláusula when
commiting o de una lista de cláusulas Before y/o After separadas por comas,
129
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
en el caso de que no se especifique una condición de activación, se asume por
default las siguientes condiciones de activación:
AFTER INSERTING tabla
AFTER UPDATING tabla
2. Todos los parámetros mencionados en una condición de activación deben tener
el mismo cursor, ya sea explícito o implícito, en esta regla se asegura que
todas las cláusulas Before y/o After incluidas en una regla de integridad
determinada se refiere al mismo registro, por lo que cualquier referencia al
registro por sus campos en la restricción o en la respuesta en caso de violación
no es ambigua.
3. Si se especifica la cláusula FROM en una sentencia BEFORE se asume que la
estructura destinada, tiene la misma estructura interna que el registro a que se
esta haciendo referencia, esto permite hacer referencia a los campos de la
estructura indicada en el FROM de la restricción y/o la respuesta en caso de
violación.
4. Si se especifican múltiples cláusulas FROM en la condición de activación
determinada, entonces todas estas cláusulas deben incluir un nombre de
estructura como si se indicaran de forma aislada y esos nombre de estructura
deben ser la misma.
5. Un cursor es un objeto cuyo valor es la dirección de algún registro especifico de
la base de datos, es decir, es un apuntador la un registro específico, la
expresión C → R se refiere a una instancia específica de un registro tipo R que
el cursor C se encuentra apuntando. Cada cursor esta restringido a apuntar a
registros de un tipo en particular y cada tipo de registro tiene un cursor de
default que se llama de la misma manera que el tipo de registro.
6. La restricción puede incluir referencias a parámetros, esto es referencias a
cursores que estén en la lista de condiciones de activación, así como también
referencias a las variables o estructuras indicadas en la cláusula, así como
también pueden hacer referencia a registros y campos de las tablas implícitas
en la regla.
130
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
7. La regla de integridad
i: BEFORE cambio
restricción
ELSE respuesta en caso de violación;
Es lógicamente equivalente a:
i : si se va a realizar el cambio entonces sino (restricción)
entonces ejecuta respuesta en caso de violación fin_si
fin_si
Si se ejecuta la respuesta en caso de violación y este incluye la operación
REJECT entonces el cambio se realiza, de otra manera se realiza y regresa a la
aplicación.
8. La regla de integridad
i: AFTER cambio
restricción
ELSE respuesta en caso de violación;
Es lógicamente equivalente a:
i : ejecuta el cambio
entonces sino (restricción)
entonces ejecuta respuesta en caso de violación
fin_si
Si respuesta en caso de violación y este incluye la operación REJECT entonces el
cambio se deshace
9. Las reglas de integridad de relación pueden involucrar a más de una
relación, por esta razón, se especifica generalmente en forma separada en
lugar de incluirse como parte de la definición de una relación.
En el ejemplo de la sección 4.2.3, se tiene que la transacción 4 fue desecha debido
a que no se contaba con el saldo suficiente para realizar la operación, esta validación
puede ser hecha por medio de reglas de integridad, por ejemplo:
131
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
After Updating cuentas
cuentas.saldo >= 0
Else
Set return code to "Saldo insuficiente”
Reject;
Esta regla verifica que el saldo sea igual o mayor a cero, después de que se realizo
la actualización, en caso de ser negativo la operación es forzada a deshacerse y se
envía el mensaje de "Saldo insuficiente".
Otro ejemplo, sería una regla que revisara la base de datos antes de dar de alta una
nueva cuenta, para evitar que, por error, se asigne un id que ya exista en la tabla de
cuentas:
Before inserting cuentas from variable-de-programa
Not exist (cuentas. Id-cuenta = variable-de-Programa. ld_cuenta)
Else
Set return code lo “El Id de la cuenta ya existe"
Reject,
Supóngase que se tiene una tabla en la cual se almacenan los movimientos
mensuales de las cuentas (retiros, depósitos). En el momento en el que se desea
borrar una cuenta de la tabla de cuentas, todos los movimientos de la cuenta deberán
de ser borrados para mantener la integridad de la base de datos. Esto se puede lograr
por medio de una regla de integridad, definida como sigue:
After deleting cuentas from variable-de-Programa
Not exist (Movimientos where movimiento. Id-cuenta
variable-de_programa.ld-cuenta)
Else Delete from movimientos
where movimientos.ld-cuenta = variable_de_programa.ld-cuenta;
132
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
De esta manera se realizaría un borrado en cascada de todos los movimientos de la
cuenta eliminada.
4.4 Seguridad
Se utiliza el término de seguridad en un contexto de bases de datos para indicar la
protección de la base de datos, acerca del acceso, alteración o destrucción no
autorizada. Existen numerosos aspectos del problema de seguridad, entre ellos los
siguientes:
1. Aspectos legales, sociales y éticos. Por ejemplo, la persona que hace la
solicitud, tal vez un usuario de crédito, tiene acceso legal a la información
solicitada.
2. Controles físicos. Considera si el cuarto de la computadora o las terminales
deberán estar cerrados o protegidos de alguna otra manera.
3. Políticas de acceso. Por ejemplo, como decide la empresa quien deberá tener
acceso a que datos.
4. Problemas de operación. Por ejemplo, si se utiliza un esquema de control de
acceso por password, como se mantiene estos en secreto.
5. Controles de hardware. Por ejemplo, provee el procesador central de alguna
característica de seguridad, tales como llaves de protección de almacenamiento,
o un modo de operación privilegiada.
6. Seguridad del sistema operativo. Por ejemplo, cual es el esquema de
protección.
7. Situaciones que conciernen específicamente al propio manejador de la base de
datos. Por ejemplo, puede un usuario tener acceso al campo A y no tener
acceso al campo B, si tanto A como B pertenecen al mismo registro.
Algunos ejemplos de lo que podría verificar el subsistema de seguridad de una base
de datos son los siguientes.
133
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Considerando la relación empleados (num - emp, nombre, dirección, departamento,
sueldo, evaluación-desempeño), los niveles de acceso a esta relación que podrían ser
otorgados a algún usuario en particular son:
1. El usuario tiene acceso sin restricciones a la relación completa para cualquier
tipo de operación.
2. El usuario no tiene acceso a la relación para ningún tipo de operación.
3. El usuario puede consultar cualquier parte de la relación pero no modificarla.
4. Puede ver exactamente un registro en la relación (del cual es propietario) pero
no cambiarlo.
5. Puede ver exactamente un registro (del cual es propietario) y dentro del registro
puede alterar únicamente el nombre y la dirección.
6. Puede ver únicamente el número de empleado, el nombre, la dirección y el
departamento de cualquier registro de la relación y puede modificar solamente
los valores del nombre, dirección y departamento.
7. Puede ver los campos del número de empleado, sueldo y puede modificar el
sueldo pero solamente entre las 9 y 17 horas, y en una terminal localizada en la
oficina de personal.
8. Puede ver los números de empleado y sueldo, y puede alterar el valor del sueldo
pero solo si el valor actual de este es menor de 5000.
9. El usuario puede aplicar operadores estadísticos al campo de sueldo, pero no
leer o alterar valores individuales.
10. El usuario puede ver los campos de número de empleado, nombre y la
evaluación del desempeño, y puede alterar la evaluación al desempeño si y solo
si es el gerente del departamento.
4.4.1 Identificación y autentificación
De la definición de seguridad se deduce que el sistema no debe permitir que se
ejecute cualquier operación sobre la base de datos a menos que el usuario este
autorizado para realizada.
En los sistemas multiusuario, el sistema operativo requiere de un nombre de usuario
(Login Name) y de una contraseña (Password) para permitir al usuario el acceso al
sistema. Existen algunos DBMS, tales como DB2 UDB de IBM, los cuales confían el
134
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
control de acceso al sistema operativo, esto es, si el usuario logro ingresar al sistema
operativo es un usuario valido para el DBMS y puede acceder a los datos.
Existen, también, otros DBMS en los que el sistema mantiene un registro en el que
se especifican los objetos que el usuario esta autorizado para accesar y las
operaciones que tiene autorizado ejecutar sobre los objetos.
Antes de accesar la base de datos, los usuarios se tendrán que identificar, esto es,
decir quienes son. Este paso direcciona el sistema al registro del usuario (USER
PROFILE) apropiado.
Normalmente los usuarios necesitan autentificar su identidad a través de password.
El proceso de identificación puede involucrar el que se provea al usuario con una
cuenta que el puede teclear directamente en su termina] o a través de algún otro medio
(voz, huellas digitales o tarjetas).
El proceso de autentificación involucro el proporcionar información solamente
conocida por el usuario propietario de la cuenta.
4.4.2 Reglas de autorización
El sistema debe permitir la definición de reglas que deberán ser expresadas en
algún lenguaje de alto nivel, por ejemplo SQL utiliza el comando GRANT, GRANT
SELECT ON empleado TO Jones, esta instrucción especifica que el usuario Jones esta
autorizado para ejecutar operaciones de selección sobre la relación empleados, esta
información se almacena en el USER PROFILE de Jones. Las reglas de autorización
serán compiladas y almacenadas en el diccionario de datos y una vez incluidas en
este, el DBMS forzará que se cumplan.
Es conveniente considerar al conjunto de todos los USER PROFILES como una
matriz de autorización en la cual, los renglones corresponden a los usuarios y las
columnas a los objetos de datos, de tal forma que A[I,J] representa al conjunto de
reglas de integridad que se aplican al usuario I con respecto al objeto J.
La granularidad de los objetos para los cuales pueden existir columnas en la matriz
de autorizaciones es una medida de lo sofisticado del sistema; por ejemplo algunos
sistemas soportan solamente a nivel de relaciones completas, mientras que otras
135
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
permitirán la autorización a nivel de campos individuales. Sin embargo una medida
significativa esta dada por el rango de características que se permite incluir en el
cuerpo de la matriz.
4.4.3 Encriptación de datos
Se ha asumido que los usuarios intentaran acceder la base de datos por los medios
normales de acceso, esto es, accesado a la red por medio de un usuario y contraseña,
a si mismo, que existe dentro del DBMS existe una matriz de accesos para este
usuario en la cual se han especificado reglas de autorización para este. Considérese
ahora el caso en que un "usuario" intenta acceder a la información rompiendo o
eludiendo los métodos de seguridad establecidos, por ejemplo, robando parte de la
información almacenada en algún medio de respaldo, o corriendo algún programa que
logre romper la seguridad del sistema operativo y del DBMS, o interceptando las líneas
de comunicación, es importante recordar que la mayor parte de la comunicación dentro
de una base de datos distribuida es hacia y desde fuera de la red de área local.
Una forma efectiva de prevenir que estos "usuarios” puedan ver la información
contenida en la base de datos, es la encriptación de datos, esto es, almacenar y
transmitir todos los datos, mensajes, contraseñas en una forma encriptada.
En el concepto de la encriptación, los datos originales son llamados texto plano. El
texto plano es encriptado por algún algoritmo de encriptación, el cual requiere del texto
plano y de una llave de encriptación, obteniendo así, la forma encriptada del texto
plano, conocida como texto cifrado.
4.4.4 Encriptación por sustitución
El método de sustitución es uno de los métodos más sencillos de encriptación de
datos, es necesario tener una llave para determinar los caracteres de texto cifrado los
cuales sustituirán a los caracteres del texto plano. A continuación se presenta un
ejemplo:
Teniendo como llave de encriptación la palabra ELIOT, se encriptará el siguiente
texto:
136
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
AS KINGFISHERS CATCH FIRE
1.- Dividir el texto plano en grupos de caracteres de la misma longitud de la
llave:
AS_KI NGFIS HERS_ CATCH _FIRE
2.- Remplazar cada carácter del texto plano por un entero en el rango de 0-26,
usando_= 00, A=01, B=02, ..., Z=26:
0119001109 1407060919 0805181900 0301200308 0006091805
3.- Repetir el paso 2 para la llave de encdptación:
0512091520
4.- Para cada grupo del texto plano, remplazar cada carácter por la suma,
módulo 27, de su código y el código de la llave de encriptación:
0119001109 1407060919 0805181900 0301200308 0006091805
0512091520 0512091520 0512091520 0512091520 0512091520
064092602 1919152412 1317000720 0813021801 0518180625
5.- Remplazar cada código por su correspondiente carácter, de acuerdo al
código del paso 2:
FDIZB SSOXL MQ_GT HMBRA ERRFY
El problema que se podría presentar en este método es, como dificultarle a un
posible "usuario” infiltrado el hecho de determinar la llave de encriptación. Es posible
también combinar con este método, el método de permutación, el cual consiste en
reordenar los caracteres resultantes de a cuerdo a alguna secuencia, previamente
definida.
137
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
4.4.5 Encriptación de llave publica
En este esquema de encriptación, la llave de encriptación es conocida por todos, y
cualquier persona puede convertir texto plano a texto cifrado. Pero la llave de
desencriptación es mantenida en secreto ( este esquema involucro dos llaves, una
para encriptar y otra para desencriptar). La llave de desencriptación no puede ser
deducida a partir de la llave de encriptación; de esta manera la persona que ejecuta la
encriptación no podrá ejecutar la desencriptación si no esta autorizada para hacerlo.
Este método de encriptación se basa en los siguientes hechos:
1.- Existe un algoritmo rápido para determinar si cualquier número grande es
primo.
2.- No hay un algoritmo rápido para determinar los factores primos de un número
grande.
Este método funciona de la siguiente manera:
1.- Se eligen, de forma aleatoria, dos numero primos largos distintos p y q, para
mayor seguridad deben de ser superiores a 80 dígitos.
Obténgase el producto r = p * q
2.- Se elige, aleatoriamente, un entero grande e que es primo con respecto a (p -1)
* (q - l); y que el mayor común divisor entre e y (p -1) * (q - 1) es 1. Entonces e es la
llave de encriptación.
3.- Se calcula la llave de desencriptación, d, la cual corresponde al único inverso
multiplicativo de e, módulo (p -1) * (q - l); esto es:
(d * e) módulo (p -1) * (q - 1) = 1
4.- Se dan a conocer e y r, pero no d, la cual es la llave de desencriptación.
138
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
5.- Para encriptar una parte del texto plano P ( se asume por simplicidad que es un
entero menor a r ), y se reemplaza por el te)do cifrado C, obtenido de la siguiente
manera:
C = Pe módulo r
6.- Para desencriptar una parte del texto cifrado, este es reemplazado por P, que
se obtiene de la siguiente manera:
P = Cd módulo r
A continuación se presenta un ejemplo, por razones de facilidad se utilizaran
números pequeños:
Dados p = 3, q = 5, P = 13
r = 3 *5 = 15
(p –1) * (q - 1) = (3 -1) * (5 - 1) = 8
se tiene e = 11 (es un numero primo mayor a p y q)
ahora se calcula d
(d * 3) módulo 8 = 1
La función módulo obtiene únicamente el residuo de la división y se tiene que d = 3
cumple con esta condición
Ahora se encripta P de la manera siguiente:
C = Pe módulo r
C = 1311 módulo 15
= 1792160394037 módulo 15
= 7 (este es el residuo de la división entera de 1792160394037 entre 15)
139
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Para desencriptar C se realiza el siguiente proceso:
p = Cd módulo r
P = 73 módulo 15
= 343 módulo 15
= 13 este es el residuo de la división entera de 343 entre 15)
4.5 Resumen
Una transacción accesa la base de datos usando primitivas de lectura y escritura.
El conjunto de elementos de lectura de datos para una transacción es llamado conjunto
lector y el conjunto de elementos de escritura de datos para una transacción es
llamado conjunto escritor. Dos transacciones Ti y Tj se ejecutan serialmente en una
planificación S, si la ultima operación de Ti precede a la primera operación de Tj en S.
En otro caso las transacciones se ejecutarían concurrentemente.
140
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
En una planificación, si la operación O¡ precede a la operación O¡, se indica como
O¡ < Oj, es decir Oi se ejecuta primero que O¡.
Las transacciones se ejecutarán lo más concurrentemente posible, cuidando que
esta ejecución sea correcta. La definición más aceptada de correcto en una bitácora es
basada en la seriabilidad:
Una planificación es correcta si esta es seriabilizable, esto es, que sea
equivalente a una planificación serial.
Un mecanismo de control de concurrencia es correcto si permite a las transacciones
ejecutarse en una secuencia tal que solo una planificación señalizaba podría producir.
Un mecanismo de control de concurrencia restringe las posibles secuencias de
operación ejecutados por una transacción que fuerza a otra transacción a esperar
mientras la primera termina de realizar sus operaciones.
Las siguientes dos condiciones son suficientes para decir que dos planificaciones
son equivalentes:
1. Cada operación de lectura lee los mismos valores que fueron producidos por
las mismas operaciones de escritura en ambas planificaciones.
2. La operación de escritura final es igual en ambas planificaciones.
Es importante también considerar el hecho de que dos operaciones pueden llegar a
caer en conflicto:
Dos operaciones están en conflicto si, ellas procesan el mismo dato y
al menos una de estas operaciones es una operación de escritura, y
estas operaciones pertenecen a diferentes transacciones.
Usando este concepto es posible obtener una definición de planificación equivalente
de otra manera:
141
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Dos planificaciones S1 y S2 son equivalentes si por cada par de
operaciones en conflicto O¡ y Oj, donde O¡ < Oj en S1, entonces
O¡ deberá preceder a Oj en S2.
En una base de datos distribuida, cada transacción ejecuta operaciones en vanos
sitios. La secuencia de operaciones procesada por las transacciones en un sitio es
una planificación local.
Si se aplica en cada sitio un mecanismo de control de concurrencia se aseguraría
que todas las planificaciones locales son serializables. Sin embargo, la seriabilidad
local no es suficiente para asegurar la exactitud de la ejecución de un conjunto de
transacciones distribuidas.
La ejecución de las transacciones T1, ..., Tn es correcta sí:
1. Cada entrada local Sk es serializable.
2. Existe un orden total de T1, ..., Tn tal que, si Ti < Ti en el orden total, entonces
hay una entrada serial Sk‘ tal que, Sk es equivalente a Sk ' y Ti < Tj en el
Señal(Sk'), para cada sitio k donde ambas transacciones tienen algún proceso
en ejecución.
La anterior definición puede ser explicada usando la definición de conflicto:
Sea T1, ..., Tn un conjunto de transacciones, y sea E una ejecución de
estas transacciones, modelado por el conjunto de entradas de bitácora
Sl,... Sm. E es correcto (serializable) si existe un orden total de las
transacciones, y además para cada par de operaciones en conflicto O¡ y
Oj de las transacciones Ti y Ti respectivamente, O¡ precede a O¡ en
cualquier entrada Sl,.. Sn, si y solo si Ti precede Tj en el orden total.
La idea básica del bloqueo (lock) es que cuando una transacción requiera accesar
un registro, esta bloquee dicho registro antes de intentar el acceso, y cuando una
transacción intente bloquear un registro que anteriormente ya fue bloqueado por otra
transacción, la primera deberá esperar a que la otra transacción libere dicho bloqueo
(unlock).
142
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Una transacción siempre deberá bloquear un registro de forma compartida antes de
leer el contenido, y bloquear de modo exclusivo antes de escribir.
Existen dos reglas de compatibilidad entre los modos de bloqueo:
1. Una transacción puede bloquear un registro, sí este no esta bloqueado o sí lo
esta de manera compartida.
2. Una transacción puede bloquear de manera exclusiva, solo si el registro no esta
bloqueado.
Otra condición que se deberá de tener en cuenta es que, una transacción no debe
de requerir de un nuevo bloque después de que se libere algún registro, esto quiere
decir que la transacción debe de tener un bloqueo de dos fases (2PL), esto porque la
primera fase sería el bloqueo de todos los registros necesarios para realizar la
transacción, y la segunda fase es en la cual se hace la liberación de todos los registros
antes bloqueados.
Los manejadores de transacciones locales interpretan las primitivas locales de
bloqueo (bloqueo local compartido, bloqueo local exclusivo y, liberación local), mientras
que los agentes de la transacción procesan las primitivas globales (bloqueo
compartido, bloqueo exclusivo, y liberación). Entender los aspectos peculiares del
control distribuido de concurrencia es equivalente a comprender lo que el manejador
distribuido de transacciones tiene que hacer para garantizar que la transacción global
tenga las características de sociabilidad y aislamiento.
El manejador de transacciones distribuidas tiene que traducir la primitiva de bloqueo
emitida por un agente en un registro de tal manera que sea imposible que un bloqueo
pase inadvertido por una transacción. De esta manera, una primitiva de bloqueo es
traducida en varias primitivas de bloqueo, tantas como copias de datos se deseen
bloquear.
Existen esquemas alternativos para lograr evitar conflictos en los bloqueos:
143
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
1. Write-locks-all, read-locks-one. En este esquema los bloqueos exclusivos son
adquiridos en todas las copias, mientras que los bloqueos compartidos son
adquiridos únicamente en alguna copia arbitraria.
2. Mayoría de bloqueos. En ambos bloqueos compartido y exclusivo son
requeridos en una mayoría de las copias de los registros (el número de copias
que se bloquean son estrictamente más grande que el número de copias que no
se bloquean).
3. Bloque de copia primaria. Una de las copias de cada dato es privilegiada
(llamada copia primaria) y todos los bloqueos se hacen sobre esta copia.
Considérese primero que si todas las transacciones logran un bloqueo de 2 fases,
entonces todas las entradas de bitácora son serializables. Si una transacción
distribuida logra un bloqueo de dos fases entonces todas las subtransacciones en los
diferentes sitios, lograrán separadamente un bloqueo de dos fases.
Considérese ahora que, las transacciones T1, T2, ..., Tn requieren de un bloqueo de
dos fases, cada una de estas transacciones requieren de bloquear un dato el cual, ya
esta bloqueado por otra transacción. Por lo tanto cada una de ellas tendrá que esperar
hasta que otra transacción libere el bloqueo. Sin embargo, desde el momento en que
las transacciones utilizan el bloqueo de dos fases, estas no pueden liberar el bloqueo,
sino hasta que se logran todos los bloqueos requeridos por dicha transacción. Por lo
tanto n transacciones alcanzarán un estado de deadlock, y pueden estar esperando
por siempre. Entonces, una de estas transacciones deberá ser abortada por algún
algoritmo de solución de deadlock. En cualquier caso, el conjunto de transacciones no
podrá ocurrir.
Para lograr un análisis del grado de concurrencia que es permitido por el algoritmo
de control de concurrencia, es necesario incluir en el modelo de ejecución la noción de
"operaciones concurrentes" en diferentes sitios. Se representan dos operaciones
concurrentes colocándolas una sobre otra, en la ejecución concurrente de
transacciones.
En un sistema distribuido, es necesario, algunas veces, conocer si un evento A en
algún sitio ocurrió antes o después que un evento B en un sitio diferente.
144
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Varios métodos de control de concurrencia y algoritmos de prevención de deadlock
requieren determinar el orden en que se realizarán los eventos. La determinación de
un orden de eventos consiste en asumir que a cada evento A, el cual ocurre en un
sistema distribuido, se asigna una etiqueta de tiempo TS(A) (timestamp) con las
siguientes propiedades:
1. TS(A) identifica de manera única a A (diferentes eventos tienen diferentes
etiquetas de tiempo).
2. Para dos eventos cualquiera A y B, si A ocurre antes que B, entonces TS(A) <
TS(B).
La relación “ocurre antes”, denotada por → puede ser generalizada en un sistema
distribuido por medio de las siguientes reglas:
1. Si A y B son dos eventos en el mismo sito y A ocurre antes que B, entonces
A→S.
2. Si el evento A consiste en enviar un mensaje y el evento B consiste en recibir
el mensaje de A, entonces A→B.
3. Si A→B y B→C, entonces A→C.
La detección y solución de deadlocks constituye una actividad importante de un
sistema manejador de bases de datos. La detección de deadlocks es más difícil en un
sistema distribuido que un centralizado, esto, debido a un ciclo de espera involucro
varios sitios.
La figura se muestra una gráfica wait-for distribuido (DWFG):
145
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
T1A1
T2A1
Sitio 1
T1A2
T2A2
Sitio 2
T1A1
T2A1
Sitio 1
T1A2
T2A2
Hay dos razones por las cuales un agente esperaría a otro:
1. T1A1 espera que T2A1 libere recursos en el sitio 1. Este tipo de espera se
representa por una flecha continua en la gráfica.
2. El agente TiAj requiere que el agente TiAs ejecute alguna función en un sitio
diferente. Este tipo de espera es representado por una flecha discontinuo en la
gráfica.
La porción de una DWFG que contiene únicamente los nodos y flechas
concernientes a un solo sitio se llama gráfica wait-for local. Dichas LWFG se extienden
con flechas, desde y hacia los nodos los cuales representan a agentes que tienen
conexión con el nodo local. Los nodos cuadrados son llamados puertos de entrada si
tienen una flecha hacia dentro de la gráfica, y puertos de salida si las flechas salen.
Un deadlock es local si es causado por un ciclo en una LWFG o distribuido si es
causado por un ciclo en una DWFG el cual no esta contenido en una LWFG.
La solución a un deadlock involucro la selección de una o más transacciones que
pueden se abortadas y reiniciadas. Un criterio para seleccionar que transacción será
abortada, pudiera ser el que se aborte la transacción que implique el menor costo en
dicha operación. Otros criterios podrían ser, el abortar la transacción más joven;
abortar la transacción que tiene la menor cantidad de recursos; o abortar la transacción
que requiere más tiempo para terminar.
Algo que se debe de tener en cuenta es que, la redundancia incremento la
posibilidad de un deadlock.
La recuperación en un sistema de bases de datos, significa, primero que nada
recuperar la propia base de datos, esto es, restaurar la base de datos a un estado que
se sabe es correcto, después de que una falla la ha llevado a un estado incorrecto o al
146
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
menos incierto. El principio en el cual se basa la recuperación es la redundancia. Esto
es la forma de proteger la base de datos y asegurarla de manera de que cualquier
parte de la información almacenada en ella pueda ser reconstruida de alguna otra
información almacenada redundantemente en alguna parte del sistema. Se debe
incluir algún procedimiento de recuperación, el cual puede consistir en forma general
de lo siguiente:
1. Periódicamente, tal vez diario, hacer una copia de respaldo de la base de datos
completa.
2. Cada vez que se haga un cambio en la base de datos, se escribe un registro en
un conjunto de datos especial llamado bitácora.
3. Si ocurre una falla hay dos posibilidades:
a) Que la base de datos no se halla dañado pero su contenido es incierto en
este caso la base de datos se restaura a un estado correcto utilizando la
bitácora.
b) La base de datos se daña físicamente, la solución en este caso consiste en
recuperar la base de datos utilizándola copia de respaldo más reciente.
El propósito fundamental de un sistema de bases de datos es realizar
transacciones. Una transacción es una unidad de trabajo que inicia con el operador
especial "BEGIN TRANSACTION" y termina con la operación 'COMMIT' o
"ROLLBACK". El commit se usa para indicar una terminación exitosa, el rollback se
utiliza para indicar una terminación no exitosa.
Todas las acciones recuperables deben ser ejecutadas dentro de los limites de una
transacción, una operación recuperable es una operación que puede ser deshecha o
rehecha en el caso de alguna falla, que se deben registrar en la bitácora.
Las transacciones son proposiciones de todo o nada, se debe garantizar al usuario
que cada transacción es ejecutada completamente o no se ejecuta en lo absoluto.
Una operación rollback permite asegurarse de que una falla no corrompa la base de
datos, en el caso de que la transacción por si misma descubra la condición de la falla.
147
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Los tipos de fallas que pueden ocurrir, caen en las siguientes categorías:
1. Fallas locales de la transacción, que son detectadas por el código de la
aplicación.
2. Fallas locales de transacción, que no son explícitamente manejadas por el código
de la misma.
3. Fallas del sistema que afectan a todas las transacciones que se encuentran en
ejecución, pero que no dañan la base de datos.
4. Fallas en el medio que dañan la base de datos o alguna porción de esta y
afectan a todas las transacciones que están utilizando esta parte.
El término fallas de transacción se usa para indicar una falla causada por una
terminación no planeada y anormal de un programa. Lo que ocurre cuando se da una
condición de este tipo, por regla general es lo siguiente:
1. Cuando se presenta una condición de error, el sistema enciende una condición
para ese tipo de error en particular. El programador tiene la opción de incluir
explícitamente el código correspondiente para manejar esta condición.
2. El sistema enciende una condición de error generalizada, de nuevo el
programador tiene la opción de incluir el código correspondiente para manejar
esta condición.
3. En este punto el sistema provoca la terminación anormal del programa y envía
el mensaje correspondiente al usuario, y es solamente en este punto que se
dice que a ocurrido una falla de transacción.
La ejecución de un rollback explícito no esta considerado como una falla de
transacción, sino como una terminación anormal planeada de la transacción, no del
programa.
Una falla de transacción significa que la transacción no ha llegado a su terminación
planeada, por lo que es necesario que el sistema force un rollback.
El término faltas del sistema significa que algún evento causo que el sistema se
detuviera y esto requerirá un subsecuente reinicio del sistema: El contenido del
148
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
almacenamiento primario, se pierde, pero la base de datos no sufre daño alguno. Así,
las transacciones que en el momento de la falla se estuvieran ejecutando, se deberán
de deshacer, esto si es que estas no habían terminado.
Esto se puede resolver buscando en la bitácora desde el principio, identificando
aquellas transacciones para las cuales hay un registro de inicio de transacción (BT),
pero no un registro de terminación (commit o rollback).
El principio de check-point es muy simple:
A cierto intervalos preestablecidos, por ejemplo, cada cierto tiempo o número de
entradas de bitácora, el sistema realiza un check-point que consiste en los siguientes
pasos:
1. Forza el contenido de los buffers de bitácora hacia la bitácora física.
2. Forza la escritura de un registro de check-point en la bitácora.
3. Forza la escritura del contenido de los buffers de la base de datos, en la base
de datos almacenada físicamente.
4. Escribe la dirección del registro de check-point incluido en la bitácora en un
archivo de restablecimiento.
El registro de check-point contiene la siguiente información:
1. Una lista de todas las transacciones activas al momento del check-point.
2. La dirección del registro de bitácora más reciente de cada una de estas
transacciones.
Al momento del restablecimiento, el manejador de recuperación obtiene la dirección
del registro de check-point más reciente del archivo de restablecimiento, localiza este
registro de bitácora y procede a buscar adelante en la bitácora, desde este punto hasta
el final.
Para el propósito del restablecimiento, las transacciones pueden ser clasificadas en
5 categorías:
149
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Tipo Descripción
T1 Terminan antes del check-point
T2 Inician antes del check-point y terminan después de este
T3 Inician antes del check-point, sin embargo no han terminado al momento
de la falla.
T4 Inician después del check-point y terminan antes de que ocurra la falla
T5 Inician después del check-point, pero no termina porque se presenta la
falla.
Las transacciones del tipo T3 y T5 se deben deshacer y las del tipo T2 y T4 deberán
ser rehechas. Las transacciones del tipo T1 no se consideran en al proceso de
recuperación, ya que al realizar el paso 3 del check-point sus actualizaciones se
escribieron en la base de datos.
El término integridad se usa en el contexto de la base de datos con el significado de
correctez o validez, el problema de la integridad es el asegurarse que la base de datos
sea correcta.
Se asume la existencia de un subsistema de integridad con las siguientes
responsabilidades:
1. Monitorear las transacciones especialmente, operaciones de actualización y
detección de violaciones a la integridad de la base de datos.
2. En el caso de una violación, tomar la acción apropiada, por ejemplo,
rechazando la operación, reportando la violación o corrigiendo el error.
Con el fin de ejecutar estas acciones, se le debe de proveer al subsistema de
integridad, un conjunto de reglas que define que errores debe verificar y que hacer si
se detecta el error.
Las reglas de integridad se expresan en lenguajes de alto nivel, por ejemplo SQL, y
son compilada y almacenadas en el diccionario de datos de la base de datos. La
150
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
mayor ventaja de esto es que las validaciones son manejadas por el DBMS, en lugar
de las aplicaciones individuales. Otra de las ventajas es que las reglas se concentran
en el diccionario de datos en lugar de estar distribuidas en los programas de aplicación
Las reglas de integridad se pueden dividir en dos categorías:
Reglas de integridad de dominio.
Reglas de integridad de relación.
Se utiliza el término de seguridad en un contexto de bases de datos para indicar la
protección de la base de datos, acerca del acceso, alteración o destrucción no
autorizada. Existen numerosos aspectos del problema de seguridad, entre ellos los
siguientes:
1. Aspectos legales, sociales y éticos.
2. Controles físicos.
3. Políticas de acceso.
4. Problemas de operación.
5. Controles de hardware.
6. Seguridad del sistema operativo.
7. Situaciones que conciernen específicamente al propio manejador de la base
de datos.
De la definición de seguridad se deduce que el sistema no debe permitir que se
ejecute cualquier operación sobre la base de datos a menos que el usuario este
autorizado para realizarla, por lo que para cada usuario, el sistema debe mantener un
registro, especificar los objetos que el usuario esta autorizado para accesar y las
operaciones que tiene autorizados ejecutar sobre los objetos.
Este paso se direcciona el sistema al registro del usuario (USER PROFILE)
apropiado.
El sistema debe permitir la definición de reglas que deberán ser expresadas en
algún lenguaje de alto nivel, por ejemplo SQL utiliza el comando GRANT, GRANT
151
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
SELECT, esta instrucción especifica que el usuario esta autorizado para ejecutar
operaciones de selección sobre una relación, esta información se almacena en el
USER PROFILE. Las reglas de autorización serán compiladas y almacenadas en el
diccionario de datos y una vez incluidas en este, el DBMS forzará que se cumplan.
Es conveniente considerar al conjunto de todos los USER PROFILES como una
matriz de autorización en la cual, los renglones corresponden a los usuarios y las
columnas a los objetos de datos, de tal forma que A[I,J] representa al conjunto de
reglas de integridad que se aplican al usuario 1 con respecto al objeto J.
Se ha asumido que los usuarios intentaran acceder la base de datos por los medios
normales de acceso, esto es, accesado a la red por medio de un usuario y contraseña,
a si mismo, que existe dentro del DBMS existe una matriz de accesos para este
usuario en la cual se han especificado reglas de autorización para este.
Una forma efectiva de prevenir que "usuarios" no autorizados puedan ver la
información contenida en la base de datos, es la encriptación de datos, esto es,
almacenar y transmitir todos los datos, mensajes, contraseñas en una forma
encriptada.
En el concepto de la encriptación, los datos originales son llamados texto plano. El
texto plano es encriptado por algún algoritmo de encriptación, el cual requiere del texto
plano y de una llave de encriptación, obteniendo así, la forma encriptada del texto
plano, conocida como texto cifrado.
El método de sustitución es uno de los más sencillos métodos de eneriptación de
datos, es necesario tener una llave para determinar los caracteres de texto cifrado
los cuales sustituirán a los caracteres del texto plano. Es posible también combinar
con este método, el método de permutación, el cual consiste en reordenar los
caracteres resultantes de a cuerdo a alguna secuencia, previamente definida.
En el esquema de encriptación de llave publica, la llave de encriptación es conocida
por todos, y cualquier persona puede convertir texto plano a texto cifrado. Pero la llave
de desencriptación es mantenida en secreto (este esquema involucro dos llaves, una
para encriptar y otra para desencriptar). La llave de desencriptación no puede ser
deducida a partir de la llave de encriptación; de ésta manera la persona que ejecuta la
encriptación no podrá ejecutar la desencriptación si no esta autorizada para hacerlo.
152
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
4.6 Preguntas de repaso
1.- ¿Cuál es la condición para que dos transacciones sean serializables?
Dos transacciones Ti y Tj se ejecutan serialmente en una planificación S, si la última
operación de Ti precede a la primera operación de Tj en S.
2.- ¿Cuándo dos transacciones son concurrentes?
Dos transacciones son concurrentes si no cumplen la condición de seriabilidad.
3.- ¿Cuáles son las dos condiciones que deben cumplir dos planificaciones para
que sean equivalentes?
4.- ¿Por qué dos operaciones pueden caer en conflicto?
Dos operaciones están en conflicto, cuando procesan el mismo dato y al menos una
de ellas es una operación de escritura, y dichas operaciones pertenecen a diferentes
transacciones.
5.- ¿Cómo funciona el control de concurrencia basado en bloqueos distribuidos?
6.- Mencione y describa los esquemas o métodos que existen para evitar los
conflictos entre bloqueos.
Write - lock - all, read - lock - one : Los bloqueos exclusivos se hacen en
todas las copias que existen del fragmento, mientras que los bloqueos
compartidos se hacen solo en una de las copias.
Mayoría de bloqueos: Tanto los bloqueos exclusivos como los
compartidos son hechos en la mayoría de las copias existentes,
tomando en cuenta que el número de copias bloqueadas sea mayor que
el número de las no bloqueadas.
Bloqueo de copia primaria: Todos los bloqueo son hechos en una sola
copia del fragmento, llamada copia primaria.
7.- Explique brevemente en que consiste el bloqueo de 2 fases.
153
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
8.- ¿En que consisten las etiquetas de tiempo?
Una etiqueta de tiempo, es un identificador único asignado a cada transacción
lanzada en el sistema. Esta etiqueta es utilizada para saber en que orden fueron
lanzadas cada una de las transacciones y en dado momento, poder decidir cual podría
ser abortada en caso de presentarse un interbloqueo.
9.- ¿Que se entiende por deadlocks distribuidos?
10.- ¿Que es la recuperación?
La recuperación de un sistema de bases de datos consiste en llevarla a un estado
correcto después de que ha ocurrido una falla y la base de datos se encuentra en un
estado incorrecto o incierto.
11.- ¿De que manera garantizamos que en dado momento, una base de datos
pueda ser recuperada?
12.- Además de la replicación de la base de datos, ¿qué es recomendable hacer?
Junto con la replicación, es necesario llevar una bitácora de todos y cada uno de las
actualizaciones hechas a la base de datos, esto para que en caso de una falla, se
realicen un recorrido secuencias a la bitácora y se rehagan todas éstas actualizaciones
después de haber recuperado la base de datos a partir de la copia, esto para que las
pérdidas de información sean mínimas o casi nulas.
13.- ¿Que tipos de fallas pueden darse en un sistema de base de datos?
14.- ¿Que se entiende por integridad en un sistema de bases de datos?
Una base de datos es integra cuando todos los datos almacenados en ella son
correctos o validos en el contexto de la definición de la base de datos.
15.- ¿Cuales son las responsabilidades de un subsistema de integridad?
16.- ¿Explique la regla de integridad de dominio?
154
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Cada atributo de la relación esta definido sobre un dominio, identificado en la
definición de la relación y todo valor de este atributo debe estar definido dentro del
domino.
17.- ¿A que se refiere la palabra seguridad dentro del ámbito de las bases de datos?
18.- ¿Mencione 5 aspectos que se deben tomar en cuenta dentro de la seguridad de
las bases de datos?
La existencia de controles de seguridad físicos.
Las políticas de acceso.
Los controles de acceso por medio de hardware.
La seguridad del sistema operativo.
Las situaciones concernientes al DBMS.
19.- ¿Que son las reglas de autorización?
20.- ¿Que es la encriptación de datos?
La encriptación de datos es el hecho de almacenar o transmitir la información de
manera que no seria entendible para cualquier persona que intentara accesaria
4.7 Ejercicios
1.- Para las siguiente tabla defina las reglas de integridad para el retiro de
fondos, creación de una cuenta, transferencia de fondo y para la cancelación de una
cuenta (considerando que existe una tabla de movimientos).
Cuentas
Id_cuenta Saldo
C12 458
C23 8541
C54 2369
C78 500
2.- Tomando en cuenta la tabla y regla de integridad anteriores, realice las
siguientes transacciones y regístrelas en una bitácora,
155
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
T1: Transferencia de la cuenta C23 a C12 por 1500.
T2: Deposito de 1234 a la cuenta C78.
T3: Retiro de 2000 de la cuenta C12.
T4: Transferencia de [a cuenta C12 a C78 por 1960.
T5: Cancelación de la cuenta C54.
3.- Utilizando el método de encriptación de llave publica, y teniendo encuentra
que p = 5 y q = 7, realice la encriptación y desencriptación de los siguientes
números: 8, 9.
Bibliografía
[1] Date, C.J.; "An lntroduction to Databases Systems"; Volume 1; Fifth Edition;
Addison-Wesley Publishing Company; U.S.A.; Reprinted July, 1990
[2] Date, C.J.; "An lntroduction to Databases Systems"; Volume 11; Addison-Wesley
Publishing Company; U.S.A.; Reprinted July, 1995
[3] Korth, Henry F. Silberschatz, Abraham; @Database System Concepts"; Second
Edition McGraw-Hili; U.S.A.; lnternational Edition 1991
156
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Respuestas a preguntas y ejercicios de repaso
Capítulo I
Preguntas de repaso
2.-
La mayor parte de las organizaciones ya están distribuidas.
Permiten interconexión de las bases de datos existentes.
Es posible realizar un desarrollo incrementar.
Permite reducir la carga de las líneas de comunicación.
Existe un incremento en el desempeño del sistema.
Son más confiables.
La mayor parte del tiempo se encuentra disponible la información.
4.-
Porque describe la forma en como deberá de funcionar una base de datos
distribuida. Vista desde el exterior la distribución será completamente transparente,
6.-
Significa que el usuario nunca vera la base de datos como un conjunto de
fragmentos situados en diferentes sitios, sino por el contrario, para él, la base de datos
se encuentra íntegramente en su estación de trabajo o sitio de trabajo.
8.-
157
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Es llamado por el usuario y se ejecuta durante la sesión.
Se ejecuta de modo local.
Tiene capacidad de iniciar la comunicación con el servidor.
10.-
Deberá ser capaz de soportar múltiples usuarios.
Deberá ser capaz de satisfacer las demandas de los clientes.
Deberá de proveer altos niveles de desempeño-
Deberá de contar con capacidad de red.
Capítulo II
Preguntas de repaso
2.-
Procesamiento local: Los datos son colocados en el sitio o cerca del sitio
donde residen las aplicaciones que los utilizan.
Disponibilidad y confiabilidad de los datos distribuidos: Debido a que e>dsten
vanas copias de la información, es posible conmutar a una copia altema
cuando la copia que era accesada comúnmente no se encuentre disponible.
Distribución de la carga de trabajo: La carga de trabajo es distribuida en
relación con la capacidad de cómputo de cada uno de los sitios participantes,
permitiendo un grado más alto de paralelismo-
Costo de almacenamiento: Los costos del almacenamiento son reducidos al
fragmentar la base de datos global en diferentes sitios, y esto garantiza
espacio disponible en algún sitio para el almacenamiento de nueva
información.
4.-
Fragmentación horizontal primaria: Consiste en particionar las tuplas de una
relación global en subconjuntos de tuplas, donde cada uno de estos tiene
propiedades geográficas comunes. La reconstrucción de la relación global se
lleva a cabo por medio de la operación unión.
Fragmentación horizontal derivada: Esta genera cuando una relación no puede
ser fragmentada en base a alguna propiedad de sus atributos, entonces, su
fragmentación se deriva de la fragmentación horizontal de otra relación.
158
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Fragmentación vertical: se obtiene por la subdivisión de sus atributos en
grupos. Los fragmentos son obtenidos por medio de proyecciones sobre la
relación global. La reconstrucción de la relación global se da por medio de una
operación join.
Fragmentación mixta: Los fragmentos son obtenidos a partir de la aplicación de
fragmentaciones iterativas sobre la relación global. La reconstrucción de la
relación se logra al aplicar las operaciones en orden inverso a la fragmentación.
Ejercicios de repaso
1.-
q1: Obtener los nombres de todos los clientes.
q2: Obtener los números de cliente (no_cli) por estado.
q3: Obtener los nombres de los clientes (nom_cli) por empresa.
No_cli Nom_cli Empresa Estado
C01 Juárez Gamesa Gto
C02 Vidal Lara Qro
C03 Ávila Gamesa Jal
C04 Mejía Lara Jal
C05 Herrera Lara Gto
C06 Cervantes Gamesa Qro
q2= { Estado = Gto, Estado = Qro, Estado = Jal
q3= { Empresa = Gamesa, Empresa = Lara}
P1={Ciudad = Gto}, P2={Ciudad = Oro}, P3={Ciudad = Jal}
P4={Empresa = Gamesa}, P5={Empresa = Lara}
159
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
M1 = Gto ^ ~Qro ^ ~Jal ^ ~Gamesa ^ Lara si
m2 = Gto ^ ~Qro ^ ~Jal ^ Gamesa ^ ~Lara si
m3 = ~Gto ^ Qro ^ ~Jal ^ ~Gamesa ^ Lara si
m4 = ~Gto ^ Oro ^ ~Jal ^ Gamesa ^ ~Lara si
m5 = ~Gto ^ ~Qro A Jal ^ ~Gamesa ^ Lara si
m6 = ~Gto ^ ~Qro ^ Jal ^ Gamesa ^ ~Lara si
m7 = ~Gto ^ ~Oro ^ ~Jal ^ ~ Gamesa ^ ~Lara no
m8 = Gto ^ Oro ^ Jal ^ Gamesa ^ Lara no
m9 = Gto ^ Oro ^ Jal ^ Gamesa ^ ~Lara no
m10 = Gto ^ Oro ^ Jal ^ ~Gamesa ^ Lara no
m11 = Gto ^ Oro ^ Jal ^ ~ Gamesa ^ ~-Lara no
m12 = Gto ^ Qro ^ ~ Jal ^ Gamesa ^ Lara no
.
. no
.
m1 = Gto ^ Lara
m2 = Gto ^ Gamesa
m3 = Oro ^ Lara
m4 = Oro ^ Gamesa
m5 = Jal ^ Lara
m6 = Jal ^ Gamesa
m1
No_cli Nom_cli Empresa Estado
C05 Herrera Lara Gto
m2
No_cli Nom_cli Empresa Estado
C01 Juárez Gamesa Gto
160
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
m3
No_cli Nom_cli Empresa Estado
C02 Vidal Lara Qro
m4
No_cli Nom_cli Empresa Estado
C06 Cervantes Gamesa Qro
m5
No_cli Nom_cli Empresa Estado
C04 Mejía Lara Jal
m6
No_cli Nom_cli Empresa Estado
C03 Ávila Gamesa Jal
3.-
q1: Obtener los nombres de todos los clientes.
q2: Obtener los números y nombres de los clientes por estado.
q3: Obtener los nombres de los clientes por empresa.
Matriz de accesos
S1 S2
Ql 3 2
161
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
q2 2 1
q3 1 1
q1= Select Nom_cli
From clients
q2= Select no_cli, Nom_cli
From clients
Where Estado
q3= Select Nom-cli
From clientes
Where Empresa = y
A1 no_cli A2 nom_cli A3 Empresa A4 Estado Tot de accesos
q1 0 1 0 0 5
q2 1 1 0 1 3
q3 0 1 1 0 2
Al A2 A3 A4
Al 3 3 0 3
A2 3 10 2 3
A3 0 2 2 0
A4 3 3 0 3
162
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
F1={No_cli, Nom_cli}
F2={No_cli, Empresa, Estado}
O
F1={ No_cli, Nom_cli, Empresa}
F2={ No el¡, Estado}
Capítulo III
Preguntas de repaso
2.-
Es necesario definir el número de copias físicas de cada uno de los fragmentos
que existen en el sistema, y obtener una expresión de consulta sobre cada uno
de los fragmentos.
Se deberá seleccionar el orden de ejecución del conjunto de consultas sobre
cada uno de los sitios.
Seleccionar el método optimo para la ejecución de cada operación.
4.-
Son expresiones que aparecen más de una vez dentro de una misma consulta y
que solo deberá ser ejecutada una sola vez para optimizar la ejecución de la consulta.
6.-
Iteración simple.
Iteración orientada a bloques.
Merge - join.
Hash - join.
Tree - way join.
Join paralelo
Pipeline muitiway join.
8.-
163
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Convertir la consulta a alguna expresión apropiada par el sistema administrador
de la base de datos, para que de esta manera pueda ser ejecutada
adecuadamente, eliminando las características de la sintaxis del lenguaje de
nivel externo con el cual fue hecha la consulta.
Convertir la consulta a su forma canónica, es decir, llevar a la expresión hasta
su forma más simple posible, eliminando expresiones comunes y repetidas, y
reduciendo su costo de procesamiento.
Elegir el procedimiento para evaluar la consulta, ésta, expresada en su forma
canónica, generando, generando subprocedimientos para la ejecución de las
operaciones de bajo nivel, tales como join, select, etc.
Por ultimo, se construyen un conjunto de planes de ejecución de la consulta y
se elige el más económico de ellos. Donde económico se refiere a la ejecución
de menor costo en el sistema.
164
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Ejercicios de repaso
1.-
PJEMP:NOM
DF
JNDEPTNUM=DEPTNUM JNDEPTNUM=DEPTNUM
EMP SLDESC=X SLSAL<=11000 SLDESC=x
DEPT EMP DEPT
3.
PJEMP:NOM
EMP SLDESC=X
DEPT
Capítulo IV-
Preguntas de repaso
2.-
Dos transacciones son concurrentes si no cumplen la condición de seriabilidad.
4.-
165
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
SLSAL>35000
JNDEPTNUM=DEPTNUM
DF
Dos operaciones están en conflicto, cuando procesan el mismo dato y al menos una
de ellas es una operación de escritura, y dichas operaciones pertenecen a diferentes
transacciones.
6.-
Write - lock - all, read - lock - one : Los bloqueos exclusivos se hacen en
todas las copias que existen del fragmento, mientras que los bloqueos
compartidos se hacen solo en una de las copias.
Mayoría de bloqueos: Tanto los bloqueos exclusivos como los
compartidos son hechos en la mayoría de las copias existentes,
tomando en cuenta que el número de copias bloqueadas sea mayor que
el número de las no bloqueadas.
Bloqueo de copia primaria: Todos los bloqueo son hechos en una sola
copia del fragmento, llamada copia primaria.
8.-
Una etiqueta de tiempo, es un identificador único asignado a cada transacción
lanzada en el sistema. Esta etiqueta es utilizada para saber en que orden fueron
lanzadas cada una de las transacciones y en dado momento, poder decidir cual podría
ser abortada en caso de presentarse un interbloqueo.
10.-
La recuperación de un sistema de bases de datos consiste en llevarla a un estado
correcto después de que ha ocurrido una falla y la base de datos se encuentra en un
estado incorrecto o incierto.
12.-
Junto con la replicación, es necesario llevar una bitácora de todos y cada uno de las
actualizaciones hechas a la base de datos, esto para que en caso de una falla, se
realicen un recorrido secuencias a la bitácora y se rehagan todas éstas actualizaciones
después de haber recuperado la base de datos a partir de la copia, esto para que las
perdidas de información sean mínimas o casi nulas.
166
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
14.-
Una base de datos es integra cuando todos los datos almacenados en ella son
correctos o validos en el contexto de la definición de la base de datos.
16.-
Cada atributo de la relación esta definido sobre un dominio, identificado en la
definición de la relación y todo valor de este atributo debe estar definido dentro del
domino.
18.-
La existencia de controles de seguridad físicos.
Las políticas de acceso.
Los controles de acceso por medio de hardware.
La seguridad del sistema operativo.
Las situaciones concernientes al DBMS.
19.-
La encriptación de datos es el hecho de almacenar o transmitir la información de
manera que no seria entendible para cualquier persona que intentara accesaria.
Ejercicios de repaso
1.
Para una transferencia o retiro
After Update ng cuentas
cuentas.saldo >= 0
Else
Set retum code to "Saldo insuficiente”
167
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Reject;
Para alta de cuenta:
Before inserting cuentas from variable-de-programa
Not exist (cuentas.Id-cuenta = variable-de-Programa.ld-cuenta)
Else
Set retum code to " El Id de la cuenta ya existe”
Reject;
Para el borrado de una cuenta:
After deleting cuentas from variable-de-programa
Not exist (Movimientos where movimiento.Id-cuenta =
variable-de-Programa.ld-cuenta)
Else Delete from movimientos
where movimientos.ld-cuenta variable-de-Programa.id_Cuenta;
3.
p = 5, q = 7
r = 5 * 7 = 35
(5 - 1) * (7 -1) = 24
e = 11
(d * 11) modulo 24 = 1
d=11
168
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Encriptación
C1 = (8)11 módulo 35 = 22
C2 = (9)11 módulo 35 = 4
Desencriptación
P1 = (22)11 módulo 35 = 8
P2 = (4)11 módulo 359
Conclusiones
Durante la realización de este trabajo se trato de cubrir la mayor parte del programa
de estudio de la materia de base de datos distribuida, y se logro obtener un texto que
puede ser utilizado por el maestro como apoyo, y por el alumno como libro de texto,
169
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
permitiendo así una rápida asimilación de los temas y conceptos que en esta obra se
tratan.
Es también, un texto que podría ser utilizado por personas autodidactas con
conocimientos de generales de computación y de bases de datos, permitiendo un
entendimiento claro del concepto de lo que son las bases de datos distribuidas.
170
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Recommended