Download - Bases de Datos Avanzadas: Bases de Datos Distribuidas.

Bases de Datos Avanzadas:Bases de Datos Avanzadas:

Bases de Datos DistribuidasBases de Datos Distribuidas

ÍNDICEÍNDICE

1. Introducción y Conceptos.

2. Ventajas, Complejidad e Inconvenientes de las BDD.

3. Almacenamiento distribuido de datos: FRAGMENTACIÓN,

REPLICACIÓN Y ASIGNACIÓN DE DATOS PARA EL DISEÑO DE BDD.

4. Transparencia de la red.

5. Procesamiento distribuido de consultas.

6. Transacciones distribuidas.

BDD: INTRODUCCIÓN Y CONCEPTOS

Bases de Datos Distribuidas → mezcla de dos tecnologías:

● La tecnología de base de datos.

● La tecnología de redes y comunicación de datos.

Esta última tecnología ha avanzado mucho en los últimos años gracias al desarrollo de las comunicaciones celulares y por satélite, Redes de Área Metropolitana (MAN), estandarización de protocolos como TCP/IP; y por sobre todo, gracias a la explosión de Internet.

Las organizaciones ya no están interesadas, como en los 80s, en bases de datos centralizadas gigantes. Hoy se tiende a la descentralización de procesos, a nivel del sistema, mientras que, a nivel lógico, se consigue una integración de las fuentes de información dentro de BDs geográficamente distribuidas.

BDD: INTRODUCCIÓN Y CONCEPTOS....

Las BDD aportan al dominio de la gestión de bases de datos las ventajas de la computación distribuida. En la cual un conjunto de elementos de procesamiento (no necesariamente homogéneos) interconectados por una red cooperan en forma coordinada en la ejecución de tareas, dividiendo problemas grandes e inmanejables en piezas más pequeñas que se resuelven en forma coordinada.

La viabilidad económica de este enfoque tiene dos razones:

(1) Se aprovecha más la potencia del ordenador en la resolución de tareas complejas.

(2) Cada elemento de procesamiento se puede gestionar en forma independiente en el desarrollo de tareas locales (autonomía).


Entonces, podemos definir:

Base de Datos Distribuida (BDD): colección de múltiples bases de datos interrelacionadas lógicamente, distribuidas sobre una red de computadores y manejadas por un SGBDD.

Sistema de Gestión de Bases de Datos Distribuido (SGBDD): Sistema de software que maneja BDDs y que hace de la distribución algo transparente al usuario.

SISTEMA DE BDD = BDD + SGBDD

Las siguientes figuras contrastan distintas arquitecturas de bases de datos:

Diferentes arquitecturas de sistemas de bases de datos

Arquitectura con “nada compartido”

Diferentes arquitecturas de sistemas de bases de datos

Arquitectura en red con una BD centralizada en uno de los sitios

Diferentes arquitecturas de sistemas de bases de datos...

Verdadera Arquitectura de una Base de Datos Distribuida

DB

DB

DB

DB

DB

Cliente ClienteCliente

BD BD BD

Servidor

Servidor

Sitio 1 Sitio 2

Sitio 3 Sitio n

Red deComunicaciones

. . . . .

Ejemplo de BD distribuida

Nodo E1 Nodo E2

RED Alumnos

Alumnos

Comunicación a través de la red

Nodo Rectorado

Escuelas

Ejemplo de BD distribuida:

Nodos de las Escuelas:

DNI Escuela Nombre

Nota ingreso

Beca

Nodo del Rectorado:

Escuela Ubicación Número alumnos

Nuevo alumno en la secretaría del E1: transacción local.

Nuevo alumno en el rectorado: transacción global


Los datos deben estar físicamente en más de una sede. Cada sede o computadora es un nodo de la red. Cada nodo proporciona un entorno de ejecución de transacciones, tanto local, como global.

Esquema lógico global único: Los datos han de estar lógicamente integrados, para realizar recuperación y actualización tanto en forma local como remota. En una única operación se puede acceder (recuperar o actualizar) datos que se encuentran en más de una sede.

Tipos de transacciones:

Locales: cuando se accede a los datos de la sede que inició la transacción. Globales: se accede a datos de sedes distintas al nodo que inició la transacción.

Pasos a seguir para diseñar una BDD:

1. Diseño del "esquema conceptual" el cual describe la base de datos integrada (esto es, todos los datos que son utilizados por las aplicaciones que tienen acceso a las bases de datos).

2. Diseño "físico" de la base de datos, esto es, mapear el esquema conceptual a las áreas de almacenamiento y determinar los métodos de acceso.

3. Diseño de la fragmentación, este es, determinar la forma en que las relaciones globales se subdividen en fragmentos horizontales, verticales o mixtos. 4. Diseño de la asignación de los fragmentos, esto es, determinar la forma en que los fragmentos se mapean a las imágenes físicas.

