P. 1
Bases de Datos Distribuidas

Bases de Datos Distribuidas

5.0

|Views: 4.270|Likes:
Publicado porJavi Sanchez

More info:

Published by: Javi Sanchez on Feb 08, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

08/20/2013

pdf

text

original

Sections

  • datos centralizadas
  • 1.3 Los doce objetivos de una base de datos distribuidas
  • 1.4.3 Ventajas de la arquitectura cliente/servidor
  • 1.4.4 Desventajas de la arquitectura cliente/servidor
  • 1.4.5 Características del cliente
  • 2.2.9 Criterios generales para la distribución de fragmentos
  • 2.3 Procesamiento de consultas distribuidas
  • 2.3.1 Árbol de operadores de una consulta
  • 2.3.2 Ejemplos de consultas distribuidas
  • 3.1 Importancia de la optimización de consultas
  • 3.3 Métodos de ejecución de JOIN
  • 3.3.6 Tree - way join
  • 3.3.8 Join paralelo
  • 3.6 Preguntas de repaso
  • 4.1 Control de concurrencia
  • 4.1.1 Seriabilidad en bases de datos centralizadas
  • 4.1.2 Seriabilidad en una base de datos distribuida
  • 4.1.3 Control de concurrencia basado en bloqueos centralizados
  • 4.14 Control de concurrencia basado en bloqueos distribuidos
  • 4.1.6 Etiquetas de tiempo en una base de datos distribuida
  • 4.1.7 Deadlocks distribuidos
  • 4.2 Recuperación
  • 4.2.1 Transacciones
  • 4.2.2 Manejo de mensajes
  • 4.2.3 Estructura general de los registros de bitácora
  • 4.2.4 Tipos de fallas
  • 4.2.6 Bitácora en línea
  • 4.2.7 Transacciones grandes
  • 4.3 Integridad
  • 4.4 Seguridad
  • 4.4.1 Identificación y autentificación
  • 4.4.3 Encriptación de datos
  • 4.4.4 Encriptación por sustitución
  • 4.4.5 Encriptación de llave publica
  • 4.6 Preguntas de repaso
  • Bibliografía
  • Respuestas a preguntas y ejercicios de repaso

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bases de Datos Distribuidas 24 . Existe un principio fundamental en los sistemas distribuidos. Hay además de este. se logra un alto grado de contabilidad y disponibilidad. 12 reglas para los sistemas distribuidos: Autonomía local: Significa que todas las operaciones en un sitio se controlan en ese sitio. Confiabilidad y disponibilidad: Por medio de la repica de datos. Independencia con respecto a la localización: Los usuarios nunca sabrán la localización real de los datos. un sistema distribuido deberá ser idéntico a un sistema no distribuido. el cual es aplicable a las bases de datos distribuidas: Desde el punto de vista del usuario.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. 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. Reducción de la sobrecarga de la comunicación: En una base de datos distribuida geográficamente. Desarrollo incrementar: Es posible agregar una nueva unidad en una base de datos distribuida si afectar a las ya existentes. se vería reducida la sobrecarga de las comunicaciones en comparación con una base de datos no distribuida.

la computadora que solicita el recurso pasa a Bases de Datos Distribuidas 25 . Procesamiento distribuido de consulta: En una consulta. El modelo de procesamiento cliente/servidor surgió del concepto de procesamiento compartido de las redes de área local. 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. la cual involucro a más de un sitio. Independencia con respecto al sistema operativo: Deberá de ser capaz de trabajar en cualquier sistema operativo. El paradigma que dispone que una aplicación debe esperar pasivamente a que otra aplicación inicie la comunicación. Independencia de replica: Un sistema deberá comportarse como si solo e)dstiera una sola copia de los datos. siempre habrá varias maneras de trasladar en la información para satisfacer la petición y encontrar la estrategia más eficiente. las computadoras personales conectadas a un sistema pueden compartir recursos. Independencia con respecto a la red: Deberá de ser capaz de trabajar en diferentes redes.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. tiene el nombre de interacción cliente/servidor. Independencia con respecto al DBMS: Varios DBMS deberán trabajar en conjunto y procesar las transacciones. Así.

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

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

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

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

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

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. 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 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 .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. así como cada uno de los tipos de fragmentación existentes y las operaciones necesarias para realizarla.

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

