BASES DE DATOS DISTRIBUIDAS

CYNTHIA ARRIETA

BIAIDYS BARRAZA

JOHANA GUERRERO

CARY LUZ PEREA

WILLIAM MEJÍA OROZCO

Docente

UNIVERSIDAD POPULAR DEL CESAR

FACULTAD DE INGENIERIAS Y TECNOLOGÍAS

BASE DE DATOS

VALLEDUPAR

2011

INTRODUCCION

El presente trabajo tiene como propósito conocer más acerca las bases de datos

distribuidas debido a que este es un tema nuevo lo cual hace necesario tener más

conocimiento de ello.

Una de las principales motivaciones para el desarrollo de sistemas de base de datos es el

acceso 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 usar 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, proyectos, etc., y están distribuidas de

modo físico en oficinas, fábricas e instalaciones, manteniendo cada una sus propios datos

operacionales.

Existen varios factores que han hecho que las bases de datos evolucionen a bases de datos

distribuidas. En el mundo de los negocios se ha dado una globalización y a la vez las

operaciones de las empresas son cada vez más descentralizadas geográficamente. Además

la necesidad de compartir datos ha hecho que crezca el mercado de las bases de datos

distribuidas.

INICIO DE LAS BASES DE DATOS DISTRIBUIDAS

Originalmente se almacenaba la información de manera centralizada, pero con el paso del

tiempo las necesidades aumentaron y esto produjo ciertos inconvenientes que no era

posible solucionarlos o volverlos eficientes de la forma centralizada. Estos problemas

impulsaron la creación de almacenamiento distribuido, los cuales hoy en día proveen

características indispensables en el manejo de información; es decir, la combinación de las

redes de comunicación y las bases de datos.

EVOLUCIÓN

Hay varios factores que han hecho que las bases de datos evolucionen a bases de datos

distribuidas. En el mundo de los negocios se ha dado una globalización y a la vez las

operaciones de las empresas son cada vez más descentralizadas geográficamente. También

el poder de las computadoras personales aumentó y el costo de los Mainframes ya no tenía

sentido. Además la necesidad de compartir datos ha hecho que crezca el mercado de las

bases de datos distribuidas.

UNA BASE DE DATOS DISTRIBUIDA (BDD)

Una base de datos distribuida (BDD) es un conjunto de múltiples bases de datos

lógicamente relacionadas las cuales se encuentran distribuidas en diferentes espacios

lógicos, (Por ejemplo: un servidor corriendo 2 maquinas virtuales) e interconectados por

una red de comunicaciones.

Dichas BDD tienen la capacidad de realizar procesamiento autónomo, esto permite

realizar operaciones locales o distribuidas.

Ejemplo:

CLASIFICACIÓN DE LAS BASES DE DATOS DISTRIBUIDAS

La base de datos distribuidas se clasifican en:

HOMOGÉNEAS O HETEROGÉNEAS: dependiendo de si todos los servidores utilizan el

mismo SGBD o no.

DE ÁREA LOCAL O DE ÁREA ANCHA: según sea la red de comunicaciones que conecta

los servidores.

CARACTERISTICAS DE LAS BASES DE DATOS DISTRIBUIDAS

Los datos deben estar físicamente en más de un ordenador.

Las sedes deben estar interconectadas mediante una red.

Los datos han de estar lógicamente integrados, tanto en local como remoto.

En una única operación se puede acceder datos que se encuentran en más de una sede.

Todas las acciones que necesiten realizarse sobre más de una sede serán transparentes al

usuario.

VENTAJAS Y DESVENTAJAS DE LAS BASES DE DATOS

DISTRIBUIDAS

VENTAJAS:

AUTONOMÍA: Cada nodo tiene cierto grado de control sobre sus datos, en un sistema

centralizado, hay un administrador del sistema responsable de los datos a nivel global.

Cada administrador local puede tener un nivel de autonomía local diferente.

FIABILIDAD Y DISPONIBILIDAD: La falla de uno o varios lugares o el de un enlace de

comunicación no implica la inoperatividad total del sistema, incluso si tenemos datos

duplicados puede que exista una disponibilidad total de los servicios.

COMPARTIMIENTO DE DATOS: Los usuarios de un nodo son capaces de acceder a los

