UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMTICA

MODELOS AVANZADOS DE BASES DE DATOS

BASE DE DATOS DISTRIBUIDAS

Grupo: Distribucin 1

Francisco Corbera Navas

Alejandro Delgado Gallego

Fecha : 01/04/2008

Base de Datos Distribuidas

ndice
Introduccin ... 3
Sistemas gestores de Bases de Datos Distribuidas (SGBDD) ... 5
Tipos de SGBDD ... 5
Los objetivos de un SGBDD ..... 6
Arquitectura cliente-servidor . 8
Diseo de Bases de Datos Distribuidas ..9
Estrategias de Diseo 10
Fragmentacin ...12
Asignacin .13
Transacciones en base de datos distribuidas .14
Control de concurrencia ....15
Serializacin distribuida ....16
Protocolo de bloqueo (locking protocol) ...17
Protocolo de marcas de tiempo (timestamp protocol) ...17
Procesamiento de Consultas Distribuidas . ....17
Objetivos de la optimizacin de consultas .19
Caractersticas de los procesadores de consultas ...20
Arquitectura del procesamiento de consultas .20
Ventajas y desventajas de las Bases de datos Distribuidas 21
Conclusiones ..22
Bibliografa ....22

Base de Datos Distribuidas

Introduccin
Inicialmente podemos decir que las SBDD surgen como respuesta a la distribucin que las
empresas ya tienen, al menos de manera lgica (divisiones, departamentos, etc) y que en
ocasiones tambin tiene de manera fsica (plantas, fbricas, etc). Todo esto nos lleva a que
posiblemente los datos tambin estn distribuidos, ya que cada unidad organizacional
mantendr los datos con los que normalmente opere.

A cada uno de estas subdivisiones se les llama islas de informacin (sitios), y lo que hace
un sistema distribuido es establecer los puentes necesarios para conectar a esas islas entre si.

En definitiva lo que pretende es que la estructura de la base de datos refleje la estructura de

la empresa (principal beneficio de los sistemas distribuidos). Es en realidad una BD virtual
compuesta de varias BDs reales distintas que se encuentran en varios sitios distintos.

Otra de las principales motivaciones para el desarrollo de sistemas de bases de datos es el

deseo de integrar los datos operacionales de una organizacin y proporcionar un acceso
controlado a esos datos. Aunque la integracin y el acceso controlado pueden implicar la
necesidad de utilizar mecanismos de centralizacin, el objetivo en realidad no es ese. De hecho,
el desarrollo de redes informticas promueve el modo descentralizado de trabajo.

Los SGBD distribuidos deberan ayudarnos a resolver el problema de las islas de

informacin. Esto puede ser resultado de la separacin geogrfica, de la incompatibilidad de las
arquitecturas informticas, de los protocolos de comunicaciones, etc. Si se consigue integrar las
bases de datos en un todo lgico coherente, podemos resolver el problema.

Con todo esto podemos dar una definicin ms formal de base de datos distribuida (BDD)
como una coleccin de mltiples bases de datos interrelacionadas lgicamente y distribuidas por
una red de computadores.

Base de Datos Distribuidas

Es importante tener clara la diferencia que existe con el procesamiento distribuido, en el
cual existe una BD centralizada a la que se puede acceder a travs de una
red informtica. En las siguientes figuras podemos ver claramente la diferencia entre ambos:

Base de Datos Distribuida

Procesamiento Distribuido

El Sistema Gestor de Bases de Datos Distribuido (SGBDD) es el sistema software que

permite gestionar la BDD y hace que dicha distribucin sea transparente para los usuarios.

Un SGBDD est compuesto por una nica base de datos lgica dividida en una serie de
fragmentos que pueden estar replicados en diferentes instalaciones. Cada fragmento se almacena
en uno o ms ordenadores bajo el control de un SGBD independiente. Todos estos ordenadores
(instalacin o nodo) del sistema estn conectados entre s mediante una red de comunicaciones.

Clasificaremos las BDD segn dos criterios:

Homogneas o heterogneas dependiendo de si todos los servidores utilizan el
mismo SGBD o no .
De rea local o de rea ancha segn sea la red de comunicaciones que conecta los
servidores.

Por otra parte y con lo que respecta a las implementaciones comerciales, la mayora de los
productos SQL actuales proporcionan algn tipo de soporte de base de datos distribuida, con
diversos grados de funcionalidad.
Ingres/Star.
La opcin de base de datos distribuida de Oracle.
La propiedad de datos distribuidos de DB2.
Informix y SQL Server.

Base de Datos Distribuidas

