UNIDAD 1 FUNDAMENTO DE BASES

DE DATOS DISTRIBUIDAS
1.1CONCEPTOS BSICOS
Bases de Datos Distribuidas (BDD)
Es un objeto virtual; es un conjunto de mltiples bases de datos las cuales se encuentran
distribuidas en diferentes sitios interconectados por una red de comunicaciones.
Sistema de Bases de Datos Distribuidas (SBDD)
Es un sistema en el cual mltiples sitios de bases de datos estn 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 un su
sitio propio.
Conclusin
A manera de conclusin se puede decir que una bases de datos distribuidas es un objeto
virtual, que surge de la unin de munchas bases de datos que han a cordado trabajar
juntas, y una de las ventajas que tiene este tipo de bases de datos es que almacena la
informacin que ms se utiliza de manera local y solo en algunas ocasiones accede de
manera remota a informacin de otros sitios.
1.2 OBJETIVO DE LAS B.D.D
Operaciones Locales: Son aquellas operaciones que un nodo realiza sobre su propia base
de datos, en una base de datos distribuidas estas son las consultas ms deseadas, porque son
datos que se generan en la misma estacin de trabajo.
Operaciones Globales: Suceden cuando accede a la informacin de otro, este es el
principal objetivo de las bases de datos distribuidas, pero son las operaciones ms
complejas por que existen factores de riesgo como la seguridad o en trfico en la red.
Ventajas de las BDD
1.- Compartir informacin y control sobre los datos.
2.- Disponibilidad de la informacin.
3.- Permite romper barreras geogrficas.
4.- Modularidad, se pueden modificar, agregar o quitar sistemas de bases de datos
distribuidas sin afectar a los dems sistemas (mdulos).
5.- Un fallo en una parte del sistema solo afectara a u n fragmento, en lugar de a toda la
base de datos.
Desventajas de las BDD
1.- Disponibilidad y dependencia total de la red de comunicaciones.
2.- Seguridad de la informacin.
3.- Costo del desarrollo del software.
4.- Complejidad, se debe asegurar que la base de datos sea transparente.
5.- Falta de experiencia, las BDD son un campo relativamente nuevo y poco comn por lo
cual no existe muncho personal con experiencia o conocimientos adecuados.
TPICOS DE LAS BASES DE DATOS DISTRIBUIDAS
Transparencia de la informacin: El termino transparencia se puede definir como la
forma en que el usuario percibe la informacin, lo que significa que el sistema de las BDD
actan como si la informacin estuviera almacenada en el lugar donde se consulta, dicho
proceso no lo sabe el usuario.
Bases de datos distribuidas heterogneas: Significa que es un sistema de BDD donde las
bases de datos pueden estar en diferentes sistemas gestores o en entornos operativos, lo
contrario a las bases de datos homogneas.
Replicas: Un sistema de bases de datos puede contar con replicas, lo que significa que cada
base de datos de los nodos o al menos una puede estar duplicada, con el objetivo de el
sistema sea tolerante a fallas, si una base de datos falla la informacin se redirecciona a la
rplica y cuando la base de datos se recupera copia automticamente las actualizaciones de
la rplica. De manera tcnica en bases de datos se les conoce como espejos o reflejos.
Fragmentacin: Un sistema consiste en dividir las partes o fragmentos que contribuyen al
diseo adecuado de las bases de datos.
Autonoma local: Como la base de datos distribuidas estn formadas por otras bases de
datos existe autonoma, es decir cada nodo es dueo de su propia informacin y puede
compartir solamente aquella que beneficie sus intereses.
1.3 DISCIPLINAS DE ESTUDIOS
Las bases de datos distribuidas se utilizan en diferentes instituciones como:
Hospitales
Comercios
Bancos
Proceso comercial
Proceso educativo
Farmacias
Etc.