Fundamentos de las Bases de Datos Distribuidas 2. también. de caídas del sistema o de daños físicos en alguna de las copias. Distribución de la carga del trabajo. Una manera simple de ejemplificar 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. 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. usando cualquier otra copia disponible. incremento la simplicidad en el control de la ejecución de la aplicación. La distribución de la carga del trabajo en los sitios es una característica importante de los sistemas distribuidos. La Confiabilidad se logra por medio del almacenamiento de múltiples copias de la información permitiendo recuperarla. y para Bases de Datos Distribuidas 33 . 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 vez que los sitios de origen de las aplicaciones conocen la localización local y remota de los datos. sino que además. 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.1 Objetivos del diseño de los datos distribuidos En el diseño de los datos distribuidos. es considerar dos tipos de referencias a los datos: referencias "locales" y referencias "remotas". Claramente.1. cuando la copia que comúnmente era accesada no se encuentra disponible. los siguientes objetivos deberán ser tomados en cuenta: Procesamiento local. el sistema puede conmutar a una copia alternativa. Disponibilidad y confiabilidad de los datos distribuidos. La distribución de los datos aumenta el procesamiento local. La ventaja del procesamiento local completo no solamente reduce los accesos remotos. Se deberá. la referencia depende únicamente de la distribución de los mismos.

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

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

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

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} . 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.. M7 = {~SF ^ LA ^ ~SD} M8 = {~SF ^ ~LA ^ SD} Eliminando los miniterminos contradictorios se obtiene el siguiente resultado..

