Sistemas distribuidos.

SISTEMAS DE BASES DE DATOS DISTRIBUIDAS

INTRODUCCIN El procesamiento de bases de datos distribuidas es el procesamiento de bases de datos en el cual la ejecucin de transacciones y la recuperacin y actualizacin de los datos acontece a travs de dos o ms computadoras independientes, por lo general separadas geogrficamente. La figura 1 muestra un sistema de base de datos distribuida que involucra cuatro computadoras. Figura 1 Arquitectura de base de datos distribuida

Nodo w

DBMw

BDw

Nodo x Programa de consulta o transaccin

DTMx

DBMx

BDx

Nodo y Programa de consulta o transaccin

DTMy

DBMy

BDy

Nodo z Programa de consulta o transaccin DDB Interfaz de accin

DTMz

Interfaz de solicitud

DDBMS

El sistema de administracin de base de datos distribuida (DDBMS), est formado por las transacciones y los administradores de base de datos distribuidos de todas las computadoras. Tal y como se muestra, tal DDBMS es un esquema genrico que implica un conjunto de programas que operan en diversas computadoras. Estos programas pueden ser subsistemas de un producto nico DDBMS, concesionado por un slo fabricante, o tambin pudiera resultar una coleccin de programas de fuentes dispares: algunos concesionados por fabricantes, y algunos otros escritos en casa. El propsito de esta figura es ilustrar las funciones que deban atenderse en el procesamiento de bases de datos distribuidas.
Pag. 1

Sistemas distribuidos.

Un administrador de transacciones distribuidas (DTM) es un programa que recibe solicitudes de procesamiento de los programas de consulta o de transacciones ya su vez las traduce en acciones para los administradores de la base de datos. Una funcin importante del DTM es coordinar y controlar dichas acciones. Dependiendo de la naturaleza de la aplicacin del DDBMS, el DTM puede ser proporcionado como parte de DDBMS o puede desarrollarse en casa por la organizacin que pone en prctica el sistema distribuido. En aplicaciones menos complejas, una parte de sus funciones puede ser llevada a cabo por personas, siguiendo slo procedimientos manuales. Un administrador de la base de datos (DBM) es un programa que procesa cierta porcin de la base de datos distribuida, como es el hecho de recuperar y actualizar datos del usuario y generales, de acuerdo con comandos de accin recibidos de los DTM. El DBM puede ser un subconjunto de un producto DDBMS, o ser tambin un DBMS comercial no distribuido. En algunos casos, el DDBMS pudiera contener diferentes productos DBMS. Un nodo es una computadora que ejecuta un DTM, un DBM, o inclusive ambos. Un nodo de transaccin procesa un DTM, y un nodo de base de datos procesa un DBM y su base de datos': En la Figura 17-1, el Nodo W es un nodo de base de datos ejecutando DBMwY almacenando BDw. El Nodo X es tanto un nodo de transaccin como de base de datos con DTMx' DBMx y BDx. De modo similar, el Nodo Y es tanto un nodo de transaccin como de base de datos, pero el Nodo Z es solamente un nodo de transaccin. Los programas de consulta o de transaccin se comunican con los DTM a travs de solicitudes parecidas a las solicitudes de accin del DBMS. Ejemplos son SELECT EMPLOYEE WHERE E# EQ 123 o bien STORE DUE-DATE. Estas solicitudes operan sobre estructuras lgicas. El programa de consulta o de aplicacin no se refiere a ninguna instancia fsica en particular de la estructura. Los DTM se comunican con los DBM por medio de acciones a ejecutarse en ocurrencias especficas de datos. Por lo tanto, si la nueva ocurrencia de DUE-DA TE debe almacenarse en DBx y en DBy, el DTM traducir la solicitud STORE DUE-DA TE en dos acciones. Una se dirigir a DBMx para almacenar los nuevos datos, y la segunda se dirigir a DBMy para a su vez almacenar tal informacin. En principio, las solicitudes y las acciones pueden tambin diferir en trminos de su nivel de abstraccin. Por ejemplo, se puede expresar una solicitud en trminos de un objeto y puede ser traducida en acciones o expresada en trminos de relaciones compuestas distribuidas o de archivo. A la fecha, sin embargo, no existe un DDBMS como ste. VENTAJAS DEL PROCESAMIENTO DISTRIBUIDO Existen cuatro ventajas del procesamiento de base de datos distribuido. 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 utilizacin, de forma que el tiempo de comunicacin sea ms corto. Varias computadoras operando en forma simultnea pueden entregar ms volumen de procesamiento que una sola computadora.

