UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMÁTICA

BASES DE DATOS DISTRIBUIDAS

Grupo: Distribución 1

Angulo Sánchez-Herrera, Eusebio

Casero Vera, Gregorio Luis
Chacón Chacón, Ricardo
González Muñoz, Lucas
Miguel Sabariego, Raúl
Verdugo Lara, Javier
Villar Herrera, José Carlos

Asignatura: Modelos Avanzados de Bases de Datos

Titulación: Ingeniería Superior Informática.
Fecha: 10 de Abril de 2007.
Índice.
Introducción.................................................................................................................................................... ..3
Conceptos básicos............................................................................................................................................. 3
Reglas básicas de los Sistemas de BDD................................................................................ ...........................4
Gestión de Bases de Datos Relacionales Distribuidas.......................................................... ............................5
Estrategias de Diseño.................................................................................................................................. .6
Fragmentación.............................................................................................................................. ...............6
Reglas de corrección de la fragmentación.................................................................... ..........................7
Tipos de fragmentación.................................................................................................. ........................8
Información necesaria para la fragmentación................................................................... ......................9
Asignación:............................................................................................................................................... ...9
Gestión de transacciones distribuidas....................................................................................... ......................10
Control de concurrencia........................................................................................................................ ..........11
Serializabilidad distribuida................................................................................................. .......................11
Protocolos de bloqueo......................................................................................................................... ..11
Protocolos de marcado temporal........................................................................................................ ...12
Procesamiento de Consultas Distribuidas.................................................................................... ...................12
Objetivos de la optimización de consultas.................................................................................. ...............14
Caracterización de los procesadores de consultas.......................................................................... ............14
Arquitectura del procesamiento de Consultas................................................................................ ............14
Sistemas Gestores de Bases de Datos Distribuidas........................................................................ .................15
Características de los SGBDD:..................................................................................................... ........15
SGBDD Homogéneos y Heterogéneos...................................................................................... ................16
Funciones de un SGBDD......................................................................................................................... ..16
Arquitectura de un SGBDD............................................................................................................ ...........17
Componentes de un SGBDD................................................................................................... ..................17
Ventajas y desventajas de los SGBDD.................................................................................................... ........18
Ventajas.............................................................................................................................. .......................18
Desventajas............................................................................................................................................ ....19
Comparación con las BBDD móviles y paralelas.................................................................... .......................20
Arquitectura de las BD móviles....................................................................................................... ..........20
Móviles Vs Distribuidas................................................................................................... ....................20
Arquitectura de las BD paralelas....................................................................................... ........................21
Paralelas Vs Distribuidas.......................................................................................................... ............21
Estado actual y futuro.................................................................................................................... .................21
Bibliografía............................................................................................................................................... ......22

1
Introducción.
Una de las principales motivaciones para el desarrollo de sistemas de bases de datos es el deseo de
integrar los datos operacionales de una organización y proporcionar un acceso controlado a esos datos.
Aunque la integración y el acceso controlado pueden implicar la necesidad de utilizar mecanismos de
centralización, el objetivo en realidad no es ese. De hecho, el desarrollo de redes informáticas promueve el
modo descentralizado de trabajo. Esta técnica descentralizada imita la estructura organizativa de muchas
empresas, que están distribuidas de modo lógico en divisiones, departamentos, proyectos, etc., y están
distribuidas de modo físico en oficinas, fábricas e instalaciones, manteniendo cada unidad sus propios datos
operacionales. La posibilidad de compartir los datos y la eficiencia del acceso a los mismos puede mejorarse
mediante el desarrollo de sistemas de bases de datos distribuidas que reflejen esta estructura organizativa,
que hagan que los datos de todas las unidades sean accesibles y que almacenen esos datos en algún lugar
próximo a aquel donde más frecuentemente se utilice.
Los SGBD distribuidos deberían ayudarnos a resolver el problema de las islas de información. Las
bases de datos se consideran en ocasiones, islas electrónicas que constituyen lugares diferenciados y
generalmente inaccesibles, igual que las islas lejanas. Esto puede ser resultado de la separación geográfica,
de la incompatibilidad de las arquitecturas informáticas, de los protocolos de comunicaciones, etc. Si se
consigue integrar las bases de datos en un todo lógico coherente, podemos resolver el problema.
Algunos de los sistemas más conocidos que utilizan bases de datos distribuidas son DNS y algunos
IRCd como el IRC-Hispano.

Conceptos básicos.
Una BD Distribuida (BDD) es una colección lógicamente interrelacionada de datos compartidos
(junto con su descripción) físicamente distribuidos por una red informática. No es, por tanto, lo mismo que el
procesamiento distribuido, en el cual existe una BD centralizada a la que se puede acceder a través de una
red informática:

BDD Procesamiento Distribuido

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

2
gestionar la BDD y hace que dicha distribución sea transparente para los usuarios.
Un SGBDD está compuesto por una única base de datos lógica dividida en una serie de fragmentos
que pueden estar replicados en diferentes instalaciones. Cada fragmento se almacena en uno o más
ordenadores bajo el control de un SGBD independiente. Todos estos ordenadores (instalación o nodo) del
sistema están conectados entre sí mediante una red de comunicaciones.
A partir de todo lo anterior, podemos clasificar las BDD según dos criterios:
• Homogéneas o heterogéneas según todos los servidores utilicen el mismo SGBD o no, y
• De área local o de área ancha según sea la red de comunicaciones que conecta los servidores:

Tipo de Red
Tipo SGBD
LAN WAN
Homogéneo Gestión de datos y aplicaciones financieras Gestión de viajes y aplicaciones financieras
Heterogéneo Sistemas de información interdivisionales Banca integrada y sistemas interbancos

Reglas básicas de los Sistemas de BDD.