Vale la pena resear que todos estos sistemas son relacionales, adems hay varias
razones que iremos descubriendo a lo largo de este tema, que aconsejan que para que un sistema
distribuido sea exitoso, debe ser relacional.

Sistemas gestores de Bases de Datos Distribuidas (SGBDD)

Software que hace transparente al usuario la gestin de una base de datos distribuida. En
adelante lo llamaremos SGBDD.

Entre sus funciones particulares destacan:

Poder acceder a sitios remotos.

Transmitir consultas y datos a travs de redes de telecomunicaciones.

Rastrear la pista de distribucin y replicacin de los datos.

Capacidad de elaborar estrategias de ejecucin.

Control de concurrencia.

Mantener la consistencia de las copias de un elemento de informacin.

Capacidad de decidir qu versin de la copia de un elemento de informacin es la que

tiene que ser accedida en un momento determinado.

Recuperacin ante cadas.

Control de la seguridad para mantener privilegios de acceso a los datos distribuidos.

Para ofrecer todas las funcionalidades vistas un SGBDD debe contar (al menos) con los
siguientes componentes:

Componente de manejo de la base de datos.

Componente de comunicacin de datos.

Diccionario de datos

Componente de base de datos distribuida.

Tipos de SGBDD
Hay diferentes tipos de SGBDD. El factor para categorizarlos es su grado de homogeneidad.
Partiendo de l, tenemos dos tipos de SGBDD.

Homogneos: todos los nodos utilizan el mismo SGBD

Heterogneos: los nodos pueden utilizar distintos SGBD.

Base de Datos Distribuidas

Los sistemas homogneos son mucho ms fciles de disear y mantener. Esta tcnica
permite el crecimiento incremental, haciendo que la adicin de un nuevo nodo al SGBDD sea
sencilla, y tambin permite conseguir unas mayores prestaciones, al aprovechar las capacidades
de procesamiento paralelo de los mltiples nodos.

Los objetivos de un SGBDD

Una vez que nos hemos introducido en el mundo de las SBDD, estamos preparados para
establecer el principio fundamental de los sistemas distribuidos:
Los usuarios deben actuar de la misma forma tanto si estn ante un sistema distribuido como
si estn ante uno centralizado.

En 1987, uno de los ms importantes y conocidos tericos de las bases de datos

relacionales, C. J. Date, propuso 12 objetivos que deban alcanzar los diseadores en sus BDD
junto con sus SGBDD basndose en este principio fundamental. Las 12 reglas son las
siguientes:

1. Autonoma local: Los sitios de un sistema distribuido deben ser autnomos en el mayor
grado posible, lo que permite una mayor seguridad, control de concurrencia y copias de
seguridad. Esto quiere decir que los datos deben ser gestionados localmente, las operaciones
son locales y todas las operaciones en un puesto son controladas por ese puesto.

2. Independencia de un sitio central: El anterior objetivo implica que todos los sitios
deben ser tratados como iguales, por lo tanto no debe existir ningn sitio maestro central del
cual dependan el resto. Esto es as por das razones fundamentales:
Puede ser un cuello de botella.
Puede ser vulnerable, si ste falla tambin fallar todo el sistema.
3. El sistema debe estar en continua operacin: Un fallo en uno de los nodos no debe
afectar al sistema. Tampoco si se aaden nuevos nodos. As, un SD deber proporcionar las
siguientes caractersticas.
Fiabilidad (o confiabilidad): probabilidad de que el sistema est listo y
funcionando en cualquier momento dado.
Disponibilidad: probabilidad de que el sistema est listo y funcionando
continuamente a lo largo de un perodo especificado. Podemos decir que nunca

Base de Datos Distribuidas

debera ser necesario apagar el sistema para realizar tareas como: aadir un
sitio, creacin dinmica de fragmentos, actualizacin de versiones, etc.

4. Transparencia de ubicacin: Para el usuario la localizacin fsica de los datos debe ser
transparente. No necesita saber dnde est el dato para utilizarlo.

5. Transparencia de fragmentacin: Los usuarios deben comportarse, como si los datos

en realidad no tuvieran fragmentacin alguna, la cual es necesaria por razones de
rendimiento.
Este objetivo es deseable, como el anterior, porque simplifica los programas de los
usuarios y sus actividades en el sitio.

6. Transparencia en la replicacin: Consiste en que el usuario no debe tener conciencia de

la replicacin de los datos, as como de su destruccin
La replicacin es necesaria por las siguientes razones:
Un mayor rendimiento, puesto que disponemos de copias locales.
Una mayor disponibilidad, puesto que los datos son accesibles siempre al tenerse
varias copias.
La principal desventaja, es que hay que mantener actualizadas todas las copias de ese
objeto o dato replicado. Esto nos lleva al problema de la propagacin de las
actualizaciones.