Pag. 2

Sistemas distribuidos.

Figura 2 Un negocio distribuido geogrficamente

Planta A

Almacn

Planta B Planta C

Segundo, los datos duplicados aumentan su confiabilidad. Cuando falla una computadora, se pueden obtener los datos extrados 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 tamao de un modo ms sencillo. Se pueden agregar computadoras adicionales a la red conforme aumentan el nmero de usuarios y su carga de procesamiento. A menudo es ms fcil y ms barato agregar una nueva computadora ms pequea que actualizar una computadora nica y centralizada. Despus, si la carga de trabajo se reduce, el tamao de la red tambin puede reducirse. Por ltimo, los sistemas distribuidos se pueden adecuar de una manera ms sencilla a las estructuras de la organizacin de los usuarios. La Figura 2 muestra la organizacin de un fabricante distribuido geogrficamente. Los gerentes generales de cada una de las plantas poseen una enorme autoridad y libertad en la operacin de sus instalaciones. Si tales plantas dependieran de una computadora nica centralizada, la arquitectura de sistema entrara en conflicto con la filosofa y las polticas operacionales de la empresa. Incluso en organizaciones ms centralizadas, el procesamiento distribuido ofrece una mayor flexibilidad para adecuarse a la estructura organizacional, de lo que permite el procesamiento centralizado. DESVENTAJAS DEL PROCESAMIENTO DISTRIBUIDO 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 mltiples, ya que stos pueden ser
Pag. 3

Sistemas distribuidos.

abrumados por las tareas de coordinacin y de control requeridas. Tal situacin es probable cuando la carga de trabajo necesita un gran nmero 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. Figura 3 Ventajas y desventajas del procesamiento de una base de datos distribuida

VENTAJAS
Mayor rendimiento Mayor confiabilidad Cambia de tamao con facilidad Adecuado fcilmente a la estructura de la organizacin

DESVENTAJAS
Peor rendimiento Menor confiabilidad Mayor complejidad Costos ms altos Difcil de controlar

Una tercera desventaja es su mayor complejidad, a menudo se traduce en altos gastos de construccin y mantenimiento. Ya que existen ms componentes de hardware, hay ms cantidad de cosas por aprender y ms interfaces susceptibles de fallar. El control de concurrencia y recuperacin de fallas puede convertirse en algo complicado y difcil de implementar, puede empujar a una mayor carga sobre programadores y personal de operaciones y quiz se requiera de personal ms experimentado y ms costoso. El procesamiento de bases de datos distribuido es difcil 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 fsico no est controlado, y los procedimientos operativos son demasiado suaves y efectuados por personas que tienen escasa apreciacin o comprensin sobre su importancia. En sistemas centralizados, en caso
Pag. 4

Sistemas distribuidos.

de un desastre o catstrofe, la recuperacin puede ser ms difcil de sincronizar. Las ventajas y desventajas del procesamiento de datos distribuidos se resumen en la Figura 3.

COMPONENTES DE DISTRIBUIDAS

LOS SISTEMAS

DE

BASES DE

DATOS