"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. 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. si los únicos valores posibles para el atributo Cveciudad fueran "SF". nombre. 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. de otro modo no se sabría a que fragmento corresponden las tuplas que contengan otro valor. 38 Bases de Datos Distribuidas . nombre.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.

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. cveProducto.2. por medio de la operación de unión.Fundamentos de las Bases de Datos Distribuidas La reconstrucción de la Tabla global Proveedor se logra fácilmente. Considérese el siguiente ejemplo: Pedido(pclave. 2. pero se deriva de la fragmentación horizontal de otra tabla. 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. 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. No obstante que cveciudad no es un atributo de la Bases de Datos Distribuidas 39 .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.

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

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 . nombre y departamento de los empleados con salado mayor a 10. 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. Nom. lmp. los fragmentos son obtenidos al proyectar la tabla global sobre cada grupo.Fundamentos de las Bases de Datos Distribuidas 2. es posible reconstruir la tabla original por medio de uniones de todos los fragmentos a la vez. Sal. por otra parte. Considérese el siguiente ejemplo: Emp(Cvemp. 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.6 Fragmentación vertical La fragmentación vertical de una tabla global es la subdivisión de sus atributos en grupos.

A2)= (1+2+1)(1) = 4 aff(A1. A1)= (2+1+2)(1) + (1+2+1)(1) = 9 aff(A1. depto From empleados q2= Select cvemp. imp From empleados Where depto = X q3= Select cvemp.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. nom. A5)= (2+1+2)(1) + (1+2+1)(1) = 9 aff(A2. A1)= (1 +2+ 1)(1) = 4 aff(A2. de acuerdo con los atributos accesados en cada una de las aplicaciones. depto From empleados Where sal > 10000 Con esto se podrá obtener la matriz de uso. A2)= (2+3+2)(1) + (1+2+ 1)(1) = 11 Bases de Datos Distribuidas 42 . sal.Fundamentos de las Bases de Datos Distribuidas Las aplicaciones se traducirían de la manera siguiente: q1= Select nom. colocando en cada casilla un 1 si el atributo A¡ es reverenciado en la aplicación q j. A4)= (2 +1+2)(1) = 5 aff(A1. en la cual se colocara. A3)= (2+1+2)(1) + (1+2+1)(1) = 9 aff(A1. la cual se obtiene por medio de la siguiente formula aff(Ai. 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) Depto Emp o en otro caso Emp1= { A1. A4. A3. A3} Emp2= { A1. Nom) Emp2(Cvemp. Emp1(Cvemp. A5} Bases de Datos Distribuidas 43 . A5) Emp1 = PJcvemp. Nom. A2. A3)= (1+2+1)(1) = 4 aff(A2. A2. lmp. A5} Emp1 { A1. esto. Imp.Fundamentos de las Bases de Datos Distribuidas aff(A2. 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. Sal. será necesario reordenar dichas columnas para logrado. Emp Emp2 = PJCemp. Emp= {A1. El paso restante será seleccionar los campos necesarios para cada fragmento. Sal. A2). Emp2= { A1. A4)= 0 aff(A2. de acuerdo al orden en que las columnas se encuentran en la tabla. A3. de no ser así. A4. A4.

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

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

imp.cvemp) inner join Emp1 B On La fragmentación mixta se representa generalmente por medio de un árbol de fragmentación. Depto30) JNCvemp = Cvemp PJCvemp. En el árbol de fragmentación. 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. resultantes de las operaciones. y los nodos intermedios corresponden a los fragmentos intermedios. las hojas corresponden a los fragmentos. Depto20.cvemp=B. la raíz corresponde a la tabla global.Fundamentos de las Bases de Datos Distribuidas Emp = UN(Depto10. nom. Sal. Imp Emp1 Reconstruccion Horizontal Create View ReconstruccionHorizontal As Select * from Depto10 Union All Select * from Depto20 Union All Select * From Depto30 Reconstruccion Vertical Create View ReconstruccionVertical as Select A. depto From ReconstruccionHorizontal A (A.

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

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

L. Esto daría como resultado los siguientes tres fragmentos horizontales: Alumnos1 = SLespecialidad = “derecho” Alumnos No-control D12 D90 D73 nombre Pedro H. 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. ciudad. A. Roció S. domicilio. nombre. 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. 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. Mateos 234 Bases de Datos Distribuidas 51 .Fundamentos de las Bases de Datos Distribuidas Q: Seleccionar el número de control. especialidad para los alumnos de cada área. Mario V. Adriana A. Sandra F. “contaduría” Alumnos domicilio Revolución 987 A. edad. L.

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

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

y en él se realizan todas las operaciones. y la proyección. 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. NOMBRE. 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. Bases de Datos Distribuidas 54 . 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. 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. se realizarían en el sitio que lanzó la consulta. así como la unión.Fundamentos de las Bases de Datos Distribuidas PJNO CONTROL. 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. 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 transmisión se reduce considerablemente al transmitir únicamente los datos del fragmento que cumplen con la condición del select. por lo general es el sitio que lanzó la consulta. En el caso del segundo árbol. ciudad y edad). ya que el select se realizaría de manera local en cada uno de los sitios. Considérese ahora otro árbol de operaciones. sino en el costo de la ejecución de las mismas.

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

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

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

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. y la reconstrucción se realizaría aplicando las operaciones respectivas en orden inverso de acuerdo a la fragmentación. 3. 2. 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 . por las siguientes razones: 1. es necesario analizar la forma en como se distribuirán dichos fragmentos. 2. y seria difícil procesar la solución del problema al involucrar demasiadas variables. porque: 1.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. pero este enfoque no es conveniente. pero se deriva de la fragmentación de otra relación. El tercer tipo de fragmentación es la mixta. La fragmentación vertical de una relación global es la subdivisión de sus atributos en grupos. esta es obtenida por medio de operaciones de fragmentación realizadas de manera recursiva. la fragmentación se obtiene al proyectar la relación global sobre cada grupo. complejidad en el diseño. Los fragmentos no son modelados propiamente como archivos individuales. Después de que se a realizado la fragmentación de los datos. Habría más fragmentos que relaciones globales. 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. la manera más fácil de realizar esta operación seria considerar cada fragmento como archivos separados. 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.

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

50 3. 115 A5 Ciudad Celaya A6 Sem 3 A7 Esp Química A8 Prom 85. q2: Obtener el número y nombre de los clientes por estado. q3: Obtener el nombre de los clientes por empresa.7 Bases de Datos Distribuidas 60 .50 3.20 1.- Fragmentar verticalmente la siguiente tabla A1 No_al AL1 A2 Nom_al Aguilar A3 Edad 19 A4 Dir Rev. Obtener el número y nombre de los clientes del estado de Jalisco. 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.- Fragmentar horizontalmente la siguiente base de datos. si las aplicaciones son las siguientes: q1: Obtener los nombres de todos los clientes. 3. realizar una fragmentación vertical.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.Usando la tabla de dientes. Matriz de accesos S1 q1 q2 q3 3 2 1 S2 2 1 1 4.Fundamentos de las Bases de Datos Distribuidas C04 C05 C06 Mejía Herrera Cervantes Lara Lara Gamesa Jal Gto Qro 2. Obtener el estado de los clientes cuyo nombre sea Ávila.10 15.20 3.

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

Además se tratara el concepto de Bases de Datos Distribuidas 62 . 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.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.

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

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

pero definidas por dos secuencias de operadores diferentes. las cuales arrojan el mismo resultado. Transformaciones equivalentes por álgebra relacional Bases de Datos Distribuidas 65 . depto Emp Nom Juan Pérez Carmen Campos Depto 15 15 Son dos expresiones equivalentes.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. depto SL depto=15 Emp Nom Juan Pérez Carmen Campos Depto 15 15 y SL depto = 15 PJ Nom.

Fundamentos de las Bases de Datos Distribuidas Dos relaciones son equivalentes cuando sus tuplas representan el mismo mapeo de los atributos a los valores. es decir expresiones de dos o tres operadores relacionases. Estas transformaciones son clasificadas en categorías de acuerdo a las operaciones que involucro. 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 . R y S relaciones. Considérense dos expresiones E 1 y E2 de álgebra relacional. Se podrán obtener transformaciones equivalentes sistemáticamente más pequeñas. 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.

las cuales utilizan las mismas operaciones y operandos. Considérese las siguientes tablas de una base de datos: Bases de Datos Distribuidas 67 . Una forma de reconocer la existencia de dichas expresiones.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. consiste en transformar la consulta en su correspondiente árbol de operadores. esto es importante.2 Determinación de subexpresiones comunes Una parte importante en la transformación de expresiones equivalentes es el descubrir las subexpresiones comunes. De esta manera es posible localizar las subexpresiónes iguales. En el siguiente ejemplo se ilustrara este método. R) DF (SLF2 R) <-> SL F1 AND NOT P2 R 3. ya que de esta manera solo se evaluara una sola vez dicha expresión.2. las cuales aparecen en más de una vez en la consulta. enseguida se unen tanto los nodos y las hojas en una sola hoja o nodo.

000.Fundamentos de las Bases de Datos Distribuidas EMP(id-emp. edad) DEPT(deptnum.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. Bases de Datos Distribuidas 68 . nom. 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. el select es desplazado hacia arriba). 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. expresión para dicha consulta seria: Una PJEMP. sal.

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. uniendo las hojas correspondientes a las relaciones de EMP y DEPT. el nodo correspondiente al join y finalmente.

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

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

se leerá la relación cliente por cada bloque de la relación deposito.3. Para ejecutar un merge-join. De esta manera. Los Bases de Datos Distribuidas 72 . Se podrá entonces realizar una operación merge-join. Claramente se puede ver un significativo ahorro en el número de accesos necesarios en comparación con la técnica anterior.Join En aquellos casos en los cuales ninguna relación se encuentra en la memoria principal. están ordenados por nombre-cliente. Entonces. Sin embargo. 3. el costo en términos de bloques accesados es de 5500 accesos (5000 accesos a clientes más 500 accesos a dep¿>sitos). en lugar de realizar una lectura a la relación cliente por cada tupla de la relación deposito.de la relación deposito y 10 bloques de la relación diente. Este procedimiento desarrolla el join considerando un bloque entero de tuplas de la relación deposito en vez de una tupla individual.3 Merge .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.Aún. se requiere de un punto de asociación en cada relación. requieren 10*500= 5000 bloques accesados. Estos puntos son direccionados a la primera tupla de cada relación. se tienen 500 bloques. se leerá completa la relación deposito a un costo de 500 accesos. Supóngase que ambas relaciones.c) para ver sí una tupla puede ser tomada para el resultado end end end end. 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. clientes y depósitos.

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

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

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

