martes, 17 de junio de 2008

Bases de Dactos Distribuida





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 ).












Ejemplo



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.


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
 Las doce reglas.
 Autonomía Local.
Los sitios de un sistema distribuido deben ser autónomos . La autonomía local significa que todas las operaciones en un sitio dado se controlan en ese sitio; ningún sitio X deberá depender de algún otro sitio Y para su buen funcionamiento (pues de otra manera el sitio X podría ser incapaz de trabajar, aunque no tenga en sí problema alguno, si cae el sitio Y, situación a todas luces indeseable). La autonomía local implica también un propietario y una administración locales de los datos, con responsabilidad local : todos los datos pertenecen " en realidad" a una base de datos local, aunque sean accesibles desde algún sitio remoto. Por tanto, las cuestiones de seguridad, integridad y representación en almacenamiento de los datos locales permanecen bajo el control de la instalación local.
2. No dependencia de un sitio central.
La autonomía local implica que todos los sitios deben tratarse igual; no debe haber dependencia de un sitio central "maestro" para obtener un servicio central, como por ejemplo un procesamiento centralizado de las consultas o una administración centralizada de las transacciones, de modo que todo el sistema dependa de ese sitio central. Este segundo objetivo es por tanto un corolario del primero ( si se logra el primero, se logrará pro fuerza el segundo ) . Pero la "no dependencia de un sitio central" es deseable por sí misma, aun si no se logra la autonomía local completa. Por ello vale la pena expresarlo como un objetivo separado.
La dependencia de un sitio central sería indeseable al menos por las siguientes razones : en primer lugar, ese sitio central podrí ser un cuello de botella; en segundo lugar, el sistema sería vulnerable ; si el sitio central sufriera un desperfecto, todo el sistema dejaría de funcionar.
3. Operación continua.
En un sistema distribuido, lo mismo que en uno no distribuido, idealmente nunca debería haber necesidad de apagar a propósito el sistema . Es decir, el sistema nunca debería necesitar apagarse para que se pueda realizar alguna función, como añadirse un nuevo sitio o instalar una versión mejorada del DBMS en un sitio ya existente.
4. Independencia con respecto a la localización.
La idea básica de la independencia con respecto a la localización (también conocida como transparencia de localización) es simple : no debe ser necesario que los usuarios sepan dónde están almacenados físicamente los datos, sino que más bien deben poder comportarse - al menos desde un punto de vista lógico - como si todos los datos estuvieran almacenados en su propio sitio local. La independencia con respecto a la localización es deseable porque simplifica los programas de los usuarios y sus actividades en la terminal. En particular, hace posible la migración de datos de un sitio a otro sin anular la validez de ninguno de esos programas o actividades. Esta posibilidad de migración es deseable pues permite modificar la distribución de los datos dentro de la red en respuesta a cambios en los requerimientos de desempeño.
5. Independencia con respecto a la fragmentación.
Un sistema maneja fragmentación de los datos si es posible dividir una relación en partes o "fragmentos" para propósitos de almacenamiento físico. La fragmentación es deseable por razones de desempeño: los datos pueden almacenarse en la localidad donde se utilizan con mayor frecuencia, de manera que la mayor parte de las operaciones sean sólo locales y se reduzca al tráfico en la red. Por ejemplo, la relación empleados EMP podría fragmentarse de manera que los registros de los empleados de Nueva York se almacenen en el sitio de Nueva York, en tanto que los registros de los empleados de Londres se almacenan en el sitio de Londres.Existen en esencia dos clases de fragmentación, horizontal y vertical, correspondientes a las operaciones relacionales de restricción y proyección; respectivamente. En términos más generales, un fragmento puede ser cualquier subrelación arbitraria que pueda derivarse de la relación original mediante operaciones de restricción y proyección ( excepto que, en el caso de la proyección es obvio que las proyecciones deben conservar la clave primaria de la relación original ). La reconstrucción de la relación original a partir de los fragmentos se hace mediante operaciones de reunión y unión apropiadas ( reunión en el caso de fragmentación vertical, y la unión en casos de fragmentación horizontal ).