En 1987, uno de los más importantes y conocidos teóricos de las bases de datos relacionales, C. J.
Date, propuso 12 objetivos que debían alcanzar los diseñadores en sus BDD junto con sus SGBDD. Con
ellas se pretende lograr que, para el usuario, un sistema distribuido (SD) funcione exactamente igual que si
no fuera distribuido. Las 12 reglas son las siguientes:
1. Autonomía local: Los nodos de un SD deben ser autónomos 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: Cada nodo debe actuar independientemente de un nodo central
y del resto de nodos. Cada nodo debe tener las mismas capacidades y ser tratado igual al resto. Por lo
tanto no debe existir ningún sitio maestro central del cual dependan el resto. Esto es así por dos
razones fundamentales:
• Puede ser un cuello de botella.
• Puede ser vulnerable: si éste falla también fallará todo el sistema.
3. Independencia de fallos (operación continua): Un fallo en uno de los nodos no debe afectar al
sistema. Tampoco si se añaden nuevos nodos. Así, un SD mejorará las siguientes características.
• 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 período especificado. Podemos decir que nunca debería ser necesario
apagar el sistema para realizar tareas como: añadir un sitio, creación dinámica de
fragmentos, actualización de versiones, etc.
4. Independencia de localización: Para el usuario la localización física de los datos debe ser

3
 transparente. No necesita saber dónde está el dato para utilizarlo.
5. Independencia de fragmentación: Los usuarios no necesitan conocer los fragmentos físicos en que
está dividida cada colección lógica de datos.
6. Independencia de replicación: A nivel lógico, los usuarios no necesitan tener en cuenta si los datos
tienen réplicas o no. La replicación 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 “propagación de las actualizaciones”.
7. Procesamiento de consultas distribuidas: El SD debe disponer de mecanismos para optimizar las
consultas y, en especial, para reducir la carga de tráfico necesaria. Este hecho puede ser considerado
como otra razón por la que los sistemas distribuidos siempre son relacionales (las peticiones
relacionales son optimizables, mientras que las no relacionales no lo son).
8. Gestión de transacciones distribuidas: El SD debe disponer de mecanismos (protocolos)
adecuados para el control de concurrencia y la recuperación de transacciones distribuidas. Una
transacción puede acceder y modificar datos en diferentes nodos sin que el usuario se entere de que
multiples sitios se están viendo afectados por la transacción.
9. Independencia del hardware: El SD se debe poder implementar en cualquier plataforma válida, es
decir, ordenadores con recursos hardware suficientes.
10. Independencia del sistema operativo: El SD se debe poder implementar en sitios con cualquier
sistema operativo multiusuario.
11. Independencia de la red: El SD se debe poder implementar en cualquier red de comunicaciones.
12. Independencia del SGBD: Debe permitirse la heterogeneidad, es decir, que cada sitio pueda
funcionar con un SGBD diferente, incluso basado en un modelo de datos diferente, siempre y cuando
compartan un interfaz común.

Gestión de Bases de Datos Relacionales Distribuidas.

El diseño de un sistema de base de datos distribuido implica la toma de decisiones sobre la ubicación
de los programas que accederán a la base de datos y sobre los propios datos que constituyen esta última, a lo
largo de los diferentes nodos que configuran la red.
Para hacer esto, se pueden utilizar dos estrategias distintas, las cuales, además, se pueden combinar.
Estas estrategias son las utilizadas al diseñar una base de datos relacional, pero añadiendo un paso de diseño
de la distribución.

4
Estrategias de Diseño.
A la hora de abordar el diseño de una base de datos distribuida podremos optar principalmente por
dos tipos de estrategias: la estrategia ascendente y la estrategia descendente:
La estrategia ascendente podría aplicarse en aquel caso donde haya que proceder a un diseño a
partir de un número de pequeñas bases de datos existentes, con el fin de integrarlas en una sola. En este caso
se partiría de los esquemas conceptuales locales y se trabajaría para llegar a conseguir el esquema conceptual
global. Después se pasaría al diseño de distribución.
En la estrategia descendente se parte de cero y se avanza en el desarrollo del trabajo. Los pasos a
realizar mediante esta estrategia son los siguientes:
1. Se comienza con un análisis de los requisitos que definirán el sistema (rendimiento, seguridad,
disponibilidad, flexibilidad, etc.) y su entorno (necesidades de los usuarios).
2. Después se realizan el diseño conceptual para determinar los tipos de entidades y establecer la
relación entre ellas, y el diseño de las vistas.
3. A continuación, se recopilarán estimaciones en torno a la frecuencia de acceso de las aplicaciones y
las relaciones a las que acceden.
4. Después se aborda la confección del esquema conceptual global.
5. Con el esquema y la información relativa al acceso a los datos se pasa al diseño de la distribución. El
objetivo de esta etapa consiste en diseñar los esquemas conceptuales locales que se distribuirán a lo
largo de todos los puestos del sistema distribuido. Resulta bastante frecuente dividir cada relación en
subrelaciones menores denominadas fragmentos que luego se ubican en uno u otro sitio. De ahí, que
el proceso del diseño de la distribución conste de dos actividades fundamentales: la fragmentación
y la asignación.
6. El último paso del diseño de la distribución es el diseño físico, el cual proyecta los esquemas
conceptuales locales sobre los dispositivos de almacenamiento físico disponibles en los distintos
sitios.

Fragmentación.
La fragmentación es el proceso encargado de dividir una relación en otras subrelaciones de menor
tamaño, y su objetivo es encontrar la unidad apropiada de distribución. Existe una serie de razones por las
que llevar a cabo la fragmentación:
• Utilización: En general, las aplicaciones funcionan con vistas que normalmente son
subconjuntos de relaciones. Por tanto, es lógico considerar como unidad de distribución a
esos subconjuntos de relaciones.
• Eficiencia: Los datos se almacenan cerca del lugar en el que son utilizados con mayor
frecuencia. Además, los datos que las aplicaciones locales no necesitan no se almacenan
en ese nodo.

5
 • Paralelismo: La descomposición de una relación en fragmentos permite que una
transacción 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 están disponibles para los usuarios no autorizados.

Pero la fragmentación también tiene inconvenientes. Son los siguientes:

• Rendimiento: El rendimiento de las aplicaciones globales, cuyas vistas están definidas sobre más
de un fragmento, y que además, dichos fragmentos pueden estar ubicados en distintos nodos,
puede degradarse debido a que habrá que recuperar dichos fragmentos y aplicar operaciones de
unión sobre los mismos para satisfacer la consulta que lanzó la aplicación global.
• Integridad: Como resultado de la fragmentación los atributos implicados en una dependencia se
descomponen en diferentes fragmentos, los cuales pueden destinarse a nodos distintos. Debido a
ello el control de integridad puede ser más difícil, ya que puede que haya que buscar datos en
varios nodos.

Cuando se va a fragmentar una base de datos debe pensarse seriamente el grado de fragmentación
que se va a alcanzar, ya que éste será un factor que influirá notablemente en el desarrollo de la ejecución de
las consultas. El grado de fragmentación puede variar desde una ausencia de la división, considerando a las
relaciones unidades de fragmentación; o bien, fragmentar a un grado en el que cada tupla o atributo forme un
fragmento. Una fragmentación óptima es aquella que produce un esquema de división que minimiza el
tiempo de ejecución de las aplicaciones que emplean esos fragmentos.

Reglas de corrección de la fragmentación.

Las tres reglas que han de cumplirse durante el proceso de fragmentación son las siguientes:
 Completitud: Si una relación R se descompone en una serie de fragmentos Ri, cada elemento
de datos que aparezco en R debe aparecer al menos en un fragmento Ri. Con esta regla
aseguramos que no haya pérdida de datos durante la fragmentación.
 Reconstrucción: Debe ser posible definir una operación relacional que permita reconstruir la
relación R a partir de los fragmentos Ri. Esta regla garantiza que se preserven las dependencias
funcionales.
 Disyunción: Si un elemento de datos aparece en un fragmento Ri, entonces no debe aparecer
en ningún otro fragmento. Existe una excepción a esta regla, que es la fragmentación vertical.
Con este tipo de fragmentación los atributos que forman parte de la clave primaria tienen que
repetirse en todos los fragmentos verticales para permitir la reconstrucción de la relación. Esta
regla garantiza una redundancia mínima de los datos.

6
 Tipos de fragmentación.
Existen tres tipos de fragmentación: vertical, horizontal y mixta. Los dos primeros son los
principales. Todos cumplen las reglas de corrección de la fragmentación. Pasemos a dar una descripción de
cada uno de ellos:
− Fragmentación horizontal: Agrupa las tuplas de una relación que son utilizadas de manera
colectiva por las transacciones de mayor importancia. Se generan especificando un predicado que
imponga una restricción a las tuplas de la relación. Existen dos variantes de fragmentación
horizontal:
• Primaria: Se define como una operación de selección (σ) sobre una relación del esquema de
la base de datos: Dada una relación R, un fragmento horizontal primario sería σPredicado(R).
• Derivada: Intuitivamente este tipo de fragmentación consiste en dividir una relación R en
subconjuntos de tuplas a partir de otra relación ya fragmentada P. Además, R hace referencia a
P mediante una clave ajena. Formalmente, dada una relación hija R y otra padre S, la
fragmentación derivada de R se define como R f Si (operación de semicombinación), y
donde f es el atributo de combinación, y Si es un fragmento de S.
− Fragmentación vertical: Agrupa los atributos de una relación que son utilizados de manera
conjunta por las transacciones de mayor importancia. Un fragmento vertical se define utilizando la
operación de proyección del álgebra relacional (Dada una relación R con atributos ai, un fragmento
vertical sería ∏ai-1,ai(R)). Este tipo de fragmentación es más compleja que la vertical debido al
gran número alternativas posibles. Esto hace que tengan que utilizarse heurísticas para llevar a
cabo la fragmentación vertical:
• Agrupación: Comienza asignando cada atributo a un fragmento, y en cada paso, junta algunos
de los fragmentos hasta que satisface un determinado criterio.
• Escisión: A partir de la relación se deciden que fragmentos resultan mejores, basándose en las
características de acceso de las aplicaciones a los atributos. Los fragmentos verticales se
determinan estableciendo la afinidad de un atributo con otro.
− Fragmentación mixta: También denominada fragmentación híbrida. En este caso el proceso de
partición de la relación hace uso de los dos anteriores. Un fragmento mixto se define utilizando las
operaciones de selección y proyección del álgebra relacional, dada una relación R un fragmento
mixto se define como σP(Пa1…an(R)) ó como Пa1…an(σP(R)). Puede llevarse a cabo de tres formas
diferentes:
• Partición VH: Consiste en aplicar en primer lugar fragmentación vertical a la relación que
queremos fragmentar, para aplicar posteriormente fragmentación horizontal a los fragmentos
obtenidos en el primer paso.
• Partición HV: En primer lugar se aplica un proceso de fragmentación horizontal a la relación,
y seguidamente se aplica fragmentación vertical a los fragmentos que se obtienen en el primer
paso.

7
 • Aplicar de forma simultánea y no secuencial la fragmentación horizontal y la fragmentación
vertical. En este caso, se generara una rejilla y los fragmentos formaran las celdas de esa
rejilla, cada celda será exactamente un fragmento vertical y un fragmento horizontal (nótese
que en este caso el grado de fragmentación alcanzado es máximo, y no por ello la
descomposición resultará más eficiente).

Información necesaria para la fragmentación.

Para llevar a cabo el proceso de fragmentación es necesario conocer cierta información. Además,
para cada tipo de fragmentación se requiere una información distinta. A continuación se indica la
información necesaria para la fragmentación vertical y para la horizontal.
− Fragmentación horizontal:
• Información sobre la base de datos: Es importante conocer el esquema conceptual global. Así
sabremos las relaciones que existen entre las relaciones que componen la base de datos
(necesario para la fragmentación derivada).
• Información sobre la aplicación: Necesitaremos información cualitativa para guiar la
fragmentación horizontal. La principal información de carácter cualitativo son los predicados
empleados en las consultas de usuario (útiles para seleccionar los predicados apropiados para
fragmentar).
− Fragmentación vertical:
La principal información que necesitaremos se referirá a las aplicaciones. Por tanto, será útil extraer la
información de una aplicación que funciona sobre la base de datos. Teniendo en cuenta que la
fragmentación vertical coloca en un fragmento aquellos atributos a los que se accede de manera
simultánea, necesitaremos alguna medida que defina con más precisión el concepto de simultaneidad.
Esta medida es la afinidad de los atributos, que indica la relación estrecha existente entre los atributos.