7. Procesamiento de consultas distribuidas: El sistema debe ser capaz de procesar

consultas que afecten a datos de ms de un sitio y hacerlo de forma optimizada. Este hecho
puede ser considerado como otra razn por la que los sistemas distribuidos siempre son
relacionales (las peticiones relacionales son optimizables, mientras que las no relacionales
no lo son).

8. Administracin de transacciones distribuidas: El sistema distribuido debe disponer de

mecanismos (protocolos) adecuados para el control de concurrencia y la recuperacin de
transacciones distribuidas. Una transaccin puede acceder y modificar datos en diferentes
nodos sin que el usuario se entere de que mltiples sitios se estn viendo afectados por la
transaccin.

9. Independencia del hardware: Es necesario tener la posibilidad de ejecutar el mismo

SGBDD en diferentes plataformas de hardware (IBM, ICL, HP, PC, SUN) y, adems, hacer
que esas mquinas diferentes participen de igual forma en un sistema distribuido.

Base de Datos Distribuidas

10. Independencia del sistema operativo: Un vez ms, es necesario tener la posibilidad de
ejecutar el mismo SGBDD, en diferentes plataformas de sistema operativo (UNIX,
Windows XP ) bajo un mismo sistema distribuido.

11. Independencia de la red: El sistema debe tener la posibilidad de soportar tambin, una
variedad de redes de comunicacin distintas.

12. Independencia del SGBD: Lo que en realidad se pretende es que todos los ejemplares
del SGBDD locales en sitios diferentes soporten la misma interfase, que en este caso sera
el estndar SQL oficial. Con esto conseguiremos que el sistema distribuido fuera
heterogneo, al menos en cierta medida ya que en realidad los fabricantes solo cumplen
determinadas caractersticas de este estndar, que suelen ser distintas de unos a otros.

Debido a que estos cuatro ltimos objetivos son ideales y no existen estndares
al respecto, solo cabe esperar un cumplimiento parcial de los mismos.

Arquitectura cliente-servidor
Las aplicaciones de bases de datos distribuidas se desarrollan en el contexto de la
arquitectura cliente-servidor.

Base de Datos Distribuidas

La arquitectura cliente-servidor se cre para manejar los nuevos entornos de cmputo en los
que un gran nmero de PC, estaciones de trabajos, servidores de ficheros, impresoras,
servidores de bases de datos, servidores Web y otros equipos estn interconectados a travs de
una red.

En un sistema cliente-servidor tenemos dos partes fundamentales:

Cliente. Se podra corresponder con una mquina usuario que proporciona capacidad de
interfaz al usuario y procesamiento local.
Servidor. Es una mquina que puede proporcionar a las mquinas cliente servicios, tales
como impresin, acceso a ficheros, o acceso a la base de datos.
An no se ha establecido de forma exacta cmo dividir la funcionalidad del SGBD entre
el cliente y el servidor aunque existen varios enfoques.

En cuanto al software, en un sistema de gestin de bases de datos es normal dividir los

diferentes mdulos software en tres niveles:

El software de servidor que gestiona los datos locales en un sitio, al igual que el
software del SGBD centralizado.
El software del cliente que soporta casi todas las tareas de distribucin y maneja las
interfaces de usuario
El software de comunicaciones (algunas veces junto con el sistema operativo
distribuido) proporciona las primitivas de comunicacin que utiliza el cliente para
transmitir instrucciones y datos entre los sitios necesarios.

Diseo de Bases de Datos Distribuidas

El diseo de base de datos distribuidas se ocupa de tomar decisiones en la ubicacin de
programas que accedern a la base de datos y sobre los propios datos que la constituyen, a lo
largo de los diferentes nodos que constituyen la red. Tenemos que distribuir pequeos
elementos entre diferentes computadores, es decir, distribuir la informacin.

La organizacin de los sistemas de bases de datos distribuidas se puede analizar desde tres
dimensiones:

Base de Datos Distribuidas

El nivel de comparticin. Esta caracterstica posee tres alternativas dependiendo del
nivel de comparticin:
o

Inexistente. Cada aplicacin y sus datos se ejecutan en una maquina sin

comunicacin con otros programas o datos.

Comparticin de datos. Cada mquina posee sus propias aplicaciones locales

pero se comparte los datos.

Comparticin de datos y programas. Las aplicaciones locales en una

mquina pueden invocar servicios en otras y adems comparten los datos.

Caractersticas de acceso a los datos. Estas caractersticas pueden ser dos:

o

Esttico. El modelo de acceso a los datos no vara con el tiempo.