• Diseño de BDD – Las 12 Reglas de Date

1 Autonomía localLos nodos o localidades de un SD deben ser independientes entre si en el mayor grado posible.

•Características de cada nodo–Tiene su propio DBMS–El DBMS controla todos los aspectos del nodo–Las operaciones de acceso a datos locales

utilizan sólo recursos locales–Hay cooperación entre los nodos para el acceso

distribuido de datos.

Diseño de BDD – Las 12 Reglas de Date...

2 No es necesario un sitio central

Todos los sitios/nodos deben ser tratados como iguales

• De existir un sitio central, habría un cuello de botella

• De existir un sitio central, el sistema sería vulnerable, porque una falla haría fallar a todo el sistema

• Para el protocolo de commit de dos fases se necesita un sitio central pero sólo durante la ejecución de una transacción

3 Operación continua

Un sistema BDD no debería estar nunca fuera de servicio

• Para proporcionar mayor confiabilidad y mayor disponibilidad se requiere:

– Soporte para backups on line, total o incremental– Soporte para recuperaciones rápidas de BD.– DBMS tolerante a fallos (con hardware acorde)



4 Independencia de localización Los usuarios y las aplicaciones no necesitan conocer la

ubicación física de los datos. Actúan como si fuesen locales a ellos.

• Sin transparencia local deberían distinguirse los datos locales de los datos remotos.

• Simplifica los programas de usuario.

• Punto crítico: el Diccionario de Datos– Usuarios y aplicaciones se refieren a los datos mediante

alias

– El DD debe mantener una tabla con los elementos de datos, sus alias y sus ubicaciones

– Un DDBMS debe mantener y utilizar el DD aún cuando los datos se mueven entre localidades

– El DD debe estar replicado en las localidades y las réplicas deben mantenerse actualizadas.


5 Independencia de Fragmentación de datos

Los usuarios pueden comportarse como si los datos no estuvieran fragmentados (no necesitan conocer los fragmentos físicos en que está dividida cada colección lógica de datos)

– La fragmentación es necesaria por razones de rendimiento.

– Los datos pueden estar almacenados en la ubicación donde son usados con mayor frecuencia para que la mayoría de las operaciones sean locales y se reduzca el tráfico de la Red.


6 Independencia de la Replicación de datos• Replicación

El usuario debe comportarse como si los datos no estuvieran replicados (a nivel lógico los usuarios no necesitan tener en cuenta si los datos tienen réplicas o no)

Recordemos que esto significa:

– Mejor rendimiento: las aplicaciones operan sobre copias locales en vez de comunicarse con sitios remotos.

– Mejor disponibilidad: un objeto replicado está disponible mientras haya al menos una copia.

– Desventaja: propagar las actualizaciones.


7 Procesamiento de consultas distribuidas

La performance de una consulta debe ser independiente del sitio donde se realiza la consulta

– El SD debe disponer de mecanismos para optimizar las consultas y en el especial para reducir la carga de tráfico necesaria.


8 Gestión de transacciones distribuidas

El SD debe disponer de mecanismos adecuados para el control de concurrencia y la recuperación de transacciones distribuidas

– Debe mantenerse la atomicidad de las transacciones.

– Control de recuperación de información.– Control de concurrencia.

– Protocolos utilizado para preservar la atomicidad: dos fases o tres fases los más conocidos.


9 Independencia de hardware

Es necesario tener la posibilidad de ejecutar el mismo DBMS en diferentes plataformas de Hardware.

10 Independencia del SO

Es necesario tener la posibilidad de ejecutar el mismo DBMS en sitios con diferentes sistemas operativos.


11 Independencia de red

El SD debe poder operar con diferentes redes de comunicaciones.

12 Independencia del DBMS

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 una interface común.

Ventajas, Complejidad e Inconvenientes de las BDD

1-Gestión de datos distribuidos con diferentes niveles de transparencia:

Transparencia de distribución: un SGBDD debería ocultar al usuario el emplazamiento de los datos, es decir los detalles del almacenamiento de los archivos (relaciones o tablas) dentro del sistema.

Transparencia de red: hace referencia a la liberación del usuario de los detalles operacionales de la red.

transparencia de localización: se puede lanzar una tarea desde cualquier locacióntransparencia de nombres: permite acceder a cualquier objeto con nombre (archivo, relación, etc.) desde cualquier locación sin que se produzcan ambiguedades. Luego ampliaremos este tema..

Ventajas, Complejidad e Inconvenientes de las BDD…

Transparencia de replicación: copias de los datos se pueden almacenar en múltiples sitios para mejorar la disponibilidad, rendimiento y fiabilidad. La transparencia de réplica hace que el usuario desconozca la existencia de copias.

