Universidad Nacional de Trujillo

Facultad de CC.FF.MM
Escuela Académico Profesional de Informática

“BASE DE DATOS DISTRIBUIDAS”

CURSO : Tópicos Especiales en Computación III

DOCENTE : Magaly Torres Tarazona

ALUMNOS :
Goicochea Pozo, José Luis
Mejia La Madrid, Oscar
Ruiz Huamán, Roberto
Villacorta Bazán, Luis

CICLO : X

TRUJILLO - PERÚ

2010
TOPICOS ESPECIALES EN COMPUTACION III - BASE DE DATOS DISTRIBUIDAS

BASE DE DATOS DISTRIBUIDAS

I.- CLASIFICACIÓN DE LAS BASE DE DATOS DISTRIBUIDAS

1.- BASE DE DATOS HOMOGÉNEAS

En las BDDH Todos los sitios tiene idéntico software de sistemas de gestores de bases de
datos, son consientes de la existencia de los demás sitios y acuerdan cooperar en el
procesamiento de las solicitudes de los usuarios. En estos sistemas los sitios locales
renuncian a una parte de su autonomía en cuanto a su derecho a modificar los esquemas o
el software del sistema gestor de base de datos. Ese software también debe cooperar con
los demás sitios en el intercambio de la información sobre las transacciones para hacer
posible el procesamiento de las transacciones entre varios sitios.

En los homogéneos un solo gestor puede ser el administrador de la coordinación (donde

se guarda la información, cómo y quién puede acceder a ella).

Todos los sitios tienen idéntico software de sistemas gestores de bases de datos.

1.1 Caracteristicas:

• Cooperan en el procesamiento de las solicitudes del usuario.

• Cooperan en el intercambio de información de las transacciones
• Cualquier operación debe hacerse sobre la base de datos global.
TOPICOS ESPECIALES EN COMPUTACION III - BASE DE DATOS DISTRIBUIDAS

• No distingue entre usuarios locales y usuarios No-locales.

2. BASE DE DATOS HETEROGÉNEAS

Un sistema de bases de datos heterogéneo es una colección de sistemas de bases de datos

cooperativos y autónomos En un sistema heterogéneo los usuarios tienen acceso a los datos,
de los distintos sistemas, a través de una interfaz común sin embargo, no existe un esquema
global que describa a todos los datos de las distintas bases de datos, en su lugar hay varios
esquemas unificados, cada uno describiendo porciones de bases de datos y archivos para el
uso de cierta clase de usuarios

En las bases de datos heterogéneas sitios diferentes puede que utilicen esquemas diferentes
y diferente software de gestión de sistemas de base de datos. Puede que unos sitios no sean
consientes de la existencia de los demás y puede que solo proporcionen facilidades
limitadas para la cooperación en el procesamiento de las transacciones. Las diferencias en
los esquemas suelen constituir un problema importante para el procesamiento de las
consultas, mientras que la divergencia del software supone un inconveniente para el
procesamiento de transacciones que tengan acceso a varios sitios.

En las bases de datos heterogéneas, la administración se comparte entre los diferentes

DBA locales, indicando cada uno de ellos qué información es accesible globalmente y
cómo. Si existe un esquema global se dice que está fuertemente  acoplados sino
débilmente, por lo que cada  sede es responsable de mostrar los esquemas externos
de su información

 Sitios, esquemas y software diferentes.

 Presenta inconvenientes en el procesamiento de consultas y transacciones
TOPICOS ESPECIALES EN COMPUTACION III - BASE DE DATOS DISTRIBUIDAS

2.1. CLASIFICACIÓN.
Débilmente acoplados
• Los usuarios deben de tratar explícitamente con las base de datos.
Fuertemente acoplados
• Los administradores de la federación controlan el acceso y mantienen el sistema.
• Esquema federado único. SIRIUS-DELTA, DDTS.
• Múltiples esquemas federados: Mermaid, MULTIBASE.
TOPICOS ESPECIALES EN COMPUTACION III - BASE DE DATOS DISTRIBUIDAS

ALMACENAMIENTO DISTRIBUIDO DE DATOS

 Para este punto, consideraremos una tabla T que se tiene que almacenar en él una
