I

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 asi 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.



II

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.





























III

Bases de Datos Distribuidas
Bases de datos distribuidas

Contenido

Capitulo 1 Fundamentos de las bases de datos distribuidas
1.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 de
datos centralizadas................................................................. .............4

1.3 Los doce objetivos de una base de datos distribuidas...........................6

1.4 Arquitectura cliente/servidor.................................................................11
1.4.1 Paradigma cliente/servidor.................................................................11
1.4.2 Procesamiento cliente/servidor...........................................................11
1.4.3 Ventajas de la arquitectura cliente/servidor........................................11
1.4.4 Desventajas de la arquitectura cliente/servidor..................................12
1.4.5 Características del cliente...................................................................12
1.4.6 Funciones del cliente..........................................................................13
1.4.7 Interfaz grafica de usuario estándar....................................................13
1.4.8 Características de[ servido.........................r.......................................14
1.4.9 Funciones del servidor........................................................................15
1.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 servidores
2.1 Consideraciones para distribuir bases de datos....................................34
2.1.1 Objetivo del diseño de los datos distribuidos .....................................35

2.2 Diseño de bases de datos distribuidas ................................................36
2.2.1 Técnicas de diseño Top-Down y Bottom-Up de bases de datos
distribuidas ................................................................................... 36
2.2.2 Diseño de los fragmentos de la base de datos...................................37
2.2.3 Correctez de la fragmentación ........................................................... 37
2.2.4 Fragmentación Horizontal...................................................................38
2.2.5 Fragmentación Horizontal derivada. .................................... .............40

IV

Bases de Datos Distribuidas
2.2.6 Fragmentación Vertical ........................................................ .............42
2.2.7 Fragmentación Mixta ........................................................... .............46
2.2.8 Distribución de los fragmentos............................................. .............48
2.2.9 Criterios generales para la distribución de los fragmentos.................48

2.3 Procesamiento de consultas distribuidas..............................................49
2.3.1 Árbol de operadores de una consulta................................................49
2.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 acceso
3.1 Importancia de la optimización de consultas........................................63

3.2 Transformaciones equivalentes................. ..................................... ..65
3.2.1 Transformaciones equivalentes por álgebra relacional .................. .66
3.2.2 Determinación de subexpresiones comunes .................................. 68

3.3 Métodos de ejecución de JOIN..........................................................70
3.3.1 Iteración simple ............................................................................... 71
3.3.2 Iteración orientada a bloques.......................................................... 72
3.3.3 Merge - Join ................................................................................ 73
3.3.4 Uso de índices ................................................................................ 75
3.3.5 Hash Join ................................................................................ 76
3.3.6 Tree - way join ................................................................................ 78
3.3.7 Estrategias para procesamiento paralelo ...................... ................ 80
3.3.8 Join paralelo ............................................................... ................ 80
3.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



V

Bases de Datos Distribuidas
CapitulolV Procesamiento de transacciones en bases de datos distribuidas
4.1 Control de concurrencia......................................................................95
4.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. .................................................................................. 111
4.2.1 Transacciones. .............................................................................. 112
4.2.2 Manejo de mensajes ..................................................................... 113
4.2.3 estructura general de los registros de bitácora .............................. 114
4.2.4 Tipos de fallas ............................................................................... 116
4.2-5 Fallas de transacción .................................................................... 117
4.2.6 Bitácora en línea ........................................................................... 118
4.2.7 Transacciones grandes ................................................................. 118
4.2.8 Compresión de bitácora ................................................................ 119
4.2.9 Fallas del sistema .......................................................................... 120
4.2.10 Fallas en el medio de almacenamiento ....................................... 123

4.3 Integridad ..........................................................................................125
4.3.1 Reglas de integridad de dominio ................................................... 126
4.3.2 Reglas de integridad de relación ................................................... 127

4.4 Seguridad. .......................................................................................131
4.4.1 Identificación y autentificación ....................................................... 133
4.4.2 Reglas de autorización...................................................................133
4.4.3 Encriptación de datos. .. ................................................................ 134
4.4.4 Encriptación por sustitución, .......................................................... 135
4.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




1
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas





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.
Capítulo I
Fundamentos de las bases de datos
distribuidas

2
Fundamentos de las Bases de Datos Distribuidas
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.

3
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.



4
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.




5
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.




6
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.







7
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,

8
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).



9
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 vados 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.

10
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.

11
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.

12
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

13
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.

14
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 signif icativo 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.


15
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

16
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:


17
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

18
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

19
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.





Control de recuperación.

20
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
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

21
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
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

22
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.















1.7 Resumen
Las características que deben de tener los sistemas de bases de datos son:

23
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

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:

Razones organizacionales: La mayor parte de las organizaciones están ya
descentralizadas.


24
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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:

Autonomía local: Significa que todas las operaciones en un sitio se controlan en ese
sitio.

No dependencia de un sitio central: Todos los sitios son iguales y no dependen de
ningún otro sitio.

Operación continua: Un sistema distribuido siempre esta disponible.

Independencia con respecto a la localización: Los usuarios nunca sabrán la
localización real de los datos.

25
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

Independencia con respecto a la fragmentación: Un sistema distribuido deberá dar
la apariencia de que se encuentra en una sola pieza.

Independencia de replica: Un sistema deberá comportarse como si solo e)dstiera
una sola copia de los datos.

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.

Manejo distribuido de transacciones: Deberá poder procesar una transacción a
través de varios sitios.

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.

Independencia con respecto al sistema operativo: Deberá de ser capaz de trabajar
en cualquier sistema operativo.

Independencia con respecto a la red: Deberá de ser capaz de trabajar en diferentes
redes.

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.

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

26
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.


Servidor

27
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

- 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.

28
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.


29
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?








30
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



















31
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 o
Projecion Pi H
Join JN
Semi-join si
Union UN
Producto cartesiano CP X
Natural Join NJN
Natural Semi-join NSJ
Diferencia DF ÷



Capítulo II

Bases de Datos en múltiples servidores

32
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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 optimo 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.




33
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

34
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:

35
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 V tal que: R V Ri
Exclúyete

36
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[A
l
,A
2
, ... A.], un predicado simple pj es:
pj: Ai u Valor
donde u e {=, =, >, ≤, <, >}, Valor e Di y Di es el dominio de A¡.
Se tendrá entonces R[pl,P2,P3,---,PMI

Predicados minitermino
Dado Ri y Pti = {p
1
,p
2
, ... pj definir M = {mi
1
, mi
2
, ... miz} como:
Mi = {mij l mij = ^pik e 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)



37
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:
P
1
= {cveciudad = "SF" }
P
2
= { cveciudad = "LA" }
P
3
= { cveciudad = "SD" }

Dando como resultado los siguientes predicados miniterminos, los cuales se
obtienen de las combinaciones de los predicados simples:

m
1
= {SF ^ LA ^ SD} contradictorio
m
2
= {SF ^ ~LA ^ SD} contradictorio
m
3
= {SF ^ ~LA ^ ~SD}
..
M
6
= {~SF ^ ~LA ^ ~SD} contradictorio
..
M
7
= {~SF ^ LA ^ ~SD}
M
8
= {~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:
M
3
= {SF ^ ~LA ^ ~SD}
M
7
= {~SF ^ LA ^ ~SD}
M
8
= {~SF ^ ~LA ^ SD}

38
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

Entonces la fragmentación horizontal estaría dada de la siguiente forma:
Proveedor
1
= 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



Proveedor
2
= 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



Proveedor
3
= 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.

39
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 = Proveedor
1
UN Proveedor
2
UN Proveedor
3


Create View ReconstruccionProveedor
As
Select * from Proveedor1
Union All
Select * from Proveedor2
Union All
Select * 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

40
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:

Pedido
1
= Pedido SJ
pclave = pclave
Proveedor
1
Select A.* into Pedido1 From Pedido A Inner Join Proveedor1 B on (A.pclave=B.pclave)

Pclave Pnum Depto Cant
P01 2325 Compras 123
P01 2547 Compras 21
P04 7410 Ventas 53
P04 2589 Sistemas 10


Pedido
2
= Pedido SJ
pclave = pclave
Proveedor
2
Select A.* into Pedido2 From Pedido A Inner Join Proveedor2 B on (A.pclave=B.pclave)

Pclave Pnum Depto Cant
P02 3298 Ventas 98
P03 7895 Finanzas 87


Pedido
3
= Pedido SJ
pclave = pclave
Proveedor
3
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.

41
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:
q
1
: Obtener el nombre y departamento de todos los empleados
q
2
: Obtener el clave, salado y tasa de impuestos por departamento
q
3
: 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
q
1
2 3 2 7
q
2
2 1 2 5
q
3
1 2 1 4



42
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

Las aplicaciones se traducirían de la manera siguiente:

q
1
= Select nom, depto
From empleados
q
2
= Select cvemp, sal, imp
From empleados
Where depto = X
q
3
= 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 q
j
.

A
1
(cvemp) A
2
(nom) A
3
(sal) A
4
(imp) A
5
(depto)
q
1
0 1 0 0 1
q
2
1 0 1 1 1
q
3
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) = E todas las consultas que accesan A¡ y Aj (accesos en consultas) accesos
en consulta = E todos los sitios frecuencia de accesos de una consulta

aff(A
1
, A
1
)= (2+1+2)(1) + (1+2+1)(1) = 9
aff(A
1
, A
2
)= (1+2+1)(1) = 4
aff(A
1
, A
3
)= (2+1+2)(1) + (1+2+1)(1) = 9
aff(A
1
, A
4
)= (2 +1+2)(1) = 5
aff(A
1
, A
5
)= (2+1+2)(1) + (1+2+1)(1) = 9
aff(A
2
, A
1
)= (1 +2+ 1)(1) = 4
aff(A
2
, A
2
)= (2+3+2)(1) + (1+2+ 1)(1) = 11

43
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
aff(A
2
, A
3
)= (1+2+1)(1) = 4
aff(A
2
, A
4
)= 0
aff(A
2
, A
5
)= (2+3+2)(1) + (1 +2+ 1)(1) = 11



A
1
A
2
A
3
A
4
A
5

A
l
9 4 9 5 9
A
2
4 11 4 0 11
A
3
9 4 9 5 9
A
4
5 0 5 5 5
A
5
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= {A
1
, A
2
, A
3
, A
4
, A
5
}

Emp
1
{ A
1
, A
2
), Emp
2
= { A
1
, A
3
, A
4
, A
5
)
Emp
1
= PJ
cvemp, Nom
, Emp
Emp
2
= PJ
Cemp, Sal, Imp, Depto
Emp

Emp
1
(Cvemp, Nom)
Emp
2
(Cvemp, Sal, lmp, Depto)


o en otro caso

Emp
1
= { A
1
, A
2
, A
3
} Emp
2
= { A
1
, A
4
, A
5
}


44
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Emp
1
= PJ
cvemp, Nom, Depto
Emp
Emp
2
= PJ
Cemp, Sal, Imp
Emp

Emp
1
(Cvemp, Nom, Sal)
Emp
2
(Cvemp, Imp, Depto)


El atributo A
1
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 = Emp
1
JN
cvemp = cvemp
Emp
2


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.

45
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
Emp
1
= PJ
cvemp, Sal. Imp
Emp
Select cvemp, Sal, Imp Into Emp1 From Emp
Horizontal
Depto10 = SL
depto=10
PJ
Cvemp, Nom, Depto
Emp
Select cvemp, nom, depto Into Depto10 from Emp Where depto=10

Depto20 = SL
depto=20
PJ
Cvemp, Nom, Depto
Emp
Select cvemp, nom, depto Into Depto20 from Emp Where depto=20

Depto30 = SL
depto=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:

46
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas


Emp = UN(Depto10, Depto20, Depto30) JN
Cvemp = Cvemp
PJ
Cvemp, Sal, Imp
Emp
1


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


H
V

47
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

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.

48
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.



49
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:

PJ
SNUM
SL
área = “Norte”
(Prevee JN
Numdepto = 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.


PJ
SNUM



SL
AREA="Norte"


JN
Numdepto=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

50
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
R -> R op_bin R
op_uni -> SL
F
| PJ
A

op_bin CP | UN | DF | JN
F
| NJN
F
| SJ
F
| NSJ
F





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:


51
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:

Alumnos
1
= SL
especialidad = “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



Alumnos
1
= 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



Alumnos
1
= 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



52
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 horizonte¡ 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”
Alumnos
3



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:

53
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

PJ
no-control, nombre, especialidad
SL
edad>=21
(Alumnos
1
UN Alumnos
2
UN Alumnos
3
)

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:



PJ
NO CONTROL, NOMBRE. ESPECIALIDAD


SL
EDAD >= ”21”


UN

ALUMNOS
1
ALUMNOS
2
ALUMNOS
3


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:

54
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

PJ
NO CONTROL, NOMBRE. ESPECIALIDAD


UN

SL
EDAD >= ”21”
SL
EDAD >= ”21”
SL
EDAD >= ”21”


ALUMNOS
1
ALUMNOS
2
ALUMNOS
3



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).




55
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

UN


PJ
no_CONTROL,
PJ
no_CONTROL,
PJ
no_CONTROL,
NOMBRE, ESPECIALIDAD

NOMBRE, ESPECIALIDAD

NOMBRE, ESPECIALIDAD



SL
EDAD >= ”21”
SL
EDAD >= ”21”
SL
EDAD >= ”21”



ALUMNOS
1
ALUMNOS
2
ALUMNOS
3




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.






56
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 intercone)¿ión de [os 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.

57
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.
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 casto 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 e)dste 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,

58
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.
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 a 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:


59
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:

q
1
: Obtener los nombres de todos los clientes.
q
2
: Obtener el número del cliente por estado.
q
3
: Obtener el nombre del cliente por empresa.

No_cli Nom_cli Empresa Estado
C01 Juárez Gamesa Gto
C02 Vidal Lara Qro
C03 Ávila Gamesa Jal

60
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
C04 Mejía Lara Jal
C05 Herrera Lara Gto
C06 Cervantes Gamesa Qro

2.- Fragmentar horizontalmente la siguiente base de datos.
Clientes Productos
No_cli Nom_cli Edo No_p Nom_p Precio
C01 Ávila Gto P1 Lápiz 1.20
C02 Soria Gto P2 Libreta 3.50
C03 Avalos Qro P3 Lapicero 3.20
C04 Medina Mich P4 Borrador 1.50
C05 Trajo P5 Escuadra 3.10
C06 Ávila Qro P6 Plumones 15.20


Compras
No_cli Nom_cli Cant
C02 Pl 2
C01 P3 1
C02 P4 2
C01 P5 2
C03 P1 2
C03 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 Prom
AL1 Aguilar 19 Rev. 115 Celaya 3 Química 85.7

61
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
AL2 Jiménez 18 Hgo. 120 Irapuato 1 Electrónica 83.2
AL3 Trejo 18 Rev. 315 Celaya 1 Sistemas 75.2
AL4 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




62
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
Capítulo III

Optimización de estrategias de accesos

63
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.

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 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..

64
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 optima.
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)

65
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:

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



Son dos expresiones equivalentes, las cuales arrojan el mismo resultado, pero
definidas por dos secuencias de operadores diferentes.


Transformaciones equivalentes por álgebra relacional

66
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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 E
1
y E
2
de álgebra relacional, la equivalencia de dos
expresiones se representa E
1
↔ E
2
.
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 unitaria y binaria respectivamente, R y S relaciones, entonces se tienen
las siguientes propiedades:

- Conmutatividad de operaciones unitarias:

U
1
U
2
R ↔ U
2
U
1
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

- Idempotencia de operaciones unitarias:

U R ↔U
1
U
2
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)

67
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

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 SL
F
R ↔ SL
F
R
R UN SL
F
R ↔ R
R DF SL
F
R ↔ SL
NOT F
R

(SL
F1
R) NJN (SL
F2
R) ↔ SL
F1 AND F2
R
(SL
F1
R) UN (SL
F2
R) ↔SL
F1 OR F2
R
(SLF, R) DF (SLF2 R) <-> SL
F1 AND NOT P2
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:


68
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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:

PJ
EMP.Nom
((EMP JN
DEPTNUM = DEPTNUM
SL
GTENUM=373
DEPT) DF
(SL
SAL>35000
EMP JN
DEPTNUM=DEPTNUM
SL
GTENUM=373
DEPT))


A simple villa 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

JN
DEPTNUM=DEPTNUM
JN
DEPTNUM=DEPTNUM



EMP SL
GETNUM=373
SL
SAL>35000
SL
GETNUM=373



DEPT EMP DEPT

Se comienza factorizando el select sobre SAL con respecto al join (al hacer esto, el
select es desplazado hacia arriba).

69
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

PJ
EMP_NOM



DF

JN
DEPTNUM=DEPTNUM
SL
SAL>35000


EMP SL
GETNUM=373
JN
DEPTNUM=DEPTNUM


DEPT EMP SL
GETNUM=373


DEPT


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:
PJ
EMP-NOM









EMP SL
GTENUM=373


DEPT


SL
SAL>35000

JN
DEPTNUM=DEPTNUM

DF

70
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

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 deposito cuenta con 10,000 tuplas y clientes consta de
200 clientes.




3.3.1 Iteración simple
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.

71
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

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

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

72
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.


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 deposito, se leerá la relación cliente por
cada bloque de la relación deposito. 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 de[ 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

73
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.


Pd := dirección de la primera tupla de deposito;
Pc:= dirección de la primera tupla de clientes;
while (pc ≠ nuil) do
begin
tc:= tupla ala 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;

74
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.

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 e>iste 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-clientel.
Se requieren 10000 accesos para leer la relación deposito. Si se asume que la
relación clientes tiene 200 tuplas, y que se almacenan 20 apuntadores por bloque,

75
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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 deposito
son necesarios 3 accesos a bloques daría como resultado un total de 30000 accesos,
más los 10000 de la relación deposito.
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.
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

76
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
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

77
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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)

- H
c0
, H
c1
, ... , H
cmax
denotan el contenedor del apuntador a las tuplas de la
relación diente, cada uno vacío al inicio.

- H
d0
, H
d1
, ... , H
dmax
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

78
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
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

79
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.

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.


81
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Considerando nuevamente el ejemplo deposito JN cliente, se asume que se tiene N
procesadores P
1
, P
2
, ..., P
N
. Se divide la relación de deposito en N partes de igual
tamaño; deposito
1
, deposito
2
, ..., deposito
N
Se supone, por facilidad, que el tamaño de
la relación deposito es múltiplo de N, entonces cada procesador P
i
procesa deposito
i

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:

r
1
JN r
2
JN r
3
JN r
4



82
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Es posible ejecutar t
1
(r
1
JN r
2
) en paralelo con t
2
(r
3
JN r
4
) y cuando este proceso
termine se ejecutará:

t
1
JN t
2


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 P
1
la ejecución de r
1
JN r
2

y al procesador P
2
se asigna r
3
JN r
4
.
Como las tuplas resultantes del proceso de P
1
están disponibles para P
3
, así como
las tuplas resultantes del procesador P
2
, entonces P
3
podrá comenzar el proceso ( r
1

JN r
2
) JN (r
3
JN r
4
) antes de que r
1
JN r
2
y r
3
JN r
4
hallan terminado.
















A continuación se muestra el algoritmo utilizado por el procesador P
3
para procesar
el join. Las tuplas resultantes de P
1
y P
2
son colocadas en una cola para ser
procesados por P
3
, P
1
y P
2
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 P
3
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 P
1
y
r
1




r
2



r
3




r
4

P
1

P
3

P
2


83
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
P
2
respectivamente. Para ejemplo se utilizo un 4-way join pero pude extenderse para
procesar N-way join.



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:

PJ
Pnombre


SL
provee.p#=‟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.p#=’P2’
)
nombre




2.- Convertir a forma canónica.

85
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
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.



86
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
4.- Seleccionar el procedimiento más económico.
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.







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
de debe considerar además, el costo de la transmisión de datos entre los sitios
participantes de la consulta.

88
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

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 El ↔ 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:
U
1
U
2
R ↔ U
2
U
1
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

- Idempotencia de operaciones unitarias:
U R ↔ U
1
U
2
R

89
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

- 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 SL
F
R ↔ SL
F
R
R UN SL
F
R ↔ R
R DF SL
F
R ↔ SL
NOT F
R

(SL
F1
R) NJN (SL
F2
R) ↔ SL
F1 AND F2
R
(SL
F1
R) UN (SL
F2
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:

- El orden físico de las tuplas en la relación.

90
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
- 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 tendrán valores diferentes para los atributos
básicos del join a pesar de que sus valores en la función hash sean iguales.


Tree-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. 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:

r
1
JN r
2
JN r
3
JN r
4




Es posible ejecutar t
1
(r
1
JN r
2
) en paralelo con t
2
(r
3
JN r
4
) y cuando este proceso
termine se ejecutará:
t
1
JN t
2



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 P
1
la ejecución de r
1
JN r
2

y al procesador P
2
se asigna r
3
JN r
4
.


92
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
Como las tuplas resultantes del proceso de P
1
están disponibles para P
3
, así como
las tuplas resultantes del procesador P
2
, entonces P
3
podrá comenzar el proceso (r
1

JN r
2
) JN (r
3
JN r
4
) antes de que r
1
JN r
2
y r
3
JN r
4
hallan terminado. Las tuplas
resultantes de P
1
Y P
2
son colocadas en una cola para ser procesadas por P
3
, 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 diseñar una estrategia de recolección de datos. Es necesario

93
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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 cuanta 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:

Obténgase el nombre de los empleados mayores de 40 años del departamento X
con sueldo mayor a $11,000.

l.- Dibuje el árbol de operadores de la consulta.

94
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

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











Capítulo IV
Procesamiento de transacciones en bases de
datos distribuidas

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 R
j
(x) y W
i
(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.
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: R
j
(x) R
j
(x) W
i
(y) R
k
(X) W
j
(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.

96
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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: R
i
(x) W
i
(y) R
i
(y) R
j
(x) W
j
(y) R
k
(y) W
k
(X)


Ti Tj Tk
R(x)
W(y)
R(y)
R(x)
W(y)
R(y)
W(x)


Esto sería

S2: T
i
T
j
T
k



En una planificación, si la operación O
i
precede a la operación O
j
, se indica como
O
i
< O
j
, es decir O
i
se ejecuta primero que O
j
, entonces en S2 T
i
< T
j
y T
j
< T
k
.

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
corrector. La definición más aceptada de correcto en una planificación es basada en la
seriabilidad:


97
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.
Por ejemplo, [ R
j
(x), W
j
(x) ] y [ W
i
(X), W
j
(X) ] son pares de operaciones en conflicto
mientras que [ R
i
(x), R
j
(x) W
i
(x), W
j
(y) ], y [ W
i
(x), R
j
(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:


98
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
i
y O
j
, donde O
i
< O
j
en S1, entonces O
i
deberá preceder a O
j
en S2.


Por ejemplo, la estructura S3 es equivalente a la planificación S4:

S3: R
i
(x) R
i
(x) W
j
(y) W
i
(x)
S4: R
j
(x) W
j
(y) R
i
(x) W
i
(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 T
1
, T
2
, .... T
n
en
m sitios es modelado por un conjunto de entradas de bitácora Sl, S2, .... Sm.

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): R
i
(x) W
j
(x) R
i
(x) W
i
(x)
S2 (Sitio 2): R
j
(y) W
i
(y) R
i
(y) W
j
(y)

99
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas


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 señabilidad local.

La ejecución de las transacciones T
1
, ..., T
n
es correcta si:

1. Cada entrada local S
k
es serializable.
2. Existe un orden total de T
1
, ..., T
n
tal que, si Ti < Tj en el orden total, entonces
hay una planificación serial S
k
‟ tal que, S
k
es equivalente a S
k
‟ y T
i
< T
j
en el
Serial(S
k
‟), 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 T
1
, ..., T
n
un conjunto de transacciones, y sea E una ejecución
de estas transacciones, modelado por el conjunto de planificaciones
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.


100
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.





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

101
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.
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:







ROOT
AGENT


AGENT


AGENT

DTM-
AGENT

DTM-
AGENT

DTM-
AGENT
Mensaje Mensaje
2‟ 2‟ 2‟
Transacción
Distribuida

102
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas









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
copias del mismo dato almacenados en diferentes sitios, para los cuales la existencia
mutua es inadvertida para dichas transacciones.


LTM
en
sitio k

LTM
en
sitio j

LTM
en
sitio i
Mensaje Mensaje
1‟ 1‟ 1‟
Manejador
distribuido de
transacciones
Manejadores de
transacciones
locales

103
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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. Bloque 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
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]

104
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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 T
1
, T
2
, ..., T
n
requieren de un bloqueo de
dos fases, esto tal vez no llegue a ocurrir. Considere el estado intermedio en el
conjunto T
1
tiene bloqueado a X, T
2
tiene bloqueado Y, ..., T
n-1
tiene bloqueado V y T
n

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 T
i
y T
j
, 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:

T
i
: R
i1
(x) W
i1
(x) R
i2
(Y) W
i2
(Y)
T
j
: R
j1
(x) W
j1
(x) R
j2
(Y) W
j2
(Y)



Ti Ti
Ri(x) Ri(x)
Wi(x) Wi(x)

105
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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) < R
j1
(x) y
W
i2
(y) < R
j2
(y) o que W
j1
(x) < R
i1
(x) y W
j2
(y) < R
i2
(y)- Dado que existe una simetría, se
podrá considerar cualquiera de los dos casos. Para ejemplo considérese T
i
< T
j
.
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)



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

106
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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:

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.

107
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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(A) < TS(B) o

















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 de] sitio en el cual fue generada, en la posición menos significativa. Lo
Sitio 1 Sitio 2
B
A
C
F
E
D
Mensaje M2
Tiempo
Local
Tiempo
Local
Mensaje M1

108
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.



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.

109
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

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 T
r
A
s
. Hay dos razones por las cuales
un agente esperaría a otro:

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
T
1
A
1

T
2
A
1

Sitio 1
T
1
A
2

T
2
A
2

Sitio 2
T
1
A
1

T
2
A
1

Sitio 1
T
1
A
2

T
2
A
2


110
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
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: T
1
bloquea X
1
; T
2
espera
Sitio2 : T
2
bloquea X
2
; T
1
espera


111
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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 sol a
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:


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:

112
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.



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

113
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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 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

114
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
T4 Transferir 1000 pesos de la cuenta Cl a C3


Id cuenta Saldo
C1 1000
C2 500
C3 3200

115
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
C4 8000
C5 1532
C6 4553

En la bitácora se almacenan los mensajes de entrada y salida, las operaciones de
alta, baja, deposito y retiro, así como los registros de control para cada una de las
transacciones:
T1 usr23 Begin transaction
T1 usr23 ME Transferencia C1 C4 400
T1 usr23 R C1 1000 C1 600
T1 usr23 D C4 8000 C4 8400
T1 usr23 ms 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
T4 usr87 Rollback



Dando como resultado siguiente la tabla:



116
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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 manejadas 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.
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

117
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
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.


118
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
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:

119
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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 ultima 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
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

120
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.
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.

121
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.





T1

T2

T3

122
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

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
secuencia¡ de la bitácora a partir del registro de check-point y rehacer el cambio
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,

123
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
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

124
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
C4 8400
C5 4532
C6 4553




Id_cuenta Saldo
C1 600
Id_cuenta Saldo
C1 600
C2 500
C3 3200
C4 8000
C5 1532
C6 4553

125
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
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:


126
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
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:

127
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
- 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
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]




128
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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,
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

129
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.
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


130
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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:

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".

131
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

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;

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:

132
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

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.

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.

133
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
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.

134
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
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

135
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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:
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


136
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.



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:


137
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.

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 = P
e
módulo r

6.- Para desencriptar una parte del texto cifrado, este es reemplazado por P, que
se obtiene de la siguiente manera:

P = C
d
módulo r


138
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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 = P
e
módulo r
C = 13
11
módulo 15
= 1792160394037 módulo 15
= 7 (este es el residuo de la división entera de 1792160394037 entre 15)

Para desencriptar C se realiza el siguiente proceso:

p = C
d
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)





139
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
















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.
En una planificación, si la operación O¡ precede a la operación O¡, se indica como
O¡ < Oj, es decir 01 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.


140
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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:

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.


141
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
La ejecución de las transacciones T
1
, ..., T
n
es correcta sí:

1. Cada entrada local S
k
es serializable.
2. Existe un orden total de T
1
, ..., T
n
tal que, si Ti < Ti en el orden total, entonces
hay una entrada serial S
k
„ tal que, S
k
es equivalente a S
k
' y Ti < Tj en el
Señal(S
k
'), 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 T
1
, ..., T
n
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).
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

142
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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:

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.

143
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

Considérese ahora que, las transacciones T
1
, T
2
, ..., T
n
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.

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:


144
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→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):












Hay dos razones por las cuales un agente esperaría a otro:

1. T
1
A
1
espera que T
2
A
1
libere recursos en el sitio 1. Este tipo de espera se
representa por una flecha continua en la gráfica.
2. El agente T
i
A
j
requiere que el agente T
i
A
s
ejecute alguna función en un sitio
diferente. Este tipo de espera es representado por una flecha discontinuo en la
gráfica.
T
1
A
1

T
2
A
1

Sitio 1
T
1
A
2

T
2
A
2

Sitio 2
T
1
A
1

T
2
A
1

Sitio 1
T
1
A
2

T
2
A
2


145
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

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
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:

146
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.

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.


147
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
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:


148
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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:

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.


149
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
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.


150
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
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.

151
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

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.


4.6 Preguntas de repaso
1.- ¿Cuál es la condición para que dos transacciones sean serializables?
2.- ¿Cuándo dos transacciones son concurrentes?
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?

152
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.
7.- Explique brevemente en que consiste el bloqueo de 2 fases.
8.- ¿En que consisten las etiquetas de tiempo?
9.- ¿Que se entiende por deadlocks distribuidos?
10.- ¿Que es la recuperación?
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?
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?
15.- ¿Cuales son las responsabilidades de un subsistema de integridad?
16.- ¿Explique la regla de integridad de dominio?
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?
19.- ¿Que son las reglas de autorización?
20.- ¿Que es la encriptación de datos?

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

153
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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,

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





154
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.



155
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.-
- 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

156
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.
- 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

157
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas



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}


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

158
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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


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



159
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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
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




160
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

Al A2 A3 A4
Al 3 3 0 3
A2 3 10 2 3
A3 0 2 2 0
A4 3 3 0 3



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.-

161
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
- Iteración simple.
- Iteración orientada a bloques.
- Merge - join.
- Hash - join.
- Tree - way join.
- Join paralelo
- Pipeline muitiway join.

8.-
- 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.

Ejercicios de repaso
1.-
PJ
EMP:NOM

DF

JN
DEPTNUM=DEPTNUM
JN
DEPTNUM=DEPTNUM



EMP SL
DESC=X
SL
SAL<=11000
SL
DESC=x


162
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas

DEPT EMP DEPT

3.
PJ
EMP:NOM









EMP SL
DESC=X

DEPT
Capítulo IV-

Preguntas de repaso

2.-
Dos transacciones son concurrentes si no cumplen la condición de seriabilidad.

4.-
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,
SL
SAL>35000

JN
DEPTNUM=DEPTNUM

DF

163
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
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.


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.

164
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas


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 Updati ng cuentas
cuentas.saldo >= 0
Else
Set retum code to "Saldo insuficiente”
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;

165
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas


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


Encriptación

C
1
= (8)
11
módulo 35 = 22
C
2
= (9)
11
módulo 35 = 4


Desencriptación


166
Fundamentos de las Bases de Datos Distribuidas
Bases de Datos Distribuidas
P
1
= (22)
11
módulo 35 = 8
P
2
= (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,
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.

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.

Bases de Datos Distribuidas

II

Bases de datos distribuidas Contenido
Capitulo 1 Fundamentos de las bases de datos distribuidas 1.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 de datos centralizadas................................................................. .............4 1.3 Los doce objetivos de una base de datos distribuidas...........................6 1.4 Arquitectura cliente/servidor.................................................................11 1.4.1 Paradigma cliente/servidor.................................................................11 1.4.2 Procesamiento cliente/servidor...........................................................11 1.4.3 Ventajas de la arquitectura cliente/servidor........................................11 1.4.4 Desventajas de la arquitectura cliente/servidor..................................12 1.4.5 Características del cliente...................................................................12 1.4.6 Funciones del cliente..........................................................................13 1.4.7 Interfaz grafica de usuario estándar....................................................13 1.4.8 Características de[ servido.........................r.......................................14 1.4.9 Funciones del servidor........................................................................15 1.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 servidores 2.1 Consideraciones para distribuir bases de datos....................................34 2.1.1 Objetivo del diseño de los datos distribuidos .....................................35 2.2 Diseño de bases de datos distribuidas ................................................36 2.2.1 Técnicas de diseño Top-Down y Bottom-Up de bases de datos distribuidas ................................................................................... 36 2.2.2 Diseño de los fragmentos de la base de datos...................................37 2.2.3 Correctez de la fragmentación ........................................................... 37 2.2.4 Fragmentación Horizontal...................................................................38 2.2.5 Fragmentación Horizontal derivada. .................................... .............40
Bases de Datos Distribuidas

III

.............................6 Tree ..... ..3...........3 Procesamiento de consultas distribuidas........94 Bibliografía..................................... 88 3...........70 3................................................ 93 3........4..............2......................................... 84 3. Resumen del capitulo....................5............. .................... ...........................2............1 Árbol de operadores de una consulta.......................46 2..............................49 2......... Ejercicios.............3..3.............................. .............................................. Principios de optímización..2...6 Fragmentación Vertical ............................................................. .......................63 3..............................................................3...5.................way join ....................3 Merge ...................9 Criterios generales para la distribución de los fragmentos. 68 3.........2 Ejemplos de consultas distribuidas............1 Iteración simple..................................................50 2.........60 Bibliografía...........5 Hash Join ..........60 2.......................... 80 3............................ ............... ..........3......3.......................... 82 3...... .............................2...........2..... .......6................................ Preguntas de repaso...........8 Join paralelo ..8 Distribución de los fragmentos......7 Fragmentación Mixta ...................................................... .........2 Transformaciones equivalentes.............3.....1 Transformaciones equivalentes por álgebra relacional ......................7...............9 Pipeline multiway join ...............42 2..............................4 Uso de índices .................94 Bases de Datos Distribuidas IV . 76 3............ ......... 75 3...2 Iteración orientada a bloques.................. Resumen del capitulo............ Ejercicios.................................. .65 3...............1 Importancia de la optimización de consultas................ 80 3.................................................. 71 3...................................3....... 78 3........3...........................7 Estrategias para procesamiento paralelo ..Join ............................................................................... 73 3.....3 Métodos de ejecución de JOIN......4....3.....2........................................................................2...66 3.................................................................. ................................... 72 3....................................................... .57 2.. ........................... Preguntas de repaso...........................................................6......62 Capitulo III Optimización de estrategias de acceso 3..48 2...............48 2....................................49 2......2 Determinación de subexpresiones comunes ............................................................................................3...

...........95 4................100 4....1.......2........101 4................................1..................................................... 116 4.2 Manejo de mensajes .............. Resumen del capitulo...............................................................................98 4................................6 Bitácora en línea ..................... Ejercicios ........... 133 4..........2 Reglas de autorización..........................2.2...............1 Identificación y autentificación .......................................154 Bases de Datos Distribuidas V ..................95 4......4 Encriptación por sustitución............ 114 4.... 119 4.........2...............2-5 Fallas de transacción ........................1...........104 4..........2.................... ......3.....................7.................... ...........5 Bloqueo de 2 fases como un método de control de concurrencia.......6 Etiquetas de tiempo en una base de datos distribuida........5......2...........3 estructura general de los registros de bitácora ........... 120 4.133 4.....1 Seriabilidad en bases de datos centralizadas............. .......................1............................................................ 111 4.. 118 4..2 Recuperación..............4...................151 4............................3 Integridad ..............................................................10 Fallas en el medio de almacenamiento .............................. 134 4..................................................... 118 4.............2..........................................4 Control de concurrencia basado en bloqueos distribuidos ...............CapitulolV Procesamiento de transacciones en bases de datos distribuidas 4..4...2...................................................106 4.................................. 136 4..............................1 Control de concurrencia........... ......... 152 Bibliografía.......... 117 4..........6................. 135 4....................................1...................... Preguntas de repaso........1.................................................................................................4......................................................................................131 4..............................................3.....................153 Respuestas a preguntas de repaso y ejercicios............4...................109 4............7 Transacciones grandes ......3 Encriptación de datos..2 Seriabilidad en bases de datos distribuidas........4 Tipos de fallas ...3 Control de concurrencia basado en bloqueos centralizados ....................... 123 4.................. 113 4........................... ..........................7 Deadloks distribuidos...................................................1.............................................................1 Reglas de integridad de dominio .......... 112 4............. ...........................................125 4..........................................2 Reglas de integridad de relación ......... 126 4........9 Fallas del sistema .........................8 Compresión de bitácora ......................... . .......5 Encriptación de llave publica ..........................................2...........4 Seguridad...139 4.........1 Transacciones......................................4.......... 127 4.............

1. Se discutirá también. los sistemas distribuidos no podrían ser diseñados con las técnicas de diseño de los sistemas centralizados tradicionales. estructuras físicas complejas para un acceso eficiente y seguridad. así mismo. 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. reducción de redundancia.Fundamentos de las Bases de Datos Distribuidas Capítulo I Fundamentos de las bases de datos distribuidas Objetivo El alumno conocerá las características de las bases de datos distribuidas. y los aspectos que se deben considerar al diseñar una base de datos distribuida. se tratan los objetivos a cumplir por dichas bases de datos. Bases de Datos Distribuidas 1 . las cuales son: control centralizado. aun cuando presentan algunas características semejantes. 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. una pequeña descripción del paradigma cliente / servidor. el paradigma cliente / servidor. ya que las bases de datos no centralizadas hacen un uso extenso de éste.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. independencia de datos.

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. Las definiciones de esquema conceptual. Bases de Datos Distribuidas 2 . esto es considerado como la evolución de los sistemas de información. Gracias a la transparencia de distribución es que se pueden escribir programas como si la base de datos no estuviera distribuida. Independencia de datos. De manera similar. la idea de un control centralizado tiene poco énfasis. quien tiene la responsabilidad de su respectiva base de datos local. En las bases de datos distribuidas es posible identificar una estructura de control jerárquico basado en un Administrador global de bases de datos. Esto nos da como resultado una característica llamada Autonomía de sitio. el cual tiene la principal responsabilidad de la totalidad de la base de datos. esquema externo y esquema interno fueron desarrolladas para esta arquitectura. En las bases de datos. la transparencia de distribución es obtenida en las bases de datos distribuidas por la introducción de nuevos niveles y esquemas. en los cuales cada aplicación tiene sus archivos privados. sin embargo. 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. la independencia de los datos es tan importante como en las bases de datos tradicionales. y el Administrador local de bases de datos. En las bases de datos distribuidas. Los programas son escritos teniendo una vista La ventaja principal de la conceptual de los datos. llamada esquema conceptual. que la organización actual de los datos es transparente a las aplicaciones. independencia de datos es que los programas no son afectados por los cambios en la organización física de los datos. 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. esta es la transparencia de distribución. una nueva característica se agrega a la definición de la independencia de datos. La independencia de datos quiere decir.

Es conveniente tomar en cuenta dos cuestiones muy importantes en el momento de accesar una base de datos distribuida. en el sentido de que el programador especifica de qué modo será accesada la base de datos. Las estructuras de acceso complejas. permitiendo que varias aplicaciones accesen los mismos archivos. La optimización local consiste en decidir como llevar acabo el acceso a la base de datos local en cada sitio. la ejecución de la aplicación no se detiene porque existe una copia en algún otro sitio. El objetivo de estas estructuras es el de obtener un acceso eficiente a los datos. la inconsistencia entre varias copias de los datos es evitada automáticamente teniendo solo una copia de los datos. Estructuras complejas y acceso eficiente. las aplicaciones pueden verse favorecidas si los datos son replicados en todos los sitios donde la aplicación las necesita. De cualquier forma. la segunda razón. la recuperación de espacio de almacenamiento al eliminar la redundancia. debido a que si el sitio en el que se encuentran los datos fallara. son aspectos comunes de las bases de datos tradicionales. Bases de Datos Distribuidas 3 . En las bases de datos distribuidas. se tienen varias razones para considerar la redundancia de los datos como una característica necesaria: primero. 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. por dos razones: primera. El soporte para estas estructuras es una de las partes más importantes del DBMS (Database Manager System. Escribir un acceso distribuido es muy parecido al hacerlo en un sistema centralizado. y segundo. la redundancia fue reducida en lo posible. la razón de disponibilidad del sistema puede incrementarse por este medio. Sistema manejador de base de datos).Fundamentos de las Bases de Datos Distribuidas Reducción de la redundancia. como índices secundarios y enlaces entre archivos. En las bases de datos tradicionales. La redundancia se reduce compartiendo los datos. la optimización local y la optimización global de los accesos. el proceso es local a cada uno de los sitios donde se encuentran los grupos de datos.

los problemas de seguridad son intrínsecos en los sistemas de bases de datos en general.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. puede asegurarse que únicamente se tenga el acceso a los datos autorizados. 1. tiene el control centralizado. el esfuerzo requerido para esto es mucho menor que el necesario para la creación de una base de datos local completamente nueva. Sin embargo. Este proceso requiere cierto grado de reestructuración local. En las bases de datos tradicionales. 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. los dueños de los datos locales pueden proteger de diferentes maneras su información. el administrador de la base de datos. Bases de Datos Distribuidas 4 . 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.Fundamentos de las Bases de Datos Distribuidas Seguridad. 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. el administrador local enfrenta el mismo problema que el administrador de bases de datos tradicionales. y segundo. Interconexión de las bases de datos existentes. esto dependiendo del DBMS local. esto debido a que las comunicaciones en las redes es su punto débil con respecto a la protección. de cualquier forma. y las bases de datos distribuidas se acercan más a las necesidades de la estructura de la organización distribuida. En las bases de datos distribuidas.

pero esto generaría una fácil degradación del sistema. Por eso. las fallas en una base de datos distribuida pueden ser más frecuentes que en las centralizadas. sino también en las ya existentes. La existencia de varios procesadores autónomos dan como resultado un incremento en el desempeño por medio de un alto grado de paralelismo.Fundamentos de las Bases de Datos Distribuidas Desarrollo incremental. Las bases de datos distribuidas obtienen. en relación con bases de datos centralizadas. el lograr esta meta no es tan fácil. relativamente autónoma. en otras palabras. Sin embargo. entonces las bases de datos distribuidas soportarían este crecimiento con el menor grado de impacto a las unidades ya existentes. las cuales son difíciles de comprender. Consideraciones en el desempeño. por sí misma. por medio de la replica de datos. y por lo tanto es raro que el sistema en su totalidad falle. 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. pero el efecto de cada falla es considerado por cada aplicación que usa los datos en sitio que falló. un alto grado de confiabilidad y disponibilidad. La capacidad de procesamiento autónomo en los diferentes sitios no es. Si una organización agrega una nueva unidad. Esta consideración puede ser aplicada a un sistema multiprocesador y no únicamente a los sistemas de bases de datos distribuidas. Reducción en la sobrecarga de la comunicación. Bases de Datos Distribuidas 5 . En un sistema centralizado cualquier cambio en las dimensiones del sistema tendría un impacto mayor. Confiabilidad y disponibilidad. no solo en las nuevas aplicaciones. garantía de que exista una completa confiabilidad en el sistema. el factor que las aplicaciones locales verían claramente reducido es la sobrecarga de las comunicaciones. debido al gran número de componentes. de esta forma es minimizada la mutua interferencia entre diferentes procesadores. 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. En una base de datos distribuida geográficamente. pues requiere del uso de ciertas técnicas.

ningún sitio deberá depender de algún otro sitio para su buen funcionamiento. en la medida. La siguiente expresión se podría considerar como el principio fundamental de los sistemas distribuidos en general. Bases de Datos Distribuidas 6 . tales reglas son: Autonomía local. Esto quiere decir que. y por tanto es aplicable a las bases de datos distribuidas: Desde el punto de vista del usuario. aunque sean accesibles para algún sitio remoto. las cuales norman la existencia de un sistema distribuido y en este caso.3 Los doce objetivos de una base de datos distribuidas. Dichos sistemas deberán apegarse a ellas. Al principio fundamental antes mencionado se le conoce como el "objetivo o regla cero" de los sistemas distribuidos. Por tanto.Fundamentos de las Bases de Datos Distribuidas 1. de una base de datos distribuida. integridad y representación en almacenamiento de los datos locales permanecen bajo el control del sitio local. Existen doce reglas u objetivos más. la seguridad. La autonomía local significa que todas las operaciones en un sitio se controlan en ese sitio. con responsabilidad local: todos los datos pertenecen a una base de datos local. un sistema distribuido deberá ser idéntico a un sistema no distribuido. en que el diseño y la tecnología lo permitan. La autonomía local implica también un propietario y una administración local de los datos. Los sitios de un sistema distribuido deberán ser autónomos. los usuarios de un sistema distribuido deberán comportarse exactamente como si el sistema no estuviera distribuido.

el sistema sería vulnerable. 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. si el sitio central sufriera un desperfecto. no debe haber dependencia de un sitio central maestro para obtener un servicio central. La idea básica de la independencia con respecto a la localización es simple. Existen en esencia dos clases de fragmentación. Dependencia (o Transparencia) con respecto a la localización. lo ideal seria que nunca hubiera la necesidad de apagar el sistema a propósito. Es decir. 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. La no dependencia de un sitio central es deseable por sí misma. no debe ser necesario que los usuarios sepan donde están almacenados físicamente los datos. Operación continua.Fundamentos de las Bases de Datos Distribuidas No dependencia de un sitio central. todo el sistema dejaría de funcionar. el sitio central podría ser un cuello de botella. La autonomía local implica que todos los sitios deben tratarse igual. 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. En un sistema distribuido como en uno no distribuido. horizontal y vertical. 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. en segundo lugar. Bases de Datos Distribuidas 7 . La fragmentación es deseable por razones de desempeño: los datos pueden almacenarse en la localidad donde se utilizan con mayor frecuencia. como actualizar el DBMS de un sitio existente o añadir un nuevo sitio. aún si no se logra la autonomía local completa. de manera que la mayor parte de las operaciones sean locales y se reduzca el tráfico de la red. La dependencia de un sitio central seria indeseable al menos por dos razones: primero. el sistema nunca deberá necesitar apagarse para que se pueda realizar alguna función.

La desventaja principal de las replicas es la actualización. 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. Así. Independencia de réplica. en muchos sitios distintos. habrá muchas maneras de trasladar los datos en la red para satisfacer la solicitud y es crucial encontrar una estrategia eficiente. Un sistema maneja réplica de datos si una relación dada (o. la importancia crucial de la optimización es obvia. Procesamiento distribuido de las consultas. también puede significar una mejor disponibilidad.Fundamentos de las Bases de Datos Distribuidas Un fragmento puede ser cualquier subrelación arbitraria que pueda generarse de la relación original mediante ciertas operaciones. La réplica es deseable al menos por dos razones: primero. como la fragmentación. La réplica. En segundo lugar. Lo esencial es que. puede producir un mejor desempeño (las aplicaciones pueden operar sobre copias locales en vez de tener que comunicarse con sitios remotos). En otras palabras. 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. 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). donde están implicados varios sitios. un fragmento dado de una relación) se puede representar en el nivel físico mediante varias copias almacenadas o réplicas. La optimización es todavía más importante en un sistema distribuido que en uno centralizado. Bases de Datos Distribuidas 8 . en una consulta. o trasladando las dos a un tercer sitio Z. la base de datos deberá comportarse como si solo existiera una sola copia de los datos. 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). el problema de la propagación de actualizaciones. ya que cuando se actualiza un objeto copiado. debe ser transparente al usuario. deben de ser actualizadas todas las replicas de este objeto: Esto es. es decir. Por ejemplo.

esta función en un ambiente distribuido está basada con toda seguridad en el bloqueo. En un sistema distribuido. Independencia con respecto al equipo. Independencia con respecto al sistema operativo. pero en la práctica. Por tanto. El manejo de transacciones tiene dos aspectos principales. con equipo distinto y diferentes sistemas operativos. Este objetivo es en parte un corolario del anterior. el sistema debe asegurarse de que todos los agentes correspondientes a esa transacción se comprometan al unísono o retrocedan al unísono. Resulta obvia la consecuencia no sólo de poder ejecutar el mismo DBMS en diferentes equipos. Bases de Datos Distribuidas 9 . el control de recuperación y el control de concurrencia. Independencia con respecto a la red. por ejemplo. una sola transacción puede implicar la ejecución de código en vados sitios. donde un agente es el proceso ejecutado en nombre de una transacción dada en un sitio determinado. sino también de poder ejecutarlo en diferentes sistemas operativos (aun en diferentes sistemas operativos del mismo equipo). se dice que cada transacción está compuesta de varios agentes. Y el sistema requiere saber cuándo dos agentes son parte de la misma transacción. como sucede en los sistemas no distribuidos (se han estudiado otras estrategias para el control de concurrencia. resulta obvia la conveniencia de poder manejar también varias redes de comunicación distinta. 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. Si el sistema ha de poder manejar múltiples sitios diferentes. Este efecto puede lograrse mediante el protocolo de compromiso de dos fases. Para asegurar que una transacción dada sea atómica en el ambiente distribuido.Fundamentos de las Bases de Datos Distribuidas Manejo distribuido de transacciones. En cuanto al control de concurrencia. el bloqueo parece seguir siendo la técnica preferida). es obvio que no puede permitirse un bloqueo mutuo entre dos agentes que sean de la misma transacción.

Esto es. no necesitan ser por fuerza copias del mismo sistema. podría ser posible lograr una comunicación entre los dos en el contexto de un sistema distribuido. En la terminología LAN.Fundamentos de las Bases de Datos Distribuidas Independencia con respecto al sistema manejador de base de datos (DBMS). Por ejemplo. 1. Bases de Datos Distribuidas 10 . El nombre de servidor es apropiado. y seria agradable que todos esos DBMS distintos pudieran participar de alguna manera en un sistema distribuido. el rol de las estaciones de trabajo fue cambiando hasta convertirse en clientes de los servidores. En el procesamiento de dispositivos compartidos en la red de área local (LAN).4. 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.4. al menos en cierto grado. sino también ejecutan diferentes DBMS.4 Arquitectura Cliente/Servidor 1. tales dispositivos son llamados servidores (un servidor de archivos y un servidor de impresión serían un ejemplo). 1. varios sistemas operativos diferentes. En realidad no se requiere sino que los DBMS en los diferentes sitios manejen todos la misma interfaz.1 Paradigma Cliente/Servidor. 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). el sistema distribuido podría ser heterogéneo. puesto que estos dispositivos compartidos son usados para recibir solicitudes de servicio de las computadoras personales (PCs). las computadoras personales están enlazadas a un sistema de dispositivos que permite a las computadoras personales (PCs) compartir recursos. Al mismo tiempo. Dicho de otro modo.2 Procesamiento Cliente/Servidor. típico en las redes de área local. Una vez más. en la realidad las instalaciones de cómputo no solo suelen emplear máquinas distintas. los clientes realizan solicitudes de servicios a los servidores. El modelo de procesamiento cliente/servidor surgió como un concepto de alto nivel de procesamiento compartido de dispositivos.

 Facilita el uso de interfaces de usuario gráficas (GUI) disponibles en estaciones de trabajo. el servidor puede convertirse en cuello de botella. En este modelo.  Si una parte significativa de la aplicación lógica es movida al servidor. ambientes run-time y herramientas usadas para el mantenimiento de este ambiente distribuido.4 Desventajas de la arquitectura cliente/servidor. y por consiguiente las necesidades de una red de banda ancha y el costo se ven reducido. Bases de Datos Distribuidas 11 . Esto es. 1. el procesamiento de aplicaciones esta dividido entre el cliente y el servidor.  Permite que el procesamiento de los datos se realice en el lugar en el que se encuentran. la cual solo se obtenía con mainframes. son más complicadas que las no distribuidas. Estas nuevas interfaces pueden ser usadas por una gran variedad de clientes y cuentan con diferentes técnicas para mostrar la información. Esto es verdad para las aplicaciones de desarrollo. 1. logrando con esto una fácil navegación. que eran muy costosas. 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.3 Ventajas de la arquitectura cliente/servidor. Los recursos del servidor pueden verse disminuidos por el incremento de demanda debido al aumento de usuarios. (La arquitectura cliente/servidor es una forma especial de procesamiento distribuido y cooperativo) Por lo tanto.  Permite el uso de sistemas abiertos. especialmente las que son diseñadas para el proceso cooperativo. En la actualidad las estaciones de trabajo tienen un rendimiento y una potencia. el tráfico en la red se ve reducido significativamente.  Las aplicaciones distribuidas. El procesamiento es inicializado y parcialmente controlado por el solicitante del servicio (cliente) pero no es un funcionamiento maestro-esclavo.4.4.Fundamentos de las Bases de Datos Distribuidas El modelo de procesamiento cliente/servidor es una extensión natural del procesamiento de dispositivos compartidos.  Permite a las corporaciones obtener cada vez mejores tecnologías de computo.

4. según se necesite. Lo llama directamente el usuario y se ejecuta solo durante la sesión. en donde el procesador desplegaba los caracteres recibidos secuencialmente desde una aplicación en pantalla con caracteres de tamaño fijo. pero contacta activamente con un servidor remoto a la vez. Las funciones tradicionales de presentación basadas en caracteres.Fundamentos de las Bases de Datos Distribuidas 1. El usuario final interactúa con una aplicación desarrollada para la presentación lógica del sistema. Las interfaces de presentación entre el usuario y la aplicación son llamadas interfaces Gráficas de Usuario (GUI). Se ejecuta localmente en la computadora personal del usuario. Inicia el contacto con el servidor. por tanto. Estas características permiten el desarrollo de interfaces gráficas de usuario (GUI) capaces de manejar gráficos. y son diseñadas para presentar la información a los usuarios de forma gráfica. Existe una gran variedad de interfaces. pero también lleva a cabo otro computo local.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. 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. imágenes.4. y las aplicaciones sean modificadas. Una nueva interfaz de usuario requiere que las aplicaciones sean reescritas para esta nueva plataforma. Las aplicaciones escritas Bases de Datos Distribuidas 12 . 1. 1.4. Las características gráficas permiten al procesador controlar de manera individual los píxeles en la pantalla. Puede acceder a varios servicios.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. y audio-video. No necesita hardware poderoso y un sistema operativo complicado.5 Características del cliente       Es un programa de aplicación arbitrario que se vuelve cliente temporalmente cuando necesita acceso remoto. pero cada nueva interfaz requiere que los usuarios y los desarrolladores tengan una nueva capacitación en sus usos. no esta limitado a un tipo de carácter o al número de columnas de la pantalla.

Fundamentos de las Bases de Datos Distribuidas para una GUI especifica no son portabas a otro ambiente GUI. aunada a asociaciones de usuarios prefieren una GUI en particular. Un ejemplo de Aun cuando la industria del hardware y software. así como mensajes relacionados con la cultura de esos países. pero puede manejar varios clientes remotos a la vez. Esto incluye otros lenguajes. de esta manera permitiría una fácil y rápida manera de migrar de una plataforma a otra. 13 Bases de Datos Distribuidas . Una GUI estándar debe de proporcionar un API estable en cualquier plataforma. Herramientas de desarrollo: Cualquier GUI que sea considerada un estándar debe proporcionar un conjunto de herramientas para el desarrollo. y símbolos especiales. la cual debe de cumplir los siguientes requisitos: Portabilidad. formatos de fecha y hora. pero ofrece un solo servicio. Internacionalización: En la actualidad. Independencia de plataforma: Para ser un verdadero sistema abierto y un estándar. Acepta el contacto de varios clientes.Las aplicaciones deben de ser portabas a través de varias plataformas de sistema abiertos. unidades monetarias.Una GUI estándar debe de ser flexible y extensible. en el que se esta ejecutando. permitiendo ajustarse a nuevos tipos de monitores y a otros dispositivos de entrada salida. Se inicia automáticamente al arranque del sistema y continua ejecutándose en varias sesiones. Se tiene una GUI estándar.. Espera pasivamente el contacto de los clientes remotos. Windows y Unix.8 Características del servidor     Es un programa privilegiado de propósito especial dedicado a ofrecer un servicio. una GUI deberá ser diseñado para operar independientemente del sistema operativo o la plataforma de hardware. interfaces incompatibles es Linux. que podrían estar disponibles en un futuro.4. Flexibilidad. números. la internacionalización es otra de la forma de lograr una portabilidad.. 1.

 Impresión compartida. los servidores de bases de datos nos permiten un rápido almacenamiento en disco. Idealmente. una impresora de alto desempeño puede reemplazar a todas las impresoras individuales de los clientes. En un ambiente de grupo de trabajo. Entonces todos los clientes pueden enviar sus solicitudes de impresión a los servidores de impresión. En un ambiente de grupo de trabajo. Un servidor de impresión mantiene todos los archivos a ser impresos en una cola.4. y en su tumo. 1. En la computación cliente/servidor. Bases de Datos Distribuidas 14 .Fundamentos de las Bases de Datos Distribuidas  Necesita hardware poderoso y un sistema operativo complejo. un significativo poder de procesamiento. Estos archivos se colocan en procesadores de archivos compartidos (Servidores de archivos) y los clientes envían a estos sus solicitudes de 110. Un servidor es un proceso lógico que provee servicios a solicitudes de procesamiento. una vez que un cliente y un servidor se han interconectado a través de una red.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. entonces el servidor no puede participar en una interacción cooperativa cliente/servidor. Básicamente. Si un servidor es incapaz de llevar a cabo la solicitud de un cliente. y la capacidad de interactuar con varia aplicaciones (clientes) de manera simultánea. En general. los clientes tal vez necesiten compartir los mismos archivos de datos. cada una de ellos serán impresos. Un cliente no envía una solicitud que no sea soportada por un servidor. sin embargo. La función que un servidor debe llevar a cabo es determinada. a la cual se envían todos los archivos de los usuarios. un cliente inicia la interacción cliente/servidor para enviar las solicitudes a los servidores. en gran parte. por el tipo de solicitud que los clientes puedan enviar al servidor. alguna de las siguientes funciones pueden ser solicitadas al servidor por el usuario:  Compartir archivos.