Dinmico. El modelo de acceso a los datos vara con el tiempo.

El nivel de conocimiento de la caractersticas de acceso:

o

Sin informacin. Los diseadores no tienen informacin de cmo acceden los

usuarios a los datos.

Con informacin parcial. Los diseadores no poseen toda la informacin de

cmo acceden los usuarios a los datos.

Con informacin total. Los diseadores poseen la informacin completa de

cmo los usuarios acceden a los datos.

Estrategias de Diseo
Estas estrategias son las utilizadas al disear una base de datos relacional, pero aadiendo
un paso de diseo de la distribucin.
A la hora de abordar el diseo de una base de datos distribuida podremos optar
principalmente por dos tipos de estrategias: la estrategia ascendente y la estrategia descendente:

La estrategia ascendente (botton-up): En este caso se partira de los esquemas

conceptuales locales y se trabajara para llegar a conseguir el esquema conceptual
global. Despus se pasara al diseo de distribucin. Esta estrategia suele ser utilizada para
integrar varias bases de datos centralizadas existentes.

En la estrategia descendente (top-down) se parte de cero y se avanza en el desarrollo del

trabajo. Los pasos a realizar mediante esta estrategia son los siguientes:

10

Base de Datos Distribuidas

1. Anlisis de requisitos: En esta etapa se determinan los requisitos para obtener tanto los
datos como las necesidades de procesamientos de los usuarios. Igualmente se debern fijar
los requisitos del sistema, los objetivos que debe cumplir en cuanto a rendimiento,
seguridad, disponibilidad y flexibilidad teniendo en cuenta aspectos econmicos. Al
finalizar esta etapa debemos poseer unos objetivos que servirn como entrada para dos
actividades: Diseo conceptual y diseo de vistas.

2. Diseo de vistas: En esta etapa se definirn las interfaces del usuario con el sistema. Se
determinan las aplicaciones que usaran la base de datos as como datos estadsticos o
estimaciones de las mismas sobre frecuencia de acceso de cada aplicacin a cada tabla, que
nos permitir poseer informacin que nos ayudar a optimizar ciertas partes y crear un
diseo conceptual mas eficiente. Al finalizar esta etapa se debera poseer toda la
informacin de acceso y la definicin de los esquemas externos.

3. Diseo conceptual: En esta etapa se suele realizar la integracin de las vistas del usuario.
Como resultado de la ejecucin de estas dos ltimas etapas debemos tener un esquema
conceptual global, informacin de acceso y los esquemas externos que servirn de entrada
para la prxima etapa.

4. Diseo de la distribucin. Esta etapa es representativa en el diseo de BBDD

distribuidas ya que es la etapa que la diferencia del diseo de bases de datos centralizadas.
Consiste obtener diferentes esquemas conceptuales locales a partir del esquema conceptual
global y la informacin de acceso. En este punto debemos considerar dos actividades
importantes:
Fragmentacin: consiste en decidir como dividimos la base de datos y en que partes.
Asignacin: consiste en ubicar los fragmentos que hemos obtenido en los distintos
nodos.

5. Diseo fsico. A partir de los esquemas conceptuales locales y la informacin de acceso

obtenidos en las etapas anteriores se debe obtener el esquema fsico.

6. Monitorizacin y ajustes. Este paso se realiza para llevar un control del proceso y e
intentar reparar lo errores o desviaciones que se produzcan en el proceso.

11

Base de Datos Distribuidas

Fragmentacin
La fragmentacin es el proceso encargado de dividir una relacin en otras subrelaciones de
menor tamao, y su objetivo es encontrar la unidad apropiada de distribucin. Existe una serie
de razones por las que llevar a cabo la fragmentacin:

Utilizacin: En general, las aplicaciones funcionan con vistas que normalmente son
subconjuntos de relaciones. Por tanto, es lgico considerar como unidad de
distribucin a esos subconjuntos de relaciones.

Eficiencia: Los datos se almacenan cerca del lugar en el que son utilizados con mayor
frecuencia. Adems, los datos que las aplicaciones locales no necesitan no se
almacenan en ese nodo.

Paralelismo: La descomposicin de una relacin en fragmentos permite que una

transaccin pueda ser dividida en subconsultas. Cada subconsulta operar sobre el
fragmento adecuado. En definitiva, se aumenta el grado de concurrencia.

Seguridad: Los datos no requeridos por las aplicaciones locales no se almacenan en

ese nodo, por lo que no estn disponibles para los usuarios no autorizados.

Qu unidad de fragmentacin tomar?

El principal problema de la fragmentacin consiste en encontrar una unidad de