A veces, los componentes de los sistemas de base de datos distribuidos son confusos, ya que mltiples tipos distintos de procesamiento entran dentro del trmino procesamiento de base de datos distribuidas y pueden encajar en la arquitectura general de la Figura 1. Considere, por ejemplo, el sistema de la Figura 4(a). Cumple con la arquitectura mostrada en la Figura 1 en la cual los nodos estn especificados como macrocomputadoras, Es muy probable que para este sistema, el procesamiento est basado en la igualdad de colegas cooperando. Cada nodo de la base de datos (W, X e Y), posee autoridad para insertar, modificar, suprimir, o bien leer cualquier dato a todo lo largo de la red. Los datos tambin se coordinan entre computadoras en tiempo real 0 algo tan cercano como sea posible. Ahora vayamos a la Figura 4(b), en la cual el Nodo W es una macrocomputadora, los Nodos X e Y son minicomputadoras, y el Nodo Z es una microcomputadora. En tal caso, las reglas del procesamiento podran ser las siguientes: slo el Nodo W puede modificar la base de datos; los Nodos X e Y, que tienen copia de los datos del Nodo W, slo estn autorizados para lectura, y el Nodo Z puede obtener datos nada ms del Nodo Y. No se ha hecho ningn intento por conservar los datos actualizados en tiempo real. En lugar de ello, todos los das los Nodos X e Y son actualizados por el Nodo W, y una vez por semana el Nodo Y actualiza al Nodo Z. La Figura 4(c) muestra un tercer ejemplo de la arquitectura de la Figura 1, en el cual el Nodo W es una macrocomputadora , y los Nodos X, Y y Z son microcomputadoras conectadas a una red de rea local. El Nodo X es un acceso a la macrocomputadora y obtiene de W todos los datos de la base de datos que necesitan X, Y y Z y los almacena en su propia base de datos. Suponga que el Nodo Y requiere de un acceso frecuente a una parte de los datos, pero lo procesa slo en base de lectura. Cuando el Nodo X o el Nodo Z efectan modificaciones a los datos, las efectan sobre una copia de W. En forma peridica, W actualiza la base de datos de X con aquellos datos que hayan sido modificados. Estos tres ejemplos cumplen con la arquitectura general de la Figura 1, pero son del todo distintos. Tienen sus propios conjuntos de capacidades, as como su propio conjunto de problemas. Para poner orden en tal complejidad, consideraremos los siguientes cinco componentes de un sistema de base de datos distribuida: hardware, programas, datos, procedimientos y personal.

Pag. 5

Sistemas distribuidos.

Figura 4 Tres ocurrencias de arquitectura de la Figura 1: (a) Sistema distribuido con cuatro macrocomputadoras, (b) Sistema distribuido utilizando una macrocomputadora, dos minicomputadoras y una microcomputadora, y (c) Sistema distribuido utilizando una macrocomputadora, una LAN y tres microcomputadoras
Nodo W Macrocomputadora Nodo X Macrocomputadora Nodo Y Macrocomputadora

Macrocomputadora Nodo Z (a) Nodo W Macrocomputadora Nodo X Minicomputadora Nodo Y Minicomputadora Nodo Z Microcomputadora (b) Nodo X
ar liz

Nodo W Macrocomputadora
tu Ac a a tu Ac a liz r

Microcomputadora LAN

Microcomputadora

Microcomputadora Nodo Z (c)

HARDWARE Como se muestra en la Figura 4 los nodos de procesamiento pueden estar formados por mltiples y distintos tipos de hardware. En algunos sistemas distribuidos, como en la Figura 4(a), los nodos son homogneos. En otros, como en la Figura 4(b) y (c), son heterogneos. Al determinar las autorizaciones de proceso de los nodos debern tomarse en cuenta las diferencias en las velocidades de procesamiento y las capacidades de almacenamiento. SOFTWARE El programa principal que necesitamos considerar en un sistema de base de datos distribuida es el DDBMS. La arquitectura DDBMS que se muestra en la Figura 1 es genrica. Los DTM, y DBM pueden ser subsistema de un solo producto DDBMS concesionado por un solo fabricante. En forma alterna y de manera ms frecuente, el DDBMS es un amalgama de programas desarrollados en casa y de productos obtenidos por
Pag. 6