En un ambiente cliente/servidor. el procesamiento esta dividido en el sistema cliente y el sistema servidor. Los clientes envían y reciben documentos de fax por medio de una apropiada solicitud del servicio al servidor de fax.  Servicios de Fax Esto requiere usualmente software y equipo especial. un servidor debe de ser capaz de proporcionar servicio a múltiples usuarios concurrentes. manejo de configuración y manejo de recursos. los servidores deben cumplir con los siguientes requerimientos generales:  Soporte multiusuario. De cualquier forma. Un nodo servidor dentro del modelo cliente/servidor puede ser especializado para realizar cierta función. Los Bases de Datos Distribuidas 15 . para los cuales se deberá de tener los servidores apropiados. Algo similar al servidor de archivos. todas las comunicaciones de software y hardware se concentran en un dispositivo especial conocido como servidor de comunicaciones. el sistema manejador de bases de datos (DBMS). En un ambiente de grupo de trabajo que se encuentra conectado a un host remoto. conocido como servidor de fax. es más sofisticado que los métodos de acceso básicos. y toda la manipulación necesaria para dar respuesta a la solicitud se realiza en el servidor de bases de datos. clientes requieren acceder ciertos datos (a diferencia de un servidor de archivos en el cual se tiene acceso al archivo completo). El DBMS de un acceso a los datos por medio de varios niveles de bloqueo y de integridad de datos. El DBMS elimina la Los redundancia permitiendo una transparencia de distribución de datos. Sin embargo. de red. El servidor puede ejecutar una parte de la lógica de la base de datos.  Acceso a las bases de datos. Otras funciones solicitadas por los clientes pueden ser de correo electrónico. Aun en un pequeño grupo de trabajo. al cual los clientes envían sus solicitudes para ser procesadas. el servidor de bases de datos provee al cliente de los datos que residen en el servidor por medio de una solicitud.Fundamentos de las Bases de Datos Distribuidas  Servicios de comunicación.

y DEC en un proyecto conocido como Athena. La arquitectura X está basada en el modelo cliente/servidor. Por el contrario. debe de permitir una fácil expansión. Como el número de aplicaciones ejecutándose y de usuarios aumentan. comunicación de red.  Gestión de redes. X proporciona: Bases de Datos Distribuidas 16 . Conocido también como X. vídeo y sonido.  Almacenamiento.1 0 El sistema X Window El sistema X Window permite un manejo transparente de la interfaz gráfica en estaciones de trabajo. significa que usuarios deben comprar un sistema de servidor de mayor capacidad de procesamiento lo cual implicaría un costo extra.  Desempeño. Un servidor debe de ser capaz de satisfacer la creciente Escalabilidad no demanda de los recursos. es necesario dar soporte al almacenamiento y reproducción de imagen.4. así como de las aplicaciones.  Escalabilidad. Sin una red el cliente y el servidor no podrían interactuar. y los avances de la tecnología de dispositivos de almacenamiento han hecho que los costos bajen. IBM. 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. al mismo tiempo. cliente y servidor deben de contar con capacidades de red. fue desarrollado conjuntamente por el Instituto Tecnológico de Massachussets. La comunicación cliente/servidor requiere de una Ambos. el sistema debe de satisfacer los requerimientos actuales y.Fundamentos de las Bases de Datos Distribuidas clientes ejecutan múltiples tareas esperando que el servidor sea capaz de soportar un procesamiento multitarea. la demanda de almacenamiento de rápido acceso se ha convertido en un requisito esencial en un sistema servidor. 1.  Multimedia. Las nuevas aplicaciones y las nuevas tecnologías cuentan con capacidades multimedia.

aunque esta residiría en un sistema “servidor” en la red cliente/servidor. En la tecnología cliente/servidor. el X Server. 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. e interactúa con el usuario. además del proceso de ejecución de 17 Bases de Datos Distribuidas .5 Problemas de los sistemas distribuidos El mayor problema en las redes de área amplia es que son lentas. la cual puede residir en una estación de trabajo remota. el nodo que despliega y recibe información.Fundamentos de las Bases de Datos Distribuidas  Un Protocolo de comunicación transparente entre una aplicación y su presentación lógica. entre ellas las siguientes: Procesamiento de consultas. un objetivo principal de los sistemas distribuidos es reducir el número y volumen de los mensajes. X Client y X Server pueden estar en la misma máquina. el X cliente inicia la interacción con su servidor. mientras que un disco duro representativo tiene un factor de transferencia de al rededor de 1 a 2 millones de bytes por segundo. Por ejemplo algunas redes tienen una velocidad de transferencia de 1250 bytes por segundo. 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. Este objetivo a su vez da pie a problemas en varias áreas secundarias. De hecho:     En el sistema X Window. Los X clients contienen la aplicación lógica funcional escrita por el desarrollador. Por lo tanto. 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. Un X Server puede dar servicio a múltiples X clients. 1. es el nodo cliente.  Alto desempeño en la independencia de dispositivos gráficos. El X Client solicita un X Server para las funciones de despliegue en pantalla.

4.Fundamentos de las Bases de Datos Distribuidas las consultas. Administración del catálogo. el optimizador local en Z será el que decida cuál debe ser la estrategia para realizar la unión en este sitio. índices. 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. etcétera. un sitio central único mantiene una copia unificada de todos los catálogos locales. la fragmentación y la réplica. Replicas completas: El catálogo total se almacena por completo en todos los sitios. además. un proceso representativo consistirá en un paso de optimización global. como en el punto 1. 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. en un sitio central. seguido de pasos de optimización local en cada uno de los sitios. una vez que haya decidido trasladar Ry a Z. 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). Por ejemplo se requiere una consulta C en el sitio X. El catálogo total es la unión de todos los catálogos locales no traslapados. Todos estos enfoques tienen algún problema. Centralizado: El catálogo total se almacena una sola vez. como en el punto 3. pues toda actualización del catalogo deberá de ser propagada a cada uno de los sitios. 3. 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). el catálogo del sistema incluirá no solo la información usual acerca de las relaciones. El enfoque 4 es más eficiente que el 3 (encontrar un objeto remoto requiere sólo el acceso a su catálogo remoto). En un sistema distribuido. El optimizador ubicado en el sitio X escogerá la estrategia global para ejecutar C. Combinación de 1 y 3: Cada sitio mantiene su propio catálogo local. Existen varias técnicas para el almacenamiento de los catálogos: 1. 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. pero viola una vez más el objetivo de "no Bases de Datos Distribuidas 18 . usuarios. Dividido: Cada sitio mantiene su propio catálogo para los objetos almacenados en ese sitio. Después. En otras palabras. 2.

este método es distribuido).Fundamentos de las Bases de Datos Distribuidas dependerá de un sitio central". la estrategia de propagar las actualizaciones de inmediato a todas las copias podría ser inaceptable. Este método representa un problema. El problema básico con la réplica de datos. porque implica que la modificación ( y la transacción) fracasara si cualquiera de estas copias no esta disponible en el momento. Propagación de actualizaciones. el cual funciona de la siguiente manera:    Una de las copias del objeto se designa como copia primaria. 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. una violación al objetivo de autonomía local. los sistemas en la practica casi nunca usan ninguno de estos cuatro enfoques. Un método para manejar este problema es el llamado método de "copia primaria". Las copias primarias de los diferentes objetos están en sitios diferentes (de modo que. una vez más. Bases de Datos Distribuidas 19 . aun cuando se dispusiera de una copia local. Las demás serán copias secundarias. El sitio donde se encuentra esa copia se encarga entonces de propagar la actualización a las copias secundarias en un momento posterior. 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. Control de recuperación. porque ahora una transacción podría fallar cuando una copia (primaria) remota de algún objeto no estuviera disponible. Así. Las operaciones de actualización se consideran completas tan pronto como se ha modificado la copia primaria. Por lo tanto.

Control de concurrencia. El proceso de compromiso en dos fases requiere una comunicación entre el coordinador y todos los sitios participantes. las solicitudes de prueba. 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. 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. se considerara una transacción T que necesita poner al día un objeto del cual existen réplicas en n sitios remotos. el proceso debería ser capaz de soportar cualquier tipo concebible de falla. establecimiento y liberación de bloqueo se convierten en mensajes (suponiendo que el objeto en cuestión es un sitio remoto). 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. Idealmente. Por lo general se encarga de ella el sitio en el cual se inicia la transacción en cuestión. El sitio Y actúa como participante en un compromiso de dos fases coordinado por el sitio X. De acuerdo a lo anterior surgen los siguientes puntos: 1. lo cual implica más mensajes y mayor costo.Fundamentos de las Bases de Datos Distribuidas El control de recuperación en los sistemas distribuidos se basa por lo regular en el protocolo de dos fases. 2. tal como sucede en casi todos los sistemas no distribuidos. el sitio Y deberá hacer lo ordenado por el sitio X (compromiso o retroceso). y los mensajes implican costos adicionales. 4. Si cada sitio se encarga de los bloqueos sobre los objetos almacenados en Bases de Datos Distribuidas 20 . lo cual implica otra pérdida de autonomía local. 3. Pero en un sistema distribuido. 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. Como en mayor parte de los sistemas distribuidos el control de concurrencia se basa en el bloqueo. Por ejemplo.

Fundamentos de las Bases de Datos Distribuidas

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 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
21

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

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 INFORMIX VS.07 DB2 V5 ORACLE V8

DSL SQL SQL SQL

REPLICA Soportada Integrada 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.

1.7 Resumen
Las características que deben de tener los sistemas de bases de datos son:
22

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

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:

Razones organizacionales: La mayor parte de las organizaciones están ya descentralizadas.

Bases de Datos Distribuidas

23

Hay además de este. 12 reglas para los sistemas distribuidos: Autonomía local: Significa que todas las operaciones en un sitio se controlan en ese sitio. Independencia con respecto a la localización: Los usuarios nunca sabrán la localización real de los datos. Reducción de la sobrecarga de la comunicación: En una base de datos distribuida geográficamente.Fundamentos de las Bases de Datos Distribuidas 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. No dependencia de un sitio central: Todos los sitios son iguales y no dependen de ningún otro sitio. se vería reducida la sobrecarga de las comunicaciones en comparación con una base de datos no distribuida. Existe un principio fundamental en los sistemas distribuidos. Bases de Datos Distribuidas 24 . un sistema distribuido deberá ser idéntico a un sistema no distribuido. Desarrollo incrementar: Es posible agregar una nueva unidad en una base de datos distribuida si afectar a las ya existentes. se logra un alto grado de contabilidad y disponibilidad. Confiabilidad y disponibilidad: Por medio de la repica de datos. Consideraciones en el desempeño: La existencia de varios procesadores autónomos da como resultado un alto grado de procesamiento en paralelo. Operación continua: Un sistema distribuido siempre esta disponible. el cual es aplicable a las bases de datos distribuidas: Desde el punto de vista del usuario.

Independencia con respecto al sistema operativo: Deberá de ser capaz de trabajar en cualquier sistema operativo. Independencia con respecto al DBMS: Varios DBMS deberán trabajar en conjunto y procesar las transacciones. Independencia con respecto a la red: Deberá de ser capaz de trabajar en diferentes redes. Procesamiento distribuido de consulta: En una consulta. la computadora que solicita el recurso pasa a Bases de Datos Distribuidas 25 .Fundamentos de las Bases de Datos Distribuidas Independencia con respecto a la fragmentación: Un sistema distribuido deberá dar la apariencia de que se encuentra en una sola pieza. El paradigma que dispone que una aplicación debe esperar pasivamente a que otra aplicación inicie la comunicación. Así. las computadoras personales conectadas a un sistema pueden compartir recursos. El modelo de procesamiento cliente/servidor surgió del concepto de procesamiento compartido de las redes de área local. 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. Independencia de replica: Un sistema deberá comportarse como si solo e)dstiera una sola copia de los datos. Manejo distribuido de transacciones: Deberá poder procesar una transacción a través de varios sitios. tiene el nombre de interacción cliente/servidor. 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.

Servidor Bases de Datos Distribuidas 26 .Fundamentos de las Bases de Datos Distribuidas ser un cliente. Se ejecuta localmente en la computadora personal del usuario. Tanto el cliente como el servidor. Esta arquitectura provee ciertas ventajas:     Permite integrar mejores tecnologías al sistema. al verse disminuidos los recursos del servidor. Puede acceder a varios servicios. pero contacta activamente con un servidor remoto a la vez. Inicia el contacto con el servidor. pero también lleva a cabo otro computo local. 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. El desarrollo de aplicaciones distribuidas es más complicado que el de las no distribuidas. Permite el uso de sistemas abiertos. Lo llama directamente el usuario y se ejecuta solo durante la sesión. según se necesite. mientras que aquella que comparte el recurso y recibe la petición se convierte en servidor. también cuenta con algunas desventajas:   El servidor puede convertirse en cuello de botella. No necesita hardware poderoso y un sistema operativo complicado. A pesar de todo esto. 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.

Por su parte el servidor debe de proveer servicios a solicitudes de procesamiento. Se inicia automáticamente al arranque del sistema y continua ejecutándose en varias sesiones. de acuerdo a la solicitud enviada por el cliente. Almacenamiento: Debe de ser capaz de almacenar tanto aplicaciones. Servicios de comunicación. la función de un servidor debe llevar a cabo una determinada acción. pero ofrece un solo servicio. Accesos a las bases de datos. pero puede manejar varios clientes remotos a la vez. cumplir con ciertos requerimientos generales:     Soporte multiusuario: Debe de ser capaz de proporcionar servicio a múltiples clientes. Servicios de fax. Necesita hardware poderoso y un sistema operativo complejo. el cliente inicia la interacción cliente/servidor enviando solicitudes a los servidores. no en una computadora personal). Espera pasivamente el contacto de los clientes remotos. Acepta el contacto de varios clientes. Algunas funciones que un servidor pudría realizar seria:      Compartir archivos.Fundamentos de las Bases de Datos Distribuidas       Es un programa privilegiado de propósito especial dedicado a ofrecer un servicio. Bases de Datos Distribuidas 27 . así como de realizar algunas funciones lógicas en el procesamiento de dicha información. Desempeño: Un servidor debe proveer niveles de desempeño satisfactorios. Escalabilidad: Debe de ser capaz de satisfacer la creciente demanda de los recursos y las aplicaciones. Opera en una computadora compartida (es decir. como los archivos generados por estas y los usuarios. Compartir impresoras. Un servidor deberá. también. El cliente debe de cumplir con la función de presentar la información al usuario.

en todas las copias existentes de ese objeto en el sistema. Debido a que un sistema distribuido involucro el procesamiento cooperativo entre vados servidores y clientes. el catalogo del sistema incluirá la información a cerca de las relaciones. los usuarios. Control de recuperación: Es necesario que un sistema distribuido cuente con un método de recuperación. y la localización de fragmentos y replicas de los datos. los índices. El control de recuperación en los sistemas distribuidos se basa por lo regular en el protocolo de dos fases. vídeo y sonido son esenciales. las solicitudes de prueba. mensajes de actualización. y por lo tanto implica costos adicionales. se presentan algunos problemas que se deben de tomar en cuenta para ser solucionados: Procesamiento de consultas: El proceso deberá de ser distribuido. un proceso representativo consistirá en una actualización global seguida de optimizaciones locales en cada sitio. concesiones de bloqueo. esto. La puesta en practica directa requerirá por lo menos de 5 mensajes por cada sitio involucrado en la transacción: solicitud de bloqueo. Administración del catalogo: En un sistema distribuido. establecimiento y liberación de bloqueo. Bases de Datos Distribuidas 28 . Propagación de las actualizaciones: Es necesario propagar cualquier actualización de un objeto dado. los cuales se convierten en mensajes. 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.Fundamentos de las Bases de Datos Distribuidas   Gestión de red: Tanto el servidor como el cliente deben de contar con capacidades de red. en caso de caídas del sistema. solicitudes de liberación de bloqueo. Multimedia: En la actualidad la necesidad de que un servidor soporte datos. verificaciones. Control de concurrencia: el control de concurrencia se basa en el bloqueo. por lo tanto.

-¿Cuales deben ser las características de un cliente? 9.-¿Por qué la regla cero de los sistemas distribuidos es considerada el principio de las bases de datos distribuidas? 5. 1.servidor? 8. y de la misma manera al evolucionar las bases de datos centralizadas a distribuidas. es posible hacer una comparación entre bases de datos centralizadas y bases de datos distribuidas? 2.. replicación.-¿Que significa transparencia dentro del entorno de las bases de datos distribuidas? 7. el soporte de fragmentación. y el procesamiento de consultas distribuidas.-¿A que se refiere la autonomía en el enfoque de las bases de datos distribuidas? 6.¿Cuales son los principales problemas a los que se enfrentan los diseñadores de bases de datos distribuidas? Bases de Datos Distribuidas 29 .-¿Cómo describe la arquitectura cliente .-¿Cuales son las ventajas que tienen las bases de datos distribuidas sobre las centralizadas? 3.Fundamentos de las Bases de Datos Distribuidas Al aumentar la cantidad de datos y la necesidad de información.8 Preguntas de repaso 1.-¿Cuáles deben ser las caracteristic as de un servidop 10.-¿Que requerimientos son necesarios para un servidor? 11.-¿Cuales son las características sobre las cuales.-¿Cuál es la regla cero de los sistemas distribuidos? 4. los DBMS también tuvieron que evolucionar a lo que actualmente se conoce como Sistemas Manejadores de Bases de Datos Distribuidas (DDBMS). Sin dejar a un lado que un DDBMS debe de ser un sistema abierto capaz de interactuar con otros DDBMS. Estos DDBMS deberán contar con: el sublenguaje de consultas.

. Wiley Professional Computing. McGraw-Hill. Reprinted July.A. Volume 1-1 Fifth Edition.J.S. U. Addison-Wesley Publishing Company. "Introduction to Client/Server Systems A practicar guide for systems professionals". Alex . Reprinted July. 1992 [5] Renuad. Internacional Edition 1991 [4] Berson. McGraw-Hill.A."Client/ServerArchitecture'.S.-. "An lntroduction to Databases Systems". 1990 [2] Date.A. "Database System Concepts". "An Introduction to Databases Systems". U..S.J-. C. 1993 Bases de Datos Distribuidas 30 ..A-. C.S. U.Fundamentos de las Bases de Datos Distribuidas Bibliografía [1] Date. Paul E.. Volume li. 1995 [3] Korth.A. Silberschatz. Addison-Wesley Publishing Company.. Henry F. Second Edition.S. Abraham. U. U.

así como cada uno de los tipos de fragmentación existentes y las operaciones necesarias para realizarla. 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.Fundamentos de las Bases de Datos Distribuidas Capítulo II Bases de Datos en múltiples servidores Objetivo El alumno comprenderá las técnicas de diseño de bases de datos distribuidas. 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 Select Projecion Join Semi-join Union Producto cartesiano Natural Join Natural Semi-join Diferencia Abreviación SL Pi JN si UN CP NJN NSJ DF Símbolo    X  Bases de Datos Distribuidas 31 . así como los tipos de fragmentaciones que existen y como se obtienen. 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.

Estos dos puntos son característicos en el diseño de datos distribuidos. La distribución de las bases de datos requiere agregar dos nuevos puntos: 3. puesto que se sustituirá por un sistema distribuido al típico y extenso sistema centralizado. horizontalmente. determinando como se mapearán los fragmentos. y en el caso de la distribución de una aplicación tendría un gran impacto en la organización. y la distribución optima de los datos y aplicaciones en los sitios para lograr un desempeño optimo del sistema. Diseñar la distribución de los fragmentos. Diseñar el "esquema conceptual". 4. Desde el punto de vista técnico. El diseño de una base de datos centralizada consiste en: 1. los nuevos problemas que se presentan son la interconexión entre los sitios por medio de la red. De cualquier forma esta claro que el diseño de bases de datos distribuidas no es fácil. con las imágenes físicas.1 Consideraciones en la distribución de bases de datos Desde la primera etapa de las bases de datos distribuidas a la actualidad. el cual describe la base de datosDiseñ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. las técnicas y organización. se han desarrollado varias técnicas para su diseño. 2. Bases de Datos Distribuidas 32 . la descentralización es crucial. ya que por si mismas. verticalmente o en fragmentos mixtos. determinando como las relaciones globales serán divididas. Diseñar la fragmentación de los datos. Desde el punto de vista organizacional. en el diseño de un sitio sencillo son complicadas.Fundamentos de las Bases de Datos Distribuidas 2. En este punto son determinadas las replicas de los fragmentos. éstas se vuelven más complicadas en el diseño de un sistema multisitio.

esto correspondiendo a un principio básico de que los datos son colocados lo más cercano a las aplicaciones que los utilizan. de caídas del sistema o de daños físicos en alguna de las copias. una vez que los sitios de origen de las aplicaciones conocen la localización local y remota de los datos. también.Fundamentos de las Bases de Datos Distribuidas 2. 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. Una manera simple de ejemplificar el procesamiento local. La distribución de los datos aumenta el procesamiento local. es decir la aplicación se ejecuta completamente en el lugar de origen.1. incremento la simplicidad en el control de la ejecución de la aplicación. Disponibilidad y confiabilidad de los datos distribuidos. y para Bases de Datos Distribuidas 33 . Claramente. usando cualquier otra copia disponible. La distribución de la carga del trabajo en los sitios es una característica importante de los sistemas distribuidos. Se deberá. el sistema puede conmutar a una copia alternativa. sino que además. tomar en cuenta cuando una aplicación tiene un procesamiento local completo. Distribución de la carga del trabajo.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 ventaja del procesamiento local completo no solamente reduce los accesos remotos. 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. es considerar dos tipos de referencias a los datos: referencias "locales" y referencias "remotas". 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. la referencia depende únicamente de la distribución de los mismos.

La distribución de las bases de datos se refleja en el costo y disponibilidad del medio de almacenamiento en los diferentes sitios. se deberá de unir definiciones de datos comunes y resolver conflictos entre diferentes representaciones del mismo dato. Por lo general. en este caso el esquema global está. Esta técnica consiste en la integración de esquemas existentes en un solo esquema global. la técnica de diseño bottom-up puede ser utilizada. la técnica bottom-up requiere: 34 Bases de Datos Distribuidas . creando las imágenes físicas. comparado con el costo de CPU. se comienza diseñando el esquema global.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. del "diseño físico" de los datos que estarán almacenados ahí. en cada sitio. Cuando una nueva base de datos va a ser agregada a una ya existente. 2. Esto es posible teniendo sitios especializados en la red para el almacenamiento de datos. las técnicas Top-Down y Bottom-Up. por lo general.De hecho.2 Diseño de bases de datos distribuidas 2. Para la integración.2. I/O. Esta técnica es complementada con la construcción. En resumen. En la técnica top-down. Disponibilidad y costo del almacenamiento. el costo del almacenamiento de los datos nos es tan relevante. y se procede con el diseño de la fragmentación de los datos. y el costo de la transmisión de las aplicaciones. después se distribuyen los fragmentos en los sitios. La distribución de la carga del trabajo puede provocar un efecto negativo en la ejecución local. Cuando la base de datos distribuida es desarrollada como un complemento de una base de datos existente. comprometido con los datos existentes.Fundamentos de las Bases de Datos Distribuidas maximizar el grado de paralelismo en la ejecución de las aplicaciones. no es tan fácil lograr esto con la técnica top-down.

.R2. 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..3 Correctez de la fragmentación Para que una fragmentación sea correcta.Fundamentos de las Bases de Datos Distribuidas 1. . 2. . los cuales serán “unidades lógicas de distribución”. Rn.2. El propósito de la fragmentación es determinar fragmentos no traslapados..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. La integración de los esquemas locales en el esquema global común. La traducción de cada esquema local al modelo de datos común. cualquier método usado para localizar un dato puede entonces localizar a cualquiera. Cada grupo de tuplas o atributos que tienen las "mismas propiedades" puede constituir un fragmento. 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).R2. Se podrá ver que. las cuales tienen las "mismas propiedades" desde el punto de vista de la distribución.2. las tuplas y atributos de la relación no podrán ser considerados como "unidades individuales de distribución'.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. 2. 3. esta deberá de cumplir con las siguientes características: Completez La descomposición de una relación R en fragmentos RI. debiera existir un operador relacional  tal que: R  Ri Exclúyete Bases de Datos Distribuidas 35 . 2.. La selección de un modelo de base de datos común para diseñar el esquema global de la base de datos. .