Fundamentos de las Bases de Datos Distribuidas for each tupla d in deposito do begin i := h(d[nombre-cliente]). rd := rd u {d}. rc:= rc u {c ç. rd:= 0. 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 Bases de Datos Distribuidas 76 . for each apuntador pc in Hci do begin c:= tupla a la cual apunta pc. end for i := 0 to max do begin rc:= 0. Hdi := Hdi @ {apuntador a d}. end for each apuntador pd in Hdi do begin d:= tupla a la cual apunta pd.

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

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

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

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

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

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

end else /* t proviene de P2 */ begin from2 := from2  {t}. result := 0 . while not donel or not done2 do begin if la cola esta vacía then esperar hasta que no este vacía. result := result  (from1 JN {t}). Bases de Datos Distribuidas 83 .Fundamentos de las Bases de Datos Distribuidas P2 respectivamente. Para ejemplo se utilizo un 4-way join pero pude extenderse para procesar N-way join.4 Principios de optimización Se pueden identificar cuatro pasos generales para el proceso de optimización de una consulta. 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}. end end 3. from1:= 0. done2:= falso. done1:= falso. result:= result  ({t} JN from2). from2:= 0.

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

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

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

tanto en ambientes centralizados como distribuidos. Bases de Datos Distribuidas 87 . el costo de la transmisión de datos entre los sitios participantes de la consulta. La selección de estrategias alternativas para la ejecución de las consultas.Fundamentos de las Bases de Datos Distribuidas 3. 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. la eficiencia del sistema final depende mucho de la calidad del optimizador de consultas. es hecha de acuerdo al desempeño requerido.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.