Transparencia de fragmentación:fragmentación horizontal: distribuye una relación en subconjuntos de tuplas (filas).fragmentación vertical: distribuye una relación en sub-relaciones, donde cada sub-relación se define por un subconjunto de las columnas de la relación original.

Una consulta global del usuario se deberá transformar en varias consultas sobre fragmentos. La transparencia de fragmentación permite que el usuario desconozca la existencia de fragmentos.

Ventajas, Complejidad e Inconvenientes de las BDD…

2- Incremento de la fiabilidad y disponibilidad:

Fiabilidad: se define como la probabilidad de que un sistema esté en marcha (no caído) la mayor parte del tiempo. Disponibilidad: es la probabilidad de que un sistema esté disponible en forma continua durante un intervalo de tiempo.

►Cuando los datos y el SGBD están distribuidos en varios nodos, un nodo puede fallar mientras que otros estarán disponibles para hacer el trabajo. Esto mejora tanto la fiabilidad como la disponibilidad.

► Si se replican acertadamente los datos y el software en más de un sitio, se consiguen grandes mejoras. Una transacción que necesite un determinado dato puede encontrarlo en cualquiera de los diferentes nodos.

► En comparación con un sistema centralizado, en una BDD algunos de los datos podrían ser inalcanzables, pero los usuarios podrían aún acceder a otras partes de la base de datos.

Ventajas, Complejidad e Inconvenientes de las BDD

La distribución trae aparejado un incremento en la complejidad del diseño e implementación del sistema. Para conseguir las ventajas potenciales enumeradas anteriormente, el SGBDD debe tener:

Capacidad para seguirle la pista a la distribución de datos, la fragmentación y la réplica expandiendo el catálogo del SGBDD.

Capacidad para acceder a sitios remotos y transmitir consultas y datos a través de la red (procesamiento de consultas distribuidas)

Capacidad para idear estrategias de ejecución para transacciones (y consultas) que acceden a los datos desde más de un sitio, sincronizar el acceso a datos distribuidos y mantener integridad sobre toda la base de datos.

Capacidad para decidir a qué copia, de un elemento de datos replicado, acceder y para mantener la consistencia de las copias de los elementos de datos replicados (Gestión de datos replicados)

…Complejidad de las BDD: el SGBDD debe tener:

Capacidad para: recuperarse de caídas de nodos individuales y de “nuevos” tipos de fallos como el de los enlaces de comunicación (Recuperación de BDD).

Seguridad: las transacciones distribuidas se deben ejecutar con una gestión apropiada de seguridad de datos y privilegios de

autorización /acceso de usuarios.

Gestión del directorio (catálogo) distribuido: un directorio contiene información (metadatos) de los datos de la BD. El directorio puede ser global para toda la BDD, o local para cada sitio.

Para lograr todas las ventajas potenciales de la distribución, es necesario encontrar soluciones satisfactorias a las funciones expuestas anteriormente

2. Ventajas, Complejidad e Inconvenientes de la BDD

• Costo de desarrollo del software. La complejidad extra requerida para mantener la coordinación entre nodos hace que el desarrollo de software sea más costoso.

• Mayor probabilidad de errores. Como los nodos que constituyen el sistema funcionan en paralelo, es más difícil asegurar el funcionamiento correcto de los algoritmos y de los procedimientos de recuperación de fallos del sistema.

• Problemas de sincronización y detección de caídas de nodos. .

• Mayor sobrecarga de procesamiento. El intercambio de mensajes y ejecución de algoritmos para el mantenimiento de la coordinación entre nodos

supone una sobrecarga que no se da en los sistemas centralizados.

A continuación, se explicarán las técnicas para dividir la BD en unidades lógicas llamadas fragmentos, cuyo almacenamiento puede asignarse a los diversos sitios.

También se explicará la replicación de los datos, mediante la cual se pueden almacenar ciertos datos en más de un sitio, y el proceso de asignación de fragmentos, o de réplicas de fragmentos, para almacenarlos en los diferentes sitios.

Las técnicas mencionadas se utilizan durante el proceso de diseño de BDD.

La información concerniente a la fragmentación de los datos, la asignación y la replicación se almacena en un Directorio Global al que tiene acceso el SGBDD cuando sea necesario.

3. 3. Almacenamiento distribuido de datosAlmacenamiento distribuido de datos: : Fragmentación, Replicación y Asignación de Datos en el Diseño de BDD.

...Técnicas de Fragmentación, Replicación y Asignación de Datos

Fragmentación de Datos

Las unidades lógicas más simples son las propias relaciones, cada relación completa se almacenará en un sitio específico. En muchos casos, sin embargo, es posible dividir una relación en unidades lógicas más pequeñas llamadas fragmentos.