fragmentacin. Se podra considerar como unidad de fragmentacin una relacin completa pero
esto no es ptimo debido a cuestiones de eficiencia. Las siguientes afirmaciones nos dan
razones por las que la relacin no es la unidad de fragmentacin ideal:

Las vistas son subconjuntos de varias relaciones, es decir, se forman a partir de trozos
de varias tablas. Ya que cada aplicacin posee sus propias vistas lo mas adecuado ser
conseguir que la mayora de las vistas estn definidas sobre subtablas locales a cada
aplicacin y as logramos un incremento del rendimiento. Luego la mejor unidad de
fragmentacin seria subconjuntos de relaciones.

Al descomponer una relacin en fragmentos, se permite el procesamiento concurrente

de transacciones ya que no se bloquean tablas enteras sino subtablas, por lo que dos
consultas pueden acceder a la misma tabla en fragmentos distintos.

Al descomponer una relacin en fragmentos, se permite la paralelizacin de consultas al

poder descomponerlas en subconsultas, cada una de las cuales trabajar con un
fragmento distinto producindose un incremento del rendimiento.

12

Base de Datos Distribuidas

Inconvenientes de la fragmentacin:

Si las aplicaciones tienen requisitos que necesiten la descomposicin de la relacin en

fragmentos mutuamente exclusivos, estas aplicaciones cuyas vistas estn definidas
sobre ms de un fragmento pueden poseer menor rendimiento.

Si una vista de usuario no se puede definir sobre un solo fragmento necesitarn un

control semntico que dificulta y degrada el rendimiento debido a que la verificacin de
las restricciones de integridad implican buscar fragmentos en mltiples localizaciones.

Tipos de fragmentacin:

Fragmentacin horizontal. Consiste en el particionamiento en tuplas de una relacin

global en subconjuntos, donde cada subconjunto puede contener datos que cumplen una
condicin y se puede definir expresando cada fragmento como una operacin de seleccin
sobre la relacin global.
Fragmentacin vertical. En este tipo de fragmentacin se dividen el conjunto de atributos en
grupos. Los fragmentos se obtienen proyectando la relacin global sobre cada grupo. La
fragmentacin es correcta si cada atributo se mapea en al menos un atributo del fragmento.
Fragmentacin mixta. Este tipo de fragmentacin consiste en la aplicacin de
fragmentacin vertical y despus fragmentacin horizontal o viceversa.

Asignacin
Supongamos que tenemos un conjunto de fragmentos F={F1, F2, , Fn} y una red que
consiste en este conjunto de sitios S={S1, S2, , Sm}. El problema de asignacin determina la
distribucin ptima de F en S. La optimalidad puede ser definida de acuerdo a dos medidas:

1. Coste mnimo. Consiste en el coste de la comunicacin de datos, coste del

almacenamiento y el coste de procesamiento. Nuestro objetivo es encontrar una funcin
que minimiza el coste.

2. Rendimiento. La estrategia de asignacin se disea para mantener una mtrica de

rendimiento. Las dos mtricas ms utilizadas son el tiempo de respuesta y el
throughput (productividad).

13

Base de Datos Distribuidas

Cuando una serie de datos se asignan, estos pueden replicarse para mantener una copia o
varias idnticas. Por tanto, respecto a la replicacin, en la asignacin de fragmentos existen tres
estrategias:

No soportar replicacin. Cada fragmento reside en un solo sitio.

Soportar replicacin completa. Cada fragmento reside en cada uno de los sitios.
Soportar replicacin parcial. Cada fragmento reside en alguno de los sitios.

Se considera de gran utilidad la replicacin cuando el nmero de consultas de solo

lectura es bastante mayor que el nmero de consultas de actualizaciones.

Transacciones en base de datos distribuidas

La pregunta es qu pasa cuando dos consultas tratan de actualizar el mismo elemento de
datos o si el sistema falla durante la ejecucin de una consulta. Intuitivamente se puede pensar
que el concepto principal que debe manejar la base de datos es la de ejecucin consistente de
consultas. Por eso es que se introduce el concepto de una transaccin que es usado dentro del
dominio de la base de datos como una unidad bsica de cmputo consistente y confiable.

Lo que se persigue con el manejo de transacciones es por un lado tener una

transparencia adecuada de las acciones concurrentes a una base de datos y por otro lado tener
una transparencia adecuada en el manejo de las fallas que se pueden presentar en una base de
datos. Las propiedades de una transaccin son las siguientes:

1.-Atomicidad. Se refiere al hecho de que una transaccin se trata como una unidad de
operacin. Por lo tanto, o todas las acciones de la transaccin se realizan o ninguna de ellas
se lleva a cabo.
2.-Consistencia. La consistencia de una transaccin es simplemente su correctitud. En otras
palabras, una transaccin es un programa correcto que lleva la base de datos de un estado
consistente a otro con la misma caracterstica.
3.-Aislamiento. Una transaccin en ejecucin no puede revelar sus resultados a otras
transacciones concurrentes antes de su commit. Ms an, si varias transacciones se ejecutan
concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado de
manera secuencial (seriabilidad).

14

Base de Datos Distribuidas

4.-Durabilidad. Es la propiedad de las transacciones que asegura que una vez que una
transaccin hace su commit, sus resultados son permanentes y no pueden ser borrados de la
base de datos.

En resumen, las transacciones proporcionan una ejecucin atmica y confiable en

presencia de fallas, una ejecucin correcta en presencia de accesos de usuario mltiples y un
manejo correcto de rplicas (en el caso de que se soporten).

En un SBDD puede que participen varias localidades en la ejecucin de una transaccin

por lo que es ms difcil garantizar la propiedad de atomicidad. El fallo de una de estas
localidades o el fallo de la lnea de comunicacin entre ellas pueden llevar a un resultado
errneo. Es por esto que existe el gestor de transacciones cuya funcin es asegurar la ejecucin
atmica de las transacciones gestionando la ejecucin de aquellas transacciones(locales o
globales) que acceden a datos almacenados en su localidad y el coordinador de transacciones
que es el encargado de coordinar la ejecucin de varias transacciones(locales o globales)
iniciadas en su localidad.

A ms bajo nivel nos encontramos con la necesidad de transferir los datos entre el
almacenamiento en disco y la memoria principal. De esto se encarga el gestor de bferes.
En un SGBDD, todos estos mdulos se encuentran tanto a nivel local en cada equipo como
a nivel de nodo. Estos ltimos son los denominados gestores globales de transacciones.
El procedimiento a seguir cuando se ejecuta una transaccin global en un nodo N1 es la
siguiente:
o

El gestor global de transacciones del nodo N1, divide la transaccin en una secuencia de
subtransacciones, siguiendo la informacin guardada en el catlogo global del sistema.

El encargado de la comunicacin de datos del nodo N1 enva dichas subtransacciones a

los nodos adecuados, por ejemplo N2 y N3.

Los gestores globales de transacciones del los nodos que reciben los datos, se encargan
de gestionarlos y los resultados de las secuencias de instrucciones SQL se devuelven a
travs del encargado de la comunicacin de datos al primer nodo N1.

15

Base de Datos Distribuidas

Control de concurrencia
Todos los mecanismos de control de concurrencia deben asegurar la consistencia de los
objetos y cada transaccin atmica ser completada en un tiempo finito.
Un mtodo de control de concurrencia es correcto si es serializable, es decir existe una
secuencia equivalente en que las operaciones de cada transaccin aparecen antes o despus de
otra transaccin pero no entremezcladas. Una ejecucin serial de transacciones es siempre
correcta.
Se debe sincronizar las transacciones concurrentes de los usuarios, extendiendo los
argumentos para la serializabilidad y los algoritmos de control de concurrencia para la ejecucin
en ambientes distribuidos.
La finalidad del control de concurrencia es asegurar la consistencia de los datos al
ejecutar transacciones, y que cada accin atmica sea completada en un tiempo finito.

Uno de los problemas de concurrencia especficos de las bases de datos distribuidas es la

consistencia de copia mltiple (se produce cuando un mismo dato esta en varias
localizaciones). Adems se siguen dando los mismos problemas para bases de datos
centralizadas (prdida de actualizaciones, dependencia neutral (uncommitted dependency) y
anlisis inconsistentes).

Serializacin distribuida
Si cada planificador de ejecucin local es serializable y las rdenes locales serializadas
son idnticas (es decir, respetan el orden de secuencia), entonces el planificador global es
serializable.

Hay dos soluciones para el control de concurrencia en un ambiente distribuido:

El bloqueo (lock) garantiza la ejecucin concurrente. En este caso hay que tener
cuidado de que no se produzcan interbloqueos.
Las marcas de tiempo garantizan la ejecucin concurrente segn el orden fijado en
las marcas de tiempo. Este asegura la serializacin global. Si solo hay una copia de
cada dato entre todos los nodos, se pueden usar mecanismos de control de
concurrencia para sistemas centralizados, aunque con modificaciones.

16

Base de Datos Distribuidas