Ahora llegamos a un punto principal : un sistema que maneja la fragmentación de los datos deberá ofrecer también una independencia con respecto a la fragmentación (llamada también transparencia de fragmentación). La independencia con respecto a la fragmentación ( al igual que la independencia con respecto a la independencia con respecto a la localización) es deseable porque simplifica los programas de los usuarios y sus actividades en la terminal.
6. Independencia de réplica.
Un sistema maneja réplica de datos si una relación dada (ó en términos más generales, un fragmento dado en una relación) se puede representar en el nivel físico mediante varias copias almacenadas o réplicas , en muchos sitios distintos.La réplica es deseable al menos por dos razones : en primer lugar, puede producir un mejor desempeño (las aplicaciones pueden operar sobre copias locales en vez de tener que comunicarse con sitios remotos) ; en segundo lugar, también puede significar una mejor disponibilidad (un objeto estará disponible para su procesamiento en tanto esté disponible por lo menos una copia, al menos para propósitos de recuperación). La desventaja principal de las réplicas es desde luego que cuando se pone al día un cierto objeto copiado, deben ponerse al día todas las réplicas de ese objeto : el problema de la propagación de actualizaciones.
La réplica como la fragmentación, debe ser "transparente para el usuario". En otras palabras , un sistema que maneja la réplica de los datos deberá ofrecer también una independencia de réplica (conocida también como transparencia de réplica); es decir, los usuarios deberán poder comportarse como si sólo existiera una copia de los datos. La independencia de réplica es buena porque simplifica los programas de los usuarios y sus actividades en la terminal. En particular, permite la creación y eliminación dinámicas de las réplicas en cualquier momento en respuesta a cambios en los requerimientos, sin anular la validez de esos programas o actividades de los usuarios.
7. Procesamiento distribuido de consultas.
En este aspecto debemos mencionar dos puntos amplios.
Primero consideremos la consulta "obtener los proveedores de partes rojas en Londres". Supongamos que el usuario está en la instalación de Nueva York y los datos están en el sitio de Londres. Supongamos también que son n8. Manejo distribuido de transacciones.

El manejo de transacciones tiene dos aspectos principales, el control de recuperación y el control de concurrencia, cada uno de los cuales requiere un tratamiento más amplio en el ambiente distribuido. Para explicar ese tratamiento más amplio es preciso introducir primero un término nuevo, "agente". En un sistema distribuido, una sola transacción puede implicar la ejecución de código en varios sitios ( en particular puede implicar a actualizaciones en varios sitios ). Por tanto, se dice que cada transacción está compuesta de varios agentes, donde un agente es el proceso ejecutado en nombre de una transacción dada en determinado sitio. Y el sistema necesita saber cuándo dos agentes son parte de la misma transacción; por ejemplo, es obvio que no puede permitirse un bloqueo mutuo entre dos agentes que sean parte de la misma transacción. La cuestión especifica del control de recuperación; : para asegurar, pues que una transacción dada sea atómica ( todo o nada ) en el ambiente distribuido, el sistema debe asegurarse de que todos los agentes correspondientes a esa transacción se comprometan al unísono o bien que retrocedan al unísono. Este efecto puede lograrse mediante el protocolo de compromiso en dos fases.
En cuanto al control de concurrencia, esta función en un ambiente distribuido estará basada con toda seguridad en el bloqueo, como sucede en los sistemas no distribuidos.
9. Independencia con respecto al equipo.
En realidad, no hay mucho que decir acerca de este tema, el título lo dice todo. Las instalaciones de cómputo en el mundo real por lo regular incluyen varias máquinas diferentes -máquinas IBM, DEC, HP, UNISYS, PC etc- y existe una verdadera necesidad de poder integrar los datos en todos esos sistemas y presentar al usuario "una sola imagen del sistema". Por tanto conviene ejecutar el mismo DBMS en diferentes equipos, y además lograr que esos diferentes equipos participen como socios iguales en un sistema distribuido.
10. Independencia con respecto al sistema operativo.
Este objetivo es un corolario del anterior. Es obvia la conveniencia no sólo de poder ejecutar el mismo DBMS en diferentes equipos, sino también poder ejecutarlo en diferentes sistemas operativos y lograr que una versión MVS y una UNIX y una PC/DOS participen todas en el mismo sistema distribuido.
11. Independencia con respecto a la red.
Si el sistema ha de poder manejar múltiples sitios diferentes, con equipo distinto y diferentes sistemas operativos, resulta obvia la conveniencia de poder manejar también varias redes de comunicación distintas.
12. Independencia con respecto al DBMS
Bajo este título consideramos las implicaciones de relajar la suposición de homogeneidad estricta. Puede alegarse que esa suposición es quizá demasiado rígida. En realidad, no se requiere sino que los DBMS en los diferentes sitios manejen todos la misma interfaz ; no necesitan ser por fuerza copias del mismo sistema.
Ventajas
Existen cuatro ventajas del procesamiento de bases de datos distribuidas. La primera , puede dar como resultado un mejor rendimiento que el que se obtiene por un procesamiento centralizado. Los datos pueden colocarse cerca del punto de su utilización, de forma que el tiempo de comunicación sea más mas corto. Varias computadoras operando en forma simultánea pueden entregar más volumen de procesamiento que una sola computadora.
Segundo , los datos duplicados aumentan su confiabilidad. Cuando falla una computadora, se pueden obtener los datos extraídos de otras computadoras. Los usuarios no dependen de la disponibilidad de una sola fuente para sus datos .
 Una tercera ventaja , es que los sistemas distribuidos pueden variar su tamaño de un modo más sencillo. Se pueden agregar computadoras adicionales a la red conforme aumentan el número de usuarios y su carga de procesamiento. A menudo es más fácil y más barato agregar una nueva computadora más pequeña que actualizar una computadora única y centralizada. Después, si la carga de trabajo se reduce, el tamaño de la red también puede reducirse.