mi2. Rn. donde cada subconjunto pueden contener datos con propiedades geográficamente comunes.A2.P2. La frecuencia de acceso por una predicado minitermino puede también ser definida. nombre. .. .Fundamentos de las Bases de Datos Distribuidas Si la relación R es descompuesta.R2.---. . frecuencias de acceso: acc(qj) Frecuencia con la cual la aplicación qj accesa datos. >}. ≤. esto es muy utilizado en las bases de datos distribuidas.. Es importante. y datos de] elemento di están en Rj entonces di no debiera estar en algún otro fragmento Rk  k).].. cveciudad) Bases de Datos Distribuidas 36 . considerar las siguientes definiciones: Predicado simple Dado R[Al.2. .p2. Se tendrá entonces R[pl.... Valor  Di y Di es el dominio de A¡. un predicado simple pj es: pj: Ai  Valor donde   {. 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. pj definir M = {mi1. <.. Considérese la siguiente relación global: Proveedor(pclave. .. en fragmentos Rl. 2. A.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. . dentro de la fragmentación horizontal.. 1 ≤ k ≤ m.P3. miz} como: Mi = {mij l mij = ^pik  pri pik*}.PMI Predicados minitermino Dado Ri y Pti = {p1.

M7 = {~SF ^ LA ^ ~SD} M8 = {~SF ^ ~LA ^ SD} Eliminando los miniterminos contradictorios se obtiene el siguiente resultado. M6 = {~SF ^ ~LA ^ ~SD} . 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} contradictorio contradictorio contradictorio Bases de Datos Distribuidas 37 . Se tendrán los siguientes predicados simples: P1 = {cveciudad = "SF" } P2 = { cveciudad = "LA" } P3 = { cveciudad = "SD" } Dando como resultado los siguientes predicados miniterminos.Fundamentos de las Bases de Datos Distribuidas pClave Nombre cveciudad P01 P02 P03 P04 P05 P06 John Smith José Sanchéz Juan Pérez Steven Freeman Alex Tere SF LA LA SF SD SD Para la cual se tiene la siguiente aplicación: q: Obtener la clave y el nombre de los proveedores de cada ciudad.. los cuales se obtienen de las combinaciones de los predicados simples: m1 = {SF ^ LA ^ SD} m2 = {SF ^ ~LA ^ SD} m3 = {SF ^ ~LA ^ ~SD} ..

cveCiudad into Proveedor2 from Proveedor Where cveCiudad = „LA‟ Pclave Nombre P02 P03 José Sanchéz Juan Pérez Cveciudad LA LA Proveedor3 = SL cveciudad = “SD” Proveedor Select pclave.Fundamentos de las Bases de Datos Distribuidas Entonces la fragmentación horizontal estaría dada de la siguiente forma: Proveedor1 = SL cveciudad = “SF” Proveedor Select pclave. 38 Bases de Datos Distribuidas . "LA" y “SD”. cveCiudad into Proveedor3 from Proveedor Where cveCiudad = „SD‟ Pclave Nombre P05 P06 Alex Tere Cveciudad SD SD Las condiciones anteriores cumplirían con la definición de fragmentación. de otro modo no se sabría a que fragmento corresponden las tuplas que contengan otro valor. si los únicos valores posibles para el atributo Cveciudad fueran "SF". nombre. cveCiudad into Proveedor1 from Proveedor Where cveCiudad = „SF‟ Pclave Nombre P01 P04 John Smith Steven Freeman Cveciudad SF SF Proveedor2 = SL cveciudad = “LA” Proveedor Select pclave. nombre. nombre.

cveProducto. 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. Considérese el siguiente ejemplo: Pedido(pclave. por medio de la siguiente condición: Proveedor = Proveedor1 UN Proveedor2 UN Proveedor3 Create View ReconstruccionProveedor As Select * from Proveedor1 Union All Select * from Proveedor2 Union All Select * from Proveedor3 La reconstrucción de la relación global siempre se lleva a cabo. No obstante que cveciudad no es un atributo de la Bases de Datos Distribuidas 39 . por medio de la operación de unión. cant) Pclave P01 P01 P02 P03 P04 P04 cveProducto 2325 2547 3298 7895 741 0 2589 Cant 123 21 98 87 53 10 Donde pclave es la clave del proveedor.5 Fragmentación horizontal derivada En algunas ocasiones. 2.2. pero se deriva de la fragmentación horizontal de otra tabla. la fragmentación horizontal de una tabla no se puede basar en alguna propiedad de sus propios atributos.Fundamentos de las Bases de Datos Distribuidas La reconstrucción de la Tabla global Proveedor se logra fácilmente.

Fundamentos de las Bases de Datos Distribuidas tabla Pedido. los cuales no estén dentro de la tabla Proveedor. o Proveedor3 y Pedido. se necesita una operación de semi-join para determinar las tuplas de Pedido que corresponden con los proveedores en cierta cveciudad.* into Pedido2 From Pedido A Inner Join Proveedor2 B on (A.* into Pedido1 From Pedido A Inner Join Proveedor1 B on (A.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. Esto es una restricción típica dentro de las bases de datos conocida como integridad referencial.pclave=B. o Proveedor2.pclave=B. sino que es un atributo de la tabla Proveedor.pclave) Pclave P02 P03 Pnum 3298 7895 Depto Ventas Finanzas Cant 98 87 Pedido3 = Pedido SJ pclave = pclave Proveedor3 Select A. Bases de Datos Distribuidas 40 .pclave) Pclave P01 P01 P04 P04 Pnum 2325 2547 7410 2589 Depto Compras Compras Ventas Sistemas Cant 123 21 53 10 Pedido2 = Pedido SJ pclave = pclave Proveedor2 Select A. Esto se logra de la siguiente manera: Pedido1 = Pedido SJ pclave = pclave Proveedor1 Select A. La integridad de un fragmento requiere que no existan claves de proveedores en la Table Pedido.pclave=B. Por lo tanto. 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. Los Ángeles o San Diego. de esta manera se determinaran aquéllas tuplas de la Table Pedido que hacen referencia a proveedores en San Francisco.* into Pedido3 From Pedido A Inner Join Proveedor3 B on (A.

Depto) Cvemp E12 E56 E78 E98 E32 Egl E73 Nom Juan Pérez José Hernández Luis Pérez Maria SolísJohn Smith Rocio Sánchez Carmen Campos Sal 4500 756 9254 2345 5489 4600 753 Imp 15 15 15 25 2-5 15 15 Depto 15 9 17 22 22 8 15 Considérese las siguientes aplicaciones: q1: Obtener el nombre y departamento de todos los empleados q2: Obtener el clave. nombre y departamento de los empleados con salado mayor a 10. es posible reconstruir la tabla original por medio de uniones de todos los fragmentos a la vez. lmp. salado y tasa de impuestos por departamento q3: Obtener la clave.2. La fragmentación es correcta si cada atributo es mapeado por lo menos con un atributo de los demás fragmentos.Fundamentos de las Bases de Datos Distribuidas 2. por otra parte. los fragmentos son obtenidos al proyectar la tabla global sobre cada grupo. Considérese el siguiente ejemplo: Emp(Cvemp.000 Se tiene la siguiente matriz de accesos: Total de S1 q1 q2 q3 2 2 1 S2 3 1 2 S3 2 2 1 accesos 7 5 4 Bases de Datos Distribuidas 41 . Nom.6 Fragmentación vertical La fragmentación vertical de una tabla global es la subdivisión de sus atributos en grupos. Sal.

A2)= (1+2+1)(1) = 4 aff(A1. sal. la cual se obtiene por medio de la siguiente formula aff(Ai. depto From empleados q2= Select cvemp. imp From empleados Where depto = X q3= Select cvemp. de acuerdo con los atributos accesados en cada una de las aplicaciones.Fundamentos de las Bases de Datos Distribuidas Las aplicaciones se traducirían de la manera siguiente: q1= Select nom. nom. en la cual se colocara. A1)= (2+1+2)(1) + (1+2+1)(1) = 9 aff(A1.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. A4)= (2 +1+2)(1) = 5 aff(A1. A2)= (2+3+2)(1) + (1+2+ 1)(1) = 11 Bases de Datos Distribuidas 42 . A5)= (2+1+2)(1) + (1+2+1)(1) = 9 aff(A2. colocando en cada casilla un 1 si el atributo A¡ es reverenciado en la aplicación q j. A3)= (2+1+2)(1) + (1+2+1)(1) = 9 aff(A1. A1)= (1 +2+ 1)(1) = 4 aff(A2. A1 (cvemp) q1 q2 q3 0 1 1 A2 (nom) 1 0 1 A3 (sal) 0 1 1 A4 (imp) 0 1 0 A5 (depto) 1 1 1 Ahora se construirá la matriz de afinidad. depto From empleados Where sal > 10000 Con esto se podrá obtener la matriz de uso.

A5)= (2+3+2)(1) + (1 +2+ 1)(1) = 11 A1 Al A2 A3 A4 A5 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. Emp1(Cvemp. lmp. El paso restante será seleccionar los campos necesarios para cada fragmento. A5} Bases de Datos Distribuidas 43 . A3. A4. A3} Emp2= { A1. Nom) Emp2(Cvemp. A2. A2. A3)= (1+2+1)(1) = 4 aff(A2. de no ser así. A5} Emp1 { A1. A4. A2). Emp= {A1. será necesario reordenar dichas columnas para logrado. Emp2= { A1. A4. A4)= 0 aff(A2. Sal. Nom. Imp. Sal. A3. Emp Emp2 = PJCemp. esto. de acuerdo al orden en que las columnas se encuentran en la tabla. A5) Emp1 = PJcvemp. Depto) Depto Emp o en otro caso Emp1= { A1.Fundamentos de las Bases de Datos Distribuidas aff(A2.

Depto) El atributo A1 aparece en ambos fragmentos debido a que es la llave primaria de la relación global. Sal) Emp2(Cvemp. Imp.Fundamentos de las Bases de Datos Distribuidas Emp1 = PJcvemp. Nom. Nom. 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. dando como resultado las condiciones necesarias para la fragmentación.2. es posible aplicar la operación de fragmentación (vertical y horizontal) de manera recursiva. 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. Bases de Datos Distribuidas 44 . Imp Emp Emp1(Cvemp.7 Fragmentación mixta Los fragmentos son obtenidos por medio de las operaciones de fragmentación. Depto Emp Emp2 = PJCemp. Sal. que pueden relacionarse precedentemente. 2. La reconstrucción se logra aplicando las reglas de reconstrucción en orden inverso de acuerdo a la fragmentación. La manera de seleccionar que atributos irían en cada fragmento depende de las necesidades del sistema.

Sal. necesitando únicamente los campos de clave del empleado. seguida por una fragmentación horizontal por Depto: Vertical Emp1 = PJcvemp. Depto) Se tiene un sitio en el departamento fiscal el cual se encarga del cálculo de los impuestos. Nom. donde se aplica la fragmentación vertical. Nom. Imp Into Emp1 From Emp Emp Where depto=10 Into Depto10 from Emp Depto20 = SLdepto=20 PJ Cvemp. depto Depto Emp Where depto=20 Into Depto20 from Emp Depto30 = SLdepto=30 PJ Cvemp. esto es considérese la siguiente tabla: Emp(Cvemp. Sal. Por medio de las siguientes operaciones se realizará una fragmentación mixta. sal y imp) para este departamento. Select cvemp. Imp Emp Select Horizontal Depto10 = SLdepto=10 PJ Cvemp. Para el departamento fiscal. y tres sitios más. nom. lmp. El resto de la tabla global podría fragmentarse horizontalmente de acuerdo a cada departamento. nom. Select cvemp. uno por cada uno de los tres departamentos restantes dentro de la empresa. Select cvemp. es conveniente realizar una fragmentación vertical para obtener un fragmento con los campos necesarios (cvemp. las cuales se situarían en cada uno de los tres sitios restantes dentro del sistema distribuido. nom.Fundamentos de las 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. Nom. depto Depto cvemp. salario y tasa de impuesto. depto Depto Emp Where depto=30 Into Depto30 from Emp La reconstrucción de la tabla Emp se define de la siguiente forma: Bases de Datos Distribuidas 45 . Sal. obteniendo tres tablas. Por tanto. el nombre y el departamento del trabajador no son relevantes. Nom.

Depto20. nom. y los nodos intermedios corresponden a los fragmentos intermedios. Depto30) JNCvemp = Cvemp PJCvemp. la raíz corresponde a la tabla global. las hojas corresponden a los fragmentos. imp. 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. A continuación se presenta el árbol de distribución del ejemplo anterior: Emp V H Depto10 Depto20 Emp1 Depto30 Bases de Datos Distribuidas 46 .cvemp) inner join Emp1 B On La fragmentación mixta se representa generalmente por medio de un árbol de fragmentación. Sal.Fundamentos de las Bases de Datos Distribuidas Emp = UN(Depto10. resultantes de las operaciones. depto From ReconstruccionHorizontal A (A. En el árbol de fragmentación.cvemp.cvemp=B.

Fundamentos de las Bases de Datos Distribuidas

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

Bases de Datos Distribuidas

Fundamentos de las 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.

Bases de Datos Distribuidas

48

Fundamentos de las 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

Bases de Datos Distribuidas

49

ciudad. A. Domicilio Hidalgo 100 Morelos 23-4 Revolución 987 ciudad Celaya edad especialidad 1-9 derecho Administración Contaduría contaduría administración derecho derecho administración contaduría Salamanca 20 Irapuato 21 21 21 21 A.Fundamentos de las Bases de Datos Distribuidas R -> R op_bin R op_uni -> SLF | PJA op_bin CP | UN | DF | JNF | NJNF | SJF | NSJF 2. Juan J. Adolfo A Adriana A Sandra F. L. nombre.2 Ejemplos de consultas distribuidas Supóngase una universidad. Mateos 234 Rocio S. José L. edad. 1.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. que cuenta con las carreras de derecho. Mario V. domicilio. Mateos 2345 Celaya Juárez 199 Guerrero 987 Revolución 200 Celaya Irapuato Salamanca 20 Celaya Celaya 19 20 Carmen G. contaduría y administración. se realizaría una fragmentación horizontal utilizando la siguiente aplicación: Bases de Datos Distribuidas 50 . Guerrero 987 Debido a que cada departamento requiere tener la información de sus alumnos.3. especialidad) No-control nombre D12 A32 C54 C78 A29 D90 D73 A99 C34 Pedro H.

A. edad. Roció S. Mario V. especialidad para los alumnos de cada área. Adolfo A domicilio Morelos 234 Juárez 199 ciudad Salamanca Celaya Celaya edad 20 21 19 especialidad administración administración administración Carmen G. Adriana A. Mateos 234 Bases de Datos Distribuidas 51 .Fundamentos de las Bases de Datos Distribuidas Q: Seleccionar el número de control. “contaduría” Alumnos domicilio Revolución 987 A. L. Mateos 2345 Guerrero 987 ciudad Irapuato Celaya Celaya edad 21 2-1 2-0 especialidad contaduría contaduría contaduría Alumnos1 = SL especialidad = “administración” Alumnos No-control A32 A29 A99 Nombre José L. Esto daría como resultado los siguientes tres fragmentos horizontales: Alumnos1 = SLespecialidad = “derecho” Alumnos No-control D12 D90 D73 nombre Pedro H. ciudad. Sandra F. nombre. domicilio Hidalgo 100 Guerrero 987 Revolución ciudad Celaya Irapuato Salamanca Edad 19 21 20 Especialidad Derecho Derecho Derecho Alumnos1 = SL especialidad = No-control C54 C78 C34 Nombre Juan J. domicilio. L.

La consulta global sería de la siguiente manera: PJ no-control. domicilio SL especialidad = “administración” AND ciudad = "Celaya” Alumnos La cual seña traducida por el DBMS local. conteniendo un fragmento horizonte¡ de la tabla global de acuerdo a la especialidad. Esta consulta involucro a todos los fragmentos que se encuentran distribuidos en el sistema. Carmen G. dado que el proceso se realizaría de manera local en el sitio de administración. especialidad SL edad>=21 Alumnos La cual se traduciría en el sistema distribuido de la siguiente manera: Bases de Datos Distribuidas 52 . que no hay necesidad de efectuar consultas en otros sitios. número de control y especialidad de los alumnos que tienen 21 años o más. en el departamento de administración a: PJ nombre. Por lo tanto el DBMS local deberá detectar que el procesamiento de la consulta se debe de realizar sobre los datos locales y. L. esto seria como sigue: PJ nombre. Domicilio Juárez 199 A.Fundamentos de las Bases de Datos Distribuidas Como se puede observar cada departamento es un sitio dentro de nuestra base de datos distribuida. nombre. domicilio SL ciudad = "Celaya” Alumnos3 nombre Adolfo A. dicha consulta no tendría mayor complicación para el sistema de bases de datos. 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. Considérese. Mateos 234 Ahora supóngase el caso de que el departamento de contabilidad requiere el nombre.

ésta no es la única forma de realizar la consulta. esto es. El árbol de operaciones quedaría de esta manera: PJNO CONTROL. especialidad contaduría contaduría administración 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. Por ejemplo el siguiente árbol arroja el mismo resultado que el anterior: Bases de Datos Distribuidas 53 . NOMBRE. especialidad SL edad>=21 (Alumnos1 UN Alumnos2 UN Alumnos3) no control C54 C78 A29 D90 nombre Juan J.Fundamentos de las Bases de Datos Distribuidas PJ no-control. ESPECIALIDAD SLEDAD >= ”21” UN ALUMNOS1 ALUMNOS2 ALUMNOS3 En este punto se debe de considerar un aspecto muy importante en el procesamiento de las consultas. Existen varias formas de realizar la misma consulta. se podría variar el orden de ejecución de las operaciones o reemplazarlas por un conjunto de operaciones equivalentes. Adriana A. Mario V. Ádolfo A. nombre.

y en él se realizan todas las operaciones. Bases de Datos Distribuidas 54 . ciudad y edad). 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 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. En el caso del segundo árbol. Considérese ahora otro árbol de operaciones. sino en el costo de la ejecución de las mismas. ESPECIALIDAD UN SLEDAD >= ”21” ALUMNOS1 SLEDAD >= ”21” ALUMNOS2 SLEDAD >= ”21” ALUMNOS3 La diferencia que existe entre este árbol y el anterior no radica en el resultado de las operaciones.Fundamentos de las Bases de Datos Distribuidas PJNO CONTROL. el costo de transmisión se reduce considerablemente al transmitir únicamente los datos del fragmento que cumplen con la condición del select. se realizarían en el sitio que lanzó la consulta. y la proyección. ya que el select se realizaría de manera local en cada uno de los sitios. 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. Es decir en el árbol anterior los fragmentos eran transmitidos íntegramente a un sitio. y el costo de la ejecución de las operaciones se distribuye en cada uno de los sitios de la base de datos distribuida. NOMBRE. por lo general es el sitio que lanzó la consulta. así como la unión. 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.

el costo de la transmisión de los datos entre sitios. los costos de transmisión son mucho mayores al transmitir dentro de una red WAN. Por lo tanto. esto dado que. NOMBRE. en el diseño de consultas se debe de considerar los costos en la ejecución de las operaciones. convendrá más. en la que tal vez se involucren transmisiones vía telefónica o vía satélite. NOMBRE. ESPECIALIDAD PJno_CONTROL. NOMBRE.Fundamentos de las Bases de Datos Distribuidas UN PJno_CONTROL. se debe de considerar que se está generando una carga de trabajo para los demás sitios. esto quiere decir que. 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. si existen sitios con mucha mayor potencia de computo que el sitio en el cual se generó la consulta. Bases de Datos Distribuidas 55 . ESPECIALIDAD PJno_CONTROL. los cuales. la cual involucro transmisiones por medio de cables que interconectan directamente los sitios. que entre sitios de una red LAN. posiblemente estén ejecutando sus propias consultas. que la mayor parte de las operaciones se realicen en dichos sitios y no en el que generó la consultaTambién se debe considerar el que posiblemente sea el costo más importante en una base de datos distribuida. y existe poca carga de trabajo en estos sitios. tanto locales como las que se ejecutarán en otros sitios.

4. Diseñar la distribución de los fragmentos.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. Diseñar la fragmentación de los datos. 3. el procesamiento local aumenta. en cuanto al diseño de los múltiples sitios. 2. Existen varios objetivos que una base de datos distribuida deberá de lograr: Procesamiento local: Debido a que los datos son colocados donde se necesitan. Diseñar el esquema conceptual.Fundamentos de las Bases de Datos Distribuidas 2. Los problemas principales serían la intercone)¿ión de [os diferentes sitios. Diseñar el esquema físico. así como la distribución de los datos en dichos sitios. Bases de Datos Distribuidas 56 . El diseño de una base de datos distribuida consiste en: 1. esto.

Disponibilidad y casto del almacenamiento: la distribución de las bases de datos refleja una reducción en el costo del almacenamiento en los sitios. existe un tercer método de fragmentación. 3. para el diseño del esquema global de la base de datos. la técnica que se utiliza es bottom-top. por lo general por medios de una operación select. Existen dos técnicas de diseño de bases de datos distribuidas: La técnica topdown y la técnica bottom-up. Existen dos tipos básicos de fragmentación. 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. La traducción de cada esquema local a un modelo de datos común. La fragmentación horizontal consiste en dividir las tuplas de la relación global en subconjuntos de tuplas. La fragmentación permite determinar cuales serán las unidades lógicas de distribución. Esta técnica consiste en: 1. La integración de los esquemas locales en el esquema global común. consiste en agrupar tuplas y atributos que tengan las mismas propiedades lógicas. no podrán ser El diseño de los fragmentos considerados como unidades lógicas de distribución. el cual es la combinación de los dos anteriores. esta técnica es utilizada cuando no e)dste base de datos alguna.Fundamentos de las Bases de Datos Distribuidas 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. Cuando una base de datos distribuida se va a agregar a una base de datos ya existente. la horizontal y la vertical. La selección del modelo de datos. donde cada subconjunto puede contener datos con propiedades geográficamente comunes. mientras que la reconstrucción de la relación global siempre se llevara a cabo por medio de una operación de union. continuando con la distribución de los fragmentos en los diferentes sitios. 2. Existe un subtipo de fragmentación horizontal conocida como fragmentación horizontal derivada. Bases de Datos Distribuidas 57 . La fragmentación se realiza. En la técnica top-down se inicia diseñando el esquema global y la fragmentación de los datos. Las tuplas y atributos de la relación por si mismos.

pero este enfoque no es conveniente. 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. El grado de replicación de cada fragmento llega a ser una variable del problema. complejidad en el diseño. 2. El tercer tipo de fragmentación es la mixta. La replicación introduce una amplia Existen dos métodos para determinar la redundancia en la distribución de fragmentos: Bases de Datos Distribuidas 58 . La reconstrucción de la relación global se obtiene por medio de la operación join. En la distribución de los fragmentos es importante decidir si se va diseñar una distribución redundante o no redundante. 2. y seria difícil procesar la solución del problema al involucrar demasiadas variables. es necesario analizar la forma en como se distribuirán dichos fragmentos. y la reconstrucción se realizaría aplicando las operaciones respectivas en orden inverso de acuerdo a la fragmentación. La fragmentación vertical de una relación global es la subdivisión de sus atributos en grupos. 3. esta es obtenida por medio de operaciones de fragmentación realizadas de manera recursiva. porque: 1. Habría más fragmentos que relaciones globales. Después de que se a realizado la fragmentación de los datos. por las siguientes razones: 1. la manera más fácil de realizar esta operación seria considerar cada fragmento como archivos separados. pero se deriva de la fragmentación de otra relación.Fundamentos de las Bases de Datos Distribuidas esta consiste en la fragmentación de una relación que no se puede basar en sus propios atributos. Los fragmentos no son modelados propiamente como archivos individuales. la fragmentación se obtiene al proyectar la relación global sobre cada grupo. 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.

3. Determinar primero la solución sin replica del problema. este proceso termina cuando una replica no es benéfica. ¿Que representa y que partes conforman a un árbol de operadores? 2. esto es de abajo hacia arriba.Usando la tabla de clientes. En el análisis del procesamiento de consultas distribuidas. existe una herramienta muy útil llamada árbol de operadores. Un árbol define un orden parcial en como las operaciones se deben de aplicar para obtener el resultado deseado en la consulta. Obtener el número del cliente por estado. realizar una fragmentación horizontal. Obtener el nombre del cliente por empresa. este árbol representa la secuencia en que se realizan las operaciones de una consulta. 2. en este árbol.5. y posteriormente introducir replicas iniciando por las más benéficas. No_cli C01 C02 C03 Nom_cli Juárez Vidal Ávila Empresa Gamesa Lara Gamesa Estado Gto Qro Jal Bases de Datos Distribuidas 59 . las hojas son las relaciones globales y cada nodo representa una operación binaria o unitaria.2. ¿Cuándo es conveniente utilizar la técnica bottom-up para diseñar una base de datos distribuida? Explique brevemente en que consiste cada uno de los tipos de fragmentación que existen. y colocar un fragmento en cada uno de los sitios de este conjunto. si las aplicaciones son las siguientes: q1: q2: q3: Obtener los nombres de todos los clientes.- Preguntas de repaso ¿Cuales son los cuatro pasos en el diseño de una base de datos distribuida? Mencione y describa los objetivos del diseño de datos distribuidos.Fundamentos de las 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.5 1.4.6 Ejercicios 1..

Fundamentos de las Bases de Datos Distribuidas C04 C05 C06 Mejía Herrera Cervantes Lara Lara Gamesa Jal Gto Qro 2.10 15. Matriz de accesos S1 q1 q2 q3 3 2 1 S2 2 1 1 4. q3: Obtener el nombre de los clientes por empresa. Clientes No_cli C01 C02 C03 C04 C05 C06 Nom_cli Ávila Soria Avalos Medina Trajo Ávila Edo Gto Gto Qro Mich Qro No_p P1 P2 P3 P4 P5 P6 Productos Nom_p Lápiz Libreta Lapicero Borrador Escuadra Plumones Precio 1.50 3.20 1. realizar una fragmentación vertical.- Fragmentar horizontalmente la siguiente base de datos.7 Bases de Datos Distribuidas 60 .Usando la tabla de dientes. Obtener el número y nombre de los clientes del estado de Jalisco. Obtener el estado de los clientes cuyo nombre sea Ávila. 3. si las aplicaciones son las siguientes: q1: Obtener los nombres de todos los clientes.50 3. 115 A5 Ciudad Celaya A6 Sem 3 A7 Esp Química A8 Prom 85.- Fragmentar verticalmente la siguiente tabla A1 No_al AL1 A2 Nom_al Aguilar A3 Edad 19 A4 Dir Rev.20 Compras No_cli C02 C01 C02 C01 C03 C03 Nom_cli Pl P3 P4 P5 P1 P5 Cant 2 1 2 2 2 3 q1: q2: q3: Obtener el número del cliente por estado. q2: Obtener el número y nombre de los clientes por estado.20 3.

S.S.. 422 Irapuato Celaya León 1 1 4 Electrónica Sistemas Química 83.S. Pelaggati. Matriz de accesos.. 1985 [2] Date. U.2 75.7 q1: Obtener el número de alumno por especialidad. 1990 [3] Date. Volume li. q2: Obtener número y nombre del alumno por ciudad. C. Stefano. "An lntroduction to Databases Systems". Volume 1.J. C. 1995 Bases de Datos Distribuidas 61 . Reprinted July. Fifth Edition. q4: Obtener el número y semestre del alumno por dirección.. S1 q1 q2 q3 q4 3 2 2 3 S2 1 0 1 5 S3 1 1 2 1 Bibliografía [1] Ceri.A. Reprinted July.2 89. "An Introduction to Databases Systems". q3: Obtener el nombre y edad por promedio.. Addison-Wesley Publishing Company. MeGraw-Hill.A. 'Distributed Databases Principles and systems'. U. lntemational Edition.A.J. 315 Hgo. Addison-Wesley Publishing Company.. 120 Rev. Giuseppe. U.Fundamentos de las Bases de Datos Distribuidas AL2 AL3 AL4 Jiménez Trejo Soria 18 18 20 Hgo.

Además se tratara el concepto de Bases de Datos Distribuidas 62 . no implica que se tenga un funcionamiento correcto del sistema. 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.Fundamentos de las Bases de Datos Distribuidas Capítulo III Optimización de estrategias de accesos 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.

Determinar las copias físicas de los fragmentos sobre los cuales se ejecutará la consulta. esto es. El desarrollo de una estrategia "buena" en el procesamiento de una consulta es necesaria en un ambiente distribuido. obteniendo una expresión de consulta sobre fragmentos.Fundamentos de las Bases de Datos Distribuidas optimización de consultas. 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.. De esta manera. se deberá de encontrar la sentencia que minimice el costo de transmisión. La selección de estrategias alternativas para la ejecución de las consultas. Por eso. la eficiencia del sistema final depende en mucho de la calidad del optimizador de consultas. es hecha de acuerdo al desempeño requerido. La selección de una estrategia de procesamiento de consultas involucro: 1 . las cuales se deben evitar. También se analizaran los diferentes métodos de ejecución de la operación Join.1 Importancia de la optimización de consultas El término “optimización” es algo inapropiado. lo cual es nuestra meta más importante. A pesar de esto. En bases de datos distribuidas de debe considerar además. Bases de Datos Distribuidas 63 . No obstante. a su forma canónica. de la ausencia de un optimizador. al referirse a este hecho como optimización se debe de ser muy cuidadoso. tanto en ambientes centralizados como distribuidos. 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. pero también pueden existir estrategias para el procesamiento de consultas "muy malas'. el costo de la transmisión de datos entre los sitios participantes de la consulta. y en la habilidad del programador de las aplicaciones. no existe ningún convenio en la importancia relativa del costo de transmisión contra I/O local. lo cual implica reducidas a una forma equivalente más pequeña y fácil de manejar para el sistema.

Además. no solo se pude interpretar una expresión de álgebra relacional por sus especificaciones semánticas de una consulta. como se puede ver. esto involucro la determinación de una buena secuencia de operaciones join. por ejemplo. para fines de estudio. Imp. Depto) Bases de Datos Distribuidas 64 . el tercer problema es despreciable. esto debido a que es posible transformar una consulta SQL en expresiones equivalentes de álgebra relacional y viceversa. Desde este punto de vista. por lo tanto. sino que además se deberá de tomar en cuanta la secuencia de las operaciones. la elección de la mejor materialización para una consulta depende del orden en el cual son ejecutadas las operaciones. Seleccionar el método para la ejecución de cada operación. una manera fácil de obtener métodos de optimización consiste exactamente en considerar estos problemas como independientes. Seleccionar el orden de ejecución de las operaciones. En la práctica. 2. 3. esto involucro el cambio de ejecución de algunas operaciones algebraicas.Fundamentos de las Bases de Datos Distribuidas 2. Una consulta dada se ejecuta sobre una sola copia no redundante de la base de datos distribuida.2 Transformaciones equivalentes Una consulta relacional puede expresarse utilizando diferentes lenguajes. El orden de ejecución de las operaciones es optima. Las operaciones son agrupadas en los programas locales. utilizar procedimientos para resolverlos de manera independiente produciría errores. 3. Por ejemplo. de esta manera: 1. dos expresiones con la misma semántica pueden describirse por medio de dos secuencias de operaciones diferentes. el primer problema no es tomado en cuenta. Nom. No obstante. considérese la siguiente relación: Emp(Cvemp. semijoin y unión. Los problemas anteriores no son independientes. por lo tanto solo se hace énfasis en el segundo problema. se utilizará álgebra relacionar y SQL. Sal. 3.

depto Emp Nom Juan Pérez Carmen Campos Depto 15 15 Son dos expresiones equivalentes. depto SL depto=15 Emp Nom Juan Pérez Carmen Campos Depto 15 15 y SL depto = 15 PJ Nom. las cuales arrojan el mismo resultado. pero definidas por dos secuencias de operadores diferentes.Fundamentos de las Bases de Datos Distribuidas Cvemp E12 E56 E78 E98 E32 E91 E73 Nom Juan Pérez José Hernández Luis Pérez Maria Solís John Smith Roció Sánchez Carmen Campos Sal 4500 8756 9254 12345 25489 4600 8753 Imp 15 15 15 25 25 15 15 Depto 15 9 17 22 22 8 15 Se tiene las siguientes consultas: PJ Nom. Transformaciones equivalentes por álgebra relacional Bases de Datos Distribuidas 65 .

es decir expresiones de dos o tres operadores relacionases.Fundamentos de las Bases de Datos Distribuidas Dos relaciones son equivalentes cuando sus tuplas representan el mismo mapeo de los atributos a los valores. Estas transformaciones son clasificadas en categorías de acuerdo a las operaciones que involucro. Se podrán obtener transformaciones equivalentes sistemáticamente más pequeñas. R y S relaciones. Considérense dos expresiones E 1 y E2 de álgebra relacional. entonces se tienen las siguientes propiedades:  Conmutatividad de operaciones unitarias: U1 U2 R ↔ U2 U1 R  Conmutatividad de operaciones binarias: RBS↔SBR  Asociatividad de operaciones binarias: R B (S B T) ↔ (R B S) B T  Idempotencia de operaciones unitarias: 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) Bases de Datos Distribuidas 66 . la equivalencia de dos expresiones se representa E1 ↔ E2. Sean U y B operaciones unitaria y binaria respectivamente. incluso si el orden de los atributos es diferente.

De esta manera es posible localizar las subexpresiónes iguales. En el siguiente ejemplo se ilustrara este método. las cuales aparecen en más de una vez en la consulta. Una forma de reconocer la existencia de dichas expresiones. ya que de esta manera solo se evaluara una sola vez dicha expresión. consiste en transformar la consulta en su correspondiente árbol de operadores. esto es importante.2. Considérese las siguientes tablas de una base de datos: Bases de Datos Distribuidas 67 . enseguida se unen tanto los nodos y las hojas en una sola hoja o nodo. R) DF (SLF2 R) <-> SL F1 AND NOT P2 R 3.2 Determinación de subexpresiones comunes Una parte importante en la transformación de expresiones equivalentes es el descubrir las subexpresiones comunes. las cuales utilizan las mismas operaciones y operandos.Fundamentos de las Bases de Datos Distribuidas Las siguientes son propiedades que también pueden ser aplicadas dentro de la transformación de expresiones: R R R NJN R ↔ R UN R ↔ R DF R ↔ 0 NJN SLF R ↔ SLF R UN SLF R ↔ R DF SLF R ↔ SLNOT F R R R R (SLF1 R) NJN (SLF2 R) ↔ SL F1 AND F2 R (SLF1 R) UN (SLF2 R) ↔SL F1 OR F2 R (SLF.

Bases de Datos Distribuidas 68 .Fundamentos de las Bases de Datos Distribuidas EMP(id-emp. nom.000. sal. edad) DEPT(deptnum. 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. 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. descr. el select es desplazado hacia arriba).Nom((EMP JN DEPTNUM = DEPTNUM SL GTENUM=373 DEPT) DF (SL SAL>35000 EMP JN DEPTNUM=DEPTNUM SL GTENUM=373 DEPT)) A simple villa se puede deducir que existe una subexpresión repetida en la consulta. deptnum. expresión para dicha consulta seria: Una PJEMP.

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 DF SLSAL>35000 JNDEPTNUM=DEPTNUM EMP SLGTENUM=373 DEPT Bases de Datos Distribuidas 69 .Fundamentos de las Bases de Datos Distribuidas PJ EMP_NOM DF JNDEPTNUM=DEPTNUM EMP SLGETNUM=373 DEPT EMP SL SAL>35000 JNDEPTNUM=DEPTNUM SLGETNUM=373 DEPT A continuación se unen los nodos correspondientes al select sobre GTENUM.

1 Iteración simple Supóngase que no se cuentan con índices.3 Métodos de ejecución de JOIN En la ejecución de una operación join.    En este punto influyen varios factores que se deben de tomar en cuenta. se reduciría significativamente el número de bloques accesados ( considérese un bloque como un conjunto físico de tuplas ).Fundamentos de las Bases de Datos Distribuidas 3. y que es necesario examinar todos los pares posibles de tuplas td en depositas y tc en cliente. En él se lee cada tupla de la relación deposito. 3. considerando que cada una de las tuplas de la relación deposito se encuentran en bloques diferentes.000 tuplas y clientes consta de 200 clientes.3. se debe de considerar el costo de procesamiento. entonces se tendrán 10000120 = 500 bloques distintos accesados. Si se ejecutará esta consulta de una manera más optima. 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 deposito cuenta con 10. examinarla 10000 * 200 = 2000000 pares de tuplas. dichos factores son: El orden físico de las tuplas en la relación. Supóngase que se utiliza el siguiente procedimiento para procesar el join. La presencia de índices y el tipo de estos. para lograr la elección de la estrategia correcta. esto requeriría accesar 10000 bloques de almacenamiento físico bajo el peor de los casos. De esta manera. Si se consideran que 20 tuplas de la relación deposito se encuentran almacenadas en un bloque. se Bases de Datos Distribuidas 70 .

solo se requieren 10 accesos en lugar de 200. En el peor de los casos cada consulta requerirá de un acceso a disco. El número exacto de accesos a disco depende del tamaño del buffer y de otros factores.000 bloques de la tupla clientes para procesar la consulta. For each bloque Bd of deposito do begin for each bloque Be of dientes do Bases de Datos Distribuidas 71 .500 bloques accesados. Puesto que se tienen 200 tuplas en la relación de clientes.3. Por lo tanto.Fundamentos de las Bases de Datos Distribuidas for each tupla d in deposito do begin for each tupla c in cliente do begin compara el par (d. 3. entonces se requieren de 10 accesos para leer la relación completa. se tendrán que hacer 2. Esto implica que se accesarán 100. se asume que las tuplas de la relación depósitos y de la relación clientes son almacenadas de manera continua también.000 accesos a clientes para un total de 100. Si se asume que 20 tuplas de la relación clientes son almacenadas en un bloque.000 lecturas a la relación de clientes.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. esto llevará a hacer 10. Se usará el procedimiento siguiente para procesar depósitos JN clientes.000 referencias a cada tupla de clientes. El costo de esta técnica es de 500 accesos a depósitos más 100.000. c) para ver si alguna tupla es agregada al resultado final end end Si se compara cada tupla de clientes con cada una de las tuplas de la relación deposito. Nuevamente.

están ordenados por nombre-cliente. 3. se leerá la relación cliente por cada bloque de la relación deposito. requieren 10*500= 5000 bloques accesados. en lugar de realizar una lectura a la relación cliente por cada tupla de la relación deposito. es posible realizar un join eficientemente si ambas relaciones se encuentran almacenadas en orden de acuerdo a un atributo por medio de[ cual se realizara el join. Supóngase que ambas relaciones. Este procedimiento desarrolla el join considerando un bloque entero de tuplas de la relación deposito en vez de una tupla individual. Para ejecutar un merge-join. Entonces. se requiere de un punto de asociación en cada relación. el costo en términos de bloques accesados es de 5500 accesos (5000 accesos a clientes más 500 accesos a dep¿>sitos). Estos puntos son direccionados a la primera tupla de cada relación. Sin embargo.Fundamentos de las Bases de Datos Distribuidas begin for each tupla d in Bd do begin for cach tupla e in Be do begin compara el par (d. Claramente se puede ver un significativo ahorro en el número de accesos necesarios en comparación con la técnica anterior. clientes y depósitos. se tienen 500 bloques. Se podrá entonces realizar una operación merge-join. se leerá completa la relación deposito a un costo de 500 accesos.Join En aquellos casos en los cuales ninguna relación se encuentra en la memoria principal. Los Bases de Datos Distribuidas 72 .3 Merge .c) para ver sí una tupla puede ser tomada para el resultado end end end end. De esta manera.de la relación deposito y 10 bloques de la relación diente.Aún.3.

Bases de Datos Distribuidas 73 . end else done:= verdad. A continuación se muestra el esquema del merge-join aplicado al ejemplo de deposito JN cliente. while ( td[nombre-Cliente] < tc[nombre-Cliente]) do begin td := tupla a la cual pd apunta. sc {tc} mueve pc a la siguiente tupla en cliente. mueve pd a la siguiente tupla. Esto permite leer cada tupla una sola vez y en el caso de que las tuplas estén almacenadas de manera ordenada. while (not done and pc ≠ nuil ) do begin tc' := tupla a la cual pc apunta. puesto que las tuplas están ordenadas. done := falso. while (pc ≠ nuil) do begin tc:= tupla ala cual pc apunta. mueve pd a la siguiente tupla de deposito. entonces se leerá cada bloque exactamente una vez. if tc[nombre-Cliente] = tc'[nombre-Cliente] then begin si := se u {tc'}.Fundamentos de las Bases de Datos Distribuidas 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. el conjunto de tuplas con el mismo valor estarán consecutivas. Pd := dirección de la primera tupla de deposito. end td := tupla a la cual pd apunta. se leen dichas tuplas. mover pc a la siguiente tupla de cliente. Pc:= dirección de la primera tupla de clientes.

La iteración orientada a bloques requiere que las tuplas de cada relación estén ordenadas físicamente. El costo de la iteración simple para el ejemplo deposito JN diente es de 2 millones de accesos a bloques. La iteración simple puede ser más eficiente si e>iste un índice en la relación cliente para el atributo nombre ~ cliente. Se requieren 10000 accesos para leer la relación deposito.Fundamentos de las Bases de Datos Distribuidas 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.4 Uso de índices Las tres estrategias que se han considerando dependen de la técnica usada para almacenar físicamente las relaciones. td := tupla a la cual pd apunta. 74 Bases de Datos Distribuidas . En estos casos se puede considerar una estrategia de join que utiliza estos índices. 3. Si se asume que la relación clientes tiene 200 tuplas. y que se almacenan 20 apuntadores por bloque. El índice es usado para buscar las tuplas en clientes para los cuales el nombre-cliente sea igual a d[nombre-clientel. Cuando se utiliza un índice. es decir en el medio de almacenamientos. Una desventaja de este método es que ambas relaciones deben de estar ordenadas físicamente. Frecuentemente los atributos del join forman parte de la llave del índice de una relación. Cuando se tiene una tupla d de la relación deposito no es necesario recorrer la relación clientes completa. sin importar la manera en como fueron almacenadas físicamente las tuplas de las relaciones. puede ser aplicada sin importar la forma en como están almacenadas las tuplas de las relaciones. el join puede ser ejecutado con una reducción de accesos significativa. end mueve pd a la siguiente tupla de deposito. end end.3. El merge-join requiere de un almacenamiento en orden. Únicamente la iteración simple.

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). Dicho índice sera usado una sola vez para la ejecución de un simple join. convendría. si por cada tupla de la relación deposito son necesarios 3 accesos a bloques daría como resultado un total de 30000 accesos. Entonces el hecho de obtener un ahorro tan alto de accesos es suficiente para justificar la creación de índices. end Bases de Datos Distribuidas 75 . A continuación se muestra el algoritmo usado para el hash join que se aplicara en el ejemplo deposito JN cliente. Si h( c ) ≠ h( d ) . tiene un costo de 2 millones de accesos a bloques. Con esto. se requieren en promedio 2 accesos a bloques más un bloque accesado para leer la relación cliente. son necesarios 3 accesos a bloques en la relación deposito en lugar de 200. más los 10000 de la relación deposito. 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.5 Hash join La construcción de un índice para la ejecución de un join. si este índice es un árbol B+. Entonces. También se debe recordar que inicialmente. esta estrategia.Fundamentos de las Bases de Datos Distribuidas entonces. Hci := Hci u {apuntador a c}. 3. entonces d y c tendrán valores diferentes para nombre-cliente.3. for each tupla c in cliente do begin i := h(c[nombre-Cliente]). Una función hash h es usada sobre las tuplas de ambas relaciones sobre los atributos básicos del join. 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.

rc:= rc u {c ç. end for i := 0 to max do begin rc:= 0. end for each apuntador pd in Hdi do begin d:= tupla a la cual apunta pd.Fundamentos de las Bases de Datos Distribuidas for each tupla d in deposito do begin i := h(d[nombre-cliente]). rd:= 0.c) para ver si una tupla puede ser agregada al resultado end end Bases de Datos Distribuidas 76 . end for each tupla d in rd do begin for each tupla c in rc do begin compara el par (d. rd := rd u {d}. Hdi := Hdi @ {apuntador a d}. for each apuntador pc in Hci do begin c:= tupla a la cual apunta pc.

Hd1. . . . Desde el Bases de Datos Distribuidas 77 . son almacenadas de forma continua físicamente.1... El costo de esta operación es de 510 accesos a bloques si las tuplas de ambas relaciones. ambos pueden estar en la memoria principal. Hcmax denotan el contenedor del apuntador a las tuplas de la relación diente. . Este join es procesado utilizando una iteración simple.  Hd0. Desde el momento en que los contenedores almacenan solo apuntadores se asumirá que se encuentran en la memoria principal. Hdmax denotan el contenedor del apuntador a las tuplas de la relación deposito. cada uno vacío al inicio. Hc1. ya que rd y rc son lo suficientemente pequeños. Se usarán estas propiedades para estimar el costo del desempeño de un hash join.max)  Hc0. 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.2.Fundamentos de las Bases de Datos Distribuidas end En el algoritmo anterior. cada uno vacío al inicio. se asume que:  h es una función hash que mapea valores de nombre-cliente con {0. La asignación de apuntadores a los contenedores hash en los primeros dos ciclos for del algoritmo generan una lectura completa de ambas relaciones... y por lo tanto no es necesario ningún acceso a disco para leer dichos contenedores. Donde i es un valor del rango de h.. En la parte final del algoritmo se itera sobre el rango de h... clientes y deposito..

Cabe hacer notar que lo anterior requiere 510 accesos a bloques inicialmente. tiene a lo más 10000 tuplas ( número de tuplas en la relación deposito). sino que ahora se debe ver cual se realizara primero. se requiere una lectura para la función hash. Considerando que nombre .3. cada tupla es leída una sola vez por el for final en el algoritmo.sucursal es la llave para sucursal es posible saber que se examinarán únicamente una tupla de la relación sucursal Bases de Datos Distribuidas 78 .. Es necesario elegir una función hash cuyo rango sea lo suficientemente extenso para que cada contenedor almacene la menor cantidad de apuntadores posible.. Estrategia 1: Se procesa el join deposito JN cliente usando alguna de las técnicas antes mencionadas. Así.t.6 Tree .ii. n.cliente es la llave para la relación clientes. = 10000.. = 50.. y una segunda lectura dentro de los contenedores.Hay varias estrategias posibles a utilizar. Si es posible construir un índice para sucursal sobre el atributo nombre-sucursal.way join Ahora supóngase que un join envuelve tres relaciones: sucursal JN deposito JN cliente Se asume que ndd. 3. el costo total estimado de un hash join es de 1020 accesos. Es posible saber que el resultado de este join... = 200 y n. No solo se tiene que considerar la estrategia para procesar el join.Fundamentos de las Bases de Datos Distribuidas momento que se aplico una función hash a una tupla y esta se coloco en un contenedor. se podría procesar lo siguiente: sucursal JN (deposito JN cliente) Considerando que nombre .

combina 2 operaciones dentro de una operación especial.Fundamentos de las Bases de Datos Distribuidas para cada una de las 10000 tuplas de la operación deposito JN cliente.una sola en las otras dos relaciones.3. Ahora se vera el caso donde varios procesadores están disponibles para el procesamiento paralelo de un join. 3. La técnica primero requiere la construcción de dos índices:   En sucursal con nombre-sucursal.7 Estrategias para procesamiento paralelo Las estrategias antes consideradas asumen que un solo procesador esta disponible para procesar un join. A continuación se considera para cada tupla t en la relación deposito. Bases de Datos Distribuidas 79 . es decir un total de 10000000. Así. El costo relativo depende de la forma en como las relaciones son almacenadas físicamente. se examinará por cada tupla en deposito . y la forma en que la relación sucursal es almacenada físicamente. Esto requerirá el acceso de 50 * 10000 * 200 posibilidades. En cambio. las correspondientes tuplas dentro de las relaciones clientes y sucursal. es posible hacer el proceso de un par de joins en uno solo. La estrategia 3 presenta una forma de realizar una operación que no tiene una correspondencia directa dentro del álgebra relacionar. Estrategia 2: Es posible ejecutar el join con las tres relaciones sin utilizar índices. Estrategia 3: En lugar de procesar dos joins. En cliente con nombre-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.

Cada procesador entonces ejecuta una parte del join. el resultado individual de cada procesador es recolectado para producir el resultado final.3. ya que algunos procesadores. La meta de un algoritmo de join paralelo es dividir los pares de tuplas entre varios procesadores. El esfuerzo hecho para dividir el trabajo equitativamente es una aproximación. El resultado final obtenido hasta que el último procesador haya terminado. En la practica la velocidad es más dramática por varias razones:    Un overhead ocurre en la partición del trabajo entre procesadores. la eficiencia se logra reduciendo el número de pares de tuplas que son comparadas. 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. Un join paralelo que utiliza N procesadores.Fundamentos de las Bases de Datos Distribuidas Antes que nada se debe considerar que:   Todos los procesadores tienen acceso a todos los discos. Un overhead ocurre en la recolección de los resultados arrojados por cada uno de los procesadores. tomará 1/N del tiempo que se tardaría en ejecutar el mismo join en un solo procesador. Idealmente.  El procesador tal vez tenga que competir por recursos compartidos del sistema. tienen más trabajo que otros. Todos los procesadores comparten la memoria principal. En un paso final.8 Join paralelo En las técnicas antes mencionadas para el procesamiento de un join en un procesador solo. Bases de Datos Distribuidas 80 . para producir el resultado final. 3. el trabajo global para procesar el join es dividido equivalente sobre todos los procesadores. El resultado se retrasa debido a que un procesador espera a que otro procesador libere los recursos. Esto sin que ningún procesador caiga en un overhead.

deposito2. entonces cada procesador P i procesa depositoi JN cliente en paralelo. depositoN Se supone. Si la memoria principal no es suficientemente grande para almacenar la relación cliente. Considere el siguiente join entre cuatro relaciones: r1 JN r2 JN r3 JN r4 Bases de Datos Distribuidas 81 . El retraso generado por la retención de recursos. Se divide la relación de deposito en N partes de igual tamaño.. se realizara la unión de los resultados parciales obtenidos por cada procesador.. Se sugiere que se utilice alguna técnica para realizar la división del trabajo entre procesadores para reducir el espacio utilizado de memoria. 3. En donde se escogerá una función hash cuyo rango sea { 1. que el tamaño de la relación deposito es múltiplo de N..3. Aunque cada procesador accesa su propia partición de la relación deposito. El costo de la construcción del resultado final. El costo de esta estrategia depende de vados factores:    La selección del algoritmo usado para cada procesador. particularmente cuando se tienen vistas.. . que cada procesados trabaje con exactamente un contenedor hash.. P2.. PN. se asume que se tiene N procesadores P1. . Esto es un uso importante en algunos queries que se realizan en el mundo real. todos los procesadores accesan a la relación cliente. Esto daría como resultado. que involucran a varias relaciones. Una técnica simple es la de utilizar una versión de hash-join para trabajar en paralelo. deposito1.9 Pipeline multiway join Existe la posibilidad del procesamiento de varios joins en paralelo.Fundamentos de las Bases de Datos Distribuidas Considerando nuevamente el ejemplo deposito JN cliente. por facilidad... el procesador necesita sincronizar sus accesos a la relación cliente con otros procesadores para reducir el número de accesos a disco. N }.. En el paso final. 2. .

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. r1 P1 r2 P3 r3 P2 r4 A continuación se muestra el algoritmo utilizado por el procesador P 3 para procesar el join. Se asigna al procesador P 1 la ejecución de r1 JN r2 y al procesador P2 se asigna r3 JN r4. entradas especiales en la cola que consisten ENDP1 y ENDP2. Como las tuplas resultantes del proceso de P 1 están disponibles para P3 . P1 y P2 pueden haber utilizado cualquier técnica para el procesamiento del join. Se deberá considerar también. que indican la finalización del procesamiento del join en los procesadores P 1 y Bases de Datos Distribuidas 82 .Fundamentos de las Bases de Datos Distribuidas 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. debe de colocarse como disponible para P 3 en la cola. Las tuplas resultantes de P 1 y P2 son colocadas en una cola para ser procesados por P3. así como las tuplas resultantes del procesador P 2 . La única modificación sería que cuando una tupla t es adicionada al resultado.

result := 0 . done1:= falso. result:= result  ({t} JN from2). 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. from1:= 0. from2:= 0. end end 3.Fundamentos de las Bases de Datos Distribuidas P2 respectivamente. result := result  (from1 JN {t}).4 Principios de optimización Se pueden identificar cuatro pasos generales para el proceso de optimización de una consulta. end else /* t proviene de P2 */ begin from2 := from2  {t}. if t = ENDP1 then donel := verdadero else if t = ENDP2 then done2:= verdadero else if t proviene de Pl then begin from1:= from1  {t}. done2:= falso. Bases de Datos Distribuidas 83 . Para ejemplo se utilizo un 4-way join pero pude extenderse para procesar N-way join.

preparando así el camino para los subsecuentes pasos de la optimización. eliminando así. se tiene la consulta "obtener los nombre de los proveedores que surten la pieza P2'.Convertir la consulta en alguna representación interna. las consideraciones del nivel externo (tales como los rasgos concretos de la sintaxis de un lenguaje de consulta).Fundamentos de las Bases de Datos Distribuidas 1. 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. 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. es posible representar esto en un árbol de operadores: PJPnombre SLprovee. dentro del álgebra relacional que se puede manejar más fácilmente por el sistema: PJ ( SL ( Proveedor JN Provee ) provee...p#=’P2’ ) nombre 2. Por ejemplo.Convertir a forma canónica. Bases de Datos Distribuidas 84 .p#=‟P2‟ JN Proveedor Provee Esto da como resultado una expresión.

). producen el mismo resultado). Es posible definirla como sigue: Se tiene un conjunto Q de objetos (Queries) y la definición de equivalencia entre ellos (dos queries son equivalentes. el optimizador ejecuta un número de transformaciones que son "garantizadas para ser correctas'. etc. representada por su forma canónica. distribución de los datos almacenados. almacenamiento físico de los registros. La obtención de expresiones equivalentes se logra por medio de reglas de transformación bien definidas y permitidas dentro del álgebra relacionar.Elegir el procedimiento de bajo nivel.. La estrategia básica es considerar la consulta como una serie de operaciones de "bajo nivel" join. en relación con los datos actuales y las rutas de acceso que existen en la base de datos. etc. Para cada operación de bajo nivel. Habiendo convertido la representación interna de la consulta en alguna forma más deseable (forma canónica). un procedimiento para cuando los campos están indexados. se debe decidir como se evaluará la consulta. si y solo si. rutas de acceso. project. y no del gran conjunto de Q. El objeto c es llamado la forma canónica de q. 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.Fundamentos de las Bases de Datos Distribuidas La definición de forma canónica es el punto central en muchas áreas de las matemáticas y disciplinas relacionadas. Por ejemplo. Cada procedimiento tiene asociado un costo. Así. se tendrá un conjunto de procedimientos predefinidos. es suficiente realizar el estudio del pequeño conjunto de formas canónicas. la consulta de la sección anterior tiene ocho posibles representaciones. un conjunto de procedimientos para la selección sería. 3. algún objeto q en Q es equivalente a solo un objeto c en C. Durante este paso. si y solo si. etc. y otro para cuando no lo están. select. Todas las propiedades que se aplican a q se aplican a la forma canónica c. pero están almacenados físicamente en orden. En este paso se debe considerar la existencia de índices. se tiene también un subconjunto C de Q. con cierta interdependencia entre ellos. Bases de Datos Distribuidas 85 . el cual se llama conjunto de formas canónicas de Q ( bajo la definición de equivalencia ). Tan solo en SQL.

etc. En un sistema distribuido de bases de datos. Entonces se debe decidir la forma en que se realizará el proceso de recolección de datos. la tabla es enviada íntegramente al sitio que lanzo la consulta o solo los registros que cumplen con la condición. Bases de Datos Distribuidas 86 . es necesario considerar. Será necesario un procedimiento por cada operación de bajo nivel en la consulta. 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 información se encuentra dispersa dentro de varios servidores y es utilizada por muchos clientes. 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. de cierta forma. la capacidad de procesamiento de los equipos para decidir que equipo o equipos realizaran los procesos más demandantes.Seleccionar el procedimiento más económico. Cuando una consulta es lanzada en un sistema de bases de datos distribuidos. Es importante recordar que dentro de un sistema de bases de datos distribuidas. los cuales pueden estar a corta distancia de los servidores o muy alejados de estos. realice el proceso integro.. Cada plan es construido con la implementación de los procedimientos necesarios para ejecutar la consulta. la utilización del CPU.Fundamentos de las Bases de Datos Distribuidas 4. Como se vio en el capítulo anterior (Ejemplos de consultas 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. etc. el costo más alto es el de la comunicación. Es decir. en ese momento es posible saber que información se requiere y en que sitio se encuentra. 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. La asignación del costo a algún plan involucrará el número de accesos a disco. por ello es necesario utilizar estrategias para reducirlo. No es necesario construir todos los planes posibles.

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. Bases de Datos Distribuidas 87 .Fundamentos de las 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. 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. 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.

R y S relaciones. 3. propiedades: Sea U y B operaciones Se tienen las siguientes  Conmutatividad de operaciones unitarias: U1 U2 R ↔ U2 U1 R  Conmutatividad de operaciones binarias: RBS↔SBR  Asociatividad de operaciones binarias: R B (S B T) ↔ (R B S) B T  Idempotencia de operaciones unitarias: U R ↔ U1 U2 R Bases de Datos Distribuidas 88 . 2. y desde este punto de vista dos expresiones con la misma semántica se pueden expresar por medio de dos secuencias de operadores diferente. Es posible obtener expresiones equivalentes pequeñas aplicando ciertas propiedades de operadores y conjuntos de operadores. Una expresión de álgebra relacional no solo se expresa por medio de sus especificaciones semánticas. Seleccionar el orden de ejecución de las operaciones. Determinar el número de copias de los fragmentos sobre los cuales se ejecutara la consulta. esto conlleva a decir que estas dos expresiones son equivalentes. Seleccionar el método para la ejecución de cada operación. aun cuando el orden de los atributos no sea el mismo. sino también por medio de una secuencia de operadores. Dos expresiones son equivalentes cuando sus tuplas representan el mismo mapeo de los atributos a los valores.Fundamentos de las Bases de Datos Distribuidas La selección de una estrategia de procesamiento de consultas involucro: 1. obteniendo una expresión de consulta sobre fragmentos. unitaria y binaria respectivamente. La equivalencia de dos expresiones se representa por El ↔ E2.

Una manera de reconocer la existencia de dichas expresiones. ahorrando así. de esta manera es posible localizar las subexpresiones iguales. las cuales podrían aparecer más de una vez en la consulta. esto es importante. que en este caso serían ramas similares. las cuales se convertirán en una sola rama. solo se tendrían que evaluar una sola vez. 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. Bases de Datos Distribuidas 89 . consiste en transformar la consulta en su correspondiente árbol de operadores. tiempo. Algo que también se debe de considerar es el costo de procesamiento de las operaciones join.Fundamentos de las Bases de Datos Distribuidas  Distributividad de operaciones unitarias con respecto a operaciones binarias: U(RBS) → U(R)BU(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 (SLF. los cuales se deberán tomar en cuenta:  El orden físico de las tuplas en la relación. dado que. En esta parte influyen varios factores.

el recorrido sobre la relación se detiene y el puntero se coloca de nuevo en la primera posición. Cada relación tendrá un puntero que indica la posición de lectura para el join. se podrían utilizar algunas de las siguientes estrategias: Bases de Datos Distribuidas 90 . 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. 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. Esta técnica leerá un bloque de tuplas en lugar de una tupla individual.Fundamentos de las Bases de Datos Distribuidas   La presencia de índices y el tipo de los mismos. Se repetirá este proceso hasta que se recorran todas las tuplas de la primera relación. El costo de procesamiento de un índice temporal para el procesamiento de una consulta. al ir leyendo. Tree-way join: Si se tiene que un join envuelve tres relaciones. esto debido a que las tuplas están ordenadas y no debe existir otro valor más allá de la posición del puntero. Al encontrarse la tupla que tiene el mismo valor que la tupla con la que se esta ejecutando el join. dichos punteros avanzarán. Sin embargo es posible que d y c tendrán valores diferentes para los atributos básicos del join a pesar de que sus valores en la función hash sean iguales. 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). Iteración orientada a bloques: Se asume que las tuplas de la relación están almacenadas en orden y de manera continua. Si h(c) ≠ h(d). entonces d y c tendrán valores diferentes para los atributos básicos del join. Hash-join: Una función hash h es usada sobre las tuplas de ambas relaciones sobre los atributos básicos del join.

En un paso final. 3. Pipeline multiway join: Existe la posibilidad de procesar varios joins en paralelo.Fundamentos de las Bases de Datos Distribuidas 1 . obteniendo así el resultado final. se procesarán primero un par de relaciones y el resultado de este join se procesara con la tercer relación. Bases de Datos Distribuidas 91 . Cada procesador ejecutará una parte del join. si es posible se deberá construir un índice sobre los atributos básicos del join. Esto requerirá la utilización de índices. tratando de que ningún procesador caiga en un overhead. Se procesa el join con cualquier técnica. el resultado individual de cada procesador es recolectado para producir el resultado final. Se asigna al procesador P 1 la ejecución de r1 JN r2 y al procesador P2 se asigna r3 JN r4. es posible hacer el proceso de un par de joins en uno solo. El trabajo global para procesar el join será dividido lo más equitativamente posible. 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. Es posible ejecutar el join con las tres relaciones sin utilizar índices. Join paralelo: La meta de un algoritmo de join paralelo es la de dividir los pares de tuplas entre varios procesadores. En lugar de procesar dos joins. 2.

producen el mismo resultado). si y solo si. 3. Elegir el procedimiento de bajo nivel: Se deberá decidir como se evaluara la consulta. Cuando una consulta es lanzada dentro de un sistema de bases de datos distribuidas. para cada operación se tendrá un conjunto de procedimientos predefinidos. 4. aquí. es que.Fundamentos de las Bases de Datos Distribuidas Como las tuplas resultantes del proceso de P 1 están disponibles para P3 . se tiene también un subconjunto C de Q. la obtención de expresiones equivalentes se logra por medio de reglas de transformación definidas y permitidas dentro del álgebra relacional. Así. 2. Entonces se deberá de diseñar una estrategia de recolección de datos. 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. 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. así como las tuplas resultantes del procesador P 2 . Se tienen cuatro pasos generales en el proceso de optimización de una consulta: 1. algún objeto q en Q es equivalente a solo un objeto c en C. 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. el cual se llama conjunto de formas canónicas de Q (bajo la definición de equivalencia). para obtener el resultado final. esto de manera que los pasos subsecuentes no se vean afectados. la mayoría de los lenguajes de consulta permiten representar una consulta en varias formas distintas. 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. 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. es posible saber que información se requiere y en que sitio se encuentra. la estrategia básica es considerar la consulta como una serie de operaciones de bajo nivel. Es necesario Bases de Datos Distribuidas 92 . si y solo si. Las tuplas resultantes de P1 Y P2 son colocadas en una cola para ser procesadas por P3 . Lo importante en este punto. El objeto c es llamado la forma canónica de q. representada por su forma canónica.

000.7. por lo tanto de deben de utilizar las estrategias que minimicen este costo en lo posible. se utilizaran las tablas EMP y DEPT del ejemplo de la sección 3.2.5. 3. l.¿Cuales son los tres puntos que se deben tomar en cuanta en la optimización de una consulta? 2.7 Ejercicios Para los siguientes ejercicios.8.¿Que condición deben cumplir dos expresiones para que sean consideradas equivalentes? 4..¿Mencione que se debe de considerar para seleccionar una estrategia de procesamiento de consultas? 3. Explique brevemente los pasos para el proceso de optimización de una consulta.- Dibuje el árbol de operadores de la consulta..Fundamentos de las Bases de Datos Distribuidas recodar que dentro de un sistema de bases de datos distribuidas el costo más alto es el de la comunicación.2 y la siguiente consulta: Obténgase el nombre de los empleados mayores de 40 años del departamento X con sueldo mayor a $11. Bases de Datos Distribuidas 93 ..¿Que métodos de ejecución de join existen? Explique brevemente el funcionamiento de la estrategia de join paralelo. 3.¿Que es una subexpresión común? ¿Que puntos se deberá tomar en cuenta para seleccionar una buena estrategia de ejecución de join? 6.6 Preguntas de repaso 1.

U.S.A..J. Bibliografia [1] Ceri.A.S. Dibuje el árbol de operadores más recomendable para este caso. Stefano. 3. U. McGraw-Hill. 1985 [2) Date. U.- Obtenga las subexpresiones comunes que contenga la consulta. Volume li. "An Introduction lo Databases Systems". Internacional Edition..- Considérese que las tablas de EMP y DEPT se encuentran en diferentes sitios. Fifth Edition. "An lntroduction lo Databases Systems". Repñnted Juiy. Giuseppe. Addison-Wesley Publishing Company-...A. Reprinted July. Pelaggati. 4. C. Addison-Wesley Publishing Company. C. "Distributed Databases Principies and systems'.J. 1990 [3] Date. y que el sitio en el cual se encuentra la tabla EMP tiene una capacidad de procesamiento muy reducida. 1995 Capítulo IV Procesamiento de transacciones en bases de datos distribuidas Bases de Datos Distribuidas 94 ..S.- Dibuje el árbol de operadores optimizado de la consulta.Fundamentos de las Bases de Datos Distribuidas 2. Volume 1.

1. El conjunto lector y el conjunto escritor de una transacción no están separados sino por el contrario.1 Seriabilidad en bases de datos centralizadas Una transacción accesa la base de datos usando primitivas de lectura y escritura. X puede ser una tupla o un fragmento completo.Fundamentos de las Bases de Datos Distribuidas Objetivo El alumno comprenderá y manejara los conceptos de control de concurrencia. 4. la siguiente serie de operaciones sería una planificación: S1: Rj (x) Rj (x) W i (y) Rk (X) W j (X) Dos transacciones Ti y Tj se ejecutan en sede dentro de una planificación S. En otro caso las transacciones se ejecutarían concurrentemente. el capítulo expone algunas técnicas para garantizar la seguridad del sistema. trabajan en conjunto. Una entrada de bitácora es una secuencia de operaciones hechas por una transacción. si la ultima operación de Ti precede a la primera operación de Tj en S o viceversa). Por ultimo. Por ejemplo. Sean Rj(x) y W i(x) las operaciones de lectura y escritura respectivamente. check-points y respaldos. evitando así el acceso a usuarios no autorizados. 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. usadas en la transacción Ti para el elemento de datos X. Bases de Datos Distribuidas 95 .1 Control de concurrencia 4. por medio de matrices de autorización. 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. 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 Ti es llamado conjunto escritor.

Fundamentos de las Bases de Datos Distribuidas Una planificación es serial si las transacciones no se ejecutan concurrentemente. La definición más aceptada de correcto en una planificación es basada en la seriabilidad: Bases de Datos Distribuidas 96 . es decir Oi se ejecuta primero que Oj. la siguiente planificación S2 es serial: S2: Ri (x) W i (y) Ri (y) Rj (x) W j (y) Rk (y) W k (X) Ti R(x) W(y) R(y) Tj Tk R(x) W(y) R(y) W(x) Esto sería S2: Ti Tj Tk En una planificación. entonces en S2 Ti < Tj y Tj < Tk. De cualquier forma no es posible forzar a las transacciones a ejecutarse serialmente. se indica como Oi < Oj. Algo ideal sería que las transacciones se ejecutaran lo más concurrentemente posible. Por ejemplo. es decir. cuidando que esta ejecución sea corrector. una detrás de otra. La ejecución serial de una transacción puede ser descrita por una planificación señal (denominada por Serial (S1) ). si la operación Oi precede a la operación Oj.

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.Fundamentos de las Bases de Datos Distribuidas Una planificación es correcta si esta es seriabilizable. Teniendo el concepto de seriabilidad. y [ W i(x). Es importante también considerar el hecho de que dos operaciones pueden llegar a caer en conflicto: Dos operaciones están en conflicto si. esto es. Un ejemplo es el bloqueo de registros. W j(y) ]. ya que fuerza a otras transacciones a esperar hasta que esta termine de realizar las operaciones sobre los datos. Estas dos condiciones son suficientes ya que ambas transacciones leen y escriben los mismos datos. La operación de escritura final es igual en ambas planificaciones. 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. y estas operaciones pertenecen a diferentes transacciones. ellas procesan el mismo dato y al menos una de estas operaciones es una operación de escritura. Rj(x) W i(x). W j (X) ] son pares de operaciones en conflicto mientras que [ Ri(x). W j (x) ] y [ W i (X). Por ejemplo. Cada operación de lectura lee los mismos valores que fueron producidos por las mismas operaciones de escritura en ambas planificaciones. [ Rj (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: Bases de Datos Distribuidas 97 . 2. que el resultado obtenido por esta sea equivalente al resultado de una planificación serial. Las siguientes dos condiciones son suficientes para decir que dos planificaciones son equivalentes: 1.

T2. . cada transacción ejecuta operaciones en varios sitios.1. entonces Oi deberá preceder a Oj en S2. . S2.Fundamentos de las Bases de Datos Distribuidas Dos planificaciones S1 y S2 son equivalentes si por cada par de operaciones en conflicto Oi y Oj. la seriabilidad local no es suficiente para asegurar la exactitud de la ejecución de un conjunto de transacciones distribuidas. Sm... donde Oi < Oj en S1. La secuencia de operaciones procesada por las transacciones en un sitio es una planificación local.2 Seriabilidad en una base de datos distribuida En una base de datos distribuida. la estructura S3 es equivalente a la planificación S4: S3: S4: Ri(x) Ri(x) W j(y) W i(x) Rj(x) W j(y) Ri(x) W i(x) S3 Ti R(x) R(x) W(x) W(x) R(x) W(x) Tj Ti S4 Tj R(x) W(y) 4... Considere los siguientes ejemplos: S1 (Sitio 1): Ri(x) W j(x) Ri(x) W i(x) S2 (Sitio 2): Rj(y) W i(y) Ri(y) W j(y) 98 Bases de Datos Distribuidas . Una ejecución de n transacciones distribuidas T 1. Sin embargo... Si se aplica en cada sitio un mecanismo de control de concurrencia se aseguraría que todas las planificaciones locales son serializables. Tn en m sitios es modelado por un conjunto de entradas de bitácora Sl. Por ejemplo.

... la seriabilidad de transacciones distribuidas. 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. ... si Ti < Tj en el orden total. es necesaria una condición más fuerte que la señabilidad local. Oi precede a Oj en cualquier entrada S1. . y además para cada par de operaciones en conflicto Oi y Oj de las transacciones Ti y Tj respectivamente. Bases de Datos Distribuidas 99 . Sm E es correcto (serializable) si existe un orden total de las transacciones... 2.... entonces hay una planificación serial S k‟ tal que. Sn si y solo si Ti precede Ti en el orden total. Existe un orden total de T1... Sk es equivalente a Sk‟ y Ti < Tj en el Serial(Sk‟). . . Tn es correcta si: 1. Tn un conjunto de transacciones. La ejecución de las transacciones T1. y sea E una ejecución de estas transacciones. Tn tal que. modelado por el conjunto de planificaciones S1.. 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. sin embargo.Fundamentos de las Bases de Datos Distribuidas S1 Ti R(x) W(x) R(x) W(x) W(y) R(y) W(y) Tj Ti S2 Tj R(y) Ambas planificaciones son seriales.. Cada entrada local Sk es serializable. ..

Esto se refiere al tamaño del "objeto" que se bloquea con una operación simple. esta bloquee dicho registro antes de intentar el acceso. Otro aspecto importante en el bloqueo es la granularidad. Un mecanismo de control de concurrencia es correcto si permite solo la ejecución de transacciones distribuidas. y bloquear de modo exclusivo antes de escribir. la primera deberá esperar a que la otra transacción libere dicho bloqueo (unlock).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. 2.1. los mecanismos típicos de bloqueo son más complejos. 4. Existen dos reglas de compatibilidad entre los modos de bloqueo: 1. una transacción no debe de requerir de un nuevo bloque después de que se libere algún registro. Una transacción siempre deberá bloquear un registro de forma compartida antes de leer el contenido. esto quiere Bases de Datos Distribuidas 100 . solo si el registro no esta bloqueado. y cuando una transacción intente bloquear un registro que anteriormente ya fue bloqueado por otra transacción. 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 puede bloquear de manera exclusiva.Fundamentos de las Bases de Datos Distribuidas Esta condición determina si una ejecución de una transacción distribuida es correcta. esto es. Otra condición que se deberá de tener en cuenta es que. se puede bloquear un registro o un archivo con una sola instrucción. si este no esta bloqueado o si lo esta de manera compartida. Una transacción puede bloquear un registro. De hecho.

el manejador local de transacciones (LTM.14 Control de concurrencia basado en bloqueos distribuidos Se asume que. 4. 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. esto porque la primera fase sería el bloqueo de todos los registros necesarios para realizar la transacción. Local Transaction Manager) permite al agente local realizar los bloqueos y liberaciones de registros locales.Fundamentos de las Bases de Datos Distribuidas decir que la transacción debe de tener un bloqueo de dos fases (2PL). Teniendo en cuenta lo anterior. y el proceso de la transacción se lleva acabo de acuerdo con la siguiente figura: ROOT AGENT Mensaje AGENT Mensaje AGENT Transacción Distribuida 2‟ DTMAGENT DTMAGENT 2‟ DTMAGENT 2‟ Bases de Datos Distribuidas 101 . y la segunda fase es en la cual se hace la liberación de todos los registros antes bloqueados. 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 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. esperando a la otra para siempre.

Un problema principal que se presenta es la administración de múltiples copias de datos. Bloqueo local exclusivo. En las bases de datos distribuidas. 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. el cual. y liberación). los LTMs interpretan las primitivas locales de bloqueo (bloqueo local compartido. bloqueo local exclusivo y. Distributed Transaction Manager) tiene que hacer para garantizar que la transacción global tenga las características de seriabilidad y aislamiento. liberación local). desbloqueo local Interface 2': Bloqueo compartido. al accesar dos copias del mismo dato almacenados en diferentes sitios. para los cuales la existencia mutua es inadvertida para dichas transacciones. mientras que los agentes de la transacción procesan las primitivas globales (bloqueo compartido. Bases de Datos Distribuidas 102 . Entender los aspectos peculiares del control distribuido de concurrencia es equivalente a comprender lo que el manejador distribuido de transacciones (DTM.Fundamentos de las Bases de Datos Distribuidas Mensaje Mensaje Manejador distribuido de transacciones 1‟ LTM en sitio i LTM en sitio j 1‟ LTM en sitio k 1‟ Manejadores de transacciones locales Interface 1': Bloqueo local compartido. de esta manera. bloqueo exclusivo. Bloqueo exclusivo. la redundancia que existe entre los datos es almacenada en diferentes sitios puede generar un conflicto de bloqueo entre dos transacciones. una transacción se da cuenta de que otra transacción está trabajando con un registro al momento de intentar accesarla. desbloqueo Entonces.

tantas como copias de datos se deseen bloquear. mientras que los bloqueos compartidos son adquiridos únicamente en alguna copia arbitrada. realicen todos los bloqueos en cada uno de los sitios en donde se encuentran almacenadas las copias de los datos. 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). si todas las transacciones logran un bloqueo de 2 fases.Fundamentos de las Bases de Datos Distribuidas 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. 3. Un conflicto es siempre detectado. Bloque de copia primaria. 2. 4. Write-locks-all. la cual es únicamente una parte de] Bases de Datos Distribuidas 103 . de esta manera si dos transacciones requieren bloquear el mismo registro. En este esquema los bloqueos exclusivos son adquiridos en todas las copias. todos los bloqueos son solicitados a esta copia. read-locks-one. Una de las copias de cada dato es privilegiada (llamada copia primaria). Este enfoque trabajaría. una primitiva de bloqueo es traducida en varias primitivas de bloqueo. 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. de esta manera. porque un bloqueo compartido . y un bloqueo exclusivo .1. hay por lo menos una copia de él en donde se descubriría el conflicto. entonces todas las entradas de bitácora son serializables. Existen esquemas alternativos para lograr evitar conflictos en los bloqueos: 1.exclusivo es detectado en todos los sitios. los LTMS.5 Bloqueo de 2 fases como un método de control de concurrencia Considérese primero que. Considérese también un sitio donde una transacción ejecuta alguna operación.exclusivo es detectado en el sitio donde este se encuentra o es requerido el bloqueo compartido. Esta es una manera sencilla de hacer que de manera local. y así es descubierto el conflicto en el sitio en donde se encuentra esta copia.

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... Por tanto.. . y pueden estar esperando por siempre. Considere el estado intermedio en el conjunto T1 tiene bloqueado a X. un algoritmo de detección y resolución de deadlock es necesario en un bloqueo de dos fases. Entonces. Cada una de estas transacciones requieren de bloquear un dato el cual. si una transacción distribuida logra un bloqueo de dos fases entonces todas las subtransacciones en los diferentes sitios. transacciones no podrá ocurrir. entonces se tendrá que.. T2 tiene bloqueado Y. el conjunto de Ti : Ri1(x) W i1(x) Ri2(Y) W i2(Y) Tj : Rj1(x) W j1(x) Rj2(Y) W j2(Y) Ti Ri(x) Wi(x) Ti Ri(x) Wi(x) Bases de Datos Distribuidas 104 .. lograrán separadamente un bloqueo de dos fases. por lo tanto cada una de ellas tendrá que esperar hasta que otra transacción libere el bloqueo. las transacciones T 1. Dichas transacciones pueden ser descritas por la siguiente secuencia de operaciones: En cualquier caso. estas no pueden liberar el bloqueo. Lo anterior es independiente del número de transacciones y de la secuencia de ejecución. las cuales transfieren fondos de una cuenta x localizada en el sitio 1 a una cuenta localizada en el sitio 2. la ejecución de las subtransacciones es serializable. ya esta bloqueado por otra transacción. esto tal vez no llegue a ocurrir. Por lo tanto n transacciones alcanzarán un estado de deadlock. una de estas transacciones deberá ser abortada por algún algoritmo de solución de deadlock.Fundamentos de las Bases de Datos Distribuidas conjunto total de operaciones ejecutadas por la transacción distribuida. T2. desde el momento en que las transacciones utilizan el bloqueo de dos fases. Tn requieren de un bloqueo de dos fases. sino hasta que se logran todos los bloqueos requeridos por dicha transacción. Sin embargo. Considérese ahora que. Considérense dos transacciones Ti y Tj.. Tn-1 tiene bloqueado V y Tn tiene bloqueado Z. . pero sí depende únicamente del orden de los pares de operaciones en conflicto.

se podrá considerar cualquiera de los dos casos. el hecho de que la operación Ri(y) aparezca abajo de Rj(x) significa que estas dos operaciones inician al mismo tiempo.Fundamentos de las Bases de Datos Distribuidas R2(Y) W2(Y) R2(Y) W2(Y) Se asume que cada transacción lee X. es necesario incluir en el modelo de ejecución la noción de "operaciones concurrentes" en diferentes sitios. y escribe su nuevo valor. Se representarán dos operaciones concurrentes colocándolas una sobre otra. Por ejemplo: Sl: S2: Ri(x) Wi(x) Ri(y) Wi(y) Rj(x) Wj(x) Rj(y) Wi(y) S1 Ri(x) Wi(X) Ri(y) Wi(Y) S2 Rj(x) Wi(X) Rj(y) Wi(Y) En esta representación de la ejecución. Por lo tanto. Para ejemplo considérese Ti < Tj. Tj inicia leyendo x. Para lograr un análisis del grado de concurrencia que es permitido por el algoritmo de control de concurrencia. esto significaría que W i1(x) < Rj1(x) y W i2(y) < Rj2(y) o que W j1(x) < Ri1(x) y W j2(y) < Ri2(y). escribe el nuevo valor. e inmediatamente Tj tiene que escribir x.Dado que existe una simetría. Un bloqueo de 2 fases asegura la ejecución serializable de estas transacciones. aunque Ti no Bases de Datos Distribuidas 105 . Supóngase que ambas transacciones son activadas de manera simultánea. y habría un orden total en el que Ti < Tj o Tj < Ti. lee Y. en la ejecución concurrente de transacciones. incremento su valor. decrementa su valor.

Si A y B son dos eventos en el mismo sito y A ocurre antes que B. debido a que no se tiene un "reloj global" para medir el tiempo exacto de ocurrencia de todos los eventos en el sistema distribuido. 2. 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. concurrencia. Si el evento A consiste en enviar un mensaje y el evento B consiste en recibir el mensaje de A. el cual ocurre en un sistema distribuido. en cambio. de manera precisa. conocer si un evento A en algún sitio ocurrió antes o después que un evento B en un sitio diferente. denotada por → puede ser generalizada en un sistema distribuido por medio de las siguientes reglas: 1. Una definición precisa de la relación "ocurre antes" en un sistema distribuido es la siguiente. si A ocurre antes que B. El principal inconveniente de la definición anterior es que el manejo de la relación "ocurre antes" no está definida. ya que es posible utilizar el mismo reloj para determinar el tiempo en que cada uno ocurre. Esta ejecución de E es serializable y permite el má)dmo grado de 4. Determinar el orden de los eventos es sencillo en un sistema centralizado. no es práctico asumir que los relojes disponibles en todos los sitios están perfectamente sincronizados. entonces A → B. La relación "ocurre antes". si dos eventos A y B ocurren en dos diferentes sitios. entonces A → B. En un sistema distribuido. 106 Bases de Datos Distribuidas .1. se asigna una etiqueta de tiempo TS(A) (timestamp) con las siguientes propiedades: 1. 2. TS(A) identifica de manera Unica a A (diferentes eventos tienen diferentes etiquetas de tiempo). algunas veces.6 Etiquetas de tiempo en una base de datos distribuida En un sistema distribuido. es necesario. entonces TS(A) < TS(B). esto. La determinación de un orden de eventos consiste en asumir que a cada evento A.Fundamentos de las Bases de Datos Distribuidas termine aun. Para dos eventos cualquiera A y B. Se asume que se conoce el significado de la declaración " el evento A ocurrió antes que el evento B en el sitio i".