Sistemas distribuidos.

varios fabricantes de software. En muchos casos, los DTM se escriben en casa, y los DBM son productos DBMS comerciales. Considere usted los ejemplos de la Figura 4. En el primero, las computadoras son del mismo tipo de mquinas (macrocomputadora) y la empresa, con tal sistema, podra decidir adquirir la licencia de un DDBMS que sea un solo producto. De hacerlo as, los DTM y DBM seran proporcionados por el fabricante como subsistemas del DDBMS. Cada DTM esperara estar en comunicacin con slo el DBM proporcionado por el fabricante. R*, un DDBMS prototipo desarrollado por IBM, es un ejemplo de un producto como ste. Sin embargo, tales productos DDBMS son raros. Vea usted la Figura 4(b). El sistema incluye una mezcla de tipos de hardware, y es poco probable que cualquier producto DDBMS comercial pudiera funcionar con todos ellos. Los DBM podran ser versiones de un producto DBMS comercial, siempre y cuando dicho producto se ejecute sobre todo tipo de hardware. Oracle, por ejemplo, se ejecuta en microcomputadoras, minicomputadoras y microcomputadoras. Los DTM no forman parte del producto comercial. En lugar de ello, seran programas de aplicacin escritos en casa, con acceso a producto de una computadora exterior y descargando los datos. O se podran utilizar como DBM varios productos DBMS, tal y como a continuacin se describe. En la Figura 4(c) se muestra una macrocomputadora que ha entrado en contacto con una red de rea local de microcomputadoras. En tal caso, el DBM podra ser nada ms un producto, como en el caso anterior, o una mezcla de productos. Si se tratara de una mezcla, el DBM del Nodo W pudiera ser un producto DBMS de una macrocomputadora como DB2, y los DBM de los Nodos X, Y y Z podran ser versiones LAN multiusuario de un DBMS de microcomputadora, como sera SQL Server o Informix. Es posible que un programa de extraccin, que obtiene datos de la base de datos en el Nodo X, fuera proporcionado por el vendedor del DBMS para microcomputadora. Entonces el DDBMS podra ser un solo producto o una amalgama de diferentes programas y productos. DATOS Una de las claves de un sistema de base de datos distribuida consiste en que los datos se duplican, o no. Una base de datos distribuida puede no estar duplicada, parcialmente duplicada o totalmente duplicada. Si no est duplicada, existe una y slo una copia de cada elemento de datos. Los elementos de datos se asignan a nodos particulares, y pueden residir en su nodo asignado. Cualquier aplicacin que necesite tener acceso a ese elemento de datos deber obtenerlo del nodo oficialmente designado. Una base de datos parcialmente duplicada contiene ciertos elementos de datos que estn duplicados y algunos que no lo estn. Un directorio de sistema indica si un elemento de datos est duplicado y dnde se encuentra. Una base de datos distribuida totalmente duplicada, es aquella en la que la base de datos total se encuentra duplicada en dos o ms nodos. Un nodo contiene o toda la base de datos o nada de ella. PROCEDIMIENTOS Los sistemas de base de datos distribuidos contienen una multitud de componentes de procesamiento. El primer grupo corresponde a derechos de procesamiento. Qu nodos
Pag. 7

Sistemas distribuidos.

