BASES DE DATOS DISTRIBUIDAS
BASE DE DATOS DISTRIBUIDAS
Llamamos base de datos distribuidas a los
fragmentos que se encuentran almacenados en
lugares distintos. Estos sitios constan con una
computadora y una DBMS (Sistema de gestión de
base de datos), para administrar la base local
situada conectándose entre sí aquellos fragmentos
de una base distribuida por medio de una red de
comunicación.
BASE DE DATOS DISTRIBUIDAS
Definición:
Consiste en una colección de sitios, conectados por medio
de algún tipo de red de comunicación, en el cual
Cada sitio es un sistema de BD completo por derecho
propio, pero
Los sitios ha acordado trabajar juntos, a fin de que un
usuario de cualquier sitio pueda acceder a los datos desde
cualquier lugar de la red, exactamente como si los datos
estuvieran guardados en el propio sitio del usuario.
Definición:
Una BDD es en realidad un tipo de BD virtual cuyas partes
componentes están almacenadas en varias BD “reales” distintas
que se encuentran en varios sitios distintos (de hecho, es la
unión lógica de esas BD reales).
BASE DE DATOS DISTRIBUIDAS
En otras palabras, sus características principales de cada sitio
son
Sus propias BD “reales”
◦ Sus propios usuarios locales
◦ Su propio DBMS local
◦ Software de administración de transacciones (incluyendo su
propio software local para bloqueo, registro en bitácora,
recuperación, etc.)
◦ Así como su propio administrador de comunicación de datos
local.
Es común suponer que los sitios componentes están dispersos
físicamente – quizá también dispersos geográficamente -,
aunque de hecho basta con que estén dispersos lógicamente.
Dos “sitios” pueden incluso coexistir en la misma máquina física.
BASE DE DATOS DISTRIBUIDAS
ARQUITECTURA DE BASES DE DATOS
DISTRIBUIDAS
Nodo w
DBMw BDw
Nodo x
Programa de
consulta o DTMx DBMx BDx
transacción
Nodo y
Programa de
consulta o DTMy DBMy BDy
transacción
Nodo z
Programa de DDB
consulta o DTMz
transacción
Interfaz de acción
Interfaz de solicitud DDBMS
ARQUITECTURA DE BASES DE DATOS DISTRIBUIDAS
1. El sistema de administración de base de datos distribuida
(DDBMS), está formado por las transacciones y los administradores
de base de datos distribuidos de todas las computadoras. Tal y como
se muestra, tal DDBMS es un esquema genérico que implica un
conjunto de programas que operan en diversas computadoras. Estos
programas pueden ser subsistemas de un producto único DDBMS,
concesionado por un sólo fabricante, o también pudiera resultar una
colección de programas de fuentes dispares: algunos concesionados
por fabricantes, y algunos otros escritos en casa. El propósito de
esta figura es ilustrar las funciones que deban atenderse en el
procesamiento de bases de datos distribuidas.
2. Un administrador de transacciones distribuidas (DTM) es un
programa que recibe solicitudes de procesamiento de los programas
de consulta o de transacciones ya su vez las traduce en acciones
para los administradores de la base de datos. Una función
importante del DTM es coordinar y controlar dichas acciones.
Dependiendo de la naturaleza de la aplicación del DDBMS, el DTM
puede ser proporcionado como parte de DDBMS o puede
desarrollarse en casa por la organización que pone en práctica el
sistema distribuido. En aplicaciones menos complejas, una parte de
sus funciones puede ser llevada a cabo por personas, siguiendo sólo
procedimientos manuales.
ARQUITECTURA DE BASES DE
DATOS DISTRIBUIDAS
3. Un administrador de la base de datos
(DBM) es un programa que procesa cierta
porción de la base de datos distribuida, como es
el hecho de recuperar y actualizar datos del
usuario y generales, de acuerdo con comandos
de acción recibidos de los DTM. El DBM puede
ser un subconjunto de un producto DDBMS, o
ser también un DBMS comercial no distribuido.
En algunos casos, el DDBMS pudiera contener
diferentes productos DBMS.
Ventajas Bases Datos D.
¿Por qué son necesarias las BDD?
1. Distribución Lógica: La respuesta es que las
empresas ya están generalmente distribuidas al menos
de manera lógica (en divisiones, departamentos,
grupos de trabajo, etc.) Y es muy probable que
también lo estén de manera física (en plantas, fábricas,
laboratorios, etc.); De esto deducimos que por lo
general también los datos ya están distribuidos Ya que
cada unidad organizacional dentro de la empresa
mantendrá los datos que son importantes para su
propia operación
Por lo tanto, el valor de la información total de la
empresa está divido en lo que a veces llamamos “islas
de información”
2. Proporciona puentes de integración: que hace un
Sistema Distribuido es proporcionar los puentes
necesarios para conectar a esas islas entre sí
Ventajas Bases Datos D.
3. Acceso mas Rápido :En otras palabras, permite que
la estructura de la BD refleje la estructura de la
empresa – los datos locales son conservados
localmente en el lugar donde pertenecen de manera
más lógica Y al mismo tiempo, permite tener acceso a
datos remotos cuando sea necesario.
4. El arreglo distribuido combina eficiencia de
procesamiento (los datos se mantienen cerca del
punto en donde se usan más frecuentemente).
5. Con una mayor accesibilidad (es posible acceder a
una cuenta remota y viceversa, por medio de la red de
comunicaciones).
6.Probablemente el mayor beneficio de los sistemas
distribuidos es que permiten que la estructura de la BD
refleje la estructura de la empresa
Desventajas Bases Datos D.
La mayor desventaja es el hecho de que los
sistemas distribuidos son complejos (al menos
desde el punto de vista técnico).
Por supuesto, de manera ideal esa complejidad
debe ser problema del implementador y no del
usuario.
Pero es probable que algunos aspectos
aparecerán ante los usuarios, a menos que se
tomen precauciones muy cuidadosas
2. Altos costos en infraestructura
TIPOS DE BASES DE DATOS DISTRIBUIDAS
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.
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.
Formas de almacenamiento o
distribución de los datos en una
BDD
Réplica.
Fragmentación.
Réplica y fragmentación
Centralizada
ALMACENAMIENTO DISTRIBUIDO DE DATOS
Replica
◦ Consiste en mantener una copia exacta de una relación o parte
de ella en más de un sitio, la réplica completa se produce
cuando se copia la relación en todos los sitios.
◦ Una BD completamente redundante es aquella en la que cada
sitio contiene una réplica completa de la BD.
Ventajas
◦ Disponibilidad: La falla del sitio donde se ubica la relación R
no resulta en la indisponibilidad de los datos de R.
◦ Paralelismo: múltiples consultas de lectura sobre R pueden
ser procesadas en paralelo por varios sitios.
◦ Trasferencia de Datos Reducida: Solo las actualizaciones en
R provocan que varios datos sean transferidos por la red.
ALMACENAMIENTO DISTRIBUIDO DE DATOS
Desventajas
◦ Costo de Actualización Incrementado: cada replica
de R debe ser actualizada, lo cual puede provocar un alto
tráfico en la red
◦ Sobrecarga incrementada durante la actualización.
◦ Se puede simplificar la gestión de las réplicas de la
relación r escogiendo una de ellas como copia principal
de r. Por ejemplo, en un sistema bancario, las cuentas
pueden asociarse con el sitio en que se abrieron.
◦ Complejidad de Control de Concurrencia
Aumentada: la actualización concurrente de las réplicas
requiere implementar mecanismos especiales de control
de concurrencia.
Fragmentación
El problema de fragmentación se refiere al
particionamiento de la información para distribuir
cada parte a los diferentes sitios de la red.
El objetivo de la fragmentación consiste en dividir
la relación en un conjunto de relaciones más
pequeñas tal que algunas de las aplicaciones de
usuario sólo hagan uso de un fragmento.
Sobre este marco, una fragmentación óptima es
aquella que produce un esquema de división que
minimiza el tiempo de ejecución de las
aplicaciones que emplean esos fragmentos. La
unidad de fragmentación ideal no es la tabla sino
una subdivisión de ésta.
Fragmentación de los datos
La fragmentación horizontal
La fragmentación vertical
Transparencia
No se debe exigir a los usuarios de los sistemas distribuidos de
bases de datos que conozcan la ubicación física de los datos ni
el modo en que se puede tener acceso a ellos en un sitio local
concreto.
•Transparencia de la fragmentación
•Transparencia de la réplica
•Transparencia de la ubicación
Fragmentación de los datos
Tipos de fragmentación de datos
Existen tres tipos de fragmentación:
Fragmentación horizontal
Fragmentación vertical
Fragmentación híbrida
Fragmentación horizontal
La fragmentación horizontal de una relación R produce una serie
de fragmentos R1, R2, ..., Rr, cada uno de los cuales contiene un
subconjunto de las tuplas de R que cumplen determinadas
propiedades (predicados) o sea que cada fila o tupla de R es
asignado a uno o más fragmentos
Ri = σ < condición i > ( R )
R = R1 U R2 U … U Rn
Fragmentación de los datos
Fragmentación horizontal primaria y derivada
La Fragmentación Horizontal Primaria (FHP) de una relación se
obtiene usando predicados que están definidos en esa relación.
La Fragmentación Horizontal Derivada (FHD) por otra parte, es el
particionamiento de una relación como resultado de predicados que
se definen en otra relación. Ejemplo:
Fragmentación de los datos
Fragmentación vertical
El esquema de la relación R es partido en dos o más
subesquemas.
Todo los subesquemas deben contar con una clave candidata que
permita la reunión natural de los fragmentos
Se puede usar el id de la tuplas como clave de reunión, de esta
manera todos los subesquemas deben contener este atributo.
Ri = π < subesquema i > (R)
R = R1 join R2 join … join Rn
Ventajas de la fragmentación
Permitimos el procesamiento concurrente de transacciones ya que no
se bloquean tablas enteras sino subtablas, por lo que dos consultas
pueden acceder a la misma tabla a fragmentos distintos.
Permitimos la paralelizarían de consultas al poder descomponerlas en
subconsultas, cada una de la cuales trabajará con un fragmento
diferente incrementándose así el rendimiento.
Horizontal
Permite el procesamiento en paralelo de los fragmentos de una
relación.
Permite que las tuplas se ubiquen el sitio donde son más
frecuentemente accedidas.
permite que una tabla global pueda estar donde se utiliza más
frecuentemente
Vertical
Permite que los fragmentos sean almacenados en el sitio más
apropiado para la información.
Permite el procesamiento paralelo sobre una relación.
permite descomposiciones adicionales que se pueden conseguir
con normalización.
el atributo especial facilita la mezcla de fragmentos verticales.
Desventajas de la fragmentación
Degradación del rendimiento en vistas definidas sobre varios
fragmentos ubicados en sitios distintos (es necesario realizar
operaciones con esos trozos lo cual es costoso)
El control semántico se dificulta y el rendimiento se degrada
debido que la verificación de restricciones de integridad (claves
ajenas, uniques, etc) implican buscar fragmentos en múltiples
localizaciones.
El principio fundamental nos
conduce a 12 reglas u
objetivos:
Principios
1.- Autonomía local. Los sitios en un sistema distribuido deben
ser autónomos.
◦ La autonomía local significa que todas las operaciones en un
sitio dado están controladas por ese sitio; ningún sitio X debe
depender de algún otro sitio Y para su operación satisfactoria.
◦ La seguridad, integridad y representación de almacenamiento
de los datos locales permanecen bajo el control y jurisdicción
del sitio local.
2.- No dependencia de un sitio central. La autonomía local
implica que todos los sitios deben ser tratados como iguales.
◦ Por lo tanto, no debe haber particularmente ninguna
dependencia de un sitio “maestro” central para algún servicio
central, tal que todo el sistema dependa de ese sitio central.
◦ Razones por las cuales no debería haber un sitio central:
El sitio central puede ser un cuello de botella
El sistema sería vulnerable; es decir, si el sitio central falla,
también fallará todo el sistema
Principios
3.- Operación continua. Una ventaja de los sistemas distribuidos es que
deben proporcionar mayor confiabilidad y mayor disponibilidad.
◦ Confiabilidad. La probabilidad de que el sistema esté listo y
funcionando en cualquier momento dado. Los SD no son una propuesta
de todo o nada; pueden continuar operando cuando hay alguna falla en
algún componente independiente.
◦ Disponibilidad. La probabilidad de que el sistema esté listo y
funcionando continuamente a lo largo de un período especificado.
4.- Independencia de ubicación. Conocida también como
transparencia de ubicación.
◦ Los usuarios no tienen que saber dónde están almacenados físicamente
los datos, sino que deben ser capaces de comportarse como si todos
los datos estuvieran almacenados en su propio sitio local.
◦ Esto simplifica los programas de los usuarios. En particular, permite que
los datos emigren de un sitio a otro sin invalidar ninguno de estos
programas o actividades.
Principios
5.- Independencia de fragmentación. Un sistema soporta la
fragmentación de datos cuando puede ser dividida en o partes o
fragmentos, para efectos de almacenamiento físico.
◦ La fragmentación es necesaria por razones de rendimiento: los datos
pueden estar almacenados en la ubicación donde son usados más
frecuentemente para que la mayoría de las operaciones sean locales
y se reduzca el tráfico en la red.
◦ Los usuarios deben comportarse como si los datos en realidad
estuvieran sin fragmentación alguna.
6.- Independencia de replicación. El sistema soporta replicación de
datos cuando un fragmento puede ser representado por muchas copias
distintas, o réplicas, guardadas en muchos sitios distintos.
Las réplicas son necesarias por dos razones principales:
◦ Significan un mejor rendimiento (las aplicaciones pueden operar
sobre las copias locales en lugar de tener que comunicarse con sitios
remotos) Pueden significar una mejor disponibilidad (un objeto
replicado permanece disponible para su procesamiento, mientras
esté disponible al menos una copia).
Principios
7.- Procesamiento de consultas distribuidas. La optimización es
importante en un sistema distribuido que en uno centralizado, incluso
mucho más.
◦ El punto básico es que en una consulta que involucra a varios sitios,
habrá muchas formas posibles de mover los datos en el sistema para
satisfacer la solicitud, y es crucialmente importante que se encuentre
una estrategia eficiente.
◦
8.- Administración de transacciones distribuidas. Existen dos
aspectos principales en la administración de transacciones: control de
recuperación y control de la concurrencia.
◦ Ambos aspectos requieren un tratamiento amplio en el ambiente
distribuido.
◦ Ya que una sola transacción puede involucrar la ejecución de código
en muchos sitios.
◦ Puede involucrar actualizaciones en muchos sitios y se debe de
cuidar que la transacción no caiga en un bloqueo mortal (basado en
el bloqueo).
◦ Para el control de la recuperación, es necesario asegurarse que una
transacción dada sea atómica en el ambiente distribuido, el sistema
debe por lo tanto asegurarse de que la transacción sea confirmada o
deshecha
Principios
9.- Independencia de hardware. Soporte para un gran
número de máquinas diferentes. Poder integrar todos los
datos de todos estos sistemas y presentar al usuario una
“imagen del sistema único”.
10.- Independencia de sistema operativo. Obviamente
es necesario no sólo tener la posibilidad de ejecutar el
mismo DBMS en diferentes plataformas de hardware, sino
también ejecutarlo en diferentes plataformas de sistema
operativo.
11.- Independencia de red.
Si el sistema va a tener la posibilidad de soportar
muchos sitios distintos es obviamente necesario tener la
posibilidad de soportar también una variedad de redes
de comunicación distintas.
Principios
12.- Independencia de DBMS. Lo que se necesita es
que todos los ejemplares de DBMS en sitios diferentes
soporten la misma interfaz.
– Aunque no tienen que ser necesariamente copias del
mismo software DBMS.
– En otras palabras, sería posible que el sistema
distribuido fuera heterogéneo, al menos en cierto
grado.
– Sería muy bueno si diferentes DBMS pudieran
participar de alguna forma en un sistema distribuido.
GRACIAS