Los eventos A y D. Lo Bases de Datos Distribuidas 107 . en la posición menos significativa. Si A → B y B → C. B y F. De cualquier forma. Considérese ahora la generación de las etiquetas de tiempo. aun si algunos son pseudosimultáneos. Es suficiente con que cada sitio agregue a cada etiqueta de tiempo local única. Considérese el siguiente ejemplo. 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. es posible que TS(A) < TS(B) o Sitio 1 Sitio 2 A Mensaje M1 D B Mensaje M2 E C Tiempo Local F Tiempo Local que TS(B) < TS(A). se puede satisfacer de manera sencilla en un sistema distribuido. que sean únicas.Fundamentos de las Bases de Datos Distribuidas 3. La relación de tiempo entre dos eventos pseudosimultáneos no puede ser determinada. Cuando se tienen asignadas las etiquetas a los eventos. el orden es definido entre ellos. el identificador de] sitio en el cual fue generada. C y E. El primer requisito. si Ay B son pseudosimultáneos. entonces A → C. B y E. La segunda propiedad de la definición de estampa del tiempo se puede ver de una manera precisa como sigue: Nótese que. La relación → es parcialmente ordenada. C y F son pseudosimultáneos.

en el caso de que los dos sitios no sean sitios cooperativos. (x.1) y TS(B)=(10. no es muy importante la sincronización de sus contadores. Sin embargo. en la implementación de etiquetas de tiempo. Bases de Datos Distribuidas 108 . el cual tiene un contador con valor x. el cual será incrementado cada vez que se genere una nueva etiqueta. esto se logra. es necesario utilizar en cada sitio un contador. El segundo requerimiento es el más complicado de satisfacer. De esta manera los contadores de sitios cooperativos se mantendrán aproximadamente sincronizados. añadiendo a cada mensaje el valor del contador del sitio que lo envía. este incremento su contador a TS + 1.2).2). Es posible que el sitio 1 genere más etiquetas que el sitio 2. l). Ahora el contador local 1 es incrementado 4y pasa a ser TS(A)=(1 1. Si un sitio recibe un mensaje con una etiqueta con valor TS mayor al actual en este sitio. se vera que se tendrán que usar siempre contadores y no relojes. la sincronización entre los contadores de diferentes sitios podría llegar a ser difícil. Nótese que TS(A) y TS(B) difieren únicamente en el identificador del sitio en donde se generaron.Fundamentos de las Bases de Datos Distribuidas anterior es necesario para evitar que las etiquetas generadas por un sitio sean consideradas como mayores a las generadas en otros sitios. Primero. inicialmente se tiene que TS(A)=(0. en algunas implementaciones será conveniente usar relojes en lugar de contadores. Por lo tanto. este genera la etiqueta de tiempo B. 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. y dado que la etiqueta de tiempo es menor en este sitio. esto con el fin de mantener un orden de estas dentro de un mismo sitio. A y B son seudo simultáneas con un orden arbitrario. Finalmente. Cuando el mensaje M2 llega al sitio 1. el contador es simplemente incrementado y pasaría a ser TS(B)=(1 1.y) representa al sitio y. De esta manera se reflejará de manera más real la secuencia en la ocurrencia de eventos. Considérese el ejemplo anterior. Sin embargo. Los contadores de dos sitios se pueden mantener aproximadamente alineados. Cuando el mensaje Ml llega al sitio 2. y por lo tanto el contador del sitio 1 se incrementaría más rápido.

Fundamentos de las Bases de Datos Distribuidas

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.

Sitio 1

Sitio 2

Sitio 1

T1A1

T1A2

T1A1

T1A2

T2A1

T2A2

T2A1

T2A2

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 T rAs. Hay dos razones por las cuales un agente esperaría a otro:

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 Tr, 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
109

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

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 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

Bases de Datos Distribuidas

110

Fundamentos de las Bases de Datos Distribuidas

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:

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:
111

Bases de Datos Distribuidas

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”. una detrás de otra. Las transacciones no se pueden anidar.Fundamentos de las Bases de Datos Distribuidas a) Que la base de datos no se halla dañado pero su contenido es incierto (por ejemplo. 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. El commit se usa para indicar una terminación exitosa (la unidad de trabajo ha terminado con éxito). 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. La ejecución de un programa puede corresponder a una secuencia de vanas transacciones. debido a algún problema de hardware) la solución en este caso.1 Transacciones El propósito fundamental de un sistema de bases de datos es realizar transacciones. consiste en recuperar la base de datos utilizándola copia de respaldo más reciente. b) La base de datos se daña físicamente (por ejemplo. por otro lado el commit y el rollback se pueden ejecutar solamente cuando se esta ejecutando una transacción. el rollback se utiliza para indicar una terminación no exitosa.2. la unidad de trabajo no puede ser terminada completamente debido a que ha ocurrido una condición excepcional. una operación recuperable es una operación que puede ser deshecha o rehecha en el caso de alguna falla. Una transacción es una unidad de trabajo. esto es el begin transaction puede ser ejecutado solamente cuando la aplicación no tiene una transacción en progreso. es decir son las 112 Bases de Datos Distribuidas . Todas las acciones recuperables deben ser ejecutadas dentro de los limites de una transacción. es decir. 4.

esta no solo actualiza la base de datos sino que además envía mensajes al usuario final. Las actualizaciones en la base de datos y los mensajes de entrada-salida son operaciones recuperables. 4. no llega a su terminación planeada a causa de un error.2 Manejo de mensajes La recuperación tiene varias ¡aplicaciones tanto con el manejo de mensajes como de la base de datos. Las operaciones commit y rollback explícitos. 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. entonces el sistema debe deshacerla automáticamente. 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. es decir planeados.Fundamentos de las Bases de Datos Distribuidas operaciones que se deben registrar en la bitácora. Los mensajes de salida deberán ser transmitidos al usuario hasta que ocurra una terminación planeada en la transacción. Si la transacción falla. provocan que el DC Manager escriba un registro en la bitácora. 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. 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. realiza la transmisión de estos mensajes al usuario y remueve el mensaje de 113 Bases de Datos Distribuidas . el efecto en este caso será como si la transacción nunca se hubiera iniciado. considerando el aspecto del manejo de mensajes de una transacción. es decir.2. Para los mensajes contenidos en la cola de salida. Las transacciones son proposiciones de todo o nada. el manejador de recuperación es el responsable de proveer esa confiabilidad. El componente responsable del manejo de los mensajes es el manejador de comunicaciones de datos (DC manager). sus actualizaciones en la base de datos deberán ser deshechas y ningún mensaje generado por la transacción deberá ser mostrado. se debe garantizar al usuario que cada transacción es ejecutada completamente o no se ejecuta en lo absoluto. si la transacción llega a su terminación planeada (commit o rollback explícito) se debe enviar un mensaje al usuario.

equipo. etc. fecha y hora. Commit.Fundamentos de las Bases de Datos Distribuidas entrada de la cola de correspondiente. usuario. 3000 pesos T3 Dar de alta la cuenta C7 con 5000 pesos T4 Transferir 1000 pesos de la cuenta Cl a C3 Id cuenta C1 C2 C3 Saldo 1000 500 3200 Bases de Datos Distribuidas 114 . 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. transacción. Rollback)  Mensajes  ldentificadores  Tipo de mensaje (entrada o salida)  Texto de mensaje  Operaciones  identificadores  Id. id. Si la transacción falla.3  Estructura general de los registros de bitácora Registro de control  Identificadores (id.2.)  Comandos (Begin transaction. 4. el sistema automáticamente genera un rollback (implícito) y esto provoca que el DC Manager descarte los mensajes de la cola de salida.

baja. así como los registros de control para cada una de las transacciones: T1 T1 T1 T1 T1 T1 T2 T2 T2 T2 T2 T3 T3 T3 T3 T3 T4 T4 T4 T4 T4 usr23 usr23 usr23 usr23 usr23 usr23 usrO2 usrO2 usrO2 usrO2 usr02 usr45 usr45 usr45 usr45 usr45 usr87 usr87 usr87 usr87 usr87 Begin transaction ME R D ms Commit Begin Transaction ME D MS Commit Begin ME A ms Commit Begin Transaction ME R MS Rollback Transferencia C1 C3 1000 C1 600 Fondos C1 -400 Insuficientes Transaction Alta C7 5000 C7 5000 Registro Completado Deposito C5 3000 C5 1532 C5 4532 Deposito Completado Transferencia C1 C4 400 C1 1000 C1 600 C4 8000 C4 8400 Transferencia Completada Dando como resultado siguiente la tabla: Bases de Datos Distribuidas 115 . las operaciones de alta.Fundamentos de las Bases de Datos Distribuidas C4 C5 C6 8000 1532 4553 En la bitácora se almacenan los mensajes de entrada y salida. deposito y retiro.

3. una falla en el CPU). etc. una división entre cero. Fallas locales de transacción. un aterrizaje de las cabezas de un disco duro). 2.4 Tipos de fallas Una operación rollback permite asegurarse de que una falla no corrompa la base de datos. por ejemplo un overflow aritmético. 4.2. caen en las siguientes categorías: 1. que son detectadas por el código de la aplicación (Por ejemplo. 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. en el caso de que la transacción por si misma descubra la condición de la falla. que no son explícitamente manejadas por el código de la misma. pero que no dañan la base de datos (por ejemplo. una condición de fondos insuficientes en una transacción bancaria). 4.Fundamentos de las Bases de Datos Distribuidas Id cuenta C1 C2 C3 C4 C5 C6 C7 Saldo 600 500 3200 8400 4532 4553 5000 4.5 Fallas de transacción Bases de Datos Distribuidas 116 . Fallas locales de la transacción. Los tipos de fallas que pueden ocurrir. una violación de seguridad. 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 manejadas de esta manera.2. Fallas del sistema que afectan a todas las transacciones que se encuentran en ejecución.

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. El sistema enciende una condición de error generalizada. Colaciones de seguridad. el sistema enciende una condición para ese tipo de error en particular por ejemplo. por lo que es necesario que el sistema force un rollback. lo que ocurre cuando se da una condición de este tipo. 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. si ocurre un error para el cual no hay un código incluido en la aplicación que maneje explícitamente ese error. Una falla de transacción significa que la transacción no ha llegado a su terminación planeada. Cuando se presenta una condición de error. si no se incluye este código. Bases de Datos Distribuidas 117 . El programador tiene la opción de incluir explícitamente el código correspondiente para manejar esta condición.Fundamentos de las Bases de Datos Distribuidas Este término se usa para indicar una falla causada por una terminación no planeada y anormal de un programa. no del programa. 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. 3. En general se dice que una falla de transacción ocurre si y solo si el programa termina de manera no planeada. el sistema realiza la siguiente acción. esto es. incluyen overflow aritmético. por regla general es lo siguiente: 1. sino como una terminación anormal planeada de la transacción. que 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. es decir. división entre cero. división entre cero. 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. Las condiciones que pueden causar esta terminación no planeada. 2. La ejecución de un rollback explícito no esta considerado como una falla de transacción.

2. 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. Si una aplicación es muy grande. posteriormente rehacer en el caso de una falla. sin perjudicar el proceso de recuperación. donde se almacenaran los siguientes registros de bitácora.7 Transacciones grandes Una transacción es tanto una unidad de recuperación como una unidad de trabajo.2. 4. es conveniente que la bitácora se pueda guardar en un dispositivo de acceso directo. Una posible solución podría ser lo siguiente: La bitácora activa es mantenida en el dispositivo de acceso directo. una transacción debe de ser corta con el fin de reducir la cantidad de trabajo que se tiene que deshacer y quizás. por lo que es claramente inconveniente el mantener la bitácora completa en línea. esta. activa otro archivo de bitácora. mientras que el otro archivo se respalda en algún medio. 4. este proceso se puede realizar de la siguiente manera: Bases de Datos Distribuidas 118 . un sistema de base de datos grande puede generar al orden de varios gigabites de bitácora al día. Con el fin de ocupar menor cantidad de espacio de almacenamiento posible. cuando el nuevo archivo de bitácora este activo.2. lo más adecuado es subdividirla en varia transacciones sin afectar el concepto de transacción. además reduce la posibilidad de que una transacción falle debido a un overflow en la bitácora. y es reiniciada posteriormente. por lo tanto. Cuando el archivo de bitácora se llena. el administrador de la bitácora.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. el sistema provoca un rollback y todas las operaciones realizadas por esta se deshacen. sin embargo. esto sugiere que.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.Fundamentos de las Bases de Datos Distribuidas 4.

6. 4. pues se hace un barrido y se rehacen todas. Se pueden eliminar los registros de control.Fundamentos de las Bases de Datos Distribuidas 1. se pueden eliminar los registros de las transacciones que terminaron con rollback. cuya actualización representan los registros de la bitácora. quedaría como sigue: T1 T1 T2 T3 R D D A C1 600 C4 8400 C5 4532 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. hora. las transacciones que en el 119 Bases de Datos Distribuidas . 2. 3. 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 puede eliminar el identificador de la transacción. Considerando la bitácora de la sección 4.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. se pierde. 7. la cual después de la compresión. 3.2. el del usuario. fecha. (identificador de transacción no es lo mismo que tipo de transacción). 4. 2. Se eliminan los registros de la bitácora que modifican el mismo registro de la base de datos quedando registrado únicamente la ultima actualización. Así. Se puede eliminar la parte UNDO de cada registro que representa una actualización sobre la base de datos. debido a que no es necesario hacer la recuperación. etc. en particular el contenido de todo los buffers de entrada/salida (I/O). Se pueden eliminar tanto los mensajes de entrada como los de salida. transacción por transacción. pero la base de datos no sufre daño alguno. 5. Se eliminan los apuntadores al registro anterior y registro siguiente.

Forza la escritura del contenido de los buffers de la base de datos. 2. Se puede reducir fuertemente la cantidad de búsqueda. esto. cada cierto tiempo o número de entradas de bitácora. si es que estas no habían terminado. en la base de datos almacenada físicamente. Forza el contenido de los buffers de bitácora hacia la bitácora física. 4. Forza la escritura de un registro de check-point en la bitácora. Escribe la dirección del registro de check-point incluido en la bitácora en un archivo de restablecimiento. El principio de check-point es muy simple: A cierto intervalos preestablecidos. el sistema realiza un check-point que consiste en los siguientes pasos: 1. tal búsqueda podría consumir demasiado tiempo. introduciendo el principio de punto de verificación (Checkpoint). Esto obliga la escritura de cualquier registro de bitácora que aun permanezca en la memoria principal. que transacciones deshacer.Fundamentos de las Bases de Datos Distribuidas momento de la falla se estuvieran ejecutando. por ejemplo. identificando aquellas transacciones para las cuales hay un registro de inicio de transacción (BT). Una lista de todas las transacciones activas al momento del check-point. Pero. como podría el manejador de recuperación saber al momento del restablecimiento. pero no un registro de terminación (commit o rollback). Esto obligará la escritura de cualquier actualización que aun se encuentre en la memoria principal. se deberán de deshacer. Esto se puede resolver buscando en la bitácora desde el principio. 3. El registro de check-point contiene la siguiente información: 1. Sin embargo. Bases de Datos Distribuidas 120 .

Fundamentos de las Bases de Datos Distribuidas 2. Para el propósito del restablecimiento. el manejador de recuperación obtiene la dirección del registro de check-point más reciente del archivo de restablecimiento. desde este punto hasta el final. La dirección del registro de bitácora más reciente de cada una de estas transacciones. Como resultado de este proceso el manejador de recuperación tiene la posibilidad de determinar. T4 T5 Inician después del check-point y terminan antes de que ocurra la falla Inician después del check-point. tanto las transacciones que tiene que deshacer. Al momento del restablecimiento. T1 T2 T3 Bases de Datos Distribuidas 121 . localiza este registro de bitácora y procede a buscar adelante en la bitácora. con el fin de llevar la base de datos a un estado correcto. sin embargo no han terminado al momento de la falla. pero no termina porque se presenta la falla. las transacciones pueden ser clasificadas en 5 categorías: Tipo T1 T2 T3 Descripción Terminan antes del check-point Inician antes del check-point y terminan después de este Inician antes del check-point. como las transacciones que tienen que ser rehechas.

4. ya que al realizar el paso 3 del check-point sus actualizaciones se escribieron en la base de datos. las transacciones del tipo T3 y T5 se deben deshacer y las del tipo T2 y T4 deberán ser rehechas. Se lee hacia atrás. sí el registro recuperado pertenece a una transacción de la lista UNDO. daña parte o toda la base de datos. Bases de Datos Distribuidas 122 .2.Fundamentos de las Bases de Datos Distribuidas T4 T5 Check Point Momento de la falla Al momento del restablecimiento. es necesario iniciar una lectura secuencia¡ de la bitácora a partir del registro de check-point y rehacer el cambio que representa cada registro de la bitácora que pertenezca a las transacciones de la lista REDO. 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. 3. no hay garantía de que sus actualizaciones hayan sido escritas en la base de datos. secuencialmente la bitácora desde el final hasta el registro de check-point. Las transacciones del tipo Tl no se consideran en al proceso de recuperación.10 Fallas en el medio de almacenamiento Este tipo de falla en el que se daña el medio de almacenamiento. hasta localizar el begin transaction de cada una de ellas. Para rehacer las transacciones del tipo T2 y T4. se deshace el movimiento que este representa. y las transacciones que estaban usando esa parte se ven afectadas. 2. ya aunque las transacciones se realizaron completas. 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.

. como las partes que se respaldaron.3. La tabla cuentas fue respaldada antes de que se realizaran las transacciones Tl. La bitácora debe contener todos los movimientos efectuados desde que se hizo el ultimo respaldo hasta el momento de la falla. siguiendo el proceso de recuperación. y enseguida se le aplican los movimientos registrados en la bitácora de las transacciones que terminaron con commit. 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. substituyendo directamente el valor almacenado en la tabla por el valor obtenido de la bitácora.- Se restaura la base de datos del medio de respaldo. juegan un papel fundamental. 1. T2. Supóngase que el disco duro en el cual estaba almacenada la tabla de cuentas se daña. los respaldos realizados periódicamente. Considérese la tabla de la sección 4.Fundamentos de las Bases de Datos Distribuidas en este caso. Bitácora T1 R C1 600 Bases de Datos Distribuidas 123 . La bitácora implica todos los movimientos que se encuentran en la parte activa. dichas transacciones fueron registradas en la bitácora.2. y es necesario recuperarla a partir del respaldo en el disco duro nuevo. Cuentas Id_cuenta C1 C2 C3 C4 C5 C6 Saldo 1000 500 3200' 8000 1532 4553 2. la cual fue sometida a un proceso de compactación y respaldo.Se aplican los movimientos almacenados en la bitácora. T3 y T4.

Fundamentos de las Bases de Datos Distribuidas T1 T2 T3 Id_cuenta C1 C2 C3 C4 C5 C6 Saldo 600 500 3200 8400 1532 4553 D D A C4 8400 C5 4532 C7 5000 Id_cuenta C1 C2 C3 C4 C5 C6 C1 C2 C3 C4 C5 C6 Saldo 600 500 3200 8000 1532 4553 Id_cuenta 600 50 3200 8400 4532 4553 Saldo Id_cuenta C1 Saldo 600 Bases de Datos Distribuidas 124 .

por lo tanto. y aun por falsificación deliberada. 4. no tiene que ver con la integridad. Se asume la existencia de un subsistema de integridad con las siguientes responsabilidades: Bases de Datos Distribuidas 125 .3 Integridad El término integridad se usa en el contexto de la base de datos con el significado de correctez o validez.Fundamentos de las Bases de Datos Distribuidas C2 C3 C4 C5 C6 C7 500 3200 8400 4532 4553 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. por errores por parte del operador o del programador de la aplicación. proteger la base de datos de transacciones invalidas que pueden ser provocadas por errores al introducir los datos. el problema de la integridad es el asegurarse que la base de datos sea correcta.El proteger la base de datos de operaciones que son ¡legales es responsabilidad del subsistema de seguridad. por fallas del sistema. sin embargo. sino con la seguridad. se asume que el usuario esta autorizado para la actualización en cuestión y que la actualización es valida. esto es. El ultimo caso.

se le debe de proveer al subsistema de integridad. Una restricción indica las acciones que se deben de realizar para que la base de datos cumpla con la regia. tomar la acción apropiada. Con el fin de ejecutar estas acciones. y la respuesta en caso de violación. En el caso de una violación. La mayor ventaja de esto es que las validaciones son manejadas por el DBMS. por lo que es más fácil entenderlas en su totalidad. rechazando la operación. y son compilada y almacenadas en el diccionario de datos de la base de datos. Monitorear las transacciones especialmente. 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. corresponde a un conjunto de instrucciones que se van a ejecutar en el caso de que no se cumpla con la restricción. además.Fundamentos de las Bases de Datos Distribuidas 1. 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. reportando la violación o corrigiendo el error. en lugar de las aplicaciones individuales. y por lo tanto modificarlas en caso de ser necesario. Las reglas de integridad se expresan en lenguajes de alto nivel. operaciones de actualización y detección de violaciones a la integridad de la base de datos. mayor oportunidad de detectar contradicciones y redundancias en ellas. por ejemplo. así como también conseguir que el proceso de validación se ejecute más eficientemente. Se tiene. 2. un conjunto de reglas que define que errores debe verificar y que hacer si se detecta el error. 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. por ejemplo SQL. Las reglas de integridad se pueden dividir en dos categorías: Bases de Datos Distribuidas 126 .

3.). cualquier valor dado como candidato del atributo A debe pertenecer a D. 4.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. no es otra que. La regla de integridad de dominio. Reglas de integridad de relación. 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] Bases de Datos Distribuidas 127 . esto es. considerado de manera aislada. la definición de ese dominio. La definición del dominio D entonces constituye una importante regla de integridad. etc. independientemente de su relación con otros valores en la base de datos. la cual deberá verificar en todas las operaciones de inserción y actualización que involucran cualquier atributo definido sobre D. el conjunto de todos los números reales. las características de ese dominio base (los dominios base son el conjunto de todas las cadenas de caracteres. Las violaciones a las reglas de integridad de dominio ocurren lo suficientemente seguido como para justificar algunas utilerías especiales para facilitar su manejoCada dominio es un subconjunto de un dominio base y hereda por lo tanto. Las reglas de integridad de dominio conciernen a la admisibilidad de un valor determinado como valor candidato para un atributo determinado. 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. el conjunto de todos los números enteros. para el atributo A de la relación R que se define sobre el dominio D.Fundamentos de las Bases de Datos Distribuidas   Reglas de integridad de dominio.

se asume por default las siguientes condiciones de activación: AFTER INSERTING tabla AFTER UPDATING tabla 2. consiste de una sola cláusula when commiting o de una lista de cláusulas Before y/o After separadas por comas. 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. si se especifica. La condición de activación.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.3.Fundamentos de las Bases de Datos Distribuidas 4. Todos los parámetros mencionados en una condición de activación deben tener el mismo cursor. en el caso de que no se especifique una condición de activación. por lo que cualquier referencia al Bases de Datos Distribuidas 128 .

Fundamentos de las Bases de Datos Distribuidas registro por sus campos en la restricción o en la respuesta en caso de violación no es ambigua. tiene la misma estructura interna que el registro a que se esta haciendo referencia. 5. La regla de integridad i: BEFORE cambio restricción ELSE respuesta en caso de violación. 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. 7. es decir. Si se especifican múltiples cláusulas FROM en la condición de activación determinada. así como también pueden hacer referencia a registros y campos de las tablas implícitas en la regla. 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. 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 Bases de Datos Distribuidas 129 . La restricción puede incluir referencias a parámetros. 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. la expresión C → R se refiere a una instancia específica de un registro tipo R que el cursor C se encuentra apuntando. Un cursor es un objeto cuyo valor es la dirección de algún registro especifico de la base de datos. 6. 4. es un apuntador la un registro específico. Si se especifica la cláusula FROM en una sentencia BEFORE se asume que la estructura destinada. 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. 3.

En el ejemplo de la sección 4. Las reglas de integridad de relación pueden involucrar a más de una relación. Esta regla verifica que el saldo sea igual o mayor a cero. 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. se especifica generalmente en forma separada en lugar de incluirse como parte de la definición de una relación. Bases de Datos Distribuidas 130 .saldo >= 0 Else Set return code to "Saldo insuficiente” Reject. en caso de ser negativo la operación es forzada a deshacerse y se envía el mensaje de "Saldo insuficiente". esta validación puede ser hecha por medio de reglas de integridad. por ejemplo: After Updating cuentas cuentas.2.3. de otra manera se realiza y regresa a la aplicación. por esta razón. 8. La regla de integridad i: AFTER cambio restricción ELSE respuesta en caso de violación. se tiene que la transacción 4 fue desecha debido a que no se contaba con el saldo suficiente para realizar la operación. después de que se realizo la actualización.Fundamentos de las Bases de Datos Distribuidas Si se ejecuta la respuesta en caso de violación y este incluye la operación REJECT entonces el cambio se realiza.

se asigne un id que ya exista en la tabla de cuentas: Before inserting cuentas from variable-de-programa Not exist (cuentas. por error.Fundamentos de las Bases de Datos Distribuidas Otro ejemplo. alteración o destrucción no autorizada. para evitar que. ld_cuenta) Else Set return code lo “El Id de la cuenta ya existe" Reject. Existen numerosos aspectos del problema de seguridad. definida como sigue: After deleting cuentas from variable-de-Programa Not exist (Movimientos where movimiento. depósitos). Id-cuenta = variable-de-Programa. De esta manera se realizaría un borrado en cascada de todos los movimientos de la cuenta eliminada. En el momento en el que se desea borrar una cuenta de la tabla de cuentas. Esto se puede lograr por medio de una regla de integridad. sería una regla que revisara la base de datos antes de dar de alta una nueva cuenta.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.ld-cuenta = variable_de_programa.ld-cuenta. Supóngase que se tiene una tabla en la cual se almacenan los movimientos mensuales de las cuentas (retiros. acerca del acceso. Id-cuenta variable-de_programa. todos los movimientos de la cuenta deberán de ser borrados para mantener la integridad de la base de datos. 4.ld-cuenta) Else Delete from movimientos where movimientos. entre ellos los siguientes: 131 Bases de Datos Distribuidas .

puede un usuario tener acceso al campo A y no tener acceso al campo B. Aspectos legales. 2. tiene acceso legal a la información solicitada. Por ejemplo. 7. nombre. 4. 3. sueldo. Controles físicos. provee el procesador central de alguna característica de seguridad.Fundamentos de las Bases de Datos Distribuidas 1. Políticas de acceso. 5. los niveles de acceso a esta relación que podrían ser otorgados a algún usuario en particular son: 1. Considera si el cuarto de la computadora o las terminales deberán estar cerrados o protegidos de alguna otra manera. Por ejemplo. El usuario puede consultar cualquier parte de la relación pero no modificarla. Problemas de operación. tales como llaves de protección de almacenamiento. Por ejemplo. Controles de hardware. 3. Situaciones que conciernen específicamente al propio manejador de la base de datos. Puede ver exactamente un registro (del cual es propietario) y dentro del registro puede alterar únicamente el nombre y la dirección. Por ejemplo. evaluación-desempeño). como se mantiene estos en secreto. o un modo de operación privilegiada. El usuario tiene acceso sin restricciones a la relación completa para cualquier tipo de operación. 4. protección. como decide la empresa quien deberá tener acceso a que datos. Bases de Datos Distribuidas 132 . Por ejemplo. 5. departamento. 6. tal vez un usuario de crédito.emp. dirección. Considerando la relación empleados (num . Puede ver exactamente un registro en la relación (del cual es propietario) pero no cambiarlo. la persona que hace la solicitud. Seguridad del sistema operativo. sociales y éticos. Por ejemplo. 2. si tanto A como B pertenecen al mismo registro. cual es el esquema de Algunos ejemplos de lo que podría verificar el subsistema de seguridad de una base de datos son los siguientes. El usuario no tiene acceso a la relación para ningún tipo de operación. si se utiliza un esquema de control de acceso por password.

la dirección y el departamento de cualquier registro de la relación y puede modificar solamente los valores del nombre. El usuario puede aplicar operadores estadísticos al campo de sueldo. y puede alterar la evaluación al desempeño si y solo si es el gerente del departamento. 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. decir quienes son. 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. esto es. El usuario puede ver los campos de número de empleado. 4. Puede ver los campos del número de empleado.4. Existen. nombre y la evaluación del desempeño. si el usuario logro ingresar al sistema operativo es un usuario valido para el DBMS y puede acceder a los datos. 9. Bases de Datos Distribuidas 133 . esto es. Existen algunos DBMS. Este paso direcciona el sistema al registro del usuario (USER PROFILE) apropiado. los usuarios se tendrán que identificar.Fundamentos de las Bases de Datos Distribuidas 6. Puede ver únicamente el número de empleado. 8. pero no leer o alterar valores individuales. el nombre. también. tales como DB2 UDB de IBM. En los sistemas multiusuario. los cuales confían el control de acceso al sistema operativo. 10. Normalmente los usuarios necesitan autentificar su identidad a través de password. sueldo y puede modificar el sueldo pero solamente entre las 9 y 17 horas.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. dirección y departamento. 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. Antes de accesar la base de datos. 7. y en una terminal localizada en la oficina de personal.

Fundamentos de las Bases de Datos Distribuidas 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. esto es. por ejemplo SQL utiliza el comando GRANT. GRANT SELECT ON empleado TO Jones. a si mismo. Sin embargo una medida significativa esta dada por el rango de características que se permite incluir en el cuerpo de la matriz.4. esta instrucción especifica que el usuario Jones esta autorizado para ejecutar operaciones de selección sobre la relación empleados. Considérese Bases de Datos Distribuidas 134 .J] representa al conjunto de reglas de integridad que se aplican al usuario I con respecto al objeto J. esta información se almacena en el USER PROFILE de Jones. El proceso de autentificación involucro el proporcionar información solamente conocida por el usuario propietario de la cuenta. por ejemplo algunos sistemas soportan solamente a nivel de relaciones completas. Las reglas de autorización serán compiladas y almacenadas en el diccionario de datos y una vez incluidas en este. 4. el DBMS forzará que se cumplan. La granularidad de los objetos para los cuales pueden existir columnas en la matriz de autorizaciones es una medida de lo sofisticado del sistema. de tal forma que A[I. accesado a la red por medio de un usuario y contraseña.3 Encriptación de datos Se ha asumido que los usuarios intentaran acceder la base de datos por los medios normales de acceso. los renglones corresponden a los usuarios y las columnas a los objetos de datos. Es conveniente considerar al conjunto de todos los USER PROFILES como una matriz de autorización en la cual. 4. 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.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.4. mientras que otras permitirán la autorización a nivel de campos individuales. huellas digitales o tarjetas).