pueden hacer qu y con qu datos? En los sistemas distribuidos ms sencillos, los datos no estn duplicados, y slo el nodo que almacena los datos puede actualizarlos. (De hecho, en el sistema ms sencillo de todos, los datos no se actualizan en lo absoluto, se obtienen de una fuente ajena, y se procesan como datos de lectura. Una situacin as es rara.) En situaciones ms complicadas, cualquier nodo puede emitir una solicitud de actualizacin para cualquier elemento de datos, por s mismo o para cualquier otro nodo. Si este elemento de datos est duplicado, todas sus copias sern modificadas. Al disear un sistema distribuido, los desarrolladores debern determinar los derechos de procesamiento, los requerimientos y las capacidades del hardware y de los programas, el control de la concurrencia, as como otros factores. Otro componente de los procedimientos es la actualidad de los datos. Qu tan actuales debern ser los datos? Necesita cada uno de los nodos el valor ms actual de todos los elementos de datos a los cuales tiene acceso? Puede permitirse que algunas bases de datos se queden desactualizadas? En la Figura 4(a), todos los nodos poseen acceso a los datos ms actuales. En la Figura 4(b) y (c), algunos de los nodos se encuentran procesando datos anteriores. Mientras ms actuales sean los datos duplicados, ms costoso ser el sistema. Para controlar y coordinar el sistema de la Figura 4(a) se debern dedicar enormes cantidades de ciclos de procesamiento y para procesar esta red se requieren CPU poderosas y costosas. Muy relacionado con los temas de los derechos de procesamiento y de actualidad es el tema del flujo de los datos. Quin actualiza a quin? En la Figura 4(b), el Nodo W actualiza los datos de los Nodos X e Y, en tanto que en la Figura 4(c), el Nodo X actualiza los datos del Nodo W. Tales flujos quedan determinados por los requisitos y los derechos de procesamiento de los nodos. Otro componente de procedimientos es el de control. Por lo que se refiere a las solicitudes de procesamiento conflictivas, qu nodo resolver el conflicto? En general, un control autoritario -por lo comn puesto en prctica en sistemas como los de las Figuras 4(b) y (c)es ms fcil de instalar que esquemas basados en la igualdad -casi siempre puestos en prctica en sistemas parecidos a los de la Figura 4(a). Para los sistemas distribuidos como el de la Figura 4(a), el control puede quedar distribuido y difundido a todo lo largo de la red. No es necesario que ningn nodo quede a cargo. Las decisiones de control pueden ser llevadas a cabo por cualquiera de los nodos, dependiendo slo del tema de control y del estado del sistema. Tal situacin permite una mayor flexibilidad y, sin embargo, es mucho ms compleja. PERSONAL Los sistemas distribuidos varan en el conocimiento que exigen a las personas que trabajan con ellos. Los sistemas con un DDBMS complejo y poderoso imponen pocas demandas especiales sobre los usuarios. De hecho, los usuarios no saben que estn procesando datos distribuidos. Slo tienen acceso a sus aplicaciones, y todo el procesamiento distribuido lo efecta el DDBMS. En sistemas menos complejos, los usuarios deben involucrarse. Considere el sistema de la Figura 4(b). Los usuarios en los Nodos X e Y pudieran necesitar acudir a uno o ms programas para hacer que los datos se descarguen de la microcomputadora. En forma similar, los usuarios en el Nodo Z pudieran necesitar iniciar
Pag. 8

Sistemas distribuidos.

de manera manual programas a fin de traer los datos del Nodo Y. Dependiendo del diseo del sistema, los usuarios tambin pueden responsabilizarse de la inspeccin de los informes de proceso para determinar que los datos fueron recibidos sin error, y que por lo tanto fueron transmitidos los datos correctos. En sistemas distribuidos muy primitivos, los usuarios deben incluso aceptar la carga de algunas de las responsabilidades del DTM. Por ejemplo, en algunos sistemas los usuarios efectan modificaciones a los datos sobre la base de datos local y a continuacin de manera manual hacen que tales cambios se efecten en los datos duplicados en los dems nodos. En los sistemas ms primitivos, los usuarios emplean el mtodo NIKE: se ponen sus zapatos tenis y corren por el pasillo, llevando disquetes de modificaciones de datos de una computadora a otra.

CUATRO METAS PARA UN DBMS DISTRIBUIDO