Hay dos tipos básicos de fragmentación:

fragmentación Horizontal fragmentación Vertical

Fragmentación horizontal Es un subconjunto de las tuplas de una relación formado por

aquellas tuplas que satisfagan una condición sobre uno o más de sus atributos (generalmente, sólo interviene un atributo). Los fragmentos pueden ser asignados a diferentes sitios del sistema distribuido.

Una condición de selección puede estar compuesta de varias condiciones conectadas por AND y OR.

fragmentación horizontal derivada: la fragmentación horizontal de una relación primaria se aplica a otras relaciones secundarias, que referencian a la primaria a través de una clave externa o foránea. De esta forma, los datos relacionados en ambos tipos de relación se fragmentan de la misma forma.


Fragmentación horizontal Derivada: Ejemplo Almacen(cod_almacen, dirección, teléfono, área) EMP( DNI, nombre, dirección, teléfono, función, localización,

cod_almacen) Producto(ref, nombre, descripción, cod_almacen)

Esta es la fragmentación horizontal para almacén

Almacensur= select * from almacen where area= ‘sur’ Almacennorte= select * from almacen where area= ‘Norte’

Esta es la fragmentación horizontal derivada para producto

productosur= select producto.* from producto, almacensur where producto.cod_almacen = almacensur.cod_almacen

productonorte= select producto.* from producto, almacennorte where producto.cod_almacen = almacennorte.cod_almacen

Esta es la fragmentación horizontal derivada para EMP

EMPsur= select EMP.* from EMP, almacensur where EMP.cod_almacen=almacensur.cod_almacen

EMPnorte= select EMP.* from EMP, almacennorte where EMP.cod_almacen=almacennorte.cod_almacen

Fragmentación horizontal....

Cada fragmento horizontal de una relación R se puede especificar como una operación “Restricción” o “Selección” del álgebra relacional ( Ci (R) ). Un conjunto de fragmentos horizontales cuyas condiciones C1, C2,…, Cn incluyan todas las tuplas de R (todas las tuplas satisfacen C1 OR C2… OR Cn) se denomina fragmentación horizontal completa de R.

En muchos casos, una fragmentación horizontal completa es además disjunta; es decir, ninguna tupla de R satisface Ci AND Cj para cualquier i<>j. Para reconstruir la relación R a partir de una fragmentación horizontal completa, es necesario aplicar la operación Unión a los fragmentos.


DNI Escuela Nombre Nota ingreso Beca

87633483 EUI Concha Queta 5.6 No

99855743 EUI Josechu Letón 7.2 Si

33887293 EUIT Oscar Romato 6.1 Si

05399075 EUI Bill Gates 5.0 No

44343234 EUIT Pepe Pótamo 8.0 No

44543324 EUI Maite Clado 7.5 Si

66553234 EUIT Ernesto Mate 6.6 No

2. Almacenamiento distribuido de datos2. Almacenamiento distribuido de datos

Fragmentación de datos

Fragmentación horizontal: Ejemplo.

Tabla inicial de alumnos de la UPM (T)

2. Almacenamiento distribuido de datos2. Almacenamiento distribuido de datos



99855743 EUI JosechuLetón 7.2 Si



DNI Escuela Nombre Nota ingreso

Beca

33887293 EUIT Oscar Romato

6.1 Si

44343234 EUIT Pepe Pótamo

8.0 No

66553234 EUIT Ernesto Mate

6.6 No

Fragmento de la EUIT: Escuela="EUIT"(T)

Fragmento de la EUI: Escuela="EUI"(T)

Fragmentación de datos

Fragmentación horizontal: Ejemplo.

Fragmentación vertical Es un subconjunto de una relación creado a partir de un

subconjunto de sus columnas. Será necesario incluir el atributo de clave primaria o clave candidata en todo fragmento vertical para poder reconstruir una relación a partir de sus fragmentos.

Un fragmento vertical de una relación R se especifica con una operación “Proyección” del álgebra relacional (Li(R) ).

Un conjunto de fragmentos verticales cuyas listas de proyección L1, L2,…, Ln incluyan todos los atributos de R, compartiendo sólo el atributo de clave primaria de R, se denomina fragmentación vertical completa de R y satisface:

L1 L2 ... Ln = ATTRS (R), donde ATTRS (R) es el conjunto de atributos de R Li Lj = PK(R) para cq i<> j, donde PK(R) es la clave primaria de R

Para reconstruir R desde una fragmentación vertical completa se aplica la operación OUTER UNION.


2. Almacenamiento distribuido de datos2. Almacenamiento distribuido de datos Fragmentación de datos

