UNIDAD 1

UNIDAD 1 BASES 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 entre diferentes sitios interconectados por una red de comunicaciones, los cuales tienen la capacidad de procesamiento autónomo lo cual indica que puede realizar operaciones locales o distribuidas. Un sistema de Bases 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 los datos en cualquier parte de la red exactamente como si los datos estuvieran siendo accedidos de forma local.
En un sistema distribuido de bases de datos se almacenan en varias computadoras. Los principales factores que distinguen un SBDD de un sistema centralizado son los siguientes:
Hay múltiples computadores, llamados sitios o nodos.
Estos sitios deben de estar comunicados por medio de algún tipo de red de comunicaciones para transmitir datos y órdenes entre los sitios.
1.1 ARQUITECTURA
La mayoría de los sistemas de manejo de bases de datos disponibles actualmente están basadas en la arquitectura ANSI-SPARC la cual divide a un sistema en tres niveles: interno, conceptual y externo, como se puede apreciar en la Figura 2.4.
La vista conceptual, conocida también como vista lógica global, representa la visión de la comunidad de usuarios de los datos en la base de datos. No toma en cuenta la forma en que las aplicaciones individuales observan los datos o como éstos son almacenados. La vista conceptual está basada en el esquema conceptual y su construcción se hace en la primera fase del diseño de una base de datos.
Los usuarios, incluyendo a los programadores de aplicaciones, observan los datos a través de un esquema externo definido a nivel externo. La vista externa proporciona una ventana a la vista conceptual lo cual permite a los usuarios observar únicamente los datos de interés y los aísla de otros datos en la base de datos. Puede existir cualquier número de vistas externas y ellos pueden ser completamente independientes o traslaparse entre sí.
El esquema conceptual se mapea a un esquema interno a nivel interno, el cual es el nivel de descripción más bajo de los datos en una base de datos. Este proporciona una interfaz al sistema de archivos del sistema operativo el cual es el responsable del acceso a la base de datos. El nivel interno tiene que ver con la especificación de qué elementos serán indexados, qué técnica de organización de archivos utilizar y como los datos se agrupan en el disco mediante "clusters" para mejorar su acceso.
1.1,1 AUTONOMIA
Autonomía. La autonomía se puede presentar a diferentes niveles:
Autonomía de diseño. La habilidad de un componente del SMBD para decidir cuestiones relacionadas a su propio diseño.
Autonomía de comunicación. La habilidad de un componente del SMBD para decidir como y cuando comunicarse con otros SMBD.
Autonomía de ejecución. La habilidad de un componente del SMBD para ejecutar operaciones locales de la manera que él quiera.
1.1.2 HETEROGENEIDAD
Heterogeneidad. La heterogeneidad se puede presentar a varios niveles: hardware, sistema de comunicaciones, sistema operativo o SMBD. Para el caso de SMBD heterogéneos ésta se puede presentar debido al modelo de datos, al lenguaje de consultas o a los algoritmos para manejo de transacciones.
Esta clase se caracteriza por el uso de diferentes DBMS en los nodos locales. Hay dos subclases principales: los que hacen su integración totalmente dentro del sistema, y los más simples “hooks” o los apéndices externos llamados gateways, para permitir enlace a sistemas ajenos.
La anterior subclase puede ser adicionalmente refinada en una subclase que provee un subconjunto importante de funciones que uno esperaría desde cualquier
SGBD, y que enfatiza en los aspectos más pragmáticos del manejo de datos colectivos, tales como conversiones entre sistemas y algún aspecto básico de desempeño (sistemas multidatabase). Los sistemas multidatabase (SGBDMs) tienen múltiples SGBD, posiblemente de diferentes tipos, y múltiples, DBspreexistentes. La integración es desempeñada por lo tanto por múltiples software de subsistemas.

1.2Diseño de bases de datos distribuidas

Cuando pensamos en el diseño de las bases de datos distribuidas debemos tener en cuenta la ubicación de los programas que accederán a las bases de datos y sobre los propios datos que constituyen la base de datos, en diferentes puntos de una red. Sobre la ubicación 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), ubicaríamos la base de dato en cada




1.2.1Diseño top-down : fragmentación.
Un esquema de este proceso puede observarse en la siguiente figura:

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.

1.3 Arquitecturas Cliente/Servidor para SGBD

Esta arquitectura se divide en dos partes claramente diferenciadas, la primera es la parte del servidor y la segunda la de un conjunto de clientes. Normalmente el servidor es una máquina bastante potente que actúa de depósito de datos y funciona como un sistema gestor de base de datos (SGBD). Por otro lado los clientes suelen ser estaciones de trabajo que solicitan varios servicios al servidor.
Ambas partes deben estar conectadas entre sí mediante una red. Este tipo de arquitectura es la más utilizada en la actualidad, debido a que es la más avanzada y la que mejor ha evolucionado en estos últimos años. Podemos decir que esta arquitectura necesita tres tipos de software para su correcto funcionamiento:
Software de gestión de datos: Este software se encarga de la manipulación y gestión de los datos almacenados y requeridos por las diferentes aplicaciones. Normalmente este software se aloja en el servidor.
Software de desarrollo: este tipo de software se aloja en los clientes y solo en aquellos que se dedique al desarrollo de aplicaciones.
Software de interacción con los usuarios: También reside en los clientes y es la aplicación gráfica de usuario para la manipulación de datos, siempre claro a nivel usuario (consultas principalmente).
A parte de estos existen más aplicaciones software para el correcto funcionamiento de esta arquitectura pero ya están condicionados por el tipo de sistema operativo instalado, el tipo de red en la que se encuentra, etc.

1.3.1Filosofía Cliente/Servidor
La tecnología llamada Cliente /Servidor es actualmente utilizada en casi todas las aplicaciones administrativas e Internet/Intranet. Bajo esta filosofia, un servidor es un ordenador remoto, en algún lugar de una red, que proporciona información según se le solicite. Mientras que un cliente funciona en su computadora local, se comunica con el servidor remoto y pide a éste información.
Típicamente, un único servidor atiende a una multitud de clientes, ahorrando a cada uno de ellos el problema de tener la información instalada y almacenada localmente. Los sistemas Cliente-Servidor pueden ser de muchos tipos, pues esto depende principalmente de las aplicaciones instaladas en el propio servidor. Entre otros, existen: servidores de impresión mediante los cuales los usuarios comparten impresoras, servidores de archivos con los que los clientes comparten discos duros, servidores de bases de datos donde existe una única base de datos que es consultada por los clientes y puede o no ser modificada por ellos y servidores Web que utilizan también la tecnología Cliente/Servidor, aunque añaden aspectos nuevos y propios a la misma.
1.3.2Sockets
Para que dos programas puedan comunicarse entre sí es necesario que se cumplan ciertos requisitos:
Que un programa sea capaz de localizar al otro.
Que ambos programas sean capaces de intercambiarse cualquier secuencia de octetos, es decir, datos relevantes a su finalidad.
Para ello son necesarios los tres recursos que originan el concepto de socket:
Un protocolo de comunicaciones, que permite el intercambio de octetos.
Una dirección del Protocolo de Red (Dirección IP, si se utiliza el Protocolo TCP/IP), que identifica una computadora.
Un número de puerto, que identifica a un programa dentro de una computadora.
Los sockets permiten implementar una arquitectura cliente-servidor. La comunicación ha de ser iniciada por uno de los programas que se denomina programa cliente. El segundo programa espera a que otro inicie la comunicación, por este motivo se denomina programa servidor.
Un socket es un fichero existente en la máquina cliente y en la máquina servidora, que sirve en última instancia para que el programa servidor y el cliente lean y escriban la información. Esta información será la transmitida por las diferentes capas de red.
1.3.3RPC
El RPC (del inglés Remote Procedure Call, Llamada a Procedimiento Remoto) es un protocolo que permite a un programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo es un gran avance sobre los sockets usados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, estando éstas encapsuladas dentro de las RPC.
Las RPC son muy utilizadas dentro del paradigma cliente-servidor. Siendo el cliente el que inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando éste de vuelta el resultado de dicha operación al cliente.
Hay distintos tipos de RPC, muchos de ellos estandarizados como pueden ser el RPC de Sun denominado ONC RPC (RFC 1057), el RPC de OSF denominado DCE/RPC y el Modelo de Objetos de Componentes Distribuidos de Microsoft DCOM, aunque ninguno de estos es compatible entre sí. La mayoría de ellos utilizan un lenguaje de descripción de interfaz (IDL) que define los métodos exportados por el servidor.
1.3.4CORBA

CORBA (Common Object Request Broker Architecture), es una arquitectura estándar para sistemas de objetos distribuidos. Permite una distribución, colección heterogénea de objetos para interoperar.

· CORBA define una arquitectura para objetos distribuidos.
· El paradigma básico de CORBA es de una solicitud para servicios de objetos distribuidos.
· Todo lo demás definido por el OMG es en términos de este paradigma básico.
· Los servicios que un objeto provee son dados por su interface. Las interfaces son definidas en el Lenguaje de Definición de Interface (IDL) del OMG.
· Los objetos distribuidos son identificados por referencias a objetos, las cuales son definidas por las interfaces IDL.

1.4 Optimización de preguntas y transacciones
El propósito es seleccionar el mejor camino de acceso para una consulta local.
· Optimización mediante operación de semijoin.
Proceso distribuido de consultas utilizando semijoin. Reducción del número de tuplasantes de ser transferidas a otro nodo. Se envía la columna con la que se va a realizar el joinde una relación R al nodo donde se encuentra la otra relación, allí se realiza el joincon la otra relación. Se envían las columnas implicadas en el resultado al nodo inicial y se vuelve a realizar el joincon R. Sólo se transfieren las columnas de R que intervienen en la realización del joinen una dirección y el subconjunto de columnas de S resultantes en la otra.