datos de otro nodo. Por ejemplo, desde el Rectorado, se puede consultar los datos de los

alumnos de Informática.

AGILIZACIÓN DEL PROCESAMIENTO DE CONSULTAS: si una consulta comprende

datos de varias localidades, puede ser posible dividir la consulta en varias subconsultas q

se ejecuten en paralelo en distintas localidades.

DESVENTAJAS:

COSTE DE DESARROLLO DEL SOFTWARE: La implementación de un sistema

distribuido de bases de datos es más difícil y, por lo tanto, más costoso.

COMPLEJIDAD: juega en contra de este tipo de sistemas, pues muchas veces se traduce

en altos gastos de construcción y mantenimiento. Esto se da por la gran cantidad de

componentes Hardware, muchas cosas que aprender, y muchas aplicaciones susceptibles

de fallar. Por ejemplo, el control de concurrencia y recuperación de fallos, requiere de

personal muy especializado y por tal costoso.

SEGURIDAD: en un sistema centralizado, el acceso a los datos puede controlarse

fácilmente. por el contrario, en un SGBD distribuido no solo es necesario controlar el

acceso a los datos replicados en múltiples ubicaciones, sino q también es necesario dotar

de seguridad a la propia red. en el pasado, las redes se consideraban un medio de

comunicación inseguro. aunque esto continua siendo parcialmente cierto, diversos

desarrollos de gran importancia han incrementado considerablemente el nivel de

seguridad de las redes

FALTA DE EXPERIENCIA: los SGBD distribuidos de propósito general no han sido

aceptados ampliamente, aunque muchos de los protocolos y de los problemas se

comprendan a la perfección. en consecuencia, todavía no tenemos el mismo nivel de

experiencia en este sector q en el caso de los SGBD centralizados. para alguien q este

pensando en adoptar esta tecnología, este factor puede ser uno d los obstáculos

principales.

SISTEMA GESTOR DE BASE DE DATOS DISTRIBUIDAS (SGBDD)

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

permite 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.

CLASIFICACION DE SGBDD

BASES DE DATOS DISTRIBUIDAS HOMOGÉNEAS

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

conscientes 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 bases 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.

BASES DE DATOS DISTRIBUIDAS HETEROGÉNEAS

Sitios diferentes puede que utilicen esquemas diferentes y diferente software de gestión de

sistemas de bases de datos. Puede que unos sitios no sean conscientes de la existencia de

los demás y puede que sólo 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.

FUNCIONES DEL SISTEMA GESTOR DE BASE DE DATOS

DISTRIBUIDA

Poder acceder a sitios remotos.

Control de concurrencia.

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

Recuperación ante caídas.

Transmitir consultas y datos a través de redes de telecomunicaciones.

Rastrear la pista de distribución y replicación de los datos.

Capacidad de elaborar estrategias de ejecución.

Mantener la consistencia de las copias de un elemento de información.

Capacidad de decidir qué versión de la copia de un elemento de información es la que

tiene que ser accedida en un momento.

VENTAJAS DE UN SGBDD

REFLEJA MEJOR LA ESTRUCTURA ORGANIZACIONAL: Los fragmentos de la base de

datos se ubican en los departamentos a los que tienen relación.

LOS DATOS PUEDEN SER COMPARTIDOS: de tal manera que se pueden hacer

transacciones desde cualquier nodo si la estructura organizacional lo permite.

MEJORA LA DISPONIBILIDAD: los fragmentos de la base de datos se ubican en los

departamentos a los que tienen relación.

MODULARIDAD: se pueden modificar, agregar o quitar sistemas de la base de datos

distribuida sin afectar a los demás sistemas (módulos).

DESVENTAJAS DE UN SGBDD

COMPLEJIDAD: las dificultades que generalmente se encuentran al diseñar una base de

datos, el diseño de una base de datos distribuida debe considerar la fragmentación,

replicación y ubicación de los fragmentos en sitios específicos.

COSTO: la complejidad y la infraestructura necesaria implica que se necesitará una

mayor mano de obra.

FALTA DE EXPERIENCIA: las bases de datos distribuidas son un campo relativamente

nuevo y poco común por lo cual no existe mucho personal con experiencia o conocimientos

adecuados.

CARENCIA DE ESTÁNDARES: aún no existen herramientas o metodologías que ayuden a