Fragmentación vertical:Ejemplo Departamento Infraestructura

Datos Rectorado (tabla R)

Departamento Ordenación Académica

Escuela, Ubicación(R)

Escuela,Número_alumnos(R)

Escuela Número alumnos

EUI 3000

EUIT 2800

TOPOGRAFIA 800

ETSIT 2500

FI 2100

Ubicación Número alumnos Escuela

EUI Campus sur 3000

EUIT Campus sur 2800

Topografía Campus sur 800

ETSIT Ciudad Universitaria 2500

FI Campus Montegancedo 2100

Ubicación Escuela

EUI Campus sur

TOPOGRAFIA Campus sur

ETSIT Ciudad Universitaria

FI Campus Montegancedo

EUIT Campus sur

Fragmentación mixta o Híbrida Este tipo de fragmentación surge cuando los dos tipos

anteriores se combinan. En tal caso, la relación original puede reconstruirse aplicando las operaciones de Unión y Reunión Externa en el orden apropiado.

En general, un fragmento de una relación R se puede especificar con una combinación de operaciones Seleccionar-Proyectar ( Li(Ci (R)) ).

Si C = True (Selecciono todas las tuplas) y si L ≠ ATTRS(R) es fragmento vertical

Si C ≠ True and L = ATTRS(R) es fragmento horizontal Si C ≠ True and L ≠ ATTRS(R) es fragmento mixto Si C = True and L = ATTRS(R) R es considerada como un fragmento *

* Es válido aclarar que una relación completa puede considerarse también como un fragmento.


2. Almacenamiento distribuido de datos2. Almacenamiento distribuido de datosFragmentación de datos

Fragmentación Mixta: Un Ejemplo

DNI Escuela

Nombre Beca87633483 EUI Concha Queta No Secretaría 99855743 EUI Josechu Letón Si 0539907 EUI Bill Gates No 44543324 EUI Maite Clado Si

DNI,Escuela,Nombre,Beca(E) Datos EUI (tabla E)

Resultante de una fragmentación horizontal previa



99855743 EUI Josechu Letón 7.2 Si



DNI,Escuela,Nombre,Nota ingreso(E)

DNI Escuela Nombre Nota ingreso

87633483 EUI Concha Queta 5.6

99855743 EUI JosechuLetón 7.2 Jefatura estudios

05399075 EUI Bill Gates 5.0

44543324 EUI Maite Clado 7.5

Otro concepto de importancia es el de Esquema de Fragmentación de BD, que es la definición de un conjunto de fragmentos que incluye a todos los atributos y tuplas de la base de datos. Dicho esquema satisface la condición de que la BD completa se puede reconstruir, a partir de los fragmentos, mediante alguna secuencia de operaciones de Reunión Externa (OUTER JOIN)- y Unión.

Por otro lado, un Esquema de Asignación describe la asignación de fragmentos entre los sitios del SBDD; por tanto, es una correspondencia que especifica el sitio o los sitios donde se almacena cada fragmento. Si un Si un fragmento se almacena en más de un sitio, se dice que fragmento se almacena en más de un sitio, se dice que está replicadoestá replicado. A continuación se explican la replicación y asignación de datos.


Almacenamiento distribuidoAlmacenamiento distribuido: Fragmentación, Replicación y Asignación de Datos...

Réplicación de Datos:Réplicación de Datos:

El sistema conserva varias copias o réplicas idénticas de una tabla. Cada

réplica se almacena en un nodo diferente.

Ventajas:

Disponibilidad: el sistema sigue funcionando aún en caso de caída de un

o de los nodos.

Aumento del paralelismo: Varios nodos pueden realizar consultas en par

alelo sobre la misma tabla. Además cuantas más réplicas existan de la ta

bla, mayor será la posibilidad de que el dato buscado se encuentre en el n

odo desde el que se realiza la consulta, minimizando el tráfico de datos e

ntre nodos.

Desventajas:

Aumento de la sobrecarga en las actualizaciones: El sistema debe asegurar que todas las réplicas de una tabla sean consistentes (los cambios deben propagarse a todas las réplicas)

Replicación de Datos Replicación completa: toda la BD es replicada en todos los sitios. Esto mejora la disponibilidad notablemente porque el sistema puede

seguir operando mientras, por lo menos, uno de los sitios esté activo.

También mejora el rendimiento de las consultas globales, por que el resultado de dicho tipo de consulta se puede obtener localmente en cualquier sitio.

La desventaja de la replicación completa es que reduce la rapidez de las operaciones de actualización, pues una actualización lógica deberá ejecutarse en todas y cada una de las copias de la BD a fin de mantener la consistencia.

Con la replicación completa, las técnicas de control de concurrencia y recuperación se vuelven más costosas de lo que serían sin replicación.