Por último , los sistemas distribuidos se puede adecuar de una manera más sencilla a las estructuras de la organización de los usuarios.
Nota:
Los siguientes puntos están basados en una referencia bibliográfica distinta, y me pareció importante hablar sobre ello, espero y aclare el tema en cuestión.

Ventajas
Existen cuatro ventajas del procesamiento de bases de datos distribuidas. La primera , puede dar como resultado un mejor rendimiento que el que se obtiene por un procesamiento centralizado. Los datos pueden colocarse cerca del punto de su utilización, de forma que el tiempo de comunicación sea más mas corto. Varias computadoras operando en forma simultánea pueden entregar más volumen de procesamiento que una sola computadora.
Segundo , los datos duplicados aumentan su confiabilidad. Cuando falla una computadora, se pueden obtener los datos extraídos de otras computadoras. Los usuarios no dependen de la disponibilidad de una sola fuente para sus datos .
 Una tercera ventaja , es que los sistemas distribuidos pueden variar su tamaño de un modo más sencillo. Se pueden agregar computadoras adicionales a la red conforme aumentan el número de usuarios y su carga de procesamiento. A menudo es más fácil y más barato agregar una nueva computadora más pequeña que actualizar una computadora única y centralizada. Después, si la carga de trabajo se reduce, el tamaño de la red también puede reducirse.
Por último , los sistemas distribuidos se puede adecuar de una manera más sencilla a las estructuras de la organización de los usuarios.


Utilización compartida de los datos y distribución del control
Si varias localidades diferentes están conectadas entre si, entonces un usuario de una localidad puede acceder a datos disponibles en otra localidad. La ventaja principal de compartir datos por medio de la distribución es que cada localidad pueda controlar hasta cierto punto los datos almacenados localmente.



Fiabilidad y disponibilidad
Si se produce un fallo en una localidad en 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 o aplicación que requiere un dato especifico puede encontrarlo en más de una localidad. Así el fallo, de una localidad no implica necesariamente la desactivación del sistema.

Agilización del procesamiento de consultas
Si una consulta comprende datos de varias localidades, puede ser posible dividir la consulta en varias subconsultas que se ejecuten en paralelo en distintas localidades. En los casos en que hay repetición de los datos, el sistema puede pasar la consulta a las localidades mas ligeras de carga.
Ejemplo de sistemas.
Para efectos de referencia posterior, mencionaremos brevemente algunas de las realizaciones de sistemas distribuidos más conocidas. En primer término, los prototipos. Entre los sistemas investigados, tres de los más conocidos son :
 SDD-1 creado en la división de investigación de Computer Corporation of America (CCA) a finales de la década de los 1970 y principios de la siguiente.
 R* (pronunciado "R estrella"), versión distribuida del prototipo System R elaborada en IBM Research a principios de la década de 1980 y ;
 INGRES distribuido, versión distribuida del prototipo INGRES, creada también a principios de la década de 1980 en la University of California en Berkeley.
Pasando a productos comerciales, algunos de los más conocidos son :
 INGRES/STAR de Relational Technology, Inc.
 SQL*STAR, de Oracle Corp. y
 DB2 versión 2 Edición 2, de IBM.