robando parte de la información almacenada en algún medio de respaldo. el cual requiere del texto plano y de una llave de encriptación.. se encriptará el siguiente texto: AS KINGFISHERS CATCH FIRE 1.- Remplazar cada carácter del texto plano por un entero en el rango de 0-26. contraseñas en una forma encriptada.llave: Dividir el texto plano en grupos de caracteres de la misma longitud de la AS_KI NGFIS HERS_ CATCH _FIRE 2. Z=26: 0119001109 1407060919 0805181900 0301200308 0006091805 Bases de Datos Distribuidas 135 .. o corriendo algún programa que logre romper la seguridad del sistema operativo y del DBMS. es necesario tener una llave para determinar los caracteres de texto cifrado los cuales sustituirán a los caracteres del texto plano. mensajes. los datos originales son llamados texto plano.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. A continuación se presenta un ejemplo: Teniendo como llave de encriptación la palabra ELIOT.. obteniendo así. 4. usando_= 00. B=02. A=01. En el concepto de la encriptación. esto es. almacenar y transmitir todos los datos. la forma encriptada del texto plano. Una forma efectiva de prevenir que estos "usuarios” puedan ver la información contenida en la base de datos. El texto plano es encriptado por algún algoritmo de encriptación.Fundamentos de las Bases de Datos Distribuidas ahora el caso en que un "usuario" intenta acceder a la información rompiendo o eludiendo los métodos de seguridad establecidos. conocida como texto cifrado. 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.4. es la encriptación de datos. por ejemplo. o interceptando las líneas de comunicación. .