Traiger y sus colegas definieron cuatro metas para un DBMS distribuido, lo que da un excelente marco de referencia para una investigacin de los temas, problemas y soluciones propuestos para las bases de datos distribuidas. Cada una de estas metas involucra un aspecto de transparencia. En un sistema de base de datos distribuida la transparencia significa que las opciones de consulta y los programas de transacciones quedan aislados de la administracin de la base de datos distribuidos, de forma tal que obtengan las ventajas del procesamiento distribuido, sin por ello tener que involucrarse en detalles de la distribucin de la base de datos. Los programadores y los usuarios pueden concentrarse en la naturaleza y en la lgica del problema de la informacin que necesitan resolver, no vindose obligados a tratar asuntos que corresponden al DDBMS: para simplificar este anlisis, en el resto de este documento nos referiremos a los usuarios de consulta y a los programas de transaccin slo como transacciones. Las transacciones necesitan tener acceso a la base de datos va un DDBMS que proporcione los cuatro siguientes tipos de transparencia: localizacin de los datos, duplicacin de los datos, concurrencia y falla. Lo cual significa que, en forma ideal, la transaccin ni siquiera est consciente que los datos se encuentran distribuidos. Los cuatro temas de distribucin se manejan tras bambalinas. TRANSPARENCIA DE LOCALIZACIN Las transacciones necesitan ser independientes de la localizacin de un elemento de datos particular. De no ser as, las cuestiones de localizacin complicaran la lgica de la transaccin. Considere usted la empresa manufacturera que se utiliz en la Figura 2. Si el gerente de inventarios desea mover refrigeradores de la Planta A a la Planta B, debern modificarse dos registros de inventario. Suponga que los datos involucrados no estn duplicados; pero que datos puedan estar almacenados en una computadora en cualquiera de las dos localizaciones. Si el programa que procesa esta transaccin no es transparente en lo que se refiere a localizacin de los datos, tendr que considerar cuatro casos: ambos registros en A, uno en A y uno en B, uno en B y el otro en A o ambos en B. La lgica de la
Pag. 9

Sistemas distribuidos.

transaccin se confunde por la necesidad de considerar la localizacin de los datos. La lgica sera mucho ms complicada para un ejemplo ms complejo, en cualquier caso estas consideraciones son innecesarias e inapropiadas para un programa de aplicacin. Se puede conseguir la transparencia de localizacin si los administradores de transacciones distribuidas (los DTM en la Figura 1) son responsables de determinar la localizacin de los datos y de emitir las acciones a los DBM apropiados, lo cual se puede llevar a cabo si los DTM poseen acceso a los directorios de las localizaciones de los datos. Si los datos se mueven, slo el DTM necesita involucrarse. Todas las transacciones quedan aisladas de la modificacin en la localizacin. TRANSPARENCIA DE DUPLICACIN Las transacciones son accesibles a la duplicacin si pueden procesarse sin saber cuntas veces, o incluso si los datos estn duplicados. La transaccin puede actuar como si todos los datos estuvieran almacenados slo una vez en nada ms un nodo. Con la transparencia de duplicacin, se pueden crear nuevos duplicados, o los duplicados existentes pueden ser eliminados, sin provocar efecto alguno sobre la transaccin del usuario o el procesamiento de la consulta. Para proporcionar transparencia en la duplicacin, los administradores de transacciones deben traducir las solicitudes de procesamiento de transaccin en acciones para los administradores de la base de datos. Las lecturas son sencillas, el DTM selecciona uno de los nodos que almacena los datos y emite una accin para su lectura. Para facilitar la seleccin, el DTM pudiera conservar estadsticas sobre el tiempo que se requiere para leer datos de varios nodos, y seleccionar el nodo con el mejor rendimiento. Es ms complicado la escritura de datos duplicados, porque el DTM deber emitir una accin de escritura para cada uno de los DBM que almacena una copia de dichos datos. Este anlisis supone que cada DTM posee una copia exacta y actualizada de un directorio que indique la localizacin de los datos. Sin embargo, aparecen problemas interesantes, si consideramos lo que ocurrira cuando el directorio deba modificarse para tomar en cuenta nuevas copias de datos o su eliminacin. Resulta crtica la coordinacin. Todos los directorios debern ser instalados de forma que ningn DTM piense que los datos estn disponibles antes que as sea (en el caso de lecturas) y que todos los DTM sepan que los datos estn disponibles cuando lo estn (en el caso de escrituras). De lo contrario, un DTM pudiera solicitar datos que toda no estn disponibles o dejar de emitir una orden de escritura a un DBM cuando los datos estn disponibles. TRANSPARENCIA DE CONCURRENCIA Aunque mltiples transacciones que involucran la base de datos distribuida se lleven a cabo al mismo tiempo, los resultados de las transacciones no debern afectarse. El DDBMS proporciona transparencia de concurrencia si los resultados de todas las transacciones concurrentes son consistentes de manera lgica con los resultados que se habran obtenido si las transacciones se hubieran ejecutado una por una, en algn orden serial arbitrario. Expresada de otra forma, la lgica de las transacciones procesadas en forma concurrente
Pag. 10