base de datos distribuida. Existen varias opciones:

RÉPLICA

El sistema conserva varias copias o réplicas idénticas de la tabla. Cada réplica se

almacena en un nodo diferente, lo que da lugar a redundancia de datos. La
alternativa a la réplica es guardar la tabla en un solo nodo. La réplica presenta las
siguientes ventajas e inconvenientes:

- Disponibilidad:
Como se vio en la introducción, la réplica permite que el sistema siga
funcionando aún en caso de caída de uno de los nodos.

- Aumento del paralelismo:

En el caso de que la mayoría de los accesos a la tabla T sean de lectura, varios
nodos pueden realizar consultas en paralelo sobre la misma tabla. Cuantas más
réplicas existan de la tabla, mayor será la posibilidad de que el dato buscado se
encuentre en el nodo desde el que se realiza la consulta, minimizando con ello el
tráfico de datos entre nodos.

- Aumento de la sobrecarga en las actualizaciones:

El sistema debe asegurar que todas las réplicas de la tabla sean consistentes, por
tanto, cuando se realiza una actualización sobre una de las réplicas, los cambios
deben propagarse a todas las réplicas de dicha tabla a lo largo del sistema
distribuido. Esto hace que las actualizaciones sean más costosas que en los
sistemas centralizados. En general, el sistema de réplica hace que las consultas
sean más eficientes, pero complica las actualizaciones debido al problema de la
redundancia de datos y el mantenimiento de la consistencia. Normalmente, se
elige una de las réplicas como copia principal para simplificar la administración.
TOPICOS ESPECIALES EN COMPUTACION III - BASE DE DATOS DISTRIBUIDAS

FRAGMENTACIÓN DE DATOS

La tabla T se puede separar en varios fragmentos que contendrán suficiente

información para reconstruir la tabla original.
La fragmentación puede ser horizontal o vertical y se puede aplicar sucesiva y
alternativamente sobre la misma tabla. Cada fragmento se encontrará en nodos
diferentes.
- Fragmentación horizontal:

La tabla T se divide en subconjuntos, T1, T2,...Tn., cada tupla de T debe

pertenecer al menos a uno de los fragmentos para poder reconstruir la tabla
original a partir de los fragmentos. Los fragmentos se definen a través de una
operación de selección y su reconstrucción se realizará en base a una
operación de unión de los fragmentos componentes.

En el ejemplo siguiente, se ilustra una posible fragmentación de la tabla

Alumnos de dos fragmentos: uno para el nodo de la EUI y otro para el nodo
de la EUIT.

En algunos casos, puede ser necesario que los fragmentos no sean disjuntos,
TOPICOS ESPECIALES EN COMPUTACION III - BASE DE DATOS DISTRIBUIDAS

consiguiendo así combinar la técnica de replicación con la de fragmentación.

La recuperación de la relación original se realizará a partir de la unión de cada
uno de los fragmentos: T= T1∪ T2∪...∪Tn.

En nuestro caso: ALUMNOS=ALUMNOS_EUI ∪ ALUMNOS_EUIT

- Fragmentación vertical:

La fragmentación vertical implica la definición de subconjuntos de atributos

de la relación de partida mediante la operación de proyección. Cada
fragmento se define como Ti=Πa1..an(T). Para poder recomponer la relación
original, cada fragmento debe incluir la clave primaria de T. La relación
inicial se recompondrá en base a unión natural de los fragmentos resultantes:
T=T1∗T2*..*Tn.

Como ejemplo, supongamos que en el rectorado existen dos departamentos

ubicados en distinto lugares y con necesidades distintas de información. El
departamento de infraestructuras que maneja la información referente a las
escuelas y su situación. Además está en departamento de ordenación
académica que utiliza la información de las escuelas y el número de
alumnos. En ésta situación se podría plantear una fragmentación vertical de
la relación original en dos fragmentos de la siguiente manera:
TOPICOS ESPECIALES EN COMPUTACION III - BASE DE DATOS DISTRIBUIDAS

- Fragmentación mixta:

La fragmentación mixta puede surgir como la aplicación combinada de la