Desventajas
Las primeras dos desventajas de las bases de datos distribuidas son las mismas que las dos primeras ventajas.
Primero , el rendimiento puede ser peor para el procesamiento distribuido que para el procesamiento centralizado. Depende de la naturaleza de la carga de trabajo, la red, el DDBMS y las estrategias utilizadas de concurrencia y de falla, así como las ventajas del acceso local a los datos y de los procesadores múltiples, ya que éstos pueden ser abrumados por las tareas de coordinación y de control requeridas. Tal situación es probable cuando la carga de trabajo necesita un gran número de actualizaciones concurrentes sobre datos duplicados, y que deben estar muy distribuidos.
Segundo , el procesamiento de base de datos distribuida puede resultar menos confiable que el procesamiento centralizado. De nuevo, depende de la confiabilidad de las computadoras de procesamiento, de la red, del DDBMS, de las transacciones y de las tasas de error en la carga de trabajo. Un sistema distribuido puede estar menos disponible que uno centralizado. Estas dos desventajas indican que un procesamiento distribuido no es ninguna panacea. A pesar de que tiene la promesa de un mejor rendimiento y de una mayor confiabilidad, tal promesa no está garantizada.
Una tercera desventaja es su mayor complejidad, a menudo se traduce en altos gastos de construcción y mantenimiento. Ya que existen más componentes de hardware, hay más cantidad de cosas por aprender y más interfaces susceptibles de fallar. El control de concurrencia y recuperación de fallas puede convertirse en algo complicado y difícil de implementar, puede empujar a una mayor carga sobre programadores y personal de operaciones y quizá se requiera de personal más experimentado y más costoso.
El procesamiento de bases de datos distribuido es difícil de controlar. Una computadora centralizada reside en un entorno controlado, con personal de operaciones que supervisa muy de cerca, y las actividades de procesamiento pueden ser vigiladas, aunque a veces con dificultad. En un sistema distribuido, las computadoras de proceso, residen muchas veces en las áreas de trabajo de los usuarios. En ocasiones el acceso físico no está controlado, y los procedimientos operativos son demasiado suaves y efectuados por personas que tienen escasa apreciación o comprensión sobre su importancia. En sistemas centralizados, en caso de un desastre o catástrofe, la recuperación puede ser más difícil de sincronizar.
Nota:
De las desventajas que se mencionan a continuación, están relacionadas con las doce reglas mencionadas anteriormente.
Procesamiento de Consultas
El problema más grande es que las redes de comunicación ( las de larga distancia en especial ) son lentas. El objetivo es reducir al mínimo el tráfico en la red y esto implica que el proceso mismo de optimización de consultas debe ser distribuido, además del proceso de ejecución de las consultas. Es decir un proceso representativo consistirá en un paso de optimización global, seguido de pasos de optimización local en cada unos de los sitios afectados.
Administración de Catálogo
En un sistema distribuido, el catálogo del sistema incluirá no solo la información usual acerca de las relaciones, índices, usuarios, sino también toda la información de control necesaria para que el sistema pueda ofrecer la independencia deseada con respecto a la localización, la fragmentación y la réplica.
 Centralizado (" no depender de un sitio central")
 Replicas completas (" falta de autonomía, toda la actualización debe ser propagada a cada sitio ")
 Dividido ( muy costoso )
 Combinación de 1 y 3 (" no depender de un sitio central ").
Propagación de Actualizaciones
El problema básico con la réplica de datos, es la necesidad de propagar cualquier modificación de un objeto lógico dado a todas las copias almacenadas de ese objeto. Un problema que surge es que algún sitio donde se mantiene una copia del objeto puede NO estar disponible, y fracasaría; la modificación si cualquiera de las copias no esta disponible.
Para tratar este problema se habla de " una copia primaria " y funciona así :
· Una de las copias del objeto se designa como copia primaria, y las otras serán secundarias.
· Las copias primarias de los distintos objetos están en sitios diferentes.
· Las operaciones de actualización se consideran completas después de que se ha modificado la copia primaria.
. El sitio donde se encuentra esa copia se encarga entonces de propagar la actualización a las copias secundarias.

Un Panorama de las Bases de Datos Orientadas a Objetos
Como cualquier base de datos programable, una base de datos orientada a objetos (BDOO) da un ambiente para el desarrollo de aplicaciones con un depósito persistente listo para su explotación. Una BDOO almacena y manipula información que puede ser digitalizada (representada) como objetos, proporciona una estructura flexible con acceso ágil, rápido, con gran capacidad de modificación. Además combina las mejores cualidades de los archivos planos, las bases jerárquicas y relaciónales.
Actualmente, el creciente uso de las metodologías de programación orientadas a objetos está promoviendo la aparición de manejadores de BDOO en el mercado. Esto tiene sentido, puesto que la tecnología de objetos proviene del desarrollo de metodologías avanzadas de programación. Más aún, la comunidad internacional está convencida de que los manejadores de BDOO tienen la flexibilidad tanto en la definición del modelo de datos como en el desempeño tan anhelado por muchos desarrolladores de aplicaciones, lo que es imposible encontrar en los modelos jerárquicos de red o relaciónales.