Sistemas distribuidos.

con otras transacciones deber de ser la misma que si la transaccin se hubiera procesado sola. Se han desarrollado dos estrategias para proporcionar control de concurrencia. Una de ellas conocida como bloqueo distribuido en dos fases, es una extensin del mecanismo de control de concurrencia. Un segundo mtodo se llama pedido con sello de recepcin. Ambos han sido implementados en productos DDBMS. Es ms comn el bloqueo distribuido en dos fases. TRANSPARENCIA DE FALLAS La cuarta meta del DDBMS es proporcionar transparencia de fallas, lo que significa que las transacciones sean procesadas de un modo correcto a pesar de fallas en la transaccin, en el DDBMS, en la red y en la computadora. Frente a una falla, las transacciones debern ser atmicas, esto es, ya sea que se procesen todas las transacciones o ninguna de ellas. Adems, una vez comprometidos los resultados de las transacciones, sern permanentes. La transparencia contra fallas es la meta ms difcil entre las cuatro. Parte del problema es que existen muchos tipos distintos de fallas. En un extremo del espectro habr un nodo que jams falla, a veces llamado un nodo perfecto. En el otro extremo aparece un nodo que falla de una manera del todo desconocida. Un nodo como ste pudiera comunicar basura a travs de la red, o bien, en razn de su falla, pudiera enviar acciones inapropiadas, pero con formato valido por la red. Nodos como stos se conocen como nodos desquiciados. Otro tipo de falla corresponde a nodos que se convierten en malvolos, lo cual significa el nodo tiene el propsito expreso de llevar a cabo una actividad no autorizada, o de causar daos en forma intencional. Es incluso posible considerar fallas donde los nodos conspiran unos con otros para hacer caer al sistema distribuido. A veces se conocen como fallas bizantinas. Entre los extremos de los nodos perfectos y los nodos desquiciados estn los nodos sensatos. Un nodo sensato es un nodo que puede fallar, pero slo en una forma definida y conocida. El ejemplo ms sencillo de un nodo sensato es uno que, o es perfecto, o deja de responder completo. Otra razn por la cual la transparencia de falla es tan difcil es que el control de concurrencia es muy complicado. En un sentido, los problemas de control de concurrencia se resuelven por medio de recuperaciones de fallas. Es como una burbuja de aire bajo el tapiz que se empuja de una esquina slo para volver a aparecer en otra. Los mecanismos de control de concurrencia funcionan siempre y cuando no ocurran fallas en ciertos momentos o en ciertos estados de la base de datos distribuida, o siempre y cuando se pueda garantizar la recuperacin en una cierta forma, etc. En el caso general de bases de datos divididas y duplicadas quedan an por resolver mltiples problemas tericos y prcticos de puesta en prctica.

Pag. 11