Base de Datos Distribuidas en Oracle

Universidad Nacional de Trujillo

Facultad de CC.FF.MMEscuela 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.


• 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


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.


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.


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,

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:


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


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.


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.


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


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

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

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


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.


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


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.

Base de Datos Distribuidas en Oracle

Documents

Transcript of Base de Datos Distribuidas en Oracle