los usuarios a convertir un DBMS centralizado en un DBMS distribuido.

LOS OBJETIVOS DE UN SGBDD

C. J. Date, propuso 12 objetivos que debían alcanzar los diseñadores en sus BDD junto

con sus SGBDD basándose en este principio fundamental.

“Los usuarios deben actuar de la misma forma tanto si están ante un sistema distribuido

como si están ante uno centralizado”.

1. AUTONOMÍA LOCAL: Los sitios de un sistema distribuido deben ser autónomos en el

mayor grado posible, lo que permite una mayor seguridad, control de concurrencia y

copias de seguridad. Por lo tanto, La autonomía local implica que en lo referente a la

integridad, seguridad y representación en almacenamiento de los datos locales

permanezcan bajo el control de la instalación local.

2. INDEPENDENCIA DE UN SITIO CENTRAL: Implica que todos los sitios deben ser

tratados como iguales, 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. EL SISTEMA DEBE ESTAR EN CONTINUA OPERACIÓN: Un fallo en uno de los

nodos no debe afectar al sistema. Tampoco si se añaden nuevos nodos. Así, un SD deberá

proporcionar 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.

4. TRANSPARENCIA DE UBICACIÓN: Para el usuario la localización física de los

datos debe ser transparente. No debe ser necesario que los usuarios sepan dónde están

almacenados físicamente los datos para poder utilizarlos.

5. TRANSPARENCIA DE FRAGMENTACIÓN: Los usuarios deben comportarse, como

si los datos en realidad no tuvieran fragmentación alguna. La cual es necesaria por

razones de rendimiento. Este objetivo es deseable, como el anterior, porque simplifica los

programas de los usuarios y sus actividades en el sitio.

6. TRANSPARENCIA EN LA REPLICACIÓN: Consiste en que el usuario no debe tener

conciencia de la replicación de los datos, así como de su destrucción. 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.

7. PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS: El sistema debe ser capaz de

procesar consultas que afecten a datos de más de un sitio y hacerlo de forma optimizada.

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. ADMINISTRACIÓN DE TRANSACCIONES DISTRIBUIDAS: El sistema distribuido

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 múltiples sitios se están

viendo afectados por la transacción.

9. INDEPENDENCIA DEL HARDWARE: Es necesario tener la posibilidad de ejecutar

el mismo SGBDD en diferentes plataformas de hardware (IBM, ICL, HP, PC, SUN) y,

además, hacer que esas máquinas diferentes participen de igual forma en un sistema

distribuido.

10. INDEPENDENCIA DEL SISTEMA OPERATIVO: Un vez más, es necesario tener la

posibilidad de ejecutar el mismo SGBDD, en diferentes plataformas de sistema operativo

(UNIX, Windows XP) bajo un mismo sistema distribuido. Es obvia la conveniencia no sólo

de poder ejecutar el mismo DBMS en diferentes equipos, sino también poder ejecutarlo en

diferentes sistemas operativos.

11. INDEPENDENCIA DE LA RED: El sistema debe tener la posibilidad de soportar

también, una variedad de redes de comunicación distintas. Si el sistema ha de poder

manejar múltiples sitios diferentes, con equipo distinto y diferentes sistemas operativos,

resulta obvia la conveniencia de poder manejar también varias redes de comunicación

distintas.

12. INDEPENDENCIA DEL SGBD: Lo que en realidad se pretende es que todos los

ejemplares del SGBDD locales en sitios diferentes soporten la misma interface, que en este

caso sería el estándar SQL oficial.

PROCESAMIENTO DISTRIBUIDO

El procesamiento distribuido: es muy importante entender la diferencia entre un sistema

gestor de base de datos distribuido y el procesamiento distribuido. El procesamiento

distribuido es una base de datos centralizada a la que se puede acceder a través de una

red informática.

El punto clave en la definición de un SGBD distribuido es q el sistema está compuesto por

datos q esta n fisilmente distribuidos entre una serie de nodos de la red. Si los datos están

centralizados, aunque otros usuarios estén accediendo a los datos a través de la red. No

consideremos q se trate de un SGBD distribuido, sino simplemente de un sistema de

procesamiento distribuido.

CONSIDERACIONES AL DISTRIBUIR LA BASE DE DATOS

Existen varias razones para construir sistemas distribuidos de base de datos q incluyen