Bases de datos Distribuidas
Una Base de Datos Distribuida es, una base de datos construida sobre una red
computacional y no por el contrario en una mquina aislada. La informacin que constituye
la base de datos esta almacenada en diferentes sitios en la red, y las aplicaciones que se
ejecutan trabajan con datos en distintos sitios. La llamada "base de datos distribuida" es en
realidad una especie de objeto virtual, cuyas partes componentes se almacenan fsicamente
en varias bases de datos "reales" distintas ubicadas en diferentes sitios. De hecho, es la
unin lgica de esas bases de datos. En otras palabras, cada sitio tiene sus propias bases de
datos "reales" locales, sus propios usuarios locales, sus propios DBMS y programas para la
administracin de transacciones (incluyendo programas de bloqueo, bitcoras,
recuperacin, etc.), y su propio administrador local de comunicacin de datos
(administrador DC). En particular un usuario dado puede realizar operaciones sobre los
datos en su propio sitio local exactamente como si ese sitio no participara en absoluto en el
sistema distribuido ( al menos, se es uno de los objetivos ). As pues, el sistema de bases
de datos distribuidas puede considerarse como una especie de sociedad entre los DBMS
individuales locales de todos los sitios. Un nuevo componente de software en cada sitio ( en
el aspecto lgico, una extensin del DBMS local ) realiza las funciones de sociedad
necesarias; y es la combinacin de este nuevo componente y el DBMS ya existente lo que
constituye el llamado "sistema de administracin de bases de datos distribuidas" (DDBMS,
distributed database management system ).
1.1Arquitectura
En un sistema de bases de datos distribuidas, existen varios factores que deben tomar en
consideracin que definen la arquitectura del sistema: Distribucin: Los componentes del
sistema estn localizados en la misma computadora o no.