Determinar el número de copias de los fragmentos sobre los cuales se ejecutara la consulta. Es posible obtener expresiones equivalentes pequeñas aplicando ciertas propiedades de operadores y conjuntos de operadores. Dos expresiones son equivalentes cuando sus tuplas representan el mismo mapeo de los atributos a los valores. R y S relaciones. 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. La equivalencia de dos expresiones se representa por El ↔ E2. y desde este punto de vista dos expresiones con la misma semántica se pueden expresar por medio de dos secuencias de operadores diferente. sino también por medio de una secuencia de operadores. 3. aun cuando el orden de los atributos no sea el mismo.Fundamentos de las Bases de Datos Distribuidas La selección de una estrategia de procesamiento de consultas involucro: 1. Seleccionar el orden de ejecución de las operaciones. obteniendo una expresión de consulta sobre fragmentos. esto conlleva a decir que estas dos expresiones son equivalentes. 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. unitaria y binaria respectivamente.

Una manera de reconocer la existencia de dichas expresiones. que en este caso serían ramas similares. dado que. las cuales se convertirán en una sola rama. consiste en transformar la consulta en su correspondiente árbol de operadores. 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. 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.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. ahorrando así. tiempo. las cuales podrían aparecer más de una vez en la consulta. Algo que también se debe de considerar es el costo de procesamiento de las operaciones join. Bases de Datos Distribuidas 89 . de esta manera es posible localizar las subexpresiones iguales. esto es importante.

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

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

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

¿Que métodos de ejecución de join existen? Explique brevemente el funcionamiento de la estrategia de join paralelo. por lo tanto de deben de utilizar las estrategias que minimicen este costo en lo posible. Explique brevemente los pasos para el proceso de optimización de una consulta.5.000.6 Preguntas de repaso 1.¿Cuales son los tres puntos que se deben tomar en cuanta en la optimización de una consulta? 2. se utilizaran las tablas EMP y DEPT del ejemplo de la sección 3.8.- Dibuje el árbol de operadores de la consulta.2. 3. l.¿Mencione que se debe de considerar para seleccionar una estrategia de procesamiento de consultas? 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.7. 3.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..7 Ejercicios Para los siguientes ejercicios.¿Que condición deben cumplir dos expresiones para que sean consideradas equivalentes? 4...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. Bases de Datos Distribuidas 93 .

Repñnted Juiy.. 1990 [3] Date. U. Volume li.- Obtenga las subexpresiones comunes que contenga la consulta. Internacional Edition.J. C. Bibliografia [1] Ceri.A.. "An Introduction lo Databases Systems". 3.. C. Reprinted July.. 4.A. U. Addison-Wesley Publishing Company. Volume 1.J. 1985 [2) Date.S. Giuseppe. McGraw-Hill.A. Pelaggati. 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 . Addison-Wesley Publishing Company-. U.- Considérese que las tablas de EMP y DEPT se encuentran en diferentes sitios.S.- Dibuje el árbol de operadores optimizado de la consulta. "An lntroduction lo Databases Systems". Fifth Edition. "Distributed Databases Principies and systems'.S.. Dibuje el árbol de operadores más recomendable para este caso. Stefano.Fundamentos de las Bases de Datos Distribuidas 2.

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

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