como dificultarle a un posible "usuario” infiltrado el hecho de determinar la llave de encriptación.- Para cada grupo del texto plano. el cual consiste en reordenar los caracteres resultantes de a cuerdo a alguna secuencia.Fundamentos de las Bases de Datos Distribuidas 3.- Remplazar cada código por su correspondiente carácter. módulo 27. la llave de encriptación es conocida por todos.5 Encriptación de llave publica En este esquema de encriptación. La llave de desencriptación no puede ser deducida a partir de la llave de encriptación. Es posible también combinar con este método. una para encriptar y otra para desencriptar). Pero la llave de desencriptación es mantenida en secreto ( este esquema involucro dos llaves. 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. previamente definida. y cualquier persona puede convertir texto plano a texto cifrado. Este método de encriptación se basa en los siguientes hechos: Bases de Datos Distribuidas 136 .4. de esta manera la persona que ejecuta la encriptación no podrá ejecutar la desencriptación si no esta autorizada para hacerlo.- Repetir el paso 2 para la llave de encdptación: 0512091520 4. remplazar cada carácter por la suma. 4. de acuerdo al del paso 2: código FDIZB SSOXL MQ_GT HMBRA ERRFY El problema que se podría presentar en este método es. el método de permutación.

Se elige. y se reemplaza por el te)do cifrado C. d.. la cual es la llave de desencriptación.Fundamentos de las Bases de Datos Distribuidas 1. 3. dos numero primos largos distintos p y q... 2. un entero grande e que es primo con respecto a (p -1) * (q . para mayor seguridad deben de ser superiores a 80 dígitos.Se calcula la llave de desencriptación. Este método funciona de la siguiente manera: 1. módulo (p -1) * (q . de forma aleatoria. este es reemplazado por P. aleatoriamente.Existe un algoritmo rápido para determinar si cualquier número grande es primo.Para desencriptar una parte del texto cifrado.l).. 5.Se eligen..Se dan a conocer e y r. que se obtiene de la siguiente manera: P = Cd módulo r Bases de Datos Distribuidas 137 . la cual corresponde al único inverso multiplicativo de e..1) es 1. y que el mayor común divisor entre e y (p -1) * (q .l). obtenido de la siguiente manera: C = Pe módulo r 6.Para encriptar una parte del texto plano P ( se asume por simplicidad que es un entero menor a r ).No hay un algoritmo rápido para determinar los factores primos de un número grande.. Entonces e es la llave de encriptación. Obténgase el producto r = p * q 2. pero no d.. esto es: (d * e) módulo (p -1) * (q .1) = 1 4.