Replicación parcial: algunas partes seleccionadas de la BD son replicadas en algunos sitios.

La replicación de datos se define a través de un esquema de replicación.

Almacenamiento distribuidoAlmacenamiento distribuido: Fragmentación, Replicación y Asignación de Datos...

Asignación de Datos es un tema relevante sólo si se usa replicación parcial.

Lo opuesto a la replicación completa es no tener ninguna replicación. En este caso todos los fragmentos deben ser disjuntos, con excepción de la repetición de claves primarias en los fragmentos verticales (o mixtos). Esto se denomina asignación no redundante.

Entre estos dos extremos, existe una amplia gama de replicación parcial de los datos. Se denomina Esquema de Replicación a una descripción de la replicación de los fragmentos.

Cada fragmento, o copia de un fragmento se debe asignar a un determinado sitio del sistema distribuido. Este proceso se denomina Distribución o Asignación de los Datos.

La elección de sitios y el grado de replicación dependen de los objetivos en cuanto a rendimiento y disponibilidad del sistema y de los tipos y frecuencias de transacciones previstas para cada sitio.

Encontrar una solución óptima, o incluso buena, para la asignación y replicación de datos distribuidos es un problema de optimización muy complejo.

Almacenamiento distribuidoAlmacenamiento distribuido: Fragmentación, Replicación y Asignación de Datos

Fragmentación y distribución de la BD “Empresa”. Una empresa tiene tres sitios. Los sitios 2 y 3 corresponden a los departamentos 5 y 4 respectivamente.

Se espera que en cada sitio haya un acceso frecuente a la información de Empleados y Proyectos del Dpto. correspondiente. Además, supongamos que en estos sitios (2 y 3) se tiene acceso principalmente a los siguientes atributos:

Nombre, NSS, Salario y NSS_Superv de Empleado.

El sitio 1 lo usa la oficina central de la empresa y tiene acceso con regularidad a toda la información de empleados y proyectos, además de utilizar la información de Dependiente.

Asignación de fragmentos en sitios: (a) Fragmentos de relaciones en el sitio 2 correspondientes al Dpto. 5 (b) Fragmentos de relaciones en el sitio 3 correspondientes al Dpto. 4

...Técnicas de Fragmentación, Replicación y Asignación de Datos: Ejemplo 2

Esquema para la base de datos relacional EMPRESA (claves primarias subrayadas).

...Técnicas de Fragmentación, Replicación y Asignación de Datos: Ejemplo 2…

De acuerdo con los requisitos, es conveniente almacenar la BD completa en el sitio 1.

...Técnicas de Fragmentación, Replicación y Asignación de Datos: Ejemplo 2…

Para generar los fragmentos correspondientes al sitio 2 y al sitio 3, primero se puede fragmentar horizontalmente Departamento por su clave (NúmeroD).

Después se aplica fragmentación derivada a las relaciones Empleado, Proyecto y Localizaciones_Dept según la clave foránea (presente en todas ellas) que refiere a un número de departamento.

Después se pueden fragmentar verticalmente los fragmentos resultantes de Empleado para incluir sólo los atributos:

{Nombre, NSS, Salario, NSS_Superv, ND}. La figura muestra los fragmentos mixtos EMPD5 y EMPD4, que

contienen las tuplas Empleado que satisfacen las condiciones ND=5 y ND=4, respectivamente.

Los fragmentos horizontales de Proyecto, Departamento y Localizaciones_Dept se fragmentan de manera similar por número de departamento.

Todos estos fragmentos, almacenados en los sitios 2 y 3, están replicados porque también se almacenan en el sitio 1 que es la oficina central.

...Técnicas de Fragmentación, Replicación y Asignación de Datos: Ejemplo 2

(a) Fragmentos en el sitio 2 correspondientes al Departamento 5

(b) Fragmentos en el sitio 3 correspondientes al Departamento 4

Transparencia de la red:Transparencia de la red: Denominación de los elementos de datos

▪ Se trata de dar un nombre único a los elementos de datos en las relaciones, fragmentos y réplicas.

Denominación centralizada de elementos: Los elementos son registrados en un único nodo llamado servidor de nombres central

Desventajas: Cuello de botella al acceder a los nombres de los elementos.

Si falla el servidor de nombres, es posible que ningún nodo siga funcionando.

Denominación distribuida de fragmentos: Cada elemento usa como prefijo el nodo en el que se encuentra. Cada fragmento y réplica debe ser identificado de forma única mediante sufijos.

Ejemplo: Eui.ALUMNOS.f3.r2 hace referencia a la réplica 2 del fragmento 3 del elemento ALUMNOS del nodo EUI.Se pierde transparencia de la red. Se usa un sistema de alias para recuperar la transparencia. Las tablas de conversión de alias deben estar en todos los nodos.Una tabla en el catálogo permite al sistema: determinar en qué fragmentos o réplicas están los datos que el usuario solicita y mantener las réplicas actualizadas cuando se modifican los datos