fragmentación horizontal y vertical. Como ejemplo, podemos partir de la
relación resultante de la fragmentación horizontal en la tabla de alumnos.
Supongamos que en la EUI existen dos nodos dedicados a distintas
funciones. Uno de ellos sería el de secretaría que maneja la información
referente a los alumnos y sus becas. Otro podría ser el de Jefatura de
Estudios que utiliza la información referente a las notas de ingreso de los
distintos alumnos. Tendríamos el siguiente esquema:
TOPICOS ESPECIALES EN COMPUTACION III - BASE DE DATOS DISTRIBUIDAS

En este caso, las dos relaciones resultantes surgen de la fragmentación

mixta: primero se ha aplicado una fragmentación horizontal por centros y
luego una fragmentación vertical por departamentos del centro.

RÉPLICA Y FRAGMENTACIÓN DE DATOS

Las técnicas de réplica y fragmentación se pueden aplicar sucesivamente a la misma

relación de partida. Un fragmento se puede replicar y a su vez esa réplica ser
fragmentada, para luego replicar alguno de esos fragmentos.
TOPICOS ESPECIALES EN COMPUTACION III - BASE DE DATOS DISTRIBUIDAS

TRANSACCIONES DISTRIBUIDAS

En el caso de las BD Distribuidas, una transacción está formada por un conjunto de

procesos, denominados agentes, cada uno de los cuales se va a ejecutar en un nodo
diferente. Un agente es, por tanto, un proceso local que realiza algunas acciones para una
transacción. Para llevar a cabo los subprocesos, los agentes tienen que comunicarse; esto se
realiza a través de mensajes.

Hay varias formas de organizar los agentes para construir una estructura de proceso
cooperativo.

En principio, asumimos que:

1. Existe un agente raíz que arranca la transacción; el lugar donde reside se denomina nodo
origen de la transacción

2. El agente raíz tiene la responsabilidad de emitir las operación begin_transaction, commit

y abort, cuando corresponda.

1. Estructura del sistema

Cada sitio tiene su propio gestor local de transacciones, cuya función es asegurar las
propiedades ACID de las transacciones que se ejecuten en ese sitio. Los diferentes gestores
de transacciones colaboran para ejecutar las transacciones globales. Para comprender el
modo en que se pueden implementar estos gestores, considérese un modelo abstracto de
sistema de transacciones, en el que cada sitio contenga dos subsistemas:

 El gestor de transacciones

Administra la ejecución de las transacciones (o subtransacciones) que tienen acceso a

los datos almacenados en un sitio local. Téngase en cuenta que cada una de esas
transacciones puede ser una transacción local (es decir, una transacción que se ejecuta
sólo en ese sitio) o parte de una transacción global (es decir, una transacción que se
ejecuta en varios sitios).

 El coordinador de transacciones

Coordina la ejecución de las diferentes transacciones (tanto locales como globales)

iniciadas en se sitio.
TOPICOS ESPECIALES EN COMPUTACION III - BASE DE DATOS DISTRIBUIDAS

2. Atomicidad de las transacciones distribuidas

La atomicidad es una propiedad de las transacciones que asegura que o bien son realizadas
todas las operaciones o ninguna. La atomicidad requiere que si una transacción es
interrumpida por un fallo, sus resultados parciales sean restaurados a las condiciones
iníciales. Las razones típicas por las que una transacción no finaliza son la cancelación o
ruptura del sistema. La finalización puede ser solicitada por la propia transacción (o el
usuario) debido a que alguna de sus entradas sea errónea o porque algunas condiciones
hacen que la terminación de la transacción sea inadecuada.

3. Fallos de comunicación en BD Distribuidas

Los mecanismos de recuperación del SGBD se construyen para permitir la vuelta a un

punto anterior consistente después de producirse un fallo. En caso de las BD Distribuidas,
los mecanismos de recuperación deberán tratar, además de los fallos propios de las BD
centralizadas (pérdida de información de memoria, del disco, etc.), aquellos que pueden
ocurrir en las comunicaciones entre nodos.

 Mensajes Incorrectos
 Pérdida de mensajes

4. Confirmación en dos fases (2PC)