1.1.1 Autonoma
Para lograr la independencia entre bases de datos de un sistema distribuido, es necesario
considerar los tipos de autonoma descritos por Sheth y Larson 1990, los cuales se detallan
a continuacin:
Autonoma de diseo: la capacidad de que cada base de datos decida los aspectos
concernientes con su diseo. Es decir, las personas involucradas son libres de
decidir cualquier particularidad e incluso decidir que DBMS usar.
Autonoma de comunicacin: la habilidad de que una BD decida comunicarse o no
con otro componente de una misma federacin.
Autonoma de ejecucin: es la habilidad de que una BD para ejecutar operaciones
locales sin la interferencia de operaciones externas en el orden de que la BD lo
decida.
Autonoma de asociacin: cada BD decide cuando y cuanto puede compartir su
funcionalidad y recursos con otros componentes, inclusive la capacidad de asociarse
o retirarse de una o mas federaciones.
1.1.2 Heterogeneidad
Un sistema es heterogneo cuando existen en l componentes que se ejecutan en diversos
sistemas operativos, de diferentes fuentes, etc.
1.1.3 Distribucin y esquema global
El problema de diseo de bases de datos distribuidos se refiere, en general, a hacer
decisiones acerca de la ubicacin de datos y programas a travs de los diferentes sitios de
una red de computadoras. Este problema debera estar relacionado al diseo de la misma
red de computadoras. Sin embargo, en estas notas nicamente el diseo de la base de datos
se toma en cuenta. La decisin 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. El diseo de las bases de datos centralizadas contempla los dos puntos siguientes:
1. Diseo 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. Diseo "fsico de la base de datos", esto es, mapear el esquema conceptual a las
reas de almacenamiento y determinar los mtodos de acceso a las bases de datos.
En el caso de las bases de datos distribuidas se tienen que considerar los dos problemas
siguientes:
1. Diseo de la fragmentacin, este se determina por la forma en que las relaciones
globales se subdividen en fragmentos horizontales, verticales o mixtos.
2. Diseo de la asignacin de los fragmentos, esto se determina en la forma en que los
fragmentos se mapean a las imgenes fsicas, en esta forma, tambin se determina la
solicitud de fragmentos.
Objetivos del Diseo de la Distribucin de los Datos.
En el diseo de la distribucin de los datos, se deben de tomar en cuenta los siguientes
objetivos: Procesamiento local. La distribucin de los datos, para maximizar el
procesamiento local corresponde al principio simple de colocar los datos tan cerca como
sea posible de las aplicaciones que los utilizan. Se puede realizar el diseo de la
distribucin de los datos para maximizar el procesamiento local agregando el nmero de
referencias locales y remotas que le corresponden a cada fragmentacin candidata y la
localizacin del fragmento, que de esta forma se seleccione la mejor solucin de ellas.
Distribucin de la carga de trabajo. La distribucin de la carga de trabajo sobre los sitios, es
una caracterstica importante de los sistemas de cmputo distribuidos. Esta distribucin de
la carga se realiza para tomar ventaja de las diferentes caractersticas (potenciales) o
utilizaciones de las computadoras de cada sitio, y maximizar el grado de ejecucin de
paralelismo de las aplicaciones. Sin embargo, la distribucin de la carga de trabajo podra
afectar negativamente el procesamiento local deseado. Costo de almacenamiento y
disponibilidad. La distribucin de la base de datos refleja el costo y disponibilidad del
almacenamiento en diferentes sitios. Para esto, es posible tener sitios especializados en la
red para el almacenamiento de datos. Sin embargo el costo de almacenamiento de datos no
es tan relevante si ste se compara con el del CPU, I/O y costos de transmisin de las
aplicaciones.
1.2 Diseo de bases de datos distribuidas
El dise de una BDD involucra 4 pasos:
1. Diseo del esquema conceptual donde se describe la BD integral.
2. Diseo de fragmentacin.
3. Diseo de la asignacin de los fragmentos.
4. Diseo de la BD fsica (transformar los esquemas locales en reas de
almacenamiento y determinar mtodos de acceso apropiados). La fragmentacin y
asignacin de los datos caracterizan el diseo de BDD.
La fragmentacin se ocupa fundamentalmente de los criterios lgicos que motivan la
divisin de relaciones globales en fragmentos, mientras que la asignacin se ocupa de los
aspectos fsicos de su ubicacin y rplicas en sitios; aunque hay una diferencia entre ambos
procesos, su interrelacin es importante para obtener un diseo ptimo.
En caso que tambin se distribuyan las aplicaciones debemos tener en cuenta el diseo de
los esquemas, los requerimientos ms importantes de las aplicaciones tenemos las
siguientes:
1. Sitio que comparte una aplicacin.
2. Frecuencia de activacin de la aplicacin
3. Cantidad, tipo y distribucin estadstica de los accesos de cada aplicacin a cada
dato requerido.
En el diseo de un sistema de bases de datos distribuidas debemos tener en cuenta algunas
estrategias y objetivos y se deben en paralelo tomar decisiones sobre cmo hay que
distribuir los datos entre los sitios de la red.
A los problemas que presentamos en el diseo de las Bases de Datos Centralizadas (BDC)
se le aaden otros nuevos cuando diseamos Bases de Datos Distribuidas (BDD) entre los
cuales se destacan la distribucin ptima de datos y de las aplicaciones en los diferentes
sitios.
Cuando pensamos en el diseo de las bases de datos distribuidas debemos tener en cuenta
la ubicacin de los programas que accedern a las bases de datos y sobre los propios datos
que constituyen la base de datos, en diferentes puntos de una red. Sobre la ubicacin de los
programas supondremos que tenemos una copia de ellos en cada maquina donde se necesite
acceder a la base de datos. Sin embargo el problema radica en como ubicaremos los datos
en la red, existen diferentes formas de repartir los datos: En solo una maquina que almacene
todos los datos y se encargue de responder a todas las consultas del resto de la red (sistema
centralizado), ubicaramos la base de dato en cada maquina donde se utilice, o pensaramos
en repartir las relaciones por toda la red.
Duplicacin de los datos.
La duplicacin de los datos ocurre si el sistema mantiene varias copias de una relacin, R,
con cada copia almacenada en un sitio diferente. Existen dos modelos bsicos de replica:
1. Consistencia estrecha. Este modelo que garantiza que todas las rplicas sean
constantemente idnticas a la original, requiere una red de alta velocidad, disminuye
la disponibilidad de la base de datos.
2. Consistencia ancha. El modelo de consistencia ancha permite un retardo entre el
momento en que los datos originales son modificados y las copias de los mismos
son actualizadas, lo que permite que la base de datos est disponible ms tiempo
que el modelo de consistencia estrecha. Permite conexiones tanto rpidas como
lentas soportadas en WANs o LANs.
La duplicacin se introduce para aumentar la disponibilidad del sistema: cuando una copia
no est disponible debido a un fallo de un sitio sera posible tener acceso a otra copia. Con
la duplicacin tambin se mejora el rendimiento puesto que las transacciones tienen mayor
probabilidad de encontrar una copia localmente. El inconveniente est en el costo extra del
almacenamiento adicional y del mantenimiento de la consistencia mutua entre las copias
cuando tenemos replicacin.
1.2.1 Diseo top-down : fragmentacin.
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 funcin de resolver las diferentes partes de dicho proyecto.
Observece la siguiente figura:

El diseo 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
diseo bottom-up de una base de datos distribuida requiere de la seleccin de un modelo de
bases de datos comn para describir el esquema global de la base de datos. Esto se debe es
posible que se utilicen diferentes SMBD. Despus se hace la traduccin de cada esquema
local en el modelo de datos comn y finalmente se hace la integracin del esquema local en
un esquema global comn
1.2.2 Diseo bottom-up : integracin de bases de datos
El diseo 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
diseo bottom-up de una base de datos distribuida requiere de la seleccin de un modelo de
bases de datos comn para describir el esquema global de la base de datos. Esto se debe es
posible que se utilicen diferentes SMBD. Despus se hace la traduccin de cada esquema
local en el modelo de datos comn
1.3 Arquitecturas Cliente/Servidor para SGBD

1.3.1 Filosofa Cliente/Servidor
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
ms servidores procesan una misma base de datos, el sistema no es considerado cliente
servidor, ms bien, es conocido como sistema de base de datos distribuido.

Funciones del cliente:
Administrar la interfaz de usuario.
Aceptar datos del usuario.
Procesar la lgica de la aplicacin.
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 verificacin de integridad.
Mantener los datos generales de la base de datos.
Proporcionar control de acceso concurrente.
Llevar a cabo la recuperacin.
Optimizar el procesamiento de consulta/actualizacin.

