Base de datos distribuida

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 accesan datos en distintos sitios.

Una Base de Datos Distribuida entonces 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. 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.

En consecuencia, la llamada "base de datos distribuida" es en realidad una especie de objeto virtual, cuyas partes componentes se almacenan físicamente en varias bases de datos "reales" distintas ubicadas en diferentes sitios. De hecho, es la unión lógica 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 administración de transacciones ( incluyendo programas de bloqueo, bitácoras, recuperación, etc ), y su propio administrador local de comunicación 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 lógico, una extensión del DBMS local ) realiza las funciones de sociedad necesarias; y es la combinación de este nuevo componente y el DBMS ya existente lo que constituye el llamado "sistema de administración de bases de datos distribuidas" (DDBMS, distributed database management system ).

El sistema de administración de Base de Datos Distribuida (DDBMS), esta formado por las transacciones y los administradores de base de datos distribuidos de todas las computadoras. Tal DDBMS en un esquema genérico 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 de una colección de programas de fuentes dispares : algunos considerados por fabricantes y algunos otros escritos en casa.

Un administrador de base de datos (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. La diferencia principal entre los sistemas de bases de datos centralizados y los distribuidos es que en los primeros, los datos residen en una sola localidad, mientras que, en lo últimos, se encuentran en varias localidades. Cada localidad puede procesar transacciones locales , es decir, aquellas que sólo acceden a datos que residen en esa localidad. Además, una localidad puede participar en la ejecución de transacciones globales , es decir, aquellas que acceden a datos de varias localidades, ésta requiere comunicación entre las localidades. · Una transacción local es la que accede a cuentas en la localidad individual donde se inicio. En cambio, una transacción global accede a cuentas de una localidad distinta a la localidad donde se inicio o a cuentas de varias localidades diferentes.

Ejemplo 1.1

Considere un banco que tiene tres sucursales, en cada sucursal, un computador controla las terminales de la misma y el sistema de cuentas. Cada computador con su sistema de cuentas local en cada sucursal constituye un "sitio" de la BDD; las computadoras están conectadas por la red. Durante las operaciones normales, las aplicaciones en las terminales de la sucursal necesitan solo accesar la BD de la misma. Como solo accesan la misma red local, se les llaman aplicaciones locales .

Desde el punto de vista tecnológico, aparentemente lo importante es la existencia de algunas transacciones que accesen información en más de una sucursal. Éstas transacciones son llamadas transacciones globales o transacciones distribuidas.
La existencia de transacciones globales será considerada como una característica que nos ayude a discriminar entre las BDD y un conjunto de base de datos locales.

Una típica transacción global sería una transferencia de fondos de una sucursal a otra. Esta aplicación requiere de actualizar datos en dos diferentes sucursales y asegurarse de la real actualización en ambos sitios o en ninguno. Asegurar el buen funcionamiento de aplicaciones globales es una tarea difícil. En el ejemplo 1.1 las computadoras estaban geográficamente en diferentes puntos; también, BDD pueden ser construidas en una red local.

¿Por qué son deseables las bases de datos distribuidas?

La respuesta básica a esta pregunta es que por lo regular las empresas ya están distribuidas, por lo menos desde el punto de vista lógico ( en divisiones, departamentos, proyectos, etc ) y muy probablemente en el sentido físico también ( en plantas, talleres, laboratorios, y demás ), de lo cual se desprende que en general la información ya está también distribuida, porque cada unidad de organización dentro de la empresa mantendrá por fuerza los datos pertinentes a su propio funcionamiento. Así pues, un sistema distribuido permite que la estructura de la base de datos refleje la estructura de la empresa : los datos locales se pueden mantener en forma local, donde por lógica deben estar, pero al mismo tiempo es posible obtener acceso a datos remotos en caso necesario.

Un principio fundamental de los sistemas de bases de datos distribuidos

El principio fundamental de las bases de datos distribuidas :

Desde el punto de vista del usuario, un sistema distribuido deberá ser idéntico un sistema no distribuido. En otras palabras, los usuarios de un sistema distribuido deberán comportarse exactamente como si el sistema no estuviera distribuido. Todos los problemas de los sistemas distribuidos son (o deberían ser ) internos o a nivel de realización, no externos o a nivel del usuario. Llamaremos al principio fundamental recién identificado la "regla cero" de los sistemas distribuidos. La regla cero conduce a varios objetivos o reglas secundarios - doce en realidad- siguientes :

 Autonomía local.

 No dependencia de un sitio central.

 Operación continua.

 Independencia con respecto a la localización.

 Independencia con respecto a la fragmentación.

 Independencia de réplica.

 Procesamiento distribuido de consultas.

 Manejo distribuido de transacciones.

 Independencia con respecto al equipo.

 Independencia con respecto al sistema operativo.

 Independencia con respecto a la red.

 Independencia con respecto al DBMS.

Estas doce reglas no son todas independientes entre sí, ni son por fuerza exhaustivas, ni tienen todas la misma importancia ( diferentes usuarios darán diferentes grados de importancia a diferentes reglas en diferentes ambientes ). Sin embargo, sí son útiles como fundamento para entender la tecnología distribuida y como marco de referencia para caracterizar la funcionalidad de sistemas distribuidos específicos.

Un último punto introductorio: es importante distinguir los sistemas distribuidos de bases de datos verdaderos, generalizados, de los sistemas que tan solo ofrecen algún tipo de acceso remoto a los datos ( llamados a veces sistemas de procesamiento distribuido o sistemas de red ). En un " sistema de acceso remoto a los datos ", el usuario podría ser capaz de trabajar con datos de un sitio remoto, o aun con datos de varios sitios remotos al mismo tiempo, pero " se notan las costuras" ; el usuario definitivamente está consciente ( en mayor o menor grado ) de que los datos son remotos, y debe comportarse de manera acorde. En cambio, en un sistema distribuido verdadero.

EL ADMINISTRADOR DE BD (DBA)

Persona que toma las decisiones estratégicas y de política con respecto a la información de la empresa, y el DBA es quién proporciona el apoyo técnico necesario para poner en práctica esas decisiones. Por tanto el DBA esta encargado del control general del sistema en el nivel técnico.

Funciones del DBA

Definir el esquema conceptual	Debe decidir cuál es la información que debe mantenerse en la BD, es decir, identificar las entidades que interesan a la empresa y la información qué debe registrarse acerca de esas entidades. Este proceso se denomina diseño lógico de BD. El DBMS utilizará la versión objeto (compilada) de ese esquema para responder a las solicitudes de acceso. La versión fuente (sin compilar) servirá como documento de referencia para los usuarios del sistema.
Definir el esquema interno	Debe decidir cómo se representará la información en la BD almacenada. A éste proceso se lo denomina diseño físico de la BD. El DBA se vale del DDL interno para crear la definición de estructura de almacenamiento y la correspondencia pertinente entre los esquemas interno y conceptual (tanto en la versión fuente como objeto).
Vincularse con los usuarios	El DBA debe encargarse de la comunicación con los usuarios, garantizar la disponibilidad de los datos que requieren y escribir los esquemas necesarios. Las consultas sobre diseño de aplicaciones, la impartición técnica, la ayuda en la localización y resolución de problemas, y otros servicios profesionales similares relacionados con el sistema.
Definir las verificaciones de seguridad e integridad	Las verificaciones de seguridad e integridad pueden considerarse parte del esquema conceptual.
Definir procedimientos de respaldo y recuperación	Cuando una empresa se decide a utilizar un sistema de BD, se vuelve dependiente en grado sumo del funcionamiento correcto de ese sistema. En caso de que sufra daño cualquier porción de la BD resulta esencial poder reparar los datos implicados con un mínimo de retraso y afectando lo menos posible al resto del sistema. El DBA debe definir y poner en práctica un plan de recuperación adecuado que incluya, por ejemplo, una descarga o “vaciado” periódico de la BD en un medio de almacenamiento de respaldo, y procedimientos para cargar otra vez la BD a partir del vaciado más reciente cuando sea necesario.
Supervisar el desempeño y responder a cambios en los requerimientos	Es responsabilidad del DBA organizar el sistema de modo que se obtenga el desempeño que sea mejor para la empresa, y realizar los ajustes apropiados cuando cambien los requerimientos.

b) Bases de Datos Distribuidas Heterogéneas:

Se compone de un conjunto de localidades, cada

una de las cuales mantiene un SBD local, éstas

pueden procesar transacciones locales (aquellas

que se realizan sobre esa localidad).

EJEMPLO

ARQUITECTURA DE UN SISTEMA DE BASES DE DATOS DISTRIBUIDAS

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.

Ventajas de SBDD

• La principal ventaja es que permiten que la estructura de la base de datos se ajuste de forma lógica a las necesidades de las empresas. El tener esto tiene como ventaja inherente que la información de la base de datos puede ser accedida más eficientemente que en un sistema centralizado.

• Autonomía Local. Los lugares que conforman el SBDD deben ser autónomos y poder operar como SGBD locales
• No dependencia de un lugar central. Dentro del sistema no debería haber un lugar central del cual dependiera la operación de todo el sistema. Esto se refiere no solo al almacenamiento de los datos, si no al manejo de transacciones, procesamiento de consultas, etc.
• Operación continua. La operación del SBDD no debería de ser afectado por cambios del SGBD en algunos lugares, o dar de alta nuevos lugares.
• Independencia de la localización. Para los usuarios debe ser transparente en donde estén localizados los datos.

Reglas que debería cumplir un SBDD

• Independencia de fragmentación. Los usuarios no deben preocuparse de cómo están particionados los datos. Respecto a la fragmentación.
• Independencia de la replicación. El usuario no debería preocuparse de que existan datos
• Un SBDD debe soportar el que una consulta sea resuelta parcialmente en diferentes lugares y después integrar los resultados, con objeto de reducir el tráfico en la red de comunicaciones. La optimización de consultas es mas importante en un SBDD que en un sistema centralizado