W j (X) ] son pares de operaciones en conflicto mientras que [ Ri(x). W j(y) ]. 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. [ Rj (x). Rj(x) W i(x). La operación de escritura final es igual en ambas planificaciones. Usando este concepto es posible obtener una definición de planificación equivalente de otra manera: Bases de Datos Distribuidas 97 . que el resultado obtenido por esta sea equivalente al resultado de una planificación serial. y [ W i(x). W j (x) ] y [ W i (X). esto es. 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. Por ejemplo. Estas dos condiciones son suficientes ya que ambas transacciones leen y escriben los mismos datos. 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. 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. Es importante también considerar el hecho de que dos operaciones pueden llegar a caer en conflicto: Dos operaciones están en conflicto si.Fundamentos de las Bases de Datos Distribuidas Una planificación es correcta si esta es seriabilizable. 2. ya que fuerza a otras transacciones a esperar hasta que esta termine de realizar las operaciones sobre los datos. Rj(y) ] son pares que no se encuentran en conflicto. Un ejemplo es el bloqueo de registros. Teniendo el concepto de seriabilidad.

T2. 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 . la seriabilidad local no es suficiente para asegurar la exactitud de la ejecución de un conjunto de transacciones distribuidas. S2.2 Seriabilidad en una base de datos distribuida En una base de datos distribuida. cada transacción ejecuta operaciones en varios sitios.. Sm..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. donde Oi < Oj en S1. Sin embargo.. Por ejemplo.. Si se aplica en cada sitio un mecanismo de control de concurrencia se aseguraría que todas las planificaciones locales son serializables.1. .. 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. Tn en m sitios es modelado por un conjunto de entradas de bitácora Sl. entonces Oi deberá preceder a Oj en S2. Una ejecución de n transacciones distribuidas T 1. La secuencia de operaciones procesada por las transacciones en un sitio es una planificación local.. .

. Cada entrada local Sk es serializable. .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.. . Para generalizar.. Tn es correcta si: 1. . Bases de Datos Distribuidas 99 .. Sn si y solo si Ti precede Ti en el orden total. modelado por el conjunto de planificaciones S1. y además para cada par de operaciones en conflicto Oi y Oj de las transacciones Ti y Tj respectivamente... La anterior definición puede ser explicada usando la definición de conflicto: Sea T1.. Sm E es correcto (serializable) si existe un orden total de las transacciones. para cada sitio k donde ambas transacciones tienen algún proceso en ejecución.. la seriabilidad de transacciones distribuidas. La ejecución de las transacciones T1.. si Ti < Tj en el orden total. es necesaria una condición más fuerte que la señabilidad local. Tn un conjunto de transacciones. 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). Tn tal que... .... Sk es equivalente a Sk‟ y Ti < Tj en el Serial(Sk‟). 2.. Existe un orden total de T1. sin embargo. y sea E una ejecución de estas transacciones. entonces hay una planificación serial S k‟ tal que. Oi precede a Oj en cualquier entrada S1..

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

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

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

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

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