Una desventaja de los sistemas cliente servidor es el control. Las computadoras clientes
operan en forma simultnea y procesan las aplicaciones en paralelo, lo cual hace ms difcil
el control de los problemas de prdidas por actualizacin y otros problemas que provoca el
control multiusuario.
1.3.2 Sockets
Los sockets no son ms que puntos o mecanismos de comunicacin entre procesos que
permiten que un proceso hable ( emita o reciba informacin ) con otro proceso incluso
estando estos procesos en distintas mquinas(11)(11). Esta caracterstica de
interconectividad entre mquinas hace que el concepto de socket nos sirva de gran utilidad.
Esta interfaz de comunicaciones es una de las distribuciones de Berkeley al sistema UNIX,
implementndose las utilidades de interconectividad de este Sistema Operativo ( rlogin,
telnet, ftp, ... ) usando sockets.
Un socket es al sistema de comunicacin entre ordenadores lo que un buzn o un telfono
es al sistema de comunicacin entre personas: un punto de comunicacin entre dos agentes
( procesos o personas respectivamente ) por el cual se puede emitir o recibir informacin.
La forma de referenciar un socket por los procesos implicados es mediante un descriptor
del mismo tipo que el utilizado para referenciar ficheros. Debido a esta caracterstica, se
podr realizar redirecciones de los archivos de E/S estndar (descriptores 0,1 y 2) a los
sockets y as combinar entre ellos aplicaciones de la red. Todo nuevo proceso creado
heredar, por tanto, los descriptores de sockets de su padre.
La comunicacin entre procesos a travs de sockets se basa en la filosofa CLIENTE-
SERVIDOR: un proceso en esta comunicacin actuar de proceso servidor creando un
socket cuyo nombre conocer el proceso cliente, el cual podr "hablar" con el proceso
servidor a travs de la conexin con dicho socket nombrado.
El proceso crea un socket sin nombre cuyo valor de vuelta es un descriptor sobre el que se
leer o escribir, permitindose una comunicacin bidireccional, caracterstica propia de los
sockets y que los diferencie de los pipes, o canales de comunicacin unidireccional entre
procesos de una misma mquina. El mecanismo de comunicacin va sockets tiene los
siguientes pasos:
1) El proceso servidor crea un socket con nombre y espera la conexin.
2) El proceso cliente crea un socket sin nombre.
3) El proceso cliente realiza una peticin de conexin al socket servidor.
4) El cliente realiza la conexin a travs de su socket mientras el proceso servidor mantiene
el socket servidor original con nombre.
Es muy comn en este tipo de comunicacin lanzar un proceso hijo, una vez realizada la
conexin, que se ocupe del intercambio de informacin con el proceso cliente mientras el
proceso padre servidor sigue aceptando conexiones. Para eliminar esta caracterstica se
cerrar el descriptor del socket servidor con nombre en cuanto realice una conexin con un
proceso socket cliente.
Todo socket viene definido por dos caractersticas fundamentales:
El tipo del socket, que indica la naturaleza del mismo, el tipo de comunicacin que
puede generarse entre los sockets.
El dominio del socket especifica el conjunto de sockets que pueden establecer una
comunicacin con el mismo.
Un servicio proporcionado por un servidor no es ms que un conjunto de operaciones
disponibles para los clientes. El acceso al servicio se realiza mediante un protocolo de
peticiones respuesta con llamadas bloqueantes. Ejemplo: Un servicio de ficheros. El
servidor mantiene como recurso compartido los ficheros. Sobre el recurso compartido se
pueden realizar diversas operaciones: Crear, Abrir, Leer, etc.
1.3.3 RPC
Los mecanismos RPC persiguen que los clientes se abstraigan e invoquen procedimientos
remotos (operaciones) para obtener servicios. As, el procedimiento llamado se ejecuta en
otro proceso de otra maquina (servidor). El objetivo de RPC es mantener la semntica de la
llamada a procedimiento normal en un entorno de implementacin totalmente distinto. La
ventaja esta en que el desarrollador se preocupa de los interfaces que soporta el servidor.
Para especificar dichos interfaces se dispones de un IDL (lenguaje de definicin de
interfaces).
Los sistemas RPC disponen de mecanismos de RPC integrados en un lenguaje de
programacin particular que incluye adems una notacin para definir interfaces entre
clientes y servidores (IDL especifico). Un IDL permite definir el nombre de las operaciones
soportadas por el servidor y sus parmetros (tipo y direccin). Tambin se deben proveer
mecanismos para manejo de excepciones, garantizar la ejecucin de las operaciones, as
como la deteccin de fallos. Todo ello de la forma ms transparente posible.
El software (middleware) que soporta RPC tiene tres tareas fundamentales:
1. Procesamiento relacionado con los interfaces: Integrar RPC en el entorno de
programacin, empaquetamiento (marshalling)/desempaquetamiento
(unmarshalling) y despachar las peticiones al procedimiento adecuado.
2. Gestionar las comunicaciones
3. Enlazado (Binding): Localizar al servidor de un servicio.
La interfaz no es ms que un nmero de procedimiento acordado entre cliente y servidor.
Este nmero viaja dentro del mensaje RPC transmitido por la red. En la parte cliente existe
un procedimiento de 'stub' encargado de empaquetar/desempaquetar los argumentos de la
llamada, convertir la llamada local en una llamada remota. Esto supone enviar un mensaje,
esperar la respuesta y retornar los resultados. En la parte del servidor esta el despachador,
junto con el conjunto de procedimientos de stub de servidor, que tienen una misin similar
a los de la parte cliente. El despachador selecciona el procedimiento de stub adecuado a
partir del nmero de procedimiento requerido.
El compilador de IDL genera los procedimientos de stub de cliente y de servidor, las
operaciones de empaquetamiento y desempaquetamiento as como los ficheros de cabecera
necesarios.
Las peticiones de los clientes son con respecto a un nombre de servicio. En ltima instancia
deben ser dirigidas a un puerto en el servidor. En un sistema distribuido un binder es un
servicio separado que mantiene una tabla que contiene correspondencias de nombres de
servicios con puertos de servidor. Se trata, como veremos ms adelante, de un servicio de
nombres. Importar un servicio es pedir al binder que busque el nombre del interfaz y
retorne el puerto del servidor. Exportar un servicio es registrarlo de cara el binder. El binder
deber estar en un puerto bien conocido o, al menos, se le podr localizar.
Una implementacin bastante habitual de RPC es la de SUN. Incorpora todo un conjunto de
primitivas para trabajar con RPC en lenguaje C. Dispone de una representacin neutral de
los datos para su empaquetamiento, XDR (External Data Representation). XDR tambin se
denomina al IDL que se proporciona.
1.3.4 CORBA
es ms que una especificacin multiplataforma, tambin define servicios habitualmente
necesarios como seguridad y transacciones. Y as este no es un sistema operativo en si, en
realidad es un middleware
1.4 Optimizacin de preguntas y transacciones
Cuando hablamos de optimizacin de consultas nos referimos a mejorar los tiempos de
respuesta en un sistema de gestin de bases de datos relacional, pues la optimizacin es el
proceso de modificar un sistema para mejorar su eficiencia o tambin el uso de los recursos
disponibles.
Transacciones distribuidas Protocolo de compromiso en dos fases.
(Twophasecommitprotocol)
1. El coordinador enva una solicitud de voto (vote request) a los nodos participantes
en la ejecucin de la transaccin.
2. Cuando los participantes reciben la solicitud de voto, respondenenviando al
coordinador un mensaje con su voto (So No). Si un participante vota No, la
transaccin se aborta (abort).
3. El coordinador recoge los mensajes con los votos de todos los participantes. Si
todos han votado S, entonces el coordinador tambin vota si y enva un mensaje
commita todos los participantes. En otro caso, el coordinador decide abandonar y
enva un mensaje aborta todos los participantes que han votado afirmativamente.
4. Cada participante que ha votado s, espera del coordinador un mensaje commito
abort para terminar la transaccin de forma normal o abortarla.
Manejo distribuido de transacciones.
El manejo de transacciones tiene dos aspectos principales, el control de recuperacin y el
control de concurrencia, cada uno de los cuales requiere un tratamiento ms amplio en el
ambiente distribuido. Para explicar ese tratamiento ms amplio es preciso introducir
primero un trmino nuevo, "agente". En un sistema distribuido, una sola transaccin puede
implicar la ejecucin de cdigo en varios sitios (en particular puede implicar a
actualizaciones en varios sitios). Por tanto, se dice que cada transaccin est compuesta de
varios agentes, donde un agente es el proceso ejecutado en nombre de una transaccin dada
en determinado sitio. Y el sistema necesita saber cundo dos agentes son parte de la misma
transaccin; por ejemplo, es obvio que no puede permitirse un bloqueo mutuo entre dos
agentes que sean parte de la misma transaccin. La cuestin especifica del control de
recuperacin: para asegurar, pues que una transaccin dada sea atmica (todo o nada) en el
ambiente distribuido, el sistema debe asegurarse de que todos los agentes correspondientes
a esa transaccin se comprometan al unsono o bien que retrocedan al unsono. Este efecto
puede lograrse mediante el protocolo de compromiso en dos fases.
En cuanto al control de concurrencia, esta funcin en un ambiente distribuido estar basada
con toda seguridad en el bloqueo, como sucede en los sistemas no distribuidos.