-Manejo de Transacciones Distribuidas. El SBDD debe soportar el manejo de control de concurrencia y recuperación. Para esto se implementa generalmente el manejo de BLOQUEOS y el PROTOCOLO COMMIT de DOS FASES.

• Independencia del Hardware. La operación del SBDD debe ser independiente del hardware utilizado en cada uno e los lugares.
• Independencia del sistema operativo. El sistema debe operar como si solo existiera un sistema operativo, es decir debe ser transparente que en el SBDD existan diversos sistemas operativos.
• Independencia de la red. Igual que la regla anterior, sin importar que red o redes se tengan en operación, debe ser como un sistema centralizado.
• Independencia del SGBD. No importando cuantos y cuales SGBD se tengan en el SBDD, para el usuario se tiene la impresión de que es un solo SGBD.

Principales problemas en los sistemas distribuidos

• Las velocidades de transmisión del medio de comunicación pueden ser tan bajas como 1200 bps. Mientras que en un sistema local tenemos velocidades de 2 Mbps.
• Procesamiento de Consultas. En este aspecto se debe tratar de reducir el número y tamaño de registros que son movidos entre los diferentes lugares al tratar de resolver consultas. Además de la información se requiere para realizar la optimización en forma local, es necesario contar con la información de fragmentación y localización

• Propagación de actualizaciones

Este es uno de los problemas más graves de tener los datos replicados. Una solución excelente no se tiene, y normalmente se implementa la siguiente estrategia:

• Una copia centralizada que es la que generalmente se actualiza.
• Múltiples copias que son actualizadas bajo la responsabilidad del lugar que tiene la copia centralizada.

Concurrencia

Este problema puede dar lugar a DEADLOCKS distribuidos Una de las estrategias que se siguen para controlar la concurrencia involucra (considerando que hay n lugares):

N requerimientos de bloqueo

N concesiones de bloqueo

N mensajes de actualización

N reconocimientos

N requerimientos de desbloqueo

En el enfoque de una copia centralizada que después se actualiza a las demás copias se requiere:

Un requerimiento de bloqueo

Una concesión de bloqueo

N actualizaciones

N reconocimientos

1 requerimiento de desbloqueo

Transacciones

Una transacción es una unidad lógica de trabajo. Una transacción esta compuesta de un conjunto de operaciones que actúan sobre una base de datos.

COMMIT Y ROLLBACK

Transacciones: Commit y Rollback

• COMMIT. Señaliza el fin exitoso de una transacción. Al ejecutar esta instrucción se hacen permanentes, dejando la base de datos consistente
• ROLLBACK. Señaliza la terminación no-existosa de una transacción. Todas las actualizaciones hechas por la transacción son desechas.

FALLAS LOCALES Y GLOBALES

Una falla local es aquella que solo afecta a una transacción local. En contraste una falla global afecta a todas las transacciones y posiblemente al sistema computacional completo.

Fallas globales:

• Fallas en el sistema. Afectan todas las transacciones en progreso pero no dañan físicamente la base dedatos. Ej. Fallas de energía.
• Fallas en unidades de almacenamiento. Afectan a la base de datoscompleta o una porción de ella. Ej. Falla en el disco.

TIPOS DE BLOQUEOS (LOCKS)

Una forma de controlar algunos de los problemas anteriormente descritos es a través del uso de LOCKS que permiten que una transacción BLOQUEE una porción de la base de datos

Bloqueos Compartidos

Bloqueos Exclusivos