Protocolo de bloqueo (locking protocol)
Nos fijaremos en el Protocolo de Bloqueo de Dos Fases distribuido (2PLP)
Se caracteriza por distribuir un gestor de bloqueo en cada nodo. Cada uno es
responsable de la gestin de bloqueos de los datos que contiene en ese nodo. El 2PLP
distribuido implementa una protocolo de control de replicas Read-One-Write-All. Cualquier
copia de un dato replicado puede ser usada para operaciones de lectura, pero todas las copias
deben ser bloqueadas para escritura antes que se puedan modificar.

Protocolo de marcas de tiempo (timestamp protocol)

Su objetivo es ordenar las transacciones globalmente de manera que transacciones con
una marca de tiempo menor, obtengan la prioridad en el caso de conflicto. El problema es que
los relojes de nodos diferentes podran no estar sincronizados.

Procesamiento de Consultas Distribuidas

El procesamiento de consultas ha recibido una gran atencin en las bases de datos
distribuidas, ya que es un aspecto crtico en el rendimiento de las mismas.

Sin embargo el procesamiento de consultas es mucho ms difcil en ambientes distribuidos

que en centralizados, ya que en ambientes distribuidos existe un gran nmero de parmetro que
afectan el rendimiento de las consultas distribuidas, mientras que en sistemas centralizados los
lenguajes de base de datos relacionales permiten la expresin de consultas complejas en una
forma concisa y simple.

La funcin principal de un procesador de consultas relacionales es transformar una

consulta en una especificacin de alto nivel, normalmente en clculo relacional, a una consulta
equivalente en una especificacin de bajo nivel, normalmente alguna variacin del lgebra
relacional.

17

Base de Datos Distribuidas

La transformacin es correcta si la consulta de bajo nivel tiene la misma semntica que la

consulta original, es decir, si ambas consultas producen el mismo resultado. Para verificar si es
correcta la transformacin se hace un mapeo bien definido entre el clculo relacional y el
lgebra relacional.

Otro aspecto importante es el consumo de recursos. Hay que elegir una buena estrategia de
ejecucin que sea eficiente para que as minimicemos el consumo de recursos de nuestro
sistema.

18

Base de Datos Distribuidas

Ejemplo: Consideramos esta Base de Datos:

EMPRESA(ID_EMPRESA,NOMBRE_EMPRESA)
PROYECTO(ID_EMPRESA,NOMBRE_PROYECTO,FUNCION)

La consulta trata de encontrar todos las empresas a las que les subvencionan un proyecto.

Expresin SQL: SELECT NOMBRE_EMPRESA FROM EMPRESA E, PROYECTO P

WHERE E.ID_EMPRESA=P.ID_EMPRESA AND FUNCION = BENEFICIARIO

Dos consultas equivalentes el lgebra relacional seran:

1) EMPRESA (FUNCION-BENEFICIARIO E.ID-P.ID (E x P))