Asignación:
Partiendo del supuesto de que el banco de datos se haya fragmentado correctamente, habrá que
decidir la manera de asignar los fragmentos a los distintos sitios de la red.
La distribución óptima puede definirse con respecto a dos medidas:
1. Coste mínimo: La función de coste consiste en el coste de almacenamiento de cada fragmento en
un sitio, el coste de practicar una consulta en un fragmento en un sitio, el coste de actualizar un
fragmento en todos los sitios donde se almacene y el coste de las comunicaciones de datos. El
problema de la asignación, entonces, intenta encontrar un esquema de asignación tal que minimice
esta función de coste combinado.
2. Rendimiento: La estrategia de asignación se diseña para mantener una medida del rendimiento.
Dos medidas habituales de este rendimiento son el tiempo de respuesta y la salida del sistema en
cada sitio. Evidentemente, se debe intentar minimizar la primera y maximizar la segunda.

8
 Se debe buscar un esquema de asignación tal que la respuesta a las consultas de los usuarios se
realizase en el menor tiempo posible mientras que el coste de procesamiento sea mínimo.
Cuando una serie de datos se asignan, éstos pueden replicarse para mantener una o varias copias. Las
razones para la réplica giran en torno a la seguridad y a la eficiencia de las consultas de lectura. Si existen
muchas reproducciones de un elemento de datos, en caso de fallo en el sistema se podría acceder a esos datos
ubicados en sitios distintos. Además, las consultas que acceden a los mismos datos pueden ejecutarse en
paralelo, ya que habrá copias en diferentes sitios. Por otra parte, la ejecución de consultas de actualización,
de escritura, implicaría la actualización de todas las copias que existan en la red, cuyo proceso puede resultar
problemático y complicado. Por tanto, un buen parámetro para afrontar el grado de réplica consistiría en
sopesar la cantidad de consultas de lectura que se efectuarán, así como el número de consultas de escritura
que se llevarán a cabo.
Podemos considerar tres estrategias de asignación respecto a la replicación:
• Base de datos fragmentada: es aquella donde no existe réplica alguna. Los fragmentos se alojan
en sitios donde únicamente existe una copia de cada uno de ellos a lo largo de toda la red.
• Base de datos totalmente replicada: es aquella donde existe una copia de todo el banco de
datos en cada sitio.
• Base de datos parcialmente replicada: es aquella donde existen copias de los fragmentos
ubicados en diferentes sitios.

Gestión de transacciones distribuidas.

Antes de nada explicar que una transacción o carga de trabajo es una secuencia de declaraciones
SQL en la que, o toda la secuencia es correcta y se realiza con éxito, o toda se considera fracasada.
El objetivo del procesamiento de las transacciones distribuidas es el mismo que en los sistemas
centralizados, aunque es más complejo debido a que el SGBDD debe también garantizar que la transacción
se realiza de una vez, es decir, de manera atómica.
El encargado de coordinar las transacciones es el gestor de transacciones, comunicándose con el
planificador (módulo que se encarga de la estrategia de control de la concurrencia). En caso de que se
produzca un fallo en la transacción o en el sistema general existe un módulo denominado gestor de
recuperación, el cual es el encargado de volver la base de datos a un estado en el que los datos sean correctos
y coherentes.
A más 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 búferes.
En un SGBDD, todos estos módulos 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 transacción global en un nodo N1 es la siguiente:
• El gestor global de transacciones del nodo N1, divide la transacción en una secuencia de
subtransacciones, siguiendo la información guardada en el catálogo global del sistema.

9
 • El encargado de la comunicación de datos del nodo N1 envía 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 través
del encargado de la comunicación de datos al primer nodo N1.

Control de concurrencia.
El control de la concurrencia debe garantizar la coherencia de los datos y que cada transacción se
realice en un tiempo finito. Un buen mecanismo de control de concurrencia debe cumplir los siguientes
requisitos:
− Resistencia a fallos de comunicación y de los nodos.
− Implementar mecanismos de paralelismo.
− No consumir demasiados recursos de procesamiento ni de almacenaje.
− Funcionar en un entorno de red sin producir demasiados retardos.
− No imponer ninguna restricción a la hora de realizar las acciones atómicas.

Los problemas que pueden surgir cuando se trata con una base de datos distribuida son similares a
los que suceden cuando en una base de datos centralizada se permite el acceso de varios usuarios a la vez:
actualización perdida, dependencia no confirmada y análisis incoherente. Además de estos problemas, en una
base de datos distribuida se añade el denominado problema de la coherencia multicopia. Este problema se
presenta cuando tenemos un dato replicado en distintos sitios y, por lo tanto, si se actualiza el dato en un
determinado lugar, se debe actualizar en todas las ubicaciones en las que aparezca.

Serializabilidad distribuida.
Si en cada uno de los nodos la planificación de ejecución es serializable, por tanto la planificación
global también es serializable, suponiendo que se respete el orden de secuencia de las órdenes.
Existen dos técnicas para solucionar estos problemas:
• La técnica de bloqueo, la cual garantiza que la ejecución va a ser concurrente, pero puede
surgir el problema clásico de los interbloqueos.
• La segunda técnica consiste en poner marcas de tiempo a las transacciones, las cuales van a
garantizar la ejecución concurrente y de forma atómica de dichas transacciones.
Detallamos estas dos técnicas a continuación:

Protocolos de bloqueo.
2PL Centralizado.
Consiste en que un único nodo mantiene toda la información de los bloqueos: Hay sólo un gestor de
bloqueos, para todo el conjunto del SGBDD, el cual se encarga de conceder y quitar recursos.

10
 Es muy sencillo de implementar, pero tiene el problema de que el nodo que se encarga de gestionar
