UNIDAD 1 Sistemas de bases de datos distribuidas
1.1. Conceptos de base de datos distribuidas.
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 y geográficos (pej.
un servidor corriendo 2 máquinas virtuales) e interconectados por una red de
comunicaciones. Dichas BDD tienen la capacidad de realizar procesamientos
autónomos, estos permiten realizar operaciones locales o distribuidas.
Como toda base de datos, la base de datos distribuida consiste en un
almacén de datos, es decir en un conjunto de datos almacenado de manera sistemática
siempre dispuesto a ser utilizado. Pero tiene una particularidad que la
diferencia y que consiste en que estos datos están almacenados en distintas
máquinas que integran un sistema y que tienen conexión entre si.
Cada uno de los procesadores que integran dicho sistema se conoce con el
nombre de localidad o nodo, y por lo tanto la información va a estar
distribuida en las distintas localidades y no en una sola localidad, que es lo
que ocurre con las bases de datos centralizadas
Cada localidad tiene una base de datos local aunque la información que
se necesite puede provenir tanto de la base de datos local como de otras
localidades, lo que se conoce como transacciones locales o transacciones
globales respectivamente.
En cuanto al las formas que pueden conectarse las localidades, las más
comunes son: la red totalmente conectada, la red prácticamente conectada, la
red con estructura de árbol, la red de estrella o la red de anillo.
¿Cuáles son las ventajas? Debido a que la informaciones está distribuida
en localidades, los resultados a las consultas se pueden obtener de manera
rápida, ágil y fiable. Asimismo, en caso de que alguna de las localidades
falle, como todas tienen autonomía local, el resto sigue trabajando sin que se
desactive el sistema.
CONCEPTOS
BÁSICOS
Un administrador de de transacciones distribuidas (DTM) es un programa que
recibe solicitudes de procesamiento de los programas de consulta o de
transacciones y a 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. Cada sitio tiene sus propias bases de datos "reales"
locales, sus propios usuarios locales, sus propios DBMS y programas para
administración de transacciones y su propio administrador local de comunicación
de datos.
Sistema de Base de Datos Distribuida (SBDD) es un sistema en el
cual múltiples sitios de bases de datos están ligados por un sistema de
comunicaciones, de tal forma que, un usuario en cualquier sitio puede acceder a
los datos en cualquier parte de la red exactamente como si los datos estuvieran
almacenados en su sitio propio. Es entonces el resultado de la integración de
una base de datos distribuida con un sistema para su manejo.
Una unidad
distribuida del trabajo (DUOW) , también conocida como actualización
del multisite, es una función que permite a sus usuarios poner al día datos en
servidores alejados de la base de datos, garantizándose la integridad de los
mismos. Por ejemplo, una transacción de las actividades bancarias que implique
la transferencia del dinero a partir de una cuenta a otra en diversos
servidores de la base de datos.
La fragmentación de
datos consiste en subdividir las relaciones y distribuirlas entre los
sitios de la red, tiene como objetivo buscar formas alternativas de dividir una
las instancias (tablas) de relaciones en otras más pequeñas. La fragmentación
se puede realizar por tuplas individuales (fragmentación horizontal), por
atributos individuales fragmentación vertical) o una combinación de ambas
(fragmentación híbrida).
La replicación de
datos consiste en que cada nodo debe tener su copia completa de la base
de datos. Es fácil ver que este esquema tiene un alto costo en el
almacenamiento de la información. Debido a que la actualización de los datos
debe ser realizada en todas las copias, también tiene un alto costo de
escritura, pero todo esto vale la pena si tenemos un sistema en el que se va a
escribir pocas veces y leer muchas, y dónde la disponibilidad y fiabilidad de
los datos sea de máxima importancia.
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 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.
1.2. Diseño de base de datos distribuidas.
El enfoque de arriba hacia abajo (top-down).
Este enfoque es más apropiado para aplicaciones nuevas y
para sistemas homogéneos. Consiste en partir desde el análisis de
requerimientos para definir el diseño conceptual y las vistas de usuario. A partir
de ellas se define un esquema conceptual global y los esquemas externos
necesarios. Se prosigue con el diseño de la fragmentación de la base de datos,
y de aquí se continúa con la localización de los fragmentos en los sitios,
creando las imágenes físicas. Esta aproximación se completa ejecutando, en cada
sitio, “el diseño físico” de los datos, que se localizan en éste
Diseño bottom-up: integración de bases de datos.
El diseño de abajo hacia arriba (bottom-up).
Se utiliza particularmente a partir de bases de datos
existentes, generando con esto bases de datos distribuidas. En forma resumida,
el diseño bottom-up de una base de datos distribuida requiere de la selección
de un modelo de bases de datos común para describir el esquema global de la
base de datos. Esto se debe es posible que se utilicen diferentes SMBD. Después
se hace la traducción de cada esquema local en el modelo de datos común y
finalmente se hace la integración del esquema local en un esquema global común.
Diseño top-down: fragmentación.
Top – Down es adecuada cuando creamos un sistema de BD
por vez primera sin restricciones de otros sistemas ya instalados y que deban
ser integrados al sistema distribuido, es decir, primero elaboramos el esquema
conceptual global del proyecto y trabajamos en función de resolver las
diferentes partes de dicho proyecto.
El problema de diseño de bases de datos distribuidos se
refiere, en general, a hacer decisiones acerca de la ubicación de datos y
programas a través de los diferentes sitios de una red de computadoras. La
decisión de donde colocar a las aplicaciones tiene que ver tanto con el
software del SMBDD como con las aplicaciones que se van a ejecutar sobre la
base de datos.
Los pasos a seguir para diseñar una base de datos
distribuida:
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).
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 a las bases de datos.
Diseño de la fragmentación, este se determina por la
forma en que las relaciones globales se subdividen en fragmentos horizontales,
verticales o mixtos.
Diseño de la asignación de los fragmentos, esto se
determina en la forma en que los fragmentos se mapean a las imágenes físicas,
en esta forma, también se determina la solicitud de fragmentos.
1.3. Procesamiento de operaciones de actualización distribuidas.
Los sistemas
cliente/servidor involucran varias computadoras conectadas a una red. Las
computadoras que procesan programas de aplicaciones se conocen como clientes y
las que procesan bases de datos se conocen como servidor.
Arquitectura Cliente
Servidor
Un sistema cliente servidor
puede tener varios servidores de procesamiento de bases de datos, cuando esto
ocurre cada servidor debe procesar una base de datos distinta. Cuando dos o más
servidores procesan una misma base de datos, el sistema no es considerado
cliente servidor, más bien, es conocido como sistema de base de datos
distribuido.
Funciones del cliente:
- · Administrar la interfaz de usuario.
- · Aceptar datos del usuario.
- · Procesar la lógica de la aplicación.
- · Generar las solicitudes para la base de datos.
- · Trasmitir las solicitudes de la base de datos al servidor.
- · Recibir los resultados del servidor.
- · Dar formatos a los resultados.
Funciones del servidor:
- · Aceptar las solicitudes de la base de datos de los clientes.
- · Procesar las solicitudes de los clientes
- · Dar formato a los resultados y trasmitirlos al cliente.
- · Llevar a cabo la verificación de integridad.
- · Mantener los datos generales de la base de datos.
- · Proporcionar control de acceso concurrente.
- · Llevar a cabo la recuperación.
- · Optimizar el procesamiento de consulta/actualización.
1.4. Procesamiento de consultas distribuidas.
Las consultas distribuidas
detienen acceso a datos de varios orígenes de datos heterogéneos. Estos
orígenes de datos pueden estar almacenados en el mismo equipo o en equipos
diferentes. El procesamiento de consultas tiene varias etapas a seguir para
resolver una consulta SQL, las características del modelo relacional permiten
quecada motor de base de datos elija su propia representación que,comúnmente,
resulta ser el álgebra relacional .Existen varios medios para calcular la
respuesta a una consulta. En el caso del sistema centralizado, el criterio
principal para determinar el costo de una estrategia específica es el número de
acceso al disco.
En un sistema distribuido es
preciso tener en cuenta otros factores como son:
El costo de transmisión de
datos en la red.
Repetición y fragmentación.
Procesamiento de
intersección simple.
TRANSFORMACIONES
EQUIVALENTES
Cuando una base de datos se
encuentra en múltiples servidores y distribuye a un número determinado de nodos
tenemos:
El servidor recibe una
petición de un nodo.
El servidor es atacado por
el acceso concurrente a la base de datos cargada localmente.
El servidor muestra un
resultado y le da un hilo a cada una de las maquinas nodo de la red local.
Cuando una base de datos es
acezada de esta manera la técnica que se utiliza es la de fragmentación de
datos que puede ser híbrida, horizontal y vertical.
En esta fragmentación lo que
no se quiere es perder la consistencia delos datos, por lo tanto se respetan
las formas normales de la base de datos.
Bueno para realizar una
transformación en la consulta primero des fragmentamos siguiendo los estándares
marcados por las reglas formales y posteriormente realizamos el envió y la
maquina que recibe es la que muestra el resultado pertinente para el usuario,
de esta se puede producir una copia que será la equivalente a la original.
El sistema debe de ser capaz
de procesar consultas que hagan referencia a datos situados a mas de un nodo.
1.5. Manejo de transacciones.
Una transacción es una
unidad lógica de trabajo, la cual no necesariamente consta de una sola
operación en la base de datos; más bien, es en general una secuencia de varias
de esas operaciones mediante la cual un estado consistente de la base de datos
se transforma en otro estado consistente, sin conservar por fuerza la
consistencia en todos los puntos intermedios. El punto importante aquí es
asegurar que la base de datos regresa a un estado consistente al fin de la
ejecución de una transacción. Una transacción es también la invocación a un
procedimiento remoto (RPC) que ejecuta un conjunto de operaciones sobre una
base de datos bajo el principio de todo o nada.
El concepto fundamental aquí
es la noción de “ejecución consistente” o “procesamiento confiable” asociada
con el concepto de una consulta. El concepto transacción es usado dentro del
dominio de la base de datos como una unidad básica de cómputo consistente y
confiable.
Se considera el manejo de
transacciones cuando un dispositivo móvil inicia una transacción hacia la base
de datos o hacia un servidor fijo. La transacción puede ejecutarse en el
servidor o en el dispositivo móvil. Se debe tomar en cuenta: Desconexiones,
movilidad, errores, fallas en el dispositivo móvil. Se debe mantener la
autonomía y la consistencia local del SMBD.
Los algoritmos dependen de:
- Si el dispositivo esta ejecutando la transacción (no, solo lectura, lectura y escritura)
- Si se almacenaron los datos en disco.
- Si el dispositivo móvil necesita datos que se encuentran en otros dispositivos móviles.
No hay comentarios.:
Publicar un comentario