2) ENOMBRE (E>< ID (FUNCION=BENEFICIARIO (P))

La segunda estrategia es mejor, ya que evitamos calcular el producto cartesiano de E x P,

por lo que la eficiencia mejora (al disminuir el coste computacional).

Sin embargo, en los sistemas distribuidos (a diferencia de los sistemas centralizados) el

lgebra relacional no es suficiente para expresar la ejecucin de estrategias, que debe ser
complementada con operaciones para el intercambio de informacin entre nodos. Entre estas
operaciones destacan las que hacen el procesador de consultas distribuidas para elegir el orden
de las operaciones del lgebra relacional, el mejor sitio para procesar datos y la forma en que los
mismos deben ser transformados.

Objetivos de la optimizacin de consultas

El objetivo PRINCIPAL de la optimizacin de consultas distribuidas es mejorar la
eficiencia de las mismas. Ms detalladamente, podramos decir que se trata de transformar una
consulta sobre una base de datos distribuidas en una especificacin de alto nivel a una estrategia
de ejecucin eficiente en un lenguaje de bajo nivel.

Tenemos que minimizar la siguiente funcin de coste:

En funcin el ambiente en que se trabaje cada uno de los factores de la expresin anterior
pueden llegar a tener pesos diferentes. Por ejemplo, en la redes WAN el coste de comunicacin

19

Base de Datos Distribuidas

domina dado que hay una velocidad de comunicacin relativamente baja. Es por esto que los
algoritmos diseados para trabajar en entornos WAN suelen despreciar el coste de CPU y de
entrada/salida. En redes LAN el peso las comunicaciones no es tan dominante y los tres factores
se equiparan.

Otro factor importante a tener en cuenta a la hora de optimizar consultas en bases de datos
distribuidas es saber la complejidad computacional de los diferentes tipos de operaciones que se
pueden hacer. Antes hemos visto que ganbamos eficiencia al eliminar un producto cartesiano,
que como veremos ahora, es la operacin ms compleja.

Veamos un listado de las principales operaciones del lgebra relacional junto con su
complejidad:

Seleccin y proyeccin sin eliminar duplicados: O(n)

Proyeccin (con eliminacin de duplicados) y agrupacin: O(n*log n).

Junta, semijunta, divisin, operaciones con conjuntos: O(n*log n).

Producto cartesiano: O(n^2).

Caractersticas de los procesadores de consultas

Comparar un sistema centralizado con uno distribuido es una tarea complicada ya que
ambos difieren en una gran cantidad de aspectos, desde su arquitectura hasta la forma de tratar
una consulta. Vamos a enumerar las principales caractersticas de los procesadores de consultas
distribuidas y que los diferencias de los procesadores de los sistemas centralizados:

Tipo de optimizacin.

Granularidad de la optimizacin.

Tiempo de optimizacin

Estadsticas

Nodos de decisin.

Topologa de la red.

Arquitectura del procesamiento de consultas

El procesamiento de consultas distribuidas podemos separarlo en cuatro fases o niveles,
desde que la consulta llega hasta que se optimiza al mximo posible:

Descomposicin de consultas.

Localizacin de datos.

20

Base de Datos Distribuidas

Optimizacin global de consultas.

Optimizacin local de consultas.

Ventajas y desventajas de las Bases de datos Distribuidas

Ventajas:

Favorecer la naturaleza distribuidora de muchas aplicaciones, no solamente a nivel local

sino incluso en diferentes lugares.

Se consigue una comparticin de los datos, sin perder un determinado control local.

Crecimiento modular.

El rendimiento se mejora. Cuando se distribuye una gran base de datos por mltiples
sitios, las consultas locales y las transacciones tienen mejor rendimiento porque las
bases de datos locales son ms pequeas. A parte de esta distribucin, se puede
conseguir lo siguiente en estos sistemas:
o

Reducir el nmero de transacciones ejecutndose por sitio.

Un paralelismo entre las consultas ejecutando varias en sitios diferentes,

descomponiendo una de ellas en subconsultas que puedan ejecutarse en
paralelo.

Aumento de la fiabilidad y la disponibilidad.

Economa: es ms barato construir un sistema con pequeas computadoras que uno

grande si ambos dan el mismo rendimiento.

Por ltimo, la autonoma de estos sistemas es grande.

Desventajas:

Hay una menor seguridad en cuanto al control de acceso a los datos: control de replicas
y errores que puedan producirse en la red.

Mayor complejidad en el diseo e implementacin del sistema. Adems si la replicacin

de datos no se hace de forma adecuada, las ventajas se pueden transformar en
desventajas.

Excesivos costes en el intento de conseguir la transparencia mencionada anteriormente.

Falta de estndares y de experiencia, una vez ms en estos modelos avanzados de BD.

No se puede garantizar al 100 % el rendimiento y la fiabilidad.

21

Base de Datos Distribuidas

Conclusiones
Las bases de datos distribuidas son cada vez ms usadas por las empresas y suponen una
ventaja competitiva frente a los sistemas centralizados, siempre y cuando la empresa en cuestin
tenga necesidad de usar una base de datos de este tipo. Lo ms habitual es disponer de varias
sedes y tener que manejar informacin comn, para lo cual las bases de datos distribuidas son
especialmente tiles.

Es una tecnologa que ya lleva aos en rodaje por lo que tiene la madurez suficiente como
para ser usada con garantas, no obstante, debido a la gran dependencia que estas bases de datos
tienen de las telecomunicaciones, en Espaa nos encontramos muchos problemas para conseguir
el rendimiento oportuno de las mismas.

Bibliografa

Distributed Databases, School of Science & Technology, Bell College (Hamilton)

Silberschatz, Korth, y Sudarshan, Fundamentos de Bases de Datos, 4 ed. Mc Graw

Hill

CONNOLLY, Thomas M. y BEGG, Carolyn E., Sistemas de bases de datos:

diseo, implementacin y gestin. Pearson - Addison Wesley, 4 edicin.

Armes A. Elmasri y Shamkant B. Navathe, Fundamentos de Sistemas de Bases de

Datos. 3 ed. Addison Wesley.

http://www.fing.edu.uy/inco/cursos/interop/interPresencial/transparencias/queries.pdf

http://www.mitecnologico.com/Main/OptimizacionDeConsultasDistribuidas

http://sistemas-distribuidos-unerg.blogspot.com/2007/12/bases-de-datosdistribuidas.html

http://catarina.udlap.mx/u_dl_a/tales/documentos/msp/alvarez_c_g/capitulo1.pdf

22