Procesamiento distribuido de consultas Procesamiento distribuido de consultas

Se estudia el costo de las comunicaciones.

Objetivo: la reducción de la cantidad de datos transferidos

Optimización mediante operación de semijoinRecordar que el semijoin (por izquierda) puede expresarse, usando natural join, como:

R ⋉ S = Πa1,..,an (R ⋈ S) ; donde a1, ..., an son atributos de R

⋊ semijoin por derecha

Procesamiento distribuido de consultasProcesamiento distribuido de consultas

Ejemplo de consulta distribuida NODO1: EMPLEADO

Dir Sexo

Sueldo

fecha Nac.

Dpto.

Nombre Apellido COD

10.000 tuplas.

Cada tupla tiene 100 bytes de longitud.

El campo COD tiene 9 bytes de longitud.

El campo Dpto tiene 4 bytes de longitud.

El campo Nombre tiene 15 bytes de longitud.

El campo Apellido tiene 15 bytes de longitud.

Tamaño de la relación: 100 * 10.000 = 106bytes

NombreDpto

NDpto

Responsable Edificio


Ejemplo de consulta distribuida

NODO2: DEPARTAMENTO

100 tuplas.

Cada tuplatiene 35 bytes de longitud.

El campo NombreDpto tiene 10 bytes de longitud.

El campo NDpto tiene 4 bytes de longitud.

El campo Responsable tiene 9 bytes de longitud.

Tamaño de la relación: 35 * 100 = 3500 bytes


Ejemplos de consulta distribuida:

“Por cada empleado, obtener el nombre del empleado y el nombre del departamento al que pertenece”

Q1(1): ΠNombre,Apellido,NombreDPto(EMPLEADO ⋈ DEPARTAMENTO)

La consulta se lanza desde el nodo3 (nodo respuesta) que no tiene datos implicados en la consulta. El resultado de ésta consulta constará de 10.000 tuplas. Cada tupla resultante será de una longitud de 40 bytes. El tamaño del resultado será por tanto de 400.000 bytes. Existen tres alternativas para resolver la consulta.

(1) Query (Q): Identificador de Consulta


Ejemplos de consulta distribuida

Primera alternativa:

Transferir, tanto la relación EMPLEADO, como la rel

ación DEPARTAMENTO al nodo respuesta (nodo3)

y realizar allí mismo la operación de join.

En éste caso se transfieren: 1.000.000 + 3.500 = 1.003.500 bytes.



Segunda alternativa:

Transferir la relación EMPLEADO al nodo2, ejecutar el join en este nodo y enviar el resultado al nodo3.

Esto implicaría transferir:

1.000.000 + 400.000 (resultado) = 1.400.000 bytes



Tercera alternativa:

Transferir la relación DEPARTAMENTO al nodo1, ejecutar el join en este nodo y enviar el resultado al nodo3.

En este caso, los bytes transferidos serán:

3.500 + 400.000 (resultado) = 403.500 bytes.

Procesamiento distribuido de consultasProcesamiento distribuido de consultasEjemplos de consulta distribuida

“Para cada departamento, obtener el nombre del departamento y el de su director”

Q2: ΠNombreDPto,Nombre,Apellido(DEPARTAMENTO ⋈ EMPLEADO)La consulta se lanza desde el nodo3. El resultado de ésta consulta constará de 100 tuplas (4.000 bytes).

Opción 1: transferimos las relaciones DEPARTAMENTO y EMPLEADO al nodo3. Se transfieren:

3.500 + 1.000.000 = 1.003.500 bytes.

Opción 2: transferimos la relación EMPLEADO al nodo2 y enviamos el resultado del join al nodo3. Se transfieren:

1.000.000 + 4.000 = 1.004.000 bytes.

Opción 3: transferimos la relación DEPARTAMENTO al nodo1 y enviamos el resultado del join al nodo3. Se transfieren:

3.500 + 4.000 = 7.500 bytes.

La Opción 2 es más optima

Procesamiento distribuido de consultasProcesamiento distribuido de consultasEjemplos de consulta distribuida

NUEVO SUPUESTO: las consultas anteriores se lanzan desde el nodo2

Opción 1: transferir la relación EMPLEADO al nodo2, realizar el join y presentar el resultado al usuario del nodo2. De ésta manera se transferirán el mismo número de bytes para la consulta Q1 y la Q2: 1.000.000 bytes.

Opción 2: transferir la relación DEPARTAMENTO al nodo1, realizar el join y enviar el resultado al nodo2. En este caso se transfieren:

Para Q1: 3.500bytes de DEPARTAMENTO y 400.000 de resultado = 403.500 bytes

Para Q2: 3.500bytes de DEPARTAMENTO y 4.000bytes de resultado = 7.500 bytes.

Procesamiento distribuido de consultas Procesamiento distribuido de consultas Proceso distribuido de consultas utilizando semijoin

Reducción del número de columnas antes de transferir a otro nodo.

• Se envía la columna con la que se va a realizar el join de una relación R al nodo donde se encuentra la otra relación, allí se realiza el join con la otra relación S

• Se envían las columnas implicadas en el resultado al nodo inicial y se vuelve a realizar el join con R.

• Sólo se transfieren las columnas de R que intervienen en la realización del join en una dirección y el subconjunto de columnas de S resultantes en la otra.

Procesamiento distribuido de consultasProcesamiento distribuido de consultasEj. de proceso distribuido de consultas utilizando semijoin en Q2

RECORDAR:

Q2: Para cada departamento, obtener el nombre del departamento y el de su director

NODO1: EMPLEADONODO2: DEPARTAMENTO

Paso 1.

Proyección de DEPARTAMENTO sobre atributos que van a intervenir en la operación de join y transferencia al nodo1.

F2: ΠResponsable(DEPARTAMENTO)

Tamaño resultante: 9 bytes del atributo Responsable por 100 tuplas de DEPARTAMENTO = 900 bytes transferidos del nodo2 al nodo1.


Paso 2.

Realización del join de los tuplas transferidas en el paso anterior. Transferencia del resultado del join de nuevo al nodo2. Se transfieren sólo los atributos necesarios para realizar el join final:

R2: ΠResponsable,Nombre,Apellido(F2 ⋈ EMPLEADO)

Tamaño: (9+ 15 + 15) * 100= 3900 bytes transferidos del nodo1 al nodo2

Total transferido: 900+3900= 4.800 bytes para Q2 (vs 7.500 bytes)

Ej. de proceso distribuido de consultas utilizando semijoin en Q2...

Recuperación Recuperación

Transacción distribuida correcta.

Se pueden producir fallos durante la ejecución de una transacción correcta si ocurre el caso de que al acceder a alguno de los nodos que intervienen en la transacción, dicho nodo falla.

Fallo de las conexiones de comunicación.

El sistema debe ser capaz de tratar los posibles fallos que se produzcan en las comunicaciones entre nodos. El caso más extremo es el que se produce cuando se divide la red. Esto puede producir la separación de la red en 2 ó más particiones; donde los nodos de cada particion pueden comunicarse entre si pero no con nodos de otras particiones.

Transacciones distribuidasTransacciones distribuidas

Protocolo de compromiso en dos fases. (Two phase commit protocol)

1.El coordinador envía una solicitud de voto (vote request) a los nodos participantes en la ejecución de la transacción.

2. Cuando reciben la solicitud de voto los participantes responden enviando al coordinador un mensaje con su voto (Sí o No). Si un participante vota No, la transacción se aborta (abort).

3. El coordinador recoge los mensajes con los votos de todos los participantes. Si todos han votado Sí, entonces el coordinador también vota por Si y envía un mensaje commit a todos los participantes. En otro caso, el coordinador decide abandonar y envía un mensaje abort a todos los participantes que han votado afirmativamente.

4. Cada participante que ha votado Sí, espera del coordinador un mensaje commit o abort para terminar la transacción de forma normal o abortarla.

En cuanto a productos disponibles... En cuanto a productos disponibles... ♦ Postgres ha innovado su tecnología constantemente, al punto de estar intentando crear BDDs, el desarrollo de dicha tecnología aún es pobre, pero con mucha tendencia a el crecimiento.

♦ Oracle utiliza el software de red Oracle Net 8 para comunicacion entre bases de datos. Net 8 permite a las BD comunicarse a través de redes para soportar transacciones distribuidas y remotas.

♦ Arquitectura Distribuida de Base de datos relacional (DRDA)

• Consiste en un sistema de protocolos para conectar múltiples DBMSs (IBM o no)

• Cualquier combinación de DBMSs relacionales que utilicen DRDA se pueden conectar para formar un sistema de gestión distribuido de BDR.

• DRDA coordina la comunicación entre los sistemas definiendo qué debe ser intercambiado y cómo debe ser intercambiado. Proporciona un ambiente de base de datos distribuido heterogéneo, abierto y robusto.

• DRDA describe sólo la arquitectura para los datos distribuidos (no la puesta en práctica). Define las reglas para tener acceso a los datos distribuidos, pero no proporciona los interfaces de programación reales (APIs) para realizar el acceso (DRDA son sólo especificaciones no programas).