q = 5.Fundamentos de las Bases de Datos Distribuidas A continuación se presenta un ejemplo. por razones de facilidad se utilizaran números pequeños: Dados p = 3.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) 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) Bases de Datos Distribuidas 138 .1) = (3 -1) * (5 . P = 13 r = 3 *5 = 15 (p –1) * (q .

se indica como O¡ < Oj. En otro caso las transacciones se ejecutarían concurrentemente. 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. En una planificación. si la operación O¡ precede a la operación O¡. 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. que sea equivalente a una planificación serial. cuidando que esta ejecución sea correcta. si la ultima operación de Ti precede a la primera operación de Tj en S.5 Resumen Una transacción accesa la base de datos usando primitivas de lectura y escritura. esto es. Bases de Datos Distribuidas 139 . es decir 01 se ejecuta primero que O¡. Las transacciones se ejecutarán lo más concurrentemente posible.Fundamentos de las Bases de Datos Distribuidas 4. Dos transacciones Ti y Tj se ejecutan serialmente en una planificación S.

donde O¡ < Oj en S1. 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. La operación de escritura final es igual en ambas planificaciones. En una base de datos distribuida. 2. entonces O¡ deberá preceder a Oj en S2. la seriabilidad local no es suficiente para asegurar la exactitud de la ejecución de un conjunto de transacciones distribuidas. Sin embargo. cada transacción ejecuta operaciones en vanos sitios. 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. Bases de Datos Distribuidas 140 . ellas procesan el mismo dato y al menos una de estas operaciones es una operación de escritura.Fundamentos de las Bases de Datos Distribuidas 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. y estas operaciones pertenecen a diferentes transacciones. 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 O¡ y Oj. 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. Es importante también considerar el hecho de que dos operaciones pueden llegar a caer en conflicto: Dos operaciones están en conflicto si.

Una transacción puede bloquear un registro. Una transacción puede bloquear de manera exclusiva. y bloquear de modo exclusivo antes de escribir. una transacción no debe de requerir de un nuevo bloque después de que se libere algún registro... 2. la primera deberá esperar a que la otra transacción libere dicho bloqueo (unlock)... Sm... y sea E una ejecución de estas transacciones. La idea básica del bloqueo (lock) es que cuando una transacción requiera accesar un registro.Fundamentos de las Bases de Datos Distribuidas La ejecución de las transacciones T1. La anterior definición puede ser explicada usando la definición de conflicto: Sea T1. Una transacción siempre deberá bloquear un registro de forma compartida antes de leer el contenido. esto quiere Bases de Datos Distribuidas 141 .... . .. E es correcto (serializable) si existe un orden total de las transacciones. entonces hay una entrada serial Sk„ tal que. Tn tal que. 2. sí este no esta bloqueado o sí lo esta de manera compartida. si Ti < Ti en el orden total. y cuando una transacción intente bloquear un registro que anteriormente ya fue bloqueado por otra transacción.. . Existen dos reglas de compatibilidad entre los modos de bloqueo: 1. Existe un orden total de T1. O¡ precede a O¡ en cualquier entrada Sl. y además para cada par de operaciones en conflicto O¡ y Oj de las transacciones Ti y Ti respectivamente.. Cada entrada local Sk es serializable. para cada sitio k donde ambas transacciones tienen algún proceso en ejecución.. Sk es equivalente a Sk ' y Ti < Tj en el Señal(Sk'). esta bloquee dicho registro antes de intentar el acceso. Tn es correcta sí: 1. Otra condición que se deberá de tener en cuenta es que. modelado por el conjunto de entradas de bitácora Sl. Sn.. si y solo si Ti precede Tj en el orden total. solo si el registro no esta bloqueado. Tn un conjunto de transacciones.

3. Mayoría de bloqueos. Bloque de copia primaria. una primitiva de bloqueo es traducida en varias primitivas de bloqueo. mientras que los agentes de la transacción procesan las primitivas globales (bloqueo compartido. Write-locks-all. Considérese primero que si todas las transacciones logran un bloqueo de 2 fases. Bases de Datos Distribuidas 142 . read-locks-one. 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. y la segunda fase es en la cual se hace la liberación de todos los registros antes bloqueados. 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. bloqueo local exclusivo y. liberación local). En este esquema los bloqueos exclusivos son adquiridos en todas las copias. esto porque la primera fase sería el bloqueo de todos los registros necesarios para realizar la transacción. Si una transacción distribuida logra un bloqueo de dos fases entonces todas las subtransacciones en los diferentes sitios. De esta manera. mientras que los bloqueos compartidos son adquiridos únicamente en alguna copia arbitraria. 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). 2.Fundamentos de las Bases de Datos Distribuidas decir que la transacción debe de tener un bloqueo de dos fases (2PL). tantas como copias de datos se deseen bloquear. Los manejadores de transacciones locales interpretan las primitivas locales de bloqueo (bloqueo local compartido. y liberación). bloqueo exclusivo. lograrán separadamente un bloqueo de dos fases. Existen esquemas alternativos para lograr evitar conflictos en los bloqueos: 1. entonces todas las entradas de bitácora son serializables. Una de las copias de cada dato es privilegiada (llamada copia primaria) y todos los bloqueos se hacen sobre esta copia.

denotada por → puede ser generalizada en un sistema distribuido por medio de las siguientes reglas: Bases de Datos Distribuidas 143 . y pueden estar esperando por siempre. En un sistema distribuido. Se representan dos operaciones concurrentes colocándolas una sobre otra. La relación “ocurre antes”. Sin embargo. las transacciones T 1. 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. ya esta bloqueado por otra transacción.. en la ejecución concurrente de transacciones. desde el momento en que las transacciones utilizan el bloqueo de dos fases. si A ocurre antes que B. La determinación de un orden de eventos consiste en asumir que a cada evento A. se asigna una etiqueta de tiempo TS(A) (timestamp) con las siguientes propiedades: 1. estas no pueden liberar el bloqueo. Para lograr un análisis del grado de concurrencia que es permitido por el algoritmo de control de concurrencia.. algunas veces.. Para dos eventos cualquiera A y B. 2. conocer si un evento A en algún sitio ocurrió antes o después que un evento B en un sitio diferente. el cual ocurre en un sistema distribuido. Entonces. Tn requieren de un bloqueo de dos fases. Por lo tanto cada una de ellas tendrá que esperar hasta que otra transacción libere el bloqueo. Por lo tanto n transacciones alcanzarán un estado de deadlock. entonces TS(A) < TS(B). una de estas transacciones deberá ser abortada por algún algoritmo de solución de deadlock. T2.Fundamentos de las Bases de Datos Distribuidas Considérese ahora que. es necesario. el conjunto de transacciones no podrá ocurrir. TS(A) identifica de manera única a A (diferentes eventos tienen diferentes etiquetas de tiempo). es necesario incluir en el modelo de ejecución la noción de "operaciones concurrentes" en diferentes sitios. cada una de estas transacciones requieren de bloquear un dato el cual. sino hasta que se logran todos los bloqueos requeridos por dicha transacción. . En cualquier caso.

El agente TiAj requiere que el agente TiAs ejecute alguna función en un sitio diferente. La detección y solución de deadlocks constituye una actividad importante de un sistema manejador de bases de datos. Si A→B y B→C. Si el evento A consiste en enviar un mensaje y el evento B consiste en recibir el mensaje de A. debido a un ciclo de espera involucro varios sitios. entonces A→C. La figura se muestra una gráfica wait-for distribuido (DWFG): Sitio 1 Sitio 2 Sitio 1 T1A1 T1A2 T1A1 T1A2 T2A1 T2A2 T2A1 T2A2 Hay dos razones por las cuales un agente esperaría a otro: 1. 2. esto. Este tipo de espera se representa por una flecha continua en la gráfica.Fundamentos de las Bases de Datos Distribuidas 1. entonces A→S. Este tipo de espera es representado por una flecha discontinuo en la gráfica. T1A1 espera que T2A1 libere recursos en el sitio 1. La detección de deadlocks es más difícil en un sistema distribuido que un centralizado. Bases de Datos Distribuidas 144 . Si A y B son dos eventos en el mismo sito y A ocurre antes que B. 3. entonces A→B. 2.

primero que nada recuperar la propia base de datos. Periódicamente. Otros criterios podrían ser. 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. Los nodos cuadrados son llamados puertos de entrada si tienen una flecha hacia dentro de la gráfica. Si ocurre una falla hay dos posibilidades: Bases de Datos Distribuidas 145 . Se debe incluir algún procedimiento de recuperación. pudiera ser el que se aborte la transacción que implique el menor costo en dicha operación. restaurar la base de datos a un estado que se sabe es correcto. abortar la transacción que tiene la menor cantidad de recursos. hacer una copia de respaldo de la base de datos completa. El principio en el cual se basa la recuperación es la redundancia. desde y hacia los nodos los cuales representan a agentes que tienen conexión con el nodo local. o abortar la transacción que requiere más tiempo para terminar. Dichas LWFG se extienden con flechas. el cual puede consistir en forma general de lo siguiente: 1. el abortar la transacción más joven. tal vez diario. 2. Algo que se debe de tener en cuenta es que. se escribe un registro en un conjunto de datos especial llamado bitácora. y puertos de salida si las flechas salen. Cada vez que se haga un cambio en la base de datos. 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. 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. 3. esto es. La recuperación en un sistema de bases de datos.Fundamentos de las Bases de Datos Distribuidas 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. después de que una falla la ha llevado a un estado incorrecto o al menos incierto. la redundancia incremento la posibilidad de un deadlock. significa.

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. Fallas locales de transacción. pero que no dañan la base de datos. El propósito fundamental de un sistema de bases de datos es realizar transacciones. en el caso de que la transacción por si misma descubra la condición de la falla. Una operación rollback permite asegurarse de que una falla no corrompa la base de datos. El commit se usa para indicar una terminación exitosa. que son detectadas por el código de la aplicación. 3. Fallas locales de la transacción. se debe garantizar al usuario que cada transacción es ejecutada completamente o no se ejecuta en lo absoluto. la solución en este caso consiste en recuperar la base de datos utilizándola copia de respaldo más reciente. que no son explícitamente manejadas por el código de la misma.Fundamentos de las Bases de Datos Distribuidas 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. que se deben registrar en la bitácora. b) La base de datos se daña físicamente. 4. una operación recuperable es una operación que puede ser deshecha o rehecha en el caso de alguna falla. el rollback se utiliza para indicar una terminación no exitosa. Fallas del sistema que afectan a todas las transacciones que se encuentran en ejecución. 2. Las transacciones son proposiciones de todo o nada. Todas las acciones recuperables deben ser ejecutadas dentro de los limites de una transacción. caen en las siguientes categorías: 1. Bases de Datos Distribuidas 146 . Los tipos de fallas que pueden ocurrir. 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".

Lo que ocurre cuando se da una condición de este tipo. las transacciones que en el momento de la falla se estuvieran ejecutando. esto si es que estas no habían terminado. El sistema enciende una condición de error generalizada. no del programa. de nuevo el programador tiene la opción de incluir el código correspondiente para manejar esta condición. pero no un registro de terminación (commit o rollback). y es solamente en este punto que se dice que a ocurrido una falla de transacción. Así. 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 almacenamiento primario. sino como una terminación anormal planeada de la transacción. El principio de check-point es muy simple: Bases de Datos Distribuidas 147 . por regla general es lo siguiente: 1. La ejecución de un rollback explícito no esta considerado como una falla de transacción. identificando aquellas transacciones para las cuales hay un registro de inicio de transacción (BT). 2. pero la base de datos no sufre daño alguno. se deberán de deshacer.Fundamentos de las Bases de Datos Distribuidas 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. En este punto el sistema provoca la terminación anormal del programa y envía el mensaje correspondiente al usuario. 3. se pierde. Esto se puede resolver buscando en la bitácora desde el principio. Cuando se presenta una condición de error. el sistema enciende una condición para ese tipo de error en particular. por lo que es necesario que el sistema force un rollback. El programador tiene la opción de incluir explícitamente el código correspondiente para manejar esta condición. Una falla de transacción significa que la transacción no ha llegado a su terminación planeada.

2. en la base de datos almacenada físicamente. El registro de check-point contiene la siguiente información: 1. 3. desde este punto hasta el final. Forza la escritura de un registro de check-point en la bitácora. Una lista de todas las transacciones activas al momento del check-point. Escribe la dirección del registro de check-point incluido en la bitácora en un archivo de restablecimiento. cada cierto tiempo o número de entradas de bitácora. Forza la escritura del contenido de los buffers de la base de datos. localiza este registro de bitácora y procede a buscar adelante en la bitácora. por ejemplo. Al momento del restablecimiento. Forza el contenido de los buffers de bitácora hacia la bitácora física. 2. sin embargo no han terminado al momento de la falla. Bases de Datos Distribuidas 148 .Fundamentos de las Bases de Datos Distribuidas A cierto intervalos preestablecidos. las transacciones pueden ser clasificadas en 5 categorías: Tipo T1 T2 T3 Descripción Terminan antes del check-point Inician antes del check-point y terminan después de este Inician antes del check-point. pero no termina porque se presenta la falla. La dirección del registro de bitácora más reciente de cada una de estas transacciones. el sistema realiza un check-point que consiste en los siguientes pasos: 1. el manejador de recuperación obtiene la dirección del registro de check-point más reciente del archivo de restablecimiento. Para el propósito del restablecimiento. T4 T5 Inician después del check-point y terminan antes de que ocurra la falla Inician después del check-point. 4.

Con el fin de ejecutar estas acciones. se le debe de proveer al subsistema de integridad. y son compilada y almacenadas en el diccionario de datos de la base de datos. reportando la violación o corrigiendo el error. Se asume la existencia de un subsistema de integridad con las siguientes responsabilidades: 1. por ejemplo. un conjunto de reglas que define que errores debe verificar y que hacer si se detecta el error. rechazando la operación. el problema de la integridad es el asegurarse que la base de datos sea correcta. El término integridad se usa en el contexto de la base de datos con el significado de correctez o validez. tomar la acción apropiada. 2. 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. en lugar de las aplicaciones individuales. ya que al realizar el paso 3 del check-point sus actualizaciones se escribieron en la base de datos. Las reglas de integridad se expresan en lenguajes de alto nivel. Bases de Datos Distribuidas 149 . por ejemplo SQL. Reglas de integridad de relación.Fundamentos de las Bases de Datos Distribuidas Las transacciones del tipo T3 y T5 se deben deshacer y las del tipo T2 y T4 deberán ser rehechas. En el caso de una violación. La mayor ventaja de esto es que las validaciones son manejadas por el DBMS. Monitorear las transacciones especialmente. operaciones de actualización y detección de violaciones a la integridad de la base de datos. Las transacciones del tipo T1 no se consideran en al proceso de recuperación.

3. Políticas de acceso. esta información se almacena en el USER PROFILE.Fundamentos de las Bases de Datos Distribuidas Se utiliza el término de seguridad en un contexto de bases de datos para indicar la protección de la base de datos. 6. Aspectos legales. por lo que para cada usuario. Problemas de operación. 7. Este paso se direcciona el sistema al registro del usuario (USER PROFILE) apropiado.J] representa al conjunto de reglas de integridad que se aplican al usuario 1 con respecto al objeto J. Situaciones que conciernen específicamente al propio manejador de la base de datos. 4. Controles de hardware. 2. Es conveniente considerar al conjunto de todos los USER PROFILES como una matriz de autorización en la cual. acerca del acceso. sociales y éticos. esta instrucción especifica que el usuario esta autorizado para ejecutar operaciones de selección sobre una relación. El sistema debe permitir la definición de reglas que deberán ser expresadas en algún lenguaje de alto nivel. entre ellos los siguientes: 1. Las reglas de autorización serán compiladas y almacenadas en el diccionario de datos y una vez incluidas en este. por ejemplo SQL utiliza el comando GRANT. 5. los renglones corresponden a los usuarios y las columnas a los objetos de datos. GRANT SELECT. Bases de Datos Distribuidas 150 . Existen numerosos aspectos del problema de seguridad. Controles físicos. 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. Seguridad del sistema operativo. el DBMS forzará que se cumplan. el sistema debe mantener un registro. de tal forma que A[I. especificar los objetos que el usuario esta autorizado para accesar y las operaciones que tiene autorizados ejecutar sobre los objetos. alteración o destrucción no autorizada.

esto es. 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. El método de sustitución es uno de los más sencillos métodos de eneriptación de datos. La llave de desencriptación no puede ser deducida a partir de la llave de encriptación. En el concepto de la encriptación. Una forma efectiva de prevenir que "usuarios" no autorizados puedan ver la información contenida en la base de datos. a si mismo. contraseñas en una forma encriptada. y cualquier persona puede convertir texto plano a texto cifrado. de ésta manera la persona que ejecuta la encriptación no podrá ejecutar la desencriptación si no esta autorizada para hacerlo.6 Preguntas de repaso 1. es necesario tener una llave para determinar los caracteres de texto cifrado los cuales sustituirán a los caracteres del texto plano. El texto plano es encriptado por algún algoritmo de encriptación. conocida como texto cifrado. el cual consiste en reordenar los caracteres resultantes de a cuerdo a alguna secuencia.¿Por qué dos operaciones pueden caer en conflicto? Bases de Datos Distribuidas 151 . previamente definida. los datos originales son llamados texto plano.Fundamentos de las Bases de Datos Distribuidas Se ha asumido que los usuarios intentaran acceder la base de datos por los medios normales de acceso. el método de permutación. obteniendo así. 4. la forma encriptada del texto plano. almacenar y transmitir todos los datos.3. En el esquema de encriptación de llave publica.2. una para encriptar y otra para desencriptar). accesado a la red por medio de un usuario y contraseña. el cual requiere del texto plano y de una llave de encriptación. mensajes. Es posible también combinar con este método.¿Cuál es la condición para que dos transacciones sean serializables? ¿Cuándo dos transacciones son concurrentes? ¿Cuáles son las dos condiciones que deben cumplir dos planificaciones para que sean equivalentes? 4. la llave de encriptación es conocida por todos. Pero la llave de desencriptación es mantenida en secreto (este esquema involucro dos llaves. es la encriptación de datos. esto es.

una base de datos pueda ser recuperada? 12.20.¿Que tipos de fallas pueden darse en un sistema de base de datos? ¿Que se entiende por integridad en un sistema de bases de datos? ¿Cuales son las responsabilidades de un subsistema de integridad? ¿Explique la regla de integridad de dominio? 17.¿A que se refiere la palabra seguridad dentro del ámbito de las bases de datos? 18.Fundamentos de las Bases de Datos Distribuidas 5.16..8.Además de la replicación de la base de datos.10.7 Ejercicios 1. 7. ¿qué es recomendable hacer? 13.9.¿Que son las reglas de autorización? ¿Que es la encriptación de datos? 4.Explique brevemente en que consiste el bloqueo de 2 fases.¿Mencione 5 aspectos que se deben tomar en cuenta dentro de la seguridad de las bases de datos? 19.6. Cuentas Bases de Datos Distribuidas 152 . creación de una cuenta.- ¿Cómo funciona el control de concurrencia basado en bloqueos distribuidos? Mencione y describa los esquemas o métodos que existen para evitar los conflictos entre bloqueos. ¿En que consisten las etiquetas de tiempo? ¿Que se entiende por deadlocks distribuidos? ¿Que es la recuperación? ¿De que manera garantizamos que en dado momento.14...- Para las siguiente tabla defina las reglas de integridad para el retiro de fondos. transferencia de fondo y para la cancelación de una cuenta (considerando que existe una tabla de movimientos).15.11.

Fifth Edition.Tomando en cuenta la tabla y regla de integridad anteriores.J.J. Reprinted July. C. realice la encriptación y desencriptación de los siguientes números: 8.A. U. realice las siguientes transacciones y regístrelas en una bitácora. lnternational Edition 1991 Bases de Datos Distribuidas 153 .. Addison-Wesley Publishing Company. Abraham. 9.. Volume 11. Retiro de 2000 de la cuenta C12. 3.. y teniendo encuentra que p = 5 y q = 7. @Database System Concepts". "An lntroduction to Databases Systems". Addison-Wesley Publishing Company. 1995 [3] Korth. Deposito de 1234 a la cuenta C78. Second Edition McGraw-Hili. Henry F.Fundamentos de las Bases de Datos Distribuidas Id_cuenta C12 C23 C54 C78 Saldo 458 8541 2369 500 2. Bibliografía [1] Date.S. Volume 1..S. U.A.- Utilizando el método de encriptación de llave publica. Cancelación de la cuenta C54.A. 1990 [2] Date. Silberschatz.. "An lntroduction to Databases Systems". C. T1: T2: T3: T4: T5: Transferencia de la cuenta C23 a C12 por 1500. Reprinted July. Transferencia de [a cuenta C12 a C78 por 1960.. U.S.

       La mayor parte de las organizaciones ya están distribuidas. Existe un incremento en el desempeño del sistema. Son más confiables. La mayor parte del tiempo se encuentra disponible la información. Permiten interconexión de las bases de datos existentes.Fundamentos de las Bases de Datos Distribuidas Respuestas a preguntas y ejercicios de repaso Capítulo I Preguntas de repaso 2. Es posible realizar un desarrollo incrementar. Bases de Datos Distribuidas 154 . Permite reducir la carga de las líneas de comunicación.

y esto garantiza Bases de Datos Distribuidas 155 . sino por el contrario.Significa que el usuario nunca vera la base de datos como un conjunto de fragmentos situados en diferentes sitios. para él. 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. Se ejecuta de modo local.  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. Deberá de proveer altos niveles de desempeñoDeberá de contar con capacidad de red.    Deberá ser capaz de soportar múltiples usuarios. la base de datos se encuentra íntegramente en su estación de trabajo o sitio de trabajo. Vista desde el exterior la distribución será completamente transparente. Capítulo II Preguntas de repaso 2.Porque describe la forma en como deberá de funcionar una base de datos distribuida. 6.   Es llamado por el usuario y se ejecuta durante la sesión. 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. 10. Tiene capacidad de iniciar la comunicación con el servidor. 8.  Procesamiento local: Los datos son colocados en el sitio o cerca del sitio donde residen las aplicaciones que los utilizan. Deberá ser capaz de satisfacer las demandas de los clientes.Fundamentos de las Bases de Datos Distribuidas 4.

Fundamentos de las Bases de Datos Distribuidas

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.  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: q2: q3: Obtener los nombres de todos los clientes. Obtener los números de cliente (no_cli) por estado. Obtener los nombres de los clientes (nom_cli) por empresa.

No_cli C01 C02 C03 C04 C05 C06

Nom_cli Juárez Vidal Ávila Mejía Herrera Cervantes

Empresa Gamesa Lara Gamesa Lara Lara Gamesa

Estado Gto Qro Jal Jal Gto Qro

Bases de Datos Distribuidas

156

Fundamentos de las Bases de Datos Distribuidas

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}

M1 = Gto ^ ~Qro ^ ~Jal ^ ~Gamesa ^ Lara m2 = Gto ^ ~Qro ^ ~Jal ^ Gamesa ^ ~Lara m3 = ~Gto ^ Qro ^ ~Jal ^ ~Gamesa ^ Lara m4 = ~Gto ^ Oro ^ ~Jal ^ Gamesa ^ ~Lara m5 = ~Gto ^ ~Qro A Jal ^ ~Gamesa ^ Lara m6 = ~Gto ^ ~Qro ^ Jal ^ Gamesa ^ ~Lara

si si si si si si

m7 = ~Gto ^ ~Oro ^ ~Jal ^ ~ Gamesa ^ ~Lara m8 = Gto ^ Oro ^ Jal ^ Gamesa ^ Lara m9 = Gto ^ Oro ^ Jal ^ Gamesa ^ ~Lara m10 = Gto ^ Oro ^ Jal ^ ~Gamesa ^ Lara m11 = Gto ^ Oro ^ Jal ^ ~ Gamesa ^ ~-Lara m12 = Gto ^ Qro ^ ~ Jal ^ Gamesa ^ Lara . . .

no no no no no no no

m1 = Gto ^ Lara m2 = Gto ^ Gamesa m3 = Oro ^ Lara m4 = Oro ^ Gamesa m5 = Jal ^ Lara

Bases de Datos Distribuidas

157

Fundamentos de las Bases de Datos Distribuidas

m6 = Jal ^ Gamesa

m1 No_cli C05 Nom_cli Herrera Empresa Lara Estado Gto

m2 No_cli C01 Nom_cli Juárez Empresa Gamesa Estado Gto

m3 No_cli C02 Nom_cli Vidal Empresa Lara Estado Qro

m4 No_cli C06 Nom_cli Cervantes Empresa Gamesa Estado Qro

m5 No_cli C04 Nom_cli Mejía Empresa Lara Estado Jal

m6 No_cli C03 Nom_cli Ávila Empresa Gamesa Estado Jal

Bases de Datos Distribuidas

158

- q1: q2: q3: Obtener los nombres de todos los clientes. Obtener los nombres de los clientes por empresa. Nom_cli From clients Where Estado q3= Select Nom-cli From clientes Where Empresa = y A1 no_cli q1 q2 q3 0 1 0 A2 nom_cli 1 1 1 A3 Empresa 0 0 1 A4 Estado 0 1 0 Tot de accesos 5 3 2 Bases de Datos Distribuidas 159 . Matriz de accesos S1 Ql q2 q3 3 2 1 S2 2 1 1 q1= Select Nom_cli From clients q2= Select no_cli. Obtener los números y nombres de los clientes por estado.Fundamentos de las Bases de Datos Distribuidas 3.

Empresa} F2={ No el¡. Seleccionar el método optimo para la ejecución de cada operación. Nom_cli. Estado} O F1={ No_cli.   Se deberá seleccionar el orden de ejecución del conjunto de consultas sobre cada uno de los sitios. 6. 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. 4. Estado} Capítulo III Preguntas de repaso 2. Empresa.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. Nom_cli} F2={No_cli.Fundamentos de las Bases de Datos Distribuidas Al Al A2 A3 A4 3 3 0 3 A2 3 10 2 3 A3 0 2 2 0 A4 3 3 0 3 F1={No_cli.- Bases de Datos Distribuidas 160 .

ésta.PJEMP:NOM DF JNDEPTNUM=DEPTNUM JNDEPTNUM=DEPTNUM EMP SLDESC=X SLSAL<=11000 SLDESC=x Bases de Datos Distribuidas 161 . es decir.  Elegir el procedimiento para evaluar la consulta. Join paralelo Pipeline muitiway join. Convertir la consulta a alguna expresión apropiada par el sistema administrador de la base de datos.way join. para que de esta manera pueda ser ejecutada adecuadamente. Iteración orientada a bloques. 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. Merge .join. se construyen un conjunto de planes de ejecución de la consulta y se elige el más económico de ellos. select. etc. Donde económico se refiere a la ejecución de menor costo en el sistema. 8. generando subprocedimientos para la ejecución de las operaciones de bajo nivel. llevar a la expresión hasta su forma más simple posible. eliminando expresiones comunes y repetidas. Tree . Ejercicios de repaso 1. tales como join. generando.Fundamentos de las Bases de Datos Distribuidas        Iteración simple. Hash . y reduciendo su costo de procesamiento.  Por ultimo.join. expresada en su forma canónica.

cuando procesan el mismo dato y al menos una de ellas es una operación de escritura.all. read .Fundamentos de las Bases de Datos Distribuidas DEPT EMP DEPT 3.lock . y dichas operaciones pertenecen a diferentes transacciones. PJEMP:NOM DF SLSAL>35000 JNDEPTNUM=DEPTNUM EMP SLDESC=X DEPT Capítulo IV- Preguntas de repaso 2. Bases de Datos Distribuidas 162 .Dos operaciones están en conflicto. 6. 4.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. Write .  Mayoría de bloqueos: Tanto los bloqueos exclusivos como los compartidos son hechos en la mayoría de las copias existentes.Dos transacciones son concurrentes si no cumplen la condición de seriabilidad.lock .

esto para que las perdidas de información sean mínimas o casi nulas.Fundamentos de las Bases de Datos Distribuidas tomando en cuenta que el número de copias bloqueadas sea mayor que el número de las no bloqueadas.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. llamada copia primaria.Una etiqueta de tiempo. poder decidir cual podría ser abortada en caso de presentarse un interbloqueo. 14. Esta etiqueta es utilizada para saber en que orden fueron lanzadas cada una de las transacciones y en dado momento. 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. 12. 8. 10. 16.Junto con la replicación.Cada atributo de la relación esta definido sobre un dominio.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. Bases de Datos Distribuidas 163 .  Bloqueo de copia primaria: Todos los bloqueo son hechos en una sola copia del fragmento. 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. es un identificador único asignado a cada transacción lanzada en el sistema. identificado en la definición de la relación y todo valor de este atributo debe estar definido dentro del domino.

Las políticas de acceso.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.Fundamentos de las Bases de Datos Distribuidas 18. Bases de Datos Distribuidas 164 . Los controles de acceso por medio de hardware. Las situaciones concernientes al DBMS.Id-cuenta = variable-de-Programa. Para alta de cuenta: Before inserting cuentas from variable-de-programa Not exist (cuentas.saldo >= 0 Else Set retum code to "Saldo insuficiente” Reject. Para una transferencia o retiro After Updati ng cuentas cuentas. La seguridad del sistema operativo.     La existencia de controles de seguridad físicos. 19. Ejercicios de repaso 1.ld-cuenta) Else Set retum code to " El Id de la cuenta ya existe” Reject.

3. p = 5.Fundamentos de las Bases de Datos Distribuidas Para el borrado de una cuenta: After deleting cuentas from variable-de-programa Not exist (Movimientos where movimiento.1) * (7 -1) = 24 e = 11 (d * 11) modulo 24 = 1 d=11 Encriptación C1 = (8)11 módulo 35 = 22 C2 = (9)11 módulo 35 = 4 Desencriptación Bases de Datos Distribuidas 165 .ld-cuenta variable-de-Programa.Id-cuenta = variable-de-Programa.id_Cuenta.ld-cuenta) Else Delete from movimientos where movimientos. q = 7 r = 5 * 7 = 35 (5 .

Fundamentos de las Bases de Datos Distribuidas 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. permitiendo así una rápida asimilación de los temas y conceptos que en esta obra se tratan. y se logro obtener un texto que puede ser utilizado por el maestro como apoyo. 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. Bases de Datos Distribuidas 166 . y por el alumno como libro de texto.

Sign up to vote on this title
UsefulNot useful