compartir la información, fiabilidad, disponibilidad y agilizar el procesamiento de las

consultas. Sin embargo, estas ventajas vienen acompañadas de varias desventajas. Como

son la complejidad, coste de desarrollo de software, seguridad, y falta de experiencia.

RECUPERACIÓN EN SISTEMAS DISTRIBUIDOS

TRANSACCIÓN: es una secuencia de una o más operaciones agrupadas como una unidad.

El inicio y el final de la transacción definen los puntos de consistencia de la base de datos.

Si una acción de la transacción no se puede ejecutar, entonces ninguna acción dentro de la

secuencia que conforma la transacción tendrá efecto.

CONSISTENCIA: Si se ejecuta una transacción sobre un estado consistente, el resultado

será un nuevo estado consistente.

CLASIFICACIÓN DE LAS TRANSACCIONES

Solicitud remota

Unidad de trabajo remota

Unidad de trabajo distribuida

Solicitud distribuida

ESTRUCTURA DE SISTEMA

COORDINADOR DE TRANSACCIONES: Su función es la de coordinar la ejecución de

varias transacciones (tanto local como global) iniciadas en esa localidad.

GESTOR DE TRANSACCIONES: Su función es gestionar la ejecución de aquellas

transacciones (o subtransacciones) que accedan a datos almacenados en esa localidad.

Cada gestor de transacción se encarga de:

Mantener una bitácora para la recuperación.

Participar en un esquema de control de concurrencia apropiado para coordinar la

ejecución en paralelo de las transacciones que se ejecuten en esa localidad.

Cada coordinador debe:

Iniciar la ejecución de la transacción

Dividir la transacción en varias subtransacciones, las cuales a de distribuir en las

localidades apropiadas para su ejecución.

Coordinar la terminación de la transacción, ya sea que quede ejecutada o abortada en

todas las localidades.

ROBUSTEZ

Para que un sistema sea robusto, es necesario que detecte cualquier fallo, que reconfigure

el sistema de manera que pueda reanudarse el proceso y que se recupere una vez que haya

sido reparado el procesador o la línea de comunicación afectados.

MANEJO DE BLOQUEOS

El principal problema en un sistema distribuido será decidir cómo se va a mantener el

grafo de espera. Algunos esquemas de uso común para organizar el grafo de espera en un

sistema distribuido.

TIPOS DE TRANSACCIONES

LOCALES: Cuando se accede a los datos del único emplazamiento donde se inició la

transacción

GLOBALES: Cuando se accede a datos de emplazamientos distintos al nodo donde se

inició la transacción

DISEÑO DE BASE DE DATOS DISTRIBUIDAS

El diseño de base de datos distribuidas se ocupa de tomar decisiones en la ubicación de

programas que accederán a la base de datos y sobre los propios datos que la constituyen, a

lo largo de los diferentes nodos que constituyen la red.

Existen 3 tipos de almacenamiento que son:

REPLICA DE LOS DATOS

Si la relación r se replica, se guarda una copia de dicha relación en dos o más sitios. En el

caso más extremo se tiene una réplica completa, en la que se guarda una copia en cada

sitio del sistema.

Hay varias ventajas y inconvenientes en las réplicas.

VENTAJAS:

DISPONIBILIDAD: Si alguno de los sitios que contiene la relación r falla, la relación

puede hallarse en otro sitio distinto. Por tanto, el sistema puede seguir procesando las

consultas que impliquen a r, pese al fallo del sitio.

MAYOR PARALELISMO: En caso de que la mayoría de los accesos a la relación r sólo

resulten en la lectura de la relación, varios sitios pueden procesar en paralelo las lecturas

que impliquen a r. Cuantas más réplicas de r haya, mayor será la posibilidad de que los

datos necesarios se hallen en el sitio en que se ejecuta la transacción. Por tanto, la réplica

de los datos minimiza el movimiento de los datos entre los sitios.

Inconvenientes:

MAYOR TIEMPO EXTRA PARA ACTUALIZACIONES: El sistema debe asegurar que

todas las réplicas de la relación r sean consistentes; en caso contrario pueden producirse

cómputos erróneos. Por eso, siempre que se actualiza r, hay que propagar la actualización

a todos los sitios que contienen réplicas. El resultado es una sobrecarga incrementada. Por

ejemplo, en un sistema bancario, en el que se replica en varios sitios la información de las

cuentas, es necesario asegurarse de que el saldo de cada cuenta concuerde en todos los

sitios.

En general, la réplica mejora el rendimiento de las operaciones leer y aumenta la

disponibilidad de los datos para las transacciones sólo de lectura. No obstante, las

transacciones de actualización suponen una mayor sobrecarga.

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.

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.

TIPOS DE FRAGMENTACIÓN

FRAGMENTACIÓN HORIZONTAL

Esta compuesta de un subconjunto de las tuplas de una relación.

La relación r se divide en cierto número de subconjuntos r1, r2, rn. Cada tupla de la

relación r debe pertenecer al menos a uno de los fragmentos, de modo que se pueda

reconstruir la relación original si fuera necesario.

Un fragmento puede definirse como una selección de la relación global r. Es decir, se

utiliza un predicado Pi para construir un fragmento ri de la manera siguiente:

ri = σPi (r)

Se puede obtener la reconstrucción de la relación r tomando la unión de todos los

fragmentos, es decir:

r = r1 U r2 U .... U rn

EJEMPLO:

deposito1 = σnombre-sucursal=”Guadarrama” (deposito)

deposito2 = σnombre-sucursal=”Cercedilla” (deposito)

Los dos fragmentos se muestran a continuación:

FRAGMENTACIÓN VERTICAL:

Está compuesta de un subconjunto de los atributos de una relación.

La fragmentación vertical de r(R) implica la definición de varios subconjuntos de atributos

R1, R2,..., Rn del esquema R tales que:

R = R1 U R2 U ... U Rn

Cada fragmento ri de r queda definido por

ri = ΠRi (r)

La fragmentación debe hacerse de modo que se pueda reconstruir la relación r a partir de

los fragmentos tomando la reunión natural:

Ejemplos:

Esquema-depósito-1 = (nombre-sucursal, nombre-cliente, id-tupla).

Esquema-depósito-2 = (número-cuenta, saldo, id-tupla).

Para reconstruir la relación depósito original a partir de los fragmentos hay que procesar:

FRAGMENTACIÓN MIXTA:

Este tipo de fragmentación consiste en la aplicación de fragmentación vertical y después

fragmentación horizontal o viceversa.

REPLICA Y FRAGMENTACIÓN

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.

DISTRIBUCIÓN DE LA INFORMACIÓN DE NODOS

NODOS: Un nodo es una computadora que ejecuta un DTM (ADMINISTRADOR DE

TRANSACCIONES DISTRIBUIDAS), un DBM (ADMINISTRADOR DE LA BASE DE

DATOS), o inclusive ambos. Un nodo de transacción procesa un DTM, y un nodo de base

de datos procesa un DBM y su base de datos.

COMUNICACIÓN ENTRE NODOS

Un nodo es una computadora que ejecuta un DTM, un DBM, o inclusive ambos. Un nodo

de transacción procesa un DTM, y un nodo de base de datos procesa un DBM y su base de

datos': En la Figura, el Nodo W es un nodo de base de datos ejecutando DBMwY

almacenando BDw. El Nodo X es tanto un nodo de transacción como de base de datos con

DTMx' DBMx y BDx. De modo similar, el Nodo Y es tanto un nodo de transacción como de

base de datos, pero el Nodo Z es solamente un nodo de transacción.

Los programas de consulta o de transacción se comunican con los DTM a través de

solicitudes parecidas a las solicitudes de acción del DBMS. Ejemplos son SELECT

EMPLOYEE WHERE E# EQ 123 o bien STORE DUE-DATE. Estas solicitudes operan

sobre estructuras lógicas. El programa de consulta o de aplicación no se refiere a ninguna

instancia física en particular de la estructura.

CONCLUSIÓN

La implementación de las base de datos distribuidas se dio por la necesidad de ubicar los

sistemas de información de base de datos distribuida de una forma global, y cambiar el

esquema centralizado ya este nuevo esquema facilito el acceso a los datos desde distintos

puntos o en distintas zonas geográficas, esta implementación trajo consigo algunas

desventajas, pero a través de una correcta administración y de algoritmos de detección de

fallos, nos ofrecen muchos más beneficios en comparación con las desventajas.