todos los bloqueos, puede, valga la redundancia, bloquear el sistema, al ser un cuello de botella. Esto reduce
la fiabilidad del sistema.
2PL de copia principal.
Este protocolo trata de paliar los problemas del 2PL Centralizado. Consiste en distribuir más de un
gestor de bloqueo para cada conjunto de datos replicados. Un dato replicado toma el rol de copia original y la
otra de copia será la esclava. No existe una política para elegir los nodos que contendrán los gestores.
La técnica se utilizará cuando los datos se dupliquen de forma selectiva, cuando las actualizaciones
no sean frecuentes y cuando los nodos no necesiten siempre la versión más actual de los datos.
Sigue teniendo la desventaja de que sigue siendo un poco centralizado y, además, es más complejo
manejar y evitar los interbloqueos.
2PL distribuido.
Este protocolo se basa en la idea de distribuir un gestor de bloqueo en cada nodo, el cual es el
encargado de controlar los bloqueos correspondientes a sus datos. Si no existe replicación de nodos el
protocolo es parecido al anterior, pero si existe replicación implementa un protocolo de control de copias
denominado ROWA: si se necesita leer una copia solo se bloquea una, pero si se necesita escribir, se
bloquean todas las copias hasta que se acaba la operación.

Protocolos de marcado temporal.

El objetivo de estos protocolos es ordenar las transacciones, de forma que las más antiguas, las que
llegaron antes, sean las primeras en ejecutarse, asignándoles una marca de tiempo más pequeña.
En sistemas distribuidos la técnica que se aplica se basa en esta, con la diferencia de que hace falta
también el nodo que produce la transacción, por lo que se utiliza un par de valores (marca temporal, nodo).

Procesamiento de Consultas Distribuidas.

El procesamiento de consultas ha recibido una gran atención en las bases de datos distribuidas, ya
que es un aspecto crítico en el rendimiento de las mismas. Además cuenta con un gran número de parámetros
que afectan al rendimiento de estas consultas.

11
 La función principal de un procesador de consultas relacionales es transformar una consulta en una
especificación de alto nivel (normalmente cálculo relacional), a una consulta equivalente en una
especificación de bajo nivel (normalmente alguna variación del álgebra relacional).

Consulta de usuario en alto nivel

Procesador
de
Consultas

Comandos de bajo nivel

Figura 8.1 Procesador de Consultas

La transformación debe ser correcta, para lo cual la consulta de bajo nivel tiene que producir el
mismo resultado que la consulta original y también debe ser eficiente.
Para verificar si es correcta la transformación se hace un mapeo bien definido entre el cálculo
relacional y el álgebra relacional. Pero lo difícil es producir una estrategia de ejecución eficiente, ya que una
consulta en el cálculo relacional puede tener muchas transformaciones correctas y equivalentes en el álgebra
relacional. Cada estrategia de ejecución tiene un consumo de recursos de cómputo muy diferente, por tanto
lo importante es seleccionar una estrategia de ejecución que minimiza el consumo de recursos.
Ejemplo: Consideramos esta Base de Datos:
ALUMNO(ID_ALUMNO,NOMBRE_ALUMNO)
PROYECTO(ID_ALUMNO,NOMBRE_PROYECTO,CARGO)
La consulta trata de encontrar “todos los alumnos que son jefes de un proyecto”.
Expresión SQL: SELECT NOMBRE_ALUMNO FROM ALUMNO A, PROYECTO P
WHERE A.ID_ALUMNO=P.ID_ALUMNO AND CARGO = “JEFE”
Dos consultas equivalentes el álgebra relacional serían:
1) Π ANOMBRE (σCARGO-“JEFE” Λ A.ID-P.ID (A x P))
2) Π ANOMBRE (A>< ID (σCARGO-“JEFE” (P))

La segunda sería mejor ya que consume menos recursos al evitar calcular el producto cartesiano
entre Alumno y Proyecto.
En sistemas distribuidos, el álgebra relacional no es suficiente para expresar la ejecución de
estrategias, debe ser complementada con operaciones para el intercambio de datos entre nodos diferentes. El
procesador de consultas distribuidas debe elegir el orden de las operaciones del álgebra relacional, el mejor
sitio para procesar datos y la forma en que los mismos tienen que ser transformados.

12
Objetivos de la optimización de consultas.
El objetivo principal es minimizar la siguiente función de costo:
Función de costo total = costo de I/O + costo de CPU + costo de comunicación
Dependiendo del ambiente distribuido, los factores pueden tener pesos diferentes. Por ejemplo en las
redes WAN el costo de comunicación es el más importante, porque la velocidad de comunicación es baja. En
estos casos normalmente se ignoran los costos de CPU y de I/O.

Caracterización de los procesadores de consultas.

A continuación señalamos las características únicas de los procesadores de consultas distribuidos.
1. Tipo de optimización: Existen dos estrategias: Búsqueda exhaustiva (obtienen la transformación
óptima y requieren alto tiempo de ejecución) y Algoritmos heurísticos (obtienen aproximaciones a la
transformación óptima y requieren mejor tiempo de ejecución).
2. Granularidad de la optimización: Hay dos posibilidades considerar sólo una consulta a la vez o
tratar de optimizar múltiples consultas.
3. Tiempo de optimización: Las consultas se pueden optimizar en tiempos diferentes con relación a
tiempo de ejecución de la consulta. Se puede realizar de manera estática (antes de ejecutar la
consulta) o de forma dinámica (durante la ejecución de la consulta). También se puede utilizar un
enfoque híbrido mezclando los dos anteriores.
4. Estadísticas: la efectividad de una optimización depende de las estadísticas de la BD. La
optimización dinámica utiliza las estadísticas para decidir que operación debe realizarse primero y la
optimización estática para estimar el tamaño de las relaciones intermedias.
5. Nodos de Decisión: En la optimización estática un nodo o varios pueden participar en la selección
de la estrategia a ser aplicada para ejecutar la consulta. El proceso de toma de decisiones puede tener
un enfoque centralizado (un solo lugar decide la estrategia) o proceso de decisión distribuido (varios
nodos deciden la estrategia).
6. Topología de la Red: El tipo de red influye en la función objetivo a optimizar para elegir la
estrategia de ejecución. No es igual la importancia de la comunicación en la función de costo con
una WAN que con una LAN.

Arquitectura del procesamiento de Consultas.

El procesamiento de consultas de separa en 4 niveles principales, de los que los tres primeros se
realizan en un nodo central mediante información global y el último en cada nodo local.
1. Descomposición de Consultas: Descompone una consulta en el cálculo relacional en
una consulta en el álgebra relacional que opera sobre relaciones globales. Se divide en:
a. Normalización. Manipula los cuantificadores de la consulta y los calificadores
mediante la aplicación de la prioridad de los operadores.

13
 b. Análisis. Detecta y rechaza las consultas semánticamente incorrectas.
c. Simplificación. Elimina predicados redundantes.
d. Reestructuración. Transforma con una serie de reglas la consulta en cálculo
relacional al álgebra relacional.
2. Localización de datos: A partir de una consulta algebraica definida sobre relaciones
distribuidas, localiza los datos de la consulta usando la información sobre la distribución de
datos. Determina los fragmentos involucrados en la consulta y transforma la consulta distribuida
en una consulta sobre fragmentos.
3. Optimización global de Consultas: El objetivo es hallar una estrategia de ejecución
para la consulta cercana a la óptima. La estrategia puede ser descrita con los operadores del
álgebra relacional y con primitivas de comunicación para transferir datos entre nodos. Las
características de los fragmentos se consideran como sus cardinalidades, para encontrar una
buena transformación.
4. Optimización local de Consultas: Se lleva a cabo en todos los nodos con fragmentos
involucrados en la consulta. Cada subconsulta que se ejecuta en un nodo, llamada consulta local,
es optimizada con el esquema local del nodo. La optimización local utiliza los algoritmos de
sistemas centralizados.

Sistemas Gestores de Bases de Datos Distribuidas.

Un SGBDD es el sistema software que permite gestionar la BDD y hace que dicha distribución sea
transparente para los usuarios. Está compuesto por una única base de datos lógica dividida en una serie de
fragmentos. Cada fragmento se almacena en una o más computadoras bajo el control de un SGBD
independiente, estando dichas computadoras conectadas mediante una red de comunicaciones. Cada una de
las instalaciones es capaz de procesar de forma independiente las solicitudes de los usuarios que requieran
acceso a los datos locales y también es capaz de procesar los datos almacenados en otras computadoras de la
red.
Los usuarios acceden a la BDD a través de una serie de aplicaciones, clasificadas en 2 grupos:
aquellas que no requieren datos en otras instalaciones (locales) y aquellas que sí (globales). Para que un
SGBDD sea considerado como tal, deberá disponer al menos de una aplicación global.

Características de los SGBDD:

− Poseen una colección de datos compartidos lógicamente relacionados.
− Los datos están divididos en una serie de fragmentos.
− Los fragmentos pueden ser replicados.
− Los fragmentos/réplicas se asignan a distintas instalaciones.
− Las distintas instalaciones están enlazadas mediante una red de comunicaciones.
− Los datos de cada instalación están bajo control de un SGBD.

14
 − El SGBD de cada instalación puede gestionar las aplicaciones locales de manera autónoma.
− Cada SGBD participa en al menos una aplicación global.

A partir de la definición de un SGBDD, podemos esperar que el sistema haga que la distribución de
los datos sea transparente al usuario. Así, el hecho de que una BDD esté dividida en una serie de fragmentos
que puedan estar almacenados en diferentes computadoras y, quizás, replicados debería ocultarse al usuario.
El objetivo de esta transparencia consiste en hacer que el sistema distribuido parezca un sistema centralizado
(Principio fundamental de los SGBDD).

SGBDD Homogéneos y Heterogéneos.

Los SGBDD pueden clasificarse como homogéneos o heterogéneos. En un sistema homogéneo todos
los nodos utilizan el mismo SGBD. En un sistema heterogéneo, los nodos pueden estar ejecutando diferentes
SGBD, los cuales no tienen por qué estar basados en un mismo modelo de datos subyacente, de modo que el
sistema puede estar compuesto de diversos SGBD relacionales, en red, jerárquicos u orientados a objetos.
Los sistemas homogéneos son mucho más fáciles de diseñar y mantener. Esta técnica permite el crecimiento
incremental, haciendo que la adición de un nuevo nodo al SGBDD sea sencilla, y también permite conseguir
unas mayores prestaciones, al aprovechar las capacidades de procesamiento paralelo de los múltiples nodos.
Los sistemas heterogéneos suelen crearse cuando los nodos individuales han implementado por su
cuenta sus propias bases de datos y la integración de los nodos se pone en marcha en una fase posterior.

Funciones de un SGBDD.
Lo ideal es que un SGBDD tenga al menos la funcionalidad de un SGBD centralizado; además
esperamos que el SGBDD proporcione la siguiente funcionalidad:
− Servicios avanzados de comunicaciones para proporcionar acceso a nodos remotos y permitir la
transferencia de consultas y de datos entre los nodos a través de una red.
− Un catálogo ampliado de sistema en el que se almacenen los detalles relativos a la distribución de
los datos.
− Procesamiento avanzado de consultas, incluyendo mecanismos de optimización de consultas y de
acceso remoto a datos.
− Un control avanzado de seguridad para mantener los apropiados privilegios de
autorización/acceso a los datos distribuidos.
− Mecanismos avanzados de control de concurrencia para mantener la coherencia de los datos
distribuidos y posteriormente replicados.
− Servicios avanzados de recuperación para tener en cuenta los fallos de los nodos individuales y
los fallos de los enlaces de comunicaciones.

15
Arquitectura de un SGBDD.
Debido a la diversidad de SGBDD, puede resultar útil presentar una posible arquitectura de
referencia que contemple la distribución de datos. La arquitectura de referencia está compuesta de los
siguientes esquemas:
− Un conjunto de esquemas externos globales.
− Un esquema conceptual global.
− Un esquema de fragmentación y un esquema de asignación.
− Un conjunto de esquemas para cada SGBD local conformes a la arquitectura en tres niveles de
ANSI-SPARC.

Componentes de un SGBDD.
Independientemente de la arquitectura de referencia, podemos identificar cuatro componentes
principales en un SGBDD. Son los siguientes:
− SGBD local (SGBDL): Es un SGBD estándar, responsable de controlar los datos locales en cada
nodo que tenga una base de datos. Tiene su propio catálogo local del sistema que almacena
información acerca de los datos contenidos en dicho nodo.
− Componente de comunicaciones de datos (CD): Corresponde al software que permite que todos
los nodos se comuniquen entre sí. El componente de comunicación de datos contiene información
acerca de los nodos y de los enlaces.
− Catálogo global del sistema (CGS): Mantiene información específica de la naturaleza
distribuida del sistema, como por ejemplo los esquemas de fragmentación, replicación y
asignación. El propio catálogo puede ser gestionado como una base de datos distribuida, por lo
que puede estar fragmentado y distribuido, completamente replicado o centralizado.
− SGBD distribuido: El SGBDD es la unidad de control del sistema completo.

16
Ventajas y desventajas de los SGBDD.
Como hemos comentado anteriormente la distribución de datos y aplicaciones aportan una serie de
ventajas potenciales, pero a su vez también tienen sus desventajas. A continuación haremos un resumen
estudiando tanto unas como otras para orientarnos a la hora de decidirnos a utilizar este tipo de SGBD:

Ventajas.

Refleja la estructura organizativa.

Imaginemos cualquier organización dividida en sucursales como podría ser un banco. Dichas
sucursales pueden hallarse en la misma o en diferentes ciudades por lo que es normal que las bases de datos
se encuentren distribuidas por las diferentes sucursales. Cada sucursal puede mantener una base de datos
local con información sobre el personal que trabaja en dicha sucursal, así como de las transacciones de sus
clientes etc. etc. El personal de la sucursal puede acceder a dicha información y, a su vez, la sucursal central
del banco puede realizar consultas que impliquen a mas de una sucursal.

Mejora la compartición de los datos y la autonomía local.

Los usuarios de un nodo pueden acceder a los datos de otros nodos. La distribución de los datos
puede realizarse de forma que aquellos usuarios que más acceden a unos datos determinados se encuentren
más cerca ellos de forma que pueden establecer e imponer políticas locales relativas al uso de estos datos.

Mayor disponibilidad.
Frente a un fallo de la computadora los SGBD centralizados detienen sus operaciones. No pasa así
con los SGBDD ya que el fallo de uno de los nodos no hace que se detenga el sistema e incluso se podrían
encaminar las peticiones a dicho nodo fallido hacia otro nodo activo.

Mayor fiabilidad.
Debido a que los datos pueden replicarse, el fallo de uno de los nodos no quiere decir que la
información deje de ser accesible.

Mayores prestaciones.
Dado que los datos se encuentran más cercanos del nodo con mayor demanda y de que cada nodo
gestiona una parte de la BD completa se podría dar que el acceso fuera más rápido en una BDD ya que la
demanda de los recursos como CPU y elementos de E/S fuera menor que en un SGBD centralizado con una
BD remota.

Economía.
Hoy en día es aceptado que es mucho más barato crear un sistema a base de pequeñas computadoras
para obtener la misma potencia que con un único computador más potente. También es mucho más barato

17
añadir estaciones de trabajo a una red que actualizar un sistema de mainframe.

Crecimiento modular.
En un entorno distribuido resulta muy sencillo expandir el sistema, ya que solo tendríamos que
añadir nuevos nodos al mismo para dotarlo de mayor almacenamiento y potencia de cálculo. No obstante,
deberíamos dotar a la red de mayor velocidad y/o capacidad de almacenamiento. Por el contrario, en un
SGBD centralizado supondría cambios en el hardware y en el software.

Integración.
Como ya hemos indicado, la integración es una amplia ventaja frente a la centralización ya que hoy
en día en sistemas muy grandes coexisten diferentes tipos de sistemas, los cuales han de integrarse bien para
poder facilitar todos los servicios necesarios que la organización puede necesitar en cada momento.

Capacidad de competir.
Muchas empresas han tenido que reorganizar sus operaciones y utilizar tecnología de bases de datos
distribuidas para seguir siendo competitivas.

Desventajas.

Complejidad.
El hecho de que el sistema se muestre transparente al usuario implica una complejidad considerable,
también el hecho de que puedan existir datos replicados añade una complejidad adicional al SGBD
distribuido. Si el software no gestiona bien dichos datos puede darse una degradación en la disponibilidad, la
fiabilidad y las prestaciones por comparación con un sistema centralizado.

Coste.
La mayor complejidad implica que el coste sea algo más elevado. Además, a estos sistemas debemos
de añadir el coste del hardware de comunicación necesario más el coste del personal de mantenimiento de
dicho hardware.

Seguridad.
En un SGBDD no solo hay que controlar el acceso a los datos replicados en múltiples ubicaciones,
sino que también es necesario dotar de seguridad a la propia red.

Control de integridad más complicado.

La integridad de la base de datos es un término que hace referencia a la validez y coherencia de los
datos almacenados. Imponer las restricciones de integridad requiere, generalmente, acceder a una gran
cantidad de datos que definen la restricción pero que no están implicados en la propia operación de
actualización. En un SGBDD, los costes de comunicaciones y de procesamiento requeridos para imponer las
restricciones de integridad pueden ser prohibitivos.

18
 Carencia de estándares.
No existen herramientas o metodologías que ayuden a los usuarios a convertir un SGBD centralizado
en uno distribuido.

Falta de experiencia.
Hoy en día no tenemos el mismo nivel de experiencia con los SGBDD que en los centralizados. No
obstante, muchos de los problemas y los protocolos se conocen a la perfección. Este puede ser un factor
determinante para alguien que esté pensando en adoptar esta tecnología.

Diseño de la base de datos más complejo

A las dificultades típicas del diseño de los sistemas centralizados se añaden las de la fragmentación y
replicación de los datos.

Comparación con las BBDD móviles y paralelas.

La arquitectura de un sistema de base de datos está influenciada por el sistema informático que
soporta la instalación del SGBD, lo que reflejará muchas de las características propias del sistema
subyacente en el SGBD.

Arquitectura de las BD móviles.

Todas las bases de datos móviles tienen una arquitectura similar, donde debemos destacar una serie
de elementos principales y característicos de este tipo de sistemas:
• Servidor de base de datos corporativo y SGBD que gestiona y almacena los datos
corporativos y proporciona aplicaciones corporativas.
• Base de datos remota y SGBD que gestiona y almacena los datos móviles. Son las bases de
datos que deben estar implementadas en los dispositivos móviles.
• Plataforma de base de datos móvil, que puede ser un ordenador portátil, PDA u otro
dispositivo de acceso a Internet, es decir, los dispositivos móviles en cuestión.

Móviles Vs Distribuidas.
La principal y visible diferencia entre las BD móviles y las distribuidas es, como su propio nombre
indica, la movilidad de sus nodos, ya que estos pueden cambiar de posición y, con ello, los datos contenidos
en cada nodo. Por lo demás guardan muchas similitudes con las BD distribuidas:
• La coherencia y la integridad de los datos son un punto crítico de ambas.
• También lo son las redes de comunicaciones utilizadas para transportar los datos.
• Los datos se pueden encontrar replicados por lo que el hecho de que un nodo deje de
funcionar no quiere decir que los datos sean inaccesibles.

Como ventajas claras frente a las distribuidas podemos decir que:

• Permiten la movilidad de los usuarios, por lo que no es necesario estar físicamente en la

19
 organización para acceder a sus datos. Éstos pueden ser accedidos remotamente.
• El mercado potencial de este tipo de bases de datos es bastante amplio, ya que multitud de
empresas de todo tipo poseen trabajadores que necesitan acceder a los datos de la compañía
mientras se encuentran en localizaciones remotas.
• Estas bases de datos poseen un gran ámbito de aplicación ya que en principio cualquier base
de datos relacional puede ampliarse para ofrecer los servicios de las bases de datos móviles.

Arquitectura de las BD paralelas.

Las redes de computadores permiten separar tareas en un esquema de clientes y servidores, el
procesamiento paralelo dentro del computador permite acelerar algunas de las tareas de la base de datos así
como la posibilidad de ejecutar más transacciones por segundo.

Los sistemas paralelos de base de datos constan de varios procesadores y varios discos conectados a
través de una red de interconexión de alta velocidad en los cuales las consultas se pueden paralelizar,
permitiendo así que una consulta se pueda ejecutar por más de un procesador al mismo tiempo.

Paralelas Vs Distribuidas.
Las BD distribuidas, al contrario que las paralelas:
• No comparten memoria ni discos y sus tamaños pueden variar tanto como sus funciones,
pudiendo abarcar desde PC hasta grandes sistemas.
• Los datos no se encuentran centralizados, sino distribuidos por los nodos que componen el
sistema.
• Si el sistema falla se pueden reencaminar las consultas hacia otros nodos sin suponer la
detención del sistema.
• Son más fácilmente ampliables y resulta más barato.
Por el contrario, las BD paralelas:
• Pueden aportar un mayor rendimiento en los casos en los que el sistema tenga que responder
a un número elevado de solicitudes constante ya que tiene la capacidad de paralelizar las
consultas.
• La coherencia y la integridad de datos es más fácil de tratar que en los sistemas distribuidos
• En general son menos complejas y requieren menos personal para mantenerlas.

Estado actual y futuro.

La explotación efectiva de la información dará ventaja competitiva a las organizaciones. Los
lenguajes de consulta (SQL) permitirán el uso del lenguaje natural para solicitar información de la Base de
Datos, haciendo más rápido y fácil su manejo.
El uso de las BDD se incrementará de manera considerable en la medida en que la tecnología de
comunicación de datos brinde más facilidades para ello, se adquiera un nivel de experiencia más elevado con
la consiguiente maduración de la tecnología en lo referente a la aparición de estándares de protocolos de

20
comunicaciones y de acceso a datos, así como herramientas o metodologías que faciliten tanto el paso de un
sistema centralizado a uno distribuido como el diseño de éstos.
El uso de bases de datos facilitará y soportará en gran medida a los Sistemas de Información para la
Toma de Decisiones.

Bibliografía.
− CONNOLLY, Thomas M. y BEGG, Carolyn E., Sistemas de bases de datos: Un enfoque práctico para
diseño, implementación y gestión. Pearson - Addison Wesley, 4ª edición.

− NAVATHE, S.B., KARLAPALEM, K. y MINYOUNG, Ra., A Mixed Fragmentation Methodology for

Initial Distributed Database Design, 1997.

− ÖZSU, M. T. y VALDURIEZ, Patrick, Principles of distributed database systems. Prentice Hall, 2a

edición.

− Asignatura Desarrollo de Aplicaciones con Sistemas de Gestión de Bases de Datos de la Escuela

Superior Informática de Ciudad Real (UCLM), Tema 1.

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

Referencias Web.
− Christopher J. Date en Wikipedia, la Enciclopedia Libre.

− Bases de Datos Distribuidas en Tecnomaestros, el Mundo a través de la Tecnología.

− Persistencia en las Bases de Datos Distribuidas, Jesús Cea Avión (Argo.es).

− Diseño de Bases de Datos Distribuidas en las páginas personales de Lycos.

− http://msdn2.microsoft.com/es-es/library/ms190918.aspx

− http://www.microsoft.com/latam/technet/articulos/200004/art16/art16.asp

− http://www.cs.cinvestav.mx/SC/prof_personal/adiaz/Disdb/Cap_4.html

− http://www.cs.cinvestav.mx/SC/prof_personal/adiaz/Disdb/Cap_5.html

Tiempo invertido en la realización.

• Búsqueda bibliográfica: 15
• Análisis y selección de la información: 12
• Discusión de contenidos: 6
• Generación del documento: 32
• Integración y finalización del documento: 2

21