aunque Ti no Bases de Datos Distribuidas 105 . lee Y. Un bloqueo de 2 fases asegura la ejecución serializable de estas transacciones. Tj inicia leyendo x. y habría un orden total en el que Ti < Tj o Tj < Ti. 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). Supóngase que ambas transacciones son activadas de manera simultánea. se podrá considerar cualquiera de los dos casos. Para ejemplo considérese Ti < Tj. en la ejecución concurrente de transacciones. decrementa su valor. incremento su valor.Dado que existe una simetría. el hecho de que la operación Ri(y) aparezca abajo de Rj(x) significa que estas dos operaciones inician al mismo tiempo. y escribe su nuevo valor. Para lograr un análisis del grado de concurrencia que es permitido por el algoritmo de control de concurrencia. e inmediatamente Tj tiene que escribir x. es necesario incluir en el modelo de ejecución la noción de "operaciones concurrentes" en diferentes sitios. escribe el nuevo valor.Fundamentos de las Bases de Datos Distribuidas R2(Y) W2(Y) R2(Y) W2(Y) Se asume que cada transacción lee X. Por lo tanto. 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.

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

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

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

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

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

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

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. el sistema automáticamente genera un rollback (implícito) y esto provoca que el DC Manager descarte los mensajes de la cola de salida.Fundamentos de las Bases de Datos Distribuidas entrada de la cola de correspondiente. id. etc. 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 .)  Comandos (Begin transaction. transacción. equipo. fecha y hora. 4. Si la transacción falla.2. usuario.3  Estructura general de los registros de bitácora Registro de control  Identificadores (id.

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. baja. deposito y retiro.

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

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

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

Se puede eliminar la parte UNDO de cada registro que representa una actualización sobre la base de datos. fecha. pues se hace un barrido y se rehacen todas. Se eliminan los apuntadores al registro anterior y registro siguiente.2. cuya actualización representan los registros de la bitácora. Se pueden eliminar tanto los mensajes de entrada como los de salida. etc. Así. el del usuario. se pierde.Fundamentos de las Bases de Datos Distribuidas 1. 2. las transacciones que en el 119 Bases de Datos Distribuidas . 3. 3. 5. transacción por transacción. Considerando la bitácora de la sección 4. 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. 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. 6. se pueden eliminar los registros de las transacciones que terminaron con rollback. 2. pero la base de datos no sufre daño alguno. 7. debido a que no es necesario hacer la recuperación. (identificador de transacción no es lo mismo que tipo de transacción). Se pueden eliminar los registros de control. la cual después de la compresión. hora. en particular el contenido de todo los buffers de entrada/salida (I/O). 4. 4. 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. Se puede eliminar el identificador de la transacción.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 puede reducir fuertemente la cantidad de búsqueda. en la base de datos almacenada físicamente. 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. 4. si es que estas no habían terminado. se deberán de deshacer. Sin embargo. esto. Esto se puede resolver buscando en la bitácora desde el principio. Pero. pero no un registro de terminación (commit o rollback). introduciendo el principio de punto de verificación (Checkpoint).Fundamentos de las Bases de Datos Distribuidas momento de la falla se estuvieran ejecutando. cada cierto tiempo o número de entradas de bitácora. Esto obligará la escritura de cualquier actualización que aun se encuentre en la memoria principal. Forza la escritura de un registro de check-point en la bitácora. Bases de Datos Distribuidas 120 . El registro de check-point contiene la siguiente información: 1. El principio de check-point es muy simple: A cierto intervalos preestablecidos. 2. que transacciones deshacer. Esto obliga la escritura de cualquier registro de bitácora que aun permanezca en la memoria principal. por ejemplo. Forza la escritura del contenido de los buffers de la base de datos. 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. tal búsqueda podría consumir demasiado tiempo. identificando aquellas transacciones para las cuales hay un registro de inicio de transacción (BT). 3. como podría el manejador de recuperación saber al momento del restablecimiento.

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

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

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

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 .

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

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

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. considerado de manera aislada. para el atributo A de la relación R que se define sobre el dominio D. 4. Las reglas de integridad de dominio conciernen a la admisibilidad de un valor determinado como valor candidato para un atributo determinado. 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. 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. el conjunto de todos los números enteros.3.Fundamentos de las Bases de Datos Distribuidas   Reglas de integridad de dominio. independientemente de su relación con otros valores en la base de datos. La regla de integridad de dominio. La definición del dominio D entonces constituye una importante regla de integridad. 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. la cual deberá verificar en todas las operaciones de inserción y actualización que involucran cualquier atributo definido sobre D. no es otra que. etc. cualquier valor dado como candidato del atributo A debe pertenecer a D.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.). la definición de ese dominio. Reglas de integridad de relación.

Fundamentos de las Bases de Datos Distribuidas 4. si se especifica. La condición de activación. Todos los parámetros mencionados en una condición de activación deben tener el mismo cursor.3. 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. 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 . ya sea explícito o implícito.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. 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.

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

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

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

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

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

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

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

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

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

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

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

Bases de Datos Distribuidas 140 . La secuencia de operaciones procesada por las transacciones en un sitio es una planificación local. Sin embargo. ellas procesan el mismo dato y al menos una de estas operaciones es una operación de escritura. 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. donde O¡ < Oj en S1.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. la seriabilidad local no es suficiente para asegurar la exactitud de la ejecución de un conjunto de transacciones distribuidas. La operación de escritura final es igual en ambas planificaciones. En una base de datos distribuida. Cada operación de lectura lee los mismos valores que fueron producidos por las mismas operaciones de escritura en ambas planificaciones. Las siguientes dos condiciones son suficientes para decir que dos planificaciones son equivalentes: 1. y estas operaciones pertenecen a diferentes transacciones. 2. 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. Es importante también considerar el hecho de que dos operaciones pueden llegar a caer en conflicto: Dos operaciones están en conflicto si. Si se aplica en cada sitio un mecanismo de control de concurrencia se aseguraría que todas las planificaciones locales son serializables. cada transacción ejecuta operaciones en vanos sitios. entonces O¡ deberá preceder a Oj en S2.

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

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

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

Si el evento A consiste en enviar un mensaje y el evento B consiste en recibir el mensaje de A. T1A1 espera que T2A1 libere recursos en el sitio 1. 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. El agente TiAj requiere que el agente TiAs ejecute alguna función en un sitio diferente. entonces A→S. debido a un ciclo de espera involucro varios sitios. entonces A→B. entonces A→C.Fundamentos de las Bases de Datos Distribuidas 1. Este tipo de espera es representado por una flecha discontinuo en la gráfica. 2. Este tipo de espera se representa por una flecha continua en la gráfica. 2. esto. Bases de Datos Distribuidas 144 . Si A y B son dos eventos en el mismo sito y A ocurre antes que B. Si A→B y B→C. 3. La detección de deadlocks es más difícil en un sistema distribuido que un centralizado. La detección y solución de deadlocks constituye una actividad importante de un sistema manejador 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. y puertos de salida si las flechas salen. Algo que se debe de tener en cuenta es que. Se debe incluir algún procedimiento de recuperación. Periódicamente. 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. desde y hacia los nodos los cuales representan a agentes que tienen conexión con el nodo local. 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. Los nodos cuadrados son llamados puertos de entrada si tienen una flecha hacia dentro de la gráfica. esto es. La solución a un deadlock involucro la selección de una o más transacciones que pueden se abortadas y reiniciadas. la redundancia incremento la posibilidad de un deadlock. el cual puede consistir en forma general de lo siguiente: 1. después de que una falla la ha llevado a un estado incorrecto o al menos incierto. abortar la transacción que tiene la menor cantidad de recursos. Otros criterios podrían ser. el abortar la transacción más joven. Si ocurre una falla hay dos posibilidades: Bases de Datos Distribuidas 145 . 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. primero que nada recuperar la propia base de datos. significa. se escribe un registro en un conjunto de datos especial llamado bitácora. La recuperación en un sistema de bases de datos. 2. hacer una copia de respaldo de la base de datos completa. 3. o abortar la transacción que requiere más tiempo para terminar. tal vez diario. Dichas LWFG se extienden con flechas. Un criterio para seleccionar que transacción será abortada. Cada vez que se haga un cambio en la base de datos.

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

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

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

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

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

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

Además de la replicación de la base de datos. una base de datos pueda ser recuperada? 12.20. ¿qué es recomendable hacer? 13.9. transferencia de fondo y para la cancelación de una cuenta (considerando que existe una tabla de movimientos).7 Ejercicios 1.¿Mencione 5 aspectos que se deben tomar en cuenta dentro de la seguridad de las bases de datos? 19.14.Explique brevemente en que consiste el bloqueo de 2 fases.16. ¿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.10.11.¿Que son las reglas de autorización? ¿Que es la encriptación de datos? 4.Fundamentos de las Bases de Datos Distribuidas 5.6. creación de una cuenta. 7.- Para las siguiente tabla defina las reglas de integridad para el retiro de fondos.¿A que se refiere la palabra seguridad dentro del ámbito de las bases de datos? 18.- ¿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..15.¿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. Cuentas Bases de Datos Distribuidas 152 ..8..

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

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

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

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

Obtener los números y nombres de los clientes por estado. Obtener los nombres de los clientes por empresa.- q1: q2: q3: Obtener los nombres de todos los clientes.Fundamentos de las Bases de Datos Distribuidas 3. 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.

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. Empresa} F2={ No el¡. Estado} O F1={ No_cli.- Bases de Datos Distribuidas 160 . Empresa. Seleccionar el método optimo para la ejecución de cada operación. Estado} Capítulo III Preguntas de repaso 2. 6. y obtener una expresión de consulta sobre cada uno de los fragmentos. Nom_cli} F2={No_cli.   Se deberá seleccionar el orden de ejecución del conjunto de consultas sobre cada uno de los sitios.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. 4. Es necesario definir el número de copias físicas de cada uno de los fragmentos que existen en el sistema.

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

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

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

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

p = 5.ld-cuenta) Else Delete from movimientos where movimientos.id_Cuenta.Id-cuenta = variable-de-Programa.ld-cuenta variable-de-Programa. 3.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 .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. q = 7 r = 5 * 7 = 35 (5 .

Es también. Bases de Datos Distribuidas 166 . y se logro obtener un texto que puede ser utilizado por el maestro como apoyo. permitiendo un entendimiento claro del concepto de lo que son las bases de datos distribuidas. permitiendo así una rápida asimilación de los temas y conceptos que en esta obra se tratan. un texto que podría ser utilizado por personas autodidactas con conocimientos de generales de computación y de bases de datos. y por el alumno como libro de texto.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.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->