En el protocolo básico, hay un agente coordinador y el resto de los agentes que deben
confirmar juntos se denominan participantes. El coordinador es responsable de tomar la
decisión final de confirmación o cancelación. Cada participante corresponde a una
subtransacción que ha realizado alguna operación de escritura sobre la BD local. La idea
básica del 2PC es determinar una decisión única para todos los participantes con respecto a
la confirmación o cancelación de subtransacciones locales. Si un participante no puede
confirmar su subtransacción local, todos los participantes deben cancelar localmente. El
TOPICOS ESPECIALES EN COMPUTACION III - BASE DE DATOS DISTRIBUIDAS

protocolo se realiza en dos fases. La meta de la primera fase es alcanzar una decisión
común, y la de la segunda fase es implementar esta decisión.

Veamos el protocolo cuando hay ausencia de fallos:

BASE DE DATOS DISTRIBUIDAS EN ORACLE

TOPICOS ESPECIALES EN COMPUTACION III - BASE DE DATOS DISTRIBUIDAS

 Se trata de una base de datos a nivel lógico (los usuarios la manejan como una base
de datos normal), pero que en realidad (físicamente) está implementada en varias
ubicaciones físicas, incluso en máquinas diferentes y distantes.

 Cada máquina ejecuta su propia instancia y conjuntos de archivos y todas se

conectan en red para hacer que el usuario no tenga que cambiar su código para
reflejar esta distribución. La dificultad de esta estructura suele estar aliviada por
medio de instantáneas que graban momentáneamente los datos de las tablas
distantes. Permiten trabajar con los datos copiados y se programan para que cada
cierto tiempo recojan nuevamente los datos a fin de reflejar sus cambios.

 Gracias a las instantáneas no hace falta una sobrecarga tan excesiva de las
instantáneas de la base de datos. Posee arquitectura cliente/servidor. Cada ordenador
en la red es un nodo que pude actuar como cliente, servidor o ambos.

 Utiliza el software de red Oracle Net8 para comunicación entre bases de datos. Net8
permite a las bases de datos comunicarse a través de redes para soportar
transacciones distribuidas y remotas. Empaqueta sentencias SQL en uno de los
muchos protocolos de comunicación para facilitar al cliente la comunicación con el
servidor y después empaqueta y devuelve los resultados de forma similar al cliente.

DATABASE LINKS
TOPICOS ESPECIALES EN COMPUTACION III - BASE DE DATOS DISTRIBUIDAS

 Concepto central en las BD distribuidas en ORACLE

 Un DB Link define un camino unidireccional desde una BD ORACLE a otra.

 Un usuario local puede acceder a través de un link a objetos de esquemas de otros

usuarios en BD remotas (siempre que tenga permiso suficiente para hacerlo) como
si se tratara de una única BD.

 Se almacenan en el catálogo:

SELECT db_link FROM user_db_links;

CREACIÓN DB LINK
 Crea un link público de nombre nombreLink que establece un enlace a una BD
remota cuya ubicación está descrita en el nombre de servicio a través un usuario y
contraseña de dicha BD.

CREATE PUBLIC DATABASE LINK nombreLink

CONNECT TO usuario IDENTIFIED BY contraseña
USING 'nombre de servicio';

BORRADO DBLINK
DROP [PUBLIC] DATABASE LINK nombreLink;

NOMBRE DE SERVICIO
 Cada BD es identificada unívocamente en una BD distribuida por un nombre global
de BD. Este consta del nombre de la BD junto con el nombre del host en la red en la
que esta BD está ubicada.

 Este nombre se hace transparente al usuario mediante el uso de nombres de servicio

(service names) en la definición de los enlaces (links).

 Los nombres de servicio se definen en el archivo tnsnames.ora de Oracle, cuya

ubicación depende del ordenador: c:\oracle\ora92\network\admin\tnsnames.ora
TOPICOS ESPECIALES EN COMPUTACION III - BASE DE DATOS DISTRIBUIDAS

TIPOS DE DBLINKS
 Los enlaces pueden ser:

- PRIVADOS: Sólo lo puede usar el que los crea.

(CREATE DATABASE LINK ....)

- PÚBLICOS: Lo pueden usar todos los usuarios de la BD.

(CREATE PUBLICDATABASE LINK ....)

 Los tipos de usuarios de un enlace pueden ser:

- FIXED: Hay que indicar en la definición usuario y contraseña.

- CONNECTED USER (SIN CONNECT): Válido para el usuario conectado.

Debe tener en la BD remota una cuenta con el mismo nombre de usuario y
misma contraseña.
ACCESO A OBJETOS REMOTOS VIA LINKS
 El nombre de un objeto en una BD es unívoco dentro del esquema de su propietario.
Sin embargo, en una BD remota puede existir un esquema con el mismo nombre,
que puede tener un objeto con el mismo nombre.

 Acceso a través de un link a un objeto remoto de un determinado propietario en una

BD remota:
propietario.nombreObjeto@nombreLink
O bien
nombreObjeto@nombreLink

Si el usuario que accede al objeto es el propietario del mismo.

TOPICOS ESPECIALES EN COMPUTACION III - BASE DE DATOS DISTRIBUIDAS

CONSULTA A BDD REMOTAS

 Para realizar consultas en una BD distribuida podemos utilizar objetos situados en
una BD remota. Se utiliza para ello los links previamente creados.

SELECT nombre
FROM dbb.autor@link
WHERE nacionalidad = "Francia"
SELECT nombre
FROM dbb.autor@link, libro
WHERE dbb.autor.idautor@link = libro.idautor
AND nacionalidad = "Francia"

 También es posible realizar operaciones de actualización (insert, update, delete) en

la BD remota, siempre que tengamos el permiso necesario para realizarlas.
SINONIMOS
 Las referencias a las tablas de la BD remota en las anteriores consultas no son
transparentes al usuario: necesita conocer el nombre del link y el propietario de la
tabla. Para hacerlas totalmente transparentes se pueden definir sinónimos.

CREATE [PUBLIC] SYNONYM nombreSinomimo FOR nombreObjeto;

- Permite referirse a un nombre global de un objeto a través del sinónimo.

- Esconde el acceso remoto a la tabla haciendo transparente su acceso.

- El parámetro PUBLIC hace disponible el sinónimo para todos los usuarios.

Ejemplo:
CREATE SYNONYM autores FOR dbb.autor@link
autores actúa como sinónimo de dbb.autor@link
Ahora podemos definir consultas totalmente transparentes al usuario:
SELECT nombre
FROM autores
WHERE nacionalidad = "Francia"

BORRADO DE SINONIMOS
DROP[PUBLIC] SYNONYM autores;
CONCLUSIONES
TOPICOS ESPECIALES EN COMPUTACION III - BASE DE DATOS DISTRIBUIDAS

 En las BDD homogéneas todos los sitios tienen idéntico software de sistemas de
gestores de bases de datos.
 En las bases de datos homogéneas un solo gestor puede ser el administrador de la
coordinación y cualquier operación que desee realizarse se hará en la base de datos
global.
 En las bases de datos heterogéneas la administración se comparte entre los
diferentes DBA locales.
 En una base de datos heterogénea los usuarios tienen acceso a los datos, de los
distintos sistemas, a través de una interfaz común sin embargo, no existe un
esquema global que describa a todos los datos de las distintas bases de datos.
 Una transacción es una unidad atómica de trabajo que se realiza por completo o bien
no se efectúa en absoluto.
 El hecho de que los gestores locales garanticen atomicidad para las transacciones
locales no es por sí mismo suficiente para proporcionar la atomicidad a nivel
distribuido.
 En el nivel más alto está la transacción distribuida, constituida por el agente raíz y
los otros agentes.
 A lo largo de este documento se ha intentado dar una visión global y genérica de los
problemas y características que contiene el diseño de una base de datos distribuida.
 Debería tenerse presente la existencia de enfoques de fragmentación distintos y,
posiblemente, más complejos, pero se debe pensar que sean más eficientes.
 Los diferentes tipos de fragmentación tiene sus ventajas unos de otro que mirando
desde el punto de la aplicación se puede escoger cualquiera dependiendo de los
beneficios que nos aporta.
 Pese a la aparición de los métodos de bases de datos distribuidas hace ya años,
parece que el salto de lo centralizado a lo distribuido a escala comercial está por
venir.
 Para facilitar las comunicaciones entre el cliente y el servidor las sentencias SQL
son empaquetadas.