UNIDAD #1 Base de Datos Distribuidas

Instituto Tecnologico

De cerro Azul

Ing. Salvador Zamora Garza

Grupo: HP42

Esperanza de la Paz Granados García

Unidad 1

Base 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 máquina aislada. La información que constituye la base de datos esta almacenada en diferentes sitios en la red, y las aplicaciones que se ejecutan accedan datos en distintos sitios.

Es una colección de datos que pertenecen lógicamente a un sólo sistema, pero se encuentra físicamente esparcido en varios "sitios" de la red.
Se almacenan físicamente en varias bases de datos "reales" distintas ubicadas en diferentes sitios.
Cada sitio tiene sus propias bases de datos "reales" locales, sus propios usuarios locales, sus propios DBMS y programas para la administración de transacciones.

Un sistema de base de datos distribuidas se compone de un conjunto de sitios, conectados entre sí mediante algún tipo de red de comunicaciones, en el cual:

• Cada sitio es un sistema de base de datos en sí mismo, pero,
• Los sitios han convenido en trabajar juntos ( si es necesario ) con el fin de que un usuario de cualquier sitio pueda obtener acceso a los datos de cualquier punto de la red tal como si todos los datos estuvieran almacenados en el sitio propio del usuario.
  

1.1ARQUITECTURA

La tecnología y prototipo de los sistemas de gestión de bases de datos distribuidas se han desarrollado de uno a otro y cada sistema adopta una arquitectura particular propia.

La arquitectura de un sistema de base de datos se divide en 3 niveles comunes, nivel interno, conceptual y externo.

Nivel Interno: Es el más cercano al almacenamiento físico, es decir, es el que se ocupa de la forma como se almacenan físicamente los datos.

Nivel Externo: Es el mas cercano a los usuarios, es decir, es el que se ocupa de la forma como los usuarios reciben los datos.

Nivel Conceptual: Es el nivel de mediación entre los 2 anteriores:
Externo (aplicaciones)
Conceptual (modelo, (entidad/relación))
Interno (Hardware)

1.1.1 AUTONOMÍA

La autonomía local es el grado hasta el cual el diseñador o administrador de una localidad pueden ser independientes del resto del sistema distribuido.

Autonomía Local: Los sitios distribuidos deben ser autónomos, es decir que todas las operaciones en un sitio dado se controlan en ese sitio.

1.1.2 HETEROGENEIDAD

La Heterogeneidad de las BD es inevitable cuando diferentes tipos de BD coexisten en una organización que trata de compartir datos entre éstas.
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” (gancho) o los apéndices externos llamados Gateway (enlaces), para permitir enlace a sistemas ajenos.

1.1.3DISTRIBUCIÓN Y ESQUEMA GLOBAL

En los sistemas Cliente/Servidor, un objeto distribuido es aquel que está gestionado por un servidor y sus clientes invocan sus métodos utilizando un "método de invocación remota". El cliente invoca el método mediante un mensaje al servidor que gestiona el objeto, se ejecuta el método del objeto en el servidor y el resultado se devuelve al cliente en otro mensaje.

1.1.2 DISEÑO DE BASES DE DATOS DISTRIBUIDAS

En un sistema de base de datos distribuida, los datos se almacenan en varios computadores.
Los computadores de un sistema distribuido se comunican entre sí a través de diversos medios de comunicación, tales como cables de alta velocidad o líneas telefónicas. No comparten la memoria principal ni el reloj.
Los procesadores de un sistema distribuido pueden variar en cuanto su tamaño y función.
Pueden incluir microcomputadores pequeños, estaciones de trabajo y sistemas de computadores grandes de aplicación general. Estos procesadores reciben diferentes nombres, tales como localidades, nodos o computadores.

Estructura de Base de Datos Distribuidas

Un sistema distribuido de base de datos consiste en un conjunto de localidades, cada una de las cuales mantiene un sistema de base de datos local. Cada localidad puede procesar transacciones locales, o bien transacciones globales entre varias localidades, requiriendo para ello comunicación entre ellas.
Las localidades pueden conectarse físicamente de diversas formas, las principales son:

• Red totalmente conectada
• Red prácticamente conectada
• Red con estructura de árbol
• Red de estrella
• Red de anillo

fiabilidad y disponibilidad

Si se produce un fallo en una localidad de un sistema distribuido, es posible que las demás localidades puedan seguir trabajando.

En particular, si los datos se repiten en varias localidades, una transacción que requiere un dato específico puede encontrarlo en más de una localidad. Así, el fallo de una localidad no implica necesariamente la desactivación del sistema.

El sistema debe detectar cuando falla una localidad y tomar las medidas necesarias para recuperarse del fallo.

El sistema no debe seguir utilizando la localidad que falló. Por último, cuando se recupere o repare esta localidad, debe contarse con mecanismos para reintegrarla al sistema con el mínimo de complicaciones.
La disponibilidad es fundamental para los sistemas de bases de datos que se utilizan en aplicaciones de tiempo real.
Por ejemplo, si una línea aérea no puede tener acceso a la información, es posible que pierda clientes a favor de la competencia.

Transparencia y Autonomía

Una relación r puede almacenarse de varias formas en un sistema de base de datos distribuida. Es esencial que el sistema reduzca al mínimo la necesidad de que el usuario se dé cuenta de cómo está almacenada una relación. Un sistema puede ocultar los detalles de la distribución de la información en la red.

Esto se denomina transparencia de la red. La transparencia de la red se relaciona, en algún modo, a la autonomía local.

La transparencia de la red es el grado hasta el cual los usuarios del sistema pueden ignorar los detalles del diseño distribuido. La autonomía local es el grado hasta el cual el diseñador o administrador de una localidad pueden ser independientes del resto del sistema distribuido.

Los temas de transparencia y autonomía serán considerados desde los siguientes puntos de vista:

• Nombre de los datos.
• Repetición de los datos.
• Fragmentación de los datos.
• Localización de los fragmentos y copias.

1.2.1DISEÑO TOP- DOWN : FRAGMENTACIÓN.

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.

1.2.2 DISEÑO BOTTOM-UP : INTEGRACIÓN DE BASES DE DATOS.

El diseño ascendente se refiere a la identificación de aquellos procesos que necesitan computarizarse con forme vayan apareciendo, su análisis como sistema y su codificación, o bien, la adquisición de paquetes de software para satisfacer el problema inmediato.
Se utiliza particularmente a partir de bases de datos existentes, generando con esto bases de datos distribuidas.
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. 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.1.3 DISTRIBUCIÓN Y ESQUEMA GLOBAL

En los sistemas Cliente/Servidor, un objeto distribuido es aquel que esta gestionado por un servidor y sus clientes invocan sus métodos utilizando un "método de invocación remota". El cliente invoca el método mediante un mensaje al servidor que gestiona el objeto, se ejecuta el método del objeto en el servidor y el resultado se devuelve al cliente en otro mensaje.

1.3 ARQUITECTURAS CLIENTE/SERVIDOR PARA SGBD

Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro programa (el servidor) que le da respuesta.
Es Ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.
En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.

1.3.1 FILOSOFÍA CLIENTE/SERVIDOR

La arquitectura cliente/servidor genérica tiene dos tipos de nodos en la red: clientes y servidores.
Algunas redes disponen de tres tipos de nodos:

• Clientes que interactúan con los usuarios finales.
• Servidores de aplicación que procesan los datos para los clientes.
• Servidores de la base de datos que almacenan los datos para los servidores de aplicación.
  
  
  Ventajas:
  
  
• Centralización del control: los accesos, recursos y la integridad de los datos son controlados por el servidor de forma que un programa cliente defectuoso o no autorizado no pueda dañar el sistema.
• Escalabilidad: se puede aumentar la capacidad de clientes y servidores por separado.


• Fácil mantenimiento: al estar distribuidas las funciones y responsabilidades entre varios ordenadores independientes, es posible reemplazar, reparar, actualizar, o incluso trasladar un servidor, mientras que sus clientes no se verán afectados por ese cambio (o se afectarán mínimamente).
  

1.3.2 SOCKETS

Los sockets no son más que puntos o mecanismos de comunicación entre procesos que permiten que un proceso hable ( emita o reciba información ) con otro proceso incluso estando estos procesos en distintas máquinas.
Un socket es al sistema de comunicación entre ordenadores lo que un buzón o un teléfono es al sistema de comunicación entre personas: un punto de comunicación entre dos agentes( procesos o personas respectivamente ) por el cual se puede emitir o recibir información
El mecanismo de comunicación vía sockets tiene los siguientes pasos:
1º) El proceso servidor crea un socket con nombre y espera la conexión.
2º) El proceso cliente crea un socket sin nombre.
3º) El proceso cliente realiza una petición de conexión al socket servidor.
4º) El cliente realiza la conexión a través de su socket mientras el proceso servidor mantiene el socket servidor original con nombre.

1.3.3 RPC( 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.
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.

1.3.4 CORBA

Es un estándar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos.
CORBA "envuelve" el código escrito en otro lenguaje, en un paquete que contiene información adicional sobre las capacidades del código que contiene y sobre cómo llamar a sus métodos.
Los objetos que resultan, pueden entonces ser invocados desde otro programa (u objeto CORBA) desde la red.
CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras, pero con más información.
CORBA es más que una especificación multiplataforma, también 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 OPTIMIZACIÓN DE PREGUNTAS Y TRANSACCIONES

Una transacción en un Sistema de Gestión de Bases de Datos (SGBD), es un conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atómica
El lenguaje de consulta de datos SQL (Structured Query Language), provee los mecanismos para especificar que un conjunto de acciones deben constituir una transacción.
BEGIN TRAN
COMMIT TRAN
ROLLBACK TRAN
Protocolo de compromiso en dos fases. (Twophasecommitprotocol).
1. El coordinador envía una solicitud de voto (vote request) a los nodos participantes en la ejecución de la transacción.
2. Cuando los participantes reciben la solicitud de voto, responden enviando al coordinador un mensaje con su voto (Sí o No).
3. El coordinador recoge los mensajes con los votos de todos los participantes. Si todos han votado Sí, entonces el coordinador también vota si y envía un mensaje omita todos los participantes.
4. Cada participante que ha votado sí, espera del coordinador un mensaje conmutado para terminar la transacción de forma normal o abortarla.