Base de Datos Distribuidas

Universidad de Concepcin Facultad de Ingeniera Dpto. Ing.Civil Inf.

Alumnas : Soledad Aravena Alejandra Daz Colomba Machiavello Andrea Nieto Evelyn Ortiz Curso : Base de datos Profesora: Claudia Jimnez

Bases de Datos Distribuidas

Indice ndice Introduccin Estructura de Base de Datos Distribuidas Las doce reglas de un sistema de bases de datos distribuidas 2 4 5 7 10 11 12 13 16 17 19 25 25 27 28 29 29 29 30 31 33 33 33 33 34 34 35 37 38 38 40 41 2

Consideraciones al distribuir la base de datos Ventajas de la distribucin de datos Desventajas de la distribucin de los datos

Diseo de bases de datos distribuidas Diseo de la distribucin Fragmentacin Tipos de Fragmentacion Grado de Fragmentacin Alternativas de asignacin

Transparencia y Autonoma Asignacin de nombres y autonoma local Transparencia de la repeticin y la fragmentacin Transparencia de localizacin Esquema completo de asignacin de nombres

Transparencia y actualizaciones

Procesamiento distribuido de consultas Optimizacin de Consultas Distribuidas

Arquitectura del procesamiento de consultas Descomposicin de consultas Localizacin de Datos Optimizacin Global de Consultas Optimizacin Local de Consultas Tipos de Transacciones Robustez Protocolos de compromiso

Recuperacin en Sistemas Distribuidos

Control de concurrenciaSerializacin distribuida:


Protocolos de bloqueo (locking protocols) Protocolos de marcas de tiempo (timestamp protocols)

41 42

Manejo de Bloqueos Enfoque centralizado Enfoque de Distribucin total

43 45 47 50 51 51 53 54 56 57

Seleccin del coordinadorCoordinadores de copia de seguridad (back-up) Algoritmos de eleccin

Sistema de base de datos mltipleSistemas de administracin de bases de datos (DBMS)

Conclusin Bibliografa

3


IntroduccinLa evolucin de los sistemas de informacin y el crecimiento no planeado de la informacin dentro de las organizaciones, ha trado como consecuencia la dispersin de los datos en localidades geogrficamente dispersas. La necesidad de integrar y compartir dicha informacin, implica el nacimiento de una nueva tecnologa capaz de administrar de manera consistente la informacin de las organizaciones. Una de las tecnologas que trabaja en el problema de integracin de informacin, es la de Bases de Datos Distribuidas (BDD). El presente informe introduce el concepto de Bases de Datos Distribuidas, especificando su estructura, diseo y administracin entre otros.

4


Estructura de Base de Datos Distribuidas

5


Un sistema de Base de datos distribuidas se compone de un conjunto de localidades, cada una de las cuales mantiene un sistema de base de datos local. Cada localidad puede procesar transacciones locales, es decir, aquellas que slo acceden a datos que residen en esa localidad. Adems una localidad puede participar en la ejecucin de transacciones globales, es decir, aquellas que acceden a datos de varias localidades. La ejecucin de transacciones globales requiere comunicacin entre las localidades, esta comunicacin puede ser, por ejemplo, mediante lneas telefnicas o cables de alta velocidad. Cabe destacar que en un sistema de BDD tiene las siguientes caractersticas: 1. Cada sitio es un sistema de base de datos en s mismo. 2. 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 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 fsicamente en varias bases de datos reales distintas ubicadas en diferentes sitios. De hecho, es la unin lgica de esas bases de datos. Los sitios pueden conectarse fsicamente, a modo de grafo, de diversas formas, como por ejemplo: Red totalmente conectada Red prcticamente conectada Red con estructura de rbol Red de estrella Red de anillo En la figura siguiente se da un ejemplo representativo): de la estructura (un sistema distribuido de bases

6


Las diferencias principales entre estas configuraciones son: Costo de instalacin: El costo de conectar fsicamente los sitios del sistema Costo de comunicacin: El costo en tiempo y dinero que implica enviar un mensaje desde el sitio A al B. Fiabilidad: La frecuencia con que falla una lnea de comunicacin o un sitio. Disponibilidad: La posibilidad de acceder a informacin a pesar de fallos en algunas sitios o lneas de comunicacin.

Las localidades pueden estar dispersas, ya sea por un rea geogrfica extensa (a lo largo de un pas), llamadas redes de larga distancia; o en un rea reducida (en un mismo edificio), llamadas redes de rea local. Para las primeras se utilizan en la comunicacin lneas telefnicas, conexiones de microondas y canales de satlites; mientras que para las segundas se utiliza cables coaxiales de banda base o banda ancha y fibra ptica. Ejemplo: Consideremos la figura anterior por sencillez, supondremos que existen dos sitios, Santiago y Concepcin, y que el sistema es un sistema bancario, con los registros de las cuentas de Santiago almacenadas en Santiago, y los registros de las cuentas de Concepcin almacenadas en Concepcin. Esta situacin presenta una ventaja evidente: el arreglo distribuido combina la eficiencia de procedimiento (los datos estn almacenados cerca del punto en el cual se les utilizan con mayor frecuencia) con una mayor accesibilidad (es posible obtener acceso a una cuenta de Santiago desde Concepcin, y viceversa, a travs de la red de comunicaciones).

Las doce reglas de un sistema de bases de datos distribuidas1.

Autonoma local: Los sitios de un sistema distribuido deben ser autnomos, esto significa que todas las operaciones en un sitio dado se controlan en ese sitio; ningn sitio X deber depender de algn otro sitio Y para su buen funcionamiento (pues de otra manera el sitio X7


podra ser incapaz de trabajar, aunque no tenga en s problema alguno, si se cae el sitio Y, situacin a todas luces indeseable). El objetivo de la autonoma local es imposible de lograr por completo; existen varias situaciones2.

No dependencia de un sitio central: La autonoma 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 administracin centralizada de las transacciones, de modo que todo el sistema dependa de ese sitio central. La dependencia de un sitio central sera indeseable al menos por las siguientes dos razones: El sitio central podra ser un cuello de botella El sistema sera vulnerable; si el sitio central sufriera un desperfecto, todo el sistema dejara de funcionar.

Operacin continua: En un sistema distribuido, lo mismo que en uno no distribuido, idealmente nunca debera haber necesidad de apagar a propsito el sistema. Es decir, el sistema nunca debera necesitar apagarse para que se pueda realizar alguna funcin, como aadir un nuevo sitio o instalar una versin mejorada del DBMS en un sitio ya existente. 4. Independencia con respecto a la localizacin: La idea bsica de la independencia con respecto a la localizacin (tambin conocida como transparencia de localizacin) es simple: no debe ser necesario que los usuarios sepan dnde estn almacenados fsicamente los datos, sino que ms bien deben poder comportarse, al menos desde el punto de vista lgico, como si todos los datos estuvieran almacenados en su propio sitio local. La independencia con respecto a la localizacin es deseable porque simplifica los programas de los usuario y sus actividades en la terminal.3. 5.

Independencia con respecto a la fragmentacin: Un sistema maneja fragmentacin de los datos si es posible dividir una relacin en partes o fragmentos para propsitos de almacenamiento fsico. La fragmentacin es deseable por razones de desempeo: los datos pueden almacenarse en la localidad donde se utilizan con mayor frecuencia, de manera que la mayor parte de las operaciones sean solo locales y se reduzca el trfico por la red. Existen en esencia dos clases de fragmentacin : Horizontal Vertical

Las cuales corresponden a las operaciones relacionales de restriccin y proyeccin, respectivamente. En trminos ms generales, un fragmento puede ser cualquier subrelacin arbitraria que pueda derivarse de la relacin original mediante operaciones de restriccin y proyeccin (excepto, en el caso de las proyecciones, es obvio que la proyeccin debe conservar la clave primaria de la relacin original). La reconstruccin de la relacin original). a partir de los fragmento se hace mediante operaciones de reunin y unin apropiadas (reunin en el caso de los fragmentos verticales, unin en el de los horizontales). Advirtase, por cierto, que la facilidad de la fragmentacin y de la reconstruccin es una de las muchas razones por las cuales los sistemas distribuidos son relacionales; el modelo relacional ofrece las operaciones precisas requeridas para estas tareas. Ejemplo de fragmentacin: Percepcin del usuario: EMP8


Num Emp E1 E2 E3 E4 Fragmentos de Santiago Num Emp Num Depto Salario E1 DX 45 E2 DY 40

Num Depto DX DY DZ DY

Salario 45 40 50 63 fragmentos de Concepcin. Num Emp Num Depto Salario E3 DZ 50 E4 DY 63

Un sistema que maneja fragmentacin de los datos deber ofrecer tambin una independencia con respecto a la fragmentacin, es decir los usuarios debern poder comportarse, al menos desde un punto de vista lgico, como si los datos no estuvieran fragmentados en la realidad, esta independencia es deseable porque simplifica los programas de los usuarios y sus actividades en la terminal. En particular, hace posible refragmentar los datos (y redistribuir fragmentos) en cualquier momento en respuesta a cambios en los requerimientos de desempeo sin anular la validez de esos programas o actividades.6.

Independencia de rplica: Un sistema maneja rplica de datos si una relacin dada se puede representar en el nivel fsico mediante varias copias almacenadas o rplicas, en muchos sitios distintos. Procesamiento distribuido de consultas: En este aspecto debemos mencionar dos puntos amplios: las consultas y la optimizacin, esta ltima es muy importante en el sistema distribuido que en uno centralizado. Manejo distribuido de transacciones: Est tiene dos aspectos principales: uno es el control de recuperacin y el otro es el control de concurrencia, cada uno de los cuales requiere un tratamiento ms amplio. Para explicar este tratamiento ms amplio es preciso introducir primero un nuevo trmino, agente. En un sistema distribuido, una transaccin puede implicar la ejecucin de cdigo en varios sitios. Por tanto se dice que una transaccin esta compuesta de varios agentes, donde un agente es el proceso ejecutado en nombre de una transaccin dada en determinado sitio. Para asegurar, pues, que una transaccin dada sea atmica (todo o nada) en el ambiente distribuido, el sistema debe asegurarse de que todos los agentes correspondientes a esa transaccin se comprometan al unsono o bien que retrocedan al unsono. En cuanto al control de concurrencias, esta funcin en un ambiente distribuido estar basada con toda seguridad en el bloqueo, como sucede en los sistemas no distribuidos. Independencia con respecto al equipo: Es conveniente poder ejecutar el mismo DBMS en diferentes equipos, y adems lograr que esos diferentes equipos participen como socios iguales en un sistema distribuido. con respecto al sistema operativo: Es necesario que se puedan utilizar una diversidad de sistemas operativos. con respecto a la red: Si el sistema ha de poder manejar mltiples sitios diferentes, con equipos distintos y diferentes sistemas operativos, resulta obvia la conveniencia de poder manejar tambin varias redes de comunicacin distinta.9

7.

8.

9.

10. Independencia

11. Independencia

Bases de Datos Distribuidas 12. Independencia

con respecto al DBMS: Sera deseable poder manejar la heterogeneidad. 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.

Consideraciones al distribuir la base de datos

10


Existen varias razones para construir sistemas distribuidos de bases de datos que incluyen compartir la informacin, fiabilidad y disponibilidad y agilizar el procesamiento de las consultas. Pero tambin tiene sus desventajas, como desarrollos de software ms costosos, mayor posibilidad de errores y costos extras de procesamiento. Ventajas de la distribucin de datos La principal ventaja de los sistemas distribuidos es la capacidad de compartir y acceder a la informacin de una forma fiable y eficaz. Utilizacin compartida de los datos y distribucin del control

La ventaja principal de compartir los datos por medio de la distribucin es que cada sitio pueda controlar hasta cierto punto los datos almacenados localmente. En un sistema centralizado, el administrador de base de datos de la localidad central controla la base de datos. En un sistema distribuido existe un administrador global de la base de datos que se encarga de todo el sistema. Parte de esta responsabilidad se delega al administrador de base de datos de cada localidad. Dependiendo del diseo del sistema distribuido, cada administrador local podr tener un grado de autonoma diferente, que se conoce como autonoma local. La posibilidad de contar con autonoma local es en muchos casos una ventaja importante de las bases de datos distribuidas. Fiabilidad y disponibilidad

Si se produce un fallo en una localidad de un sistema distribuido, es posible que los dems localidades puedan seguir trabajando. En particular, si los datos se repiten en varios sitios, una transaccin que requiere un dato especfico puede encontrarlo en ms de una localidad. As, el fallo de una localidad no implica necesariamente la desactivacin 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 mnimo de complicaciones.

11


La disponibilidad es fundamental para los sistemas de bases de datos que se utilizan en aplicaciones de tiempo real. Por ejemplo, si una lnea area no puede tener acceso a la informacin, es posible que pierda clientes a favor de la competencia. Agilizacin 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. Sin embargo, en un sistema distribuido no se comparte la memoria principal, as que no todas las estrategias de interseccin para procesadores paralelos se pueden aplicar en estos sistemas. En los casos en que hay repeticin de los datos, el sistema puede pasar la consulta a las localidades ms ligeras de carga.

Desventajas de la distribucin de los datos La desventaja principal de los sistemas distribuidos es la mayor complejidad que se requiere para garantizar una coordinacin adecuada entre las localidades. El aumento de la complejidad se refleja en:

Costo del desarrollo de software: es ms difcil estructurar un sistema de bases de datos distribuidos y por tanto su costo es mayor Mayor posibilidad de errores: puesto que los sitios del sistema distribuido operan en paralelo, es ms difcil garantizar que los algoritmos sean correctos. Mayor tiempo extra de procesamiento: el intercambio de mensajes y los clculos adicionales son una forma de tiempo extra que no existe en los sistemas centralizados.

12


Diseo de bases de datos distribuidas

13


El diseo de un sistema de base de datos distribuido (SBDD) implica la toma de decisiones sobre la ubicacin de los programas que accedern a la base de datos y sobre los propios datos que constituyen esta ltima, a lo largo de los diferentes puestos que configuren una red de computadoras. Tradicionalmente se ha clasificado la organizacin de los sistemas de bases de datos distribuidos sobre tres dimensiones:

el nivel de compartimiento las caractersticas de acceso a los datos el nivel de conocimiento de esas caractersticas de acceso.

El nivel de compartimiento presenta tres alternativas: inexistencia, es decir, cada aplicacin y sus datos se ejecutan en una computadora con ausencia total de comunicacin con otros programas u otros datos; se comparten slo los datos y no los programas, en tal caso existe una rplica de las aplicaciones en cada mquina y los datos viajan por la red; y se reparten datos y programas, dado un programa ubicado en un determinado sitio, ste puede solicitar un servicio a otro programa14


localizado en un segundo lugar, el cual podr acceder a los datos situados en un tercer emplazamiento. Respecto a las caractersticas de acceso a los datos existen dos alternativas principalmente: el modo de acceso a los datos que solicitan los usuarios puede ser esttico, es decir, no cambiar a lo largo del tiempo, o bien, dinmico. Se puede comprender la dificultad de encontrar sistemas distribuidos reales que puedan clasificarse como estticos. Sin embargo, lo realmente importante radica, estableciendo el dinamismo como base, cuntas variaciones sufre a lo largo del tiempo. Esta dimensin establece la relacin entre el diseo de bases de datos distribuidas y el procesamiento de consultas. La tercera clasificacin es el nivel de conocimiento de las caractersticas de acceso. Una posibilidad es, evidentemente, que los diseadores carezcan de informacin alguna sobre cmo los usuarios acceden a la base de datos. Es una posibilidad terica, pero sera muy laborioso abordar el diseo de la base de datos con tal ausencia de informacin. Lo ms prctico sera conocer con detenimiento la forma de acceso de los usuarios. A la hora de abordar el diseo de una base de datos distribuida se puede optar principalmente por dos tipos de estrategias: la estrategia ascendente y la estrategia descendente. La estrategia ascendente podra aplicarse en aquel caso donde haya que proceder a un diseo a partir de un nmero de pequeas bases de datos existentes, con el fin de integrarlas en una sola. En este caso se partira de los esquemas conceptuales locales y se trabajara para llegar a conseguir el esquema conceptual global. La estrategia descendente debera resultar familiar a la persona que posea conocimientos sobre el diseo de bases de datos, exceptuando la fase del diseo de la distribucin. Pese a todo, se resumirn brevemente las etapas por las que se transcurre:

15


Todo comienza con un anlisis de los requisitos que definirn el entorno del sistema en aras a obtener tanto los datos como las necesidades de procesamiento de todos los posibles usuarios de la base de datos. Igualmente, se debern fijar los requisitos del sistema, los objetivos que debe cumplir respecto a unos grados de rendimiento, seguridad, disponibilidad y flexibilidad, sin olvidar el aspecto econmico. Como puede observarse, los resultados de este ltimo paso sirven de entrada para dos actividades que se realizan de forma paralela. El diseo de las vistas trata de definir las interfaces para el usuario final y, por otro lado, el diseo conceptual se encarga de examinar la empresa para determinar los tipos de entidades y establecer la relacin entre ellas. Existe un vnculo entre el diseo de las vistas y el diseo conceptual. El diseo conceptual puede interpretarse como la integracin de las vistas del usuario, este aspecto es de vital importancia ya que el modelo conceptual debera soportar no slo las aplicaciones existentes, sino que debera estar preparado para futuras aplicaciones. En el diseo conceptual y de las vistas del usuario se especificarn las entidades de datos y se determinarn las aplicaciones que funcionarn sobre la base de datos, as mismo, se recopilarn datos estadsticos o estimaciones sobre la actividad de estas aplicaciones. Dichas estimaciones deberan girar en torno a la frecuencia de acceso, por parte de una16


aplicacin, a las distintas relaciones de las que hace uso, podra afinarse ms anotando los atributos de la relacin a la que accede. Desarrollado el trabajo hasta aqu, se puede abordar la confeccin del esquema conceptual global. Este esquema y la informacin relativa al acceso a los datos sirven de entrada al paso distintivo: el diseo de la distribucin. El objetivo de esta etapa consiste en disear los esquemas conceptuales locales que se distribuirn a lo largo de todos los puestos del sistema distribuido. Sera posible tratar cada entidad como una unidad de distribucin; en el caso del modelo relacional, cada entidad se corresponde con una relacin. Resulta bastante frecuente dividir cada relacin en subrelaciones menores denominadas fragmentos que luego se ubican en uno u otro sitio. De ah, que el proceso del diseo de la distribucin conste de dos actividades fundamentales: la fragmentacin y la asignacin. El ltimo paso del diseo de la distribucin es el diseo fsico, el cual proyecta los esquemas conceptuales locales sobre los dispositivos de almacenamiento fsico disponibles en los distintos sitios. Las entradas para este paso son los esquemas conceptuales locales y la informacin de acceso a los fragmentos. Por ltimo, se sabe que la actividad de desarrollo y diseo es un tipo de proceso que necesita de una monitorizacin y un ajuste peridicos, para que si se llegan a producir desviaciones, se pueda retornar a alguna de las fases anteriores. Diseo de la distribucin Existen diversas formas de afrontar el problema del diseo de la distribucin. Caso A, los dos procesos fundamentales, la fragmentacin y la asignacin, se abordan de forma simultnea. Esta metodologa se encuentra en desuso, sustituida por el enfoque en dos fases. Caso B: la realizacin primeramente de la particin para luego asignar los fragmentos generados. El resto de los casos se comentan en la seccin referente a los distintos tipos de la fragmentacin.

Un aspecto importante en el diseo de la distribucin es la cantidad de factores que contribuyen a un diseo ptimo. La organizacin lgica de la base de datos, la localizacin de las aplicaciones, las caractersticas de acceso de las aplicaciones a la base de datos y las caractersticas del sistema en cada sitio, tienen una decisiva influencia sobre la distribucin. La informacin necesaria para el diseo de la distribucin puede dividirse en cuatro categoras: la informacin del banco de datos, la informacin de la aplicacin, la informacin sobre la red de ordenadores y la informacin sobre los ordenadores en s. Las dos ltimas son de carcter cuantitativo y servirn, principalmente, para desarrollar el proceso de asignacin. Se entrar en detalle sobre la informacin empleada cuando se aborden los distintos algoritmos de fragmentacin y asignacin. Fragmentacin Enfoques para realizar el diseo distributivo.

17


Una base de datos fragmentada es aquella donde no existe rplica alguna. Los fragmentos se alojan en sitios donde nicamente existe una copia de cada uno de ellos a lo largo de toda la red. En caso de rplica, podemos considerar una base de datos totalmente replicada, donde existe una copia de todo el banco de datos en cada sitio, o considerar una base de datos parcialmente replicada donde existan copias de los fragmentos ubicados en diferentes sitios. El nmero de copias de un fragmento ser una de las posibles entradas a los algoritmos de asignacin, o una variable de decisin cuyo valor lo determine el algoritmo. A continuacin se muestra la comparacin de las tres alternativas de rplica con respecto a distintas funciones de un sistema de base de datos distribuido. Rplica total Procesamiento de consultas Gestin del directorio Control de concurrencia Seguridad \Realidad fcil fcil o inexistente moderado muy alta posible aplicacin Rplica parcial Dificultad Dificultad Difcil Alta Realista Particin similar similar fcil baja posible aplicacin

Antes de exponer las alternativas existentes de fragmentacin, se desean presentar las ventajas e inconvenientes de esta tcnica. Se coment anteriormente la conveniencia de descomponer las relaciones de la base de datos en pequeos fragmentos, pero no se ha justificado el hecho ni se han aportado razones para efectuarlo. Por ello, desde este punto se va a intentar aportar las razones necesarias para llevar a cabo esa descomposicin, fragmentacin.

18


El principal problema de la fragmentacin radica en encontrar la unidad apropiada de distribucin. Una relacin no es una buena unidad por muchas razones. Primero, las vistas de la aplicacin normalmente son subconjuntos de relaciones. Adems, la localidad de los accesos de las aplicaciones no est definida sobre relaciones enteras pero s sobre subconjuntos de las mismas. Por ello, sera normal considerar como unidad de distribucin a estos subconjuntos de relaciones. Segundo, si las aplicaciones tienen vistas definidas sobre una determinada relacin (considerndola ahora una unidad de distribucin) que reside en varios sitios de la red, se puede optar por dos alternativas. Por un lado, la relacin no estar replicada y se almacena en un nico sitio, o existe rplica en todos o algunos de los sitios en los cuales reside la aplicacin. Las consecuencias de esta estrategia son la generacin de un volumen de accesos remotos innecesario. Adems, se pueden realizar rplicas innecesarias que causen problemas en la ejecucin de las actualizaciones y puede no ser deseable si el espacio de almacenamiento est limitado. Tercero, la descomposicin de una relacin en fragmentos, tratados cada uno de ellos como una unidad de distribucin, permite el proceso concurrente de las transacciones. Tambin la relacin de estas relaciones, normalmente, provocar la ejecucin paralela de una consulta al dividirla en una serie de subconsultas que operar sobre los fragmentos. Pero la fragmentacin tambin acarrea inconvenientes. Si las aplicaciones tienen requisitos tales que prevengan la descomposicin de la relacin en fragmentos mutuamente exclusivos, estas aplicaciones cuyas vistas estn definidas sobre ms de un fragmento pueden sufrir una degradacin en el rendimiento. Por tanto, puede ser necesario recuperar los datos de dos fragmentos y llevar a cabo sobre ellos operacin de unin y yunto, lo cual es costoso. Un segundo problema se refiere al control semntico. Como resultado de la fragmentacin los atributos implicados en una dependencia se descomponen en diferentes fragmentos los cuales pueden destinarse a sitios diferentes. En este caso, la sencilla tarea de verificar las dependencias puede resultar una tarea de bsqueda de los datos implicados en un gran nmero de sitios. Tipos de fragmentacin Dado que una relacin se corresponde esencialmente con una tabla y la cuestin consiste en dividirla en fragmentos menores, inmediatamente surgen dos alternativas lgicas para llevar a cabo el proceso: la divisin horizontal y la divisin vertical. La divisin o fragmentacin horizontal trabaja sobre las tuplas, dividiendo la relacin en subrelaciones que contienen un subconjunto de las tuplas que alberga la primera. La fragmentacin vertical, en cambio, se basa en los atributos de la relacin para efectuar la divisin. Estos dos tipos de particin podran considerarse los fundamentales y bsicos. Sin embargo, existen otras alternativas. Fundamentalmente, se habla de fragmentacin mixta o hbrida cuando el proceso de particin hace uso de los dos tipos anteriores. La fragmentacin mixta puede llevarse a cabo de tres formas diferentes: desarrollando primero la fragmentacin vertical y, posteriormente, aplicando la particin horizontal sobre los fragmentos verticales (denominada particin VH), o aplicando primero una divisin horizontal para luego, sobre los fragmentos generados, desarrollar una fragmentacin vertical (llamada particin HV), o bien, de forma directa considerando la semntica de las transacciones.

Fragmentacin Horizontal:

19


Como se ha explicada anteriormente, la fragmentacin horizontal se realiza sobre las tuplas de la relacin. Cada fragmento ser un subconjunto de las tuplas de la relacin. Existen dos variantes de la fragmentacin horizontal: la primaria y la derivada. La fragmentacin horizontal primaria de una relacin se desarrolla empleando los predicados definidos en esa relacin. Por el contrario, la fragmentacin horizontal derivada consiste en dividir una relacin partiendo de los predicados definidos sobre alguna otra. Informacin sobre la base de datos.

Esta informacin implica al esquema conceptual global. Es importante sealar cmo las relaciones de la base de datos se conectan con otras. En una conexin de relaciones normalmente se denomina relacin propietaria a aquella situada en la cola del enlace, mientras que se llama relacin miembro a la ubicada en la cabecera del vnculo. Dicho de otra forma podemos pensar en relaciones de origen cuando nos refiramos a las propietarias y relaciones destino cuando lo hagamos con las miembro. Definiremos dos funciones: propietaria y miembro, las cuales proyectarn un conjunto de enlaces sobre un conjunto de relaciones. Adems, dado un enlace, devolvern el miembro y el propietario de la relacin, respectivamente. La informacin cuantitativa necesaria gira en torno a la cardinalidad de cada relacin, notada como card(R). Informacin sobre la aplicacin.

Necesitaremos tanto informacin cualitativa como cuantitativa. La informacin cualitativa guiar la fragmentacin, mientras que la cuantitativa se necesitar en los modelos de asignacin. La principal informacin de carcter cualitativo son los predicados empleados en las consultas de usuario. Si no fuese posible investigar todas las aplicaciones para determinar estos predicados, al menos se deberan investigar las ms importantes. Podemos pensar en la regla "80/20" para guiarnos en nuestro anlisis, esta regla dice que el 20% de las consultas existentes acceden al 80% de los datos. Llegados a este punto, sera interesante determinar los predicados simples. A parte de los predicados simples, las consultas emplean predicados ms complejos resultado de combinaciones lgicas de los simples. Una combinacin especialmente interesante es la conjuncin de predicados simples, al predicado resultante se le denomina predicado minitrmino. Partiendo de que siempre es posible transformar una expresin lgica en su forma normal conjuntiva, usaremos los predicados minitrmino en los algoritmos para no causar ninguna prdida de generalidad. Sobre la informacin cuantitativa necesaria relativa a las aplicaciones, necesitaremos definir dos conjuntos de datos.1.

Selectividad minitrmino. Es el nmero de tuplas de una relacin a las que accede una consulta de acuerdo a un predicado minitrmino dado. Por ejemplo, en el ejemplo anterior, la selectividad de m6 es 0 ya que no existe ninguna tupla que satisfaga las condiciones; en cambio, la selectividad de m1 es 2. Notaremos la selectividad de un minitrmino m i como sel(mi). Frecuencia de acceso. Es la frecuencia con la que un usuario accede a los datos. Si Q = {q1, q2, ..., qn} es un conjunto de consultas de usuario, acc(qi) indica la frecuencia de acceso a la consulta qi en un periodo dado.

2.

I.- Fragmentacin horizontal primaria Antes de presentar un algoritmo formal que lleve a cabo la fragmentacin horizontal, se explicar de manera intuitiva los procesos de fragmentacin horizontal primaria y derivada.

20


Ahora definiremos la fragmentacin horizontal ms formalmente. Un fragmento horizontal Ri de una relacin R contiene todas las tuplas de R que satisfacen un predicado minitrmino mi. Por tanto, dado un conjunto de predicados minitrmino M, existen tantos fragmentos horizontales de la relacin R como predicados minitrmino. Este conjunto de fragmentos horizontales tambin se conocen como conjuntos de fragmentos minitrmino. En los prrafos siguientes se asumir que la definicin de fragmentos horizontales se basa en los predicados minitrmino. Adems, el primer paso para el algoritmo de fragmentacin consiste en establecer un conjunto de predicados con ciertas propiedades. Un aspecto importante de los predicados simples es su complecin, as como su minimalidad. Un conjunto de predicados simples Pr se dice que es completo si y solo si existe una probabilidad idntica de acceder por cada aplicacin a cualquier par de tuplas pertenecientes a cualquier fragmento minitrmino que se define de acuerdo con Pr. Se puede apreciar como la definicin de complecin de un conjunto de predicados simples difiere de la regla de complecin de la fragmentacin. El segundo paso en el proceso de fragmentacin primaria consiste en derivar el conjunto de predicados minitrmino que pueden definirse sobre los predicados del conjunto Pr'. Estos predicados minitrmino establecen los fragmentos candidatos para el proceso de asignacin. El establecimiento de los predicados minitrmino es trivial; la dificultad radica en el tamao del conjunto de predicados minitrmino, que puede ser muy grande (de hecho, exponencial respecto al nmero de predicados simples). En el paso siguiente se presentarn formas de reducir el nmero de predicados minitrmino necesarios para la fragmentacin. El tercer paso aborda la eliminacin de algunos fragmentos minitrmino que puedan ser redundantes. Esta eliminacin se desarrolla identificando aquellos minitrminos que puedan resultar contradictorios sobre un conjunto de implicaciones. II.- Fragmentacin horizontal derivada Una fragmentacin horizontal derivada se define sobre una relacin miembro de acuerdo a una operacin de seleccin especificada sobre su propietaria. Se deben dejar claros dos puntos. Primero, el enlace entre las relaciones propietaria y miembro se define como un equi-yunto. Segundo, un equi-yunto puede desarrollarse a travs de semiyuntos. Este segundo punto es especialmente importante para nuestros propsitos, ya que deseamos fraccionar una relacin miembro segn la fragmentacin de su propietaria, adems es necesario que el fragmento resultante se defina nicamente sobre los atributos de la relacin miembro. Las tres entradas necesarias para desarrollar la fragmentacin horizontal derivada son las siguientes: el conjunto de particiones de la relacin propietaria, la relacin miembro y el conjunto se predicados resultados de aplicar el semi-yunto entre la propietaria y la miembro. El algoritmo de fragmentacin resulta tan trivial que no se ve la necesidad de entrar en detalles. Existe una posible complicacin que necesita nuestro estudio. En un esquema de base de datos, resulta frecuente que existan ms de dos enlaces sobre una relacin R. En este caso, aparece ms de una posibilidad de fragmentacin horizontal derivada. La decisin para elegir una u otra se basa en dos criterios: la fragmentacin con mejores caractersticas de yunto y la fragmentacin empleada en ms aplicaciones. Veremos el segundo criterio primero. Resulta sencillo de establecer si tomamos en consideracin la frecuencia con la que cada aplicacin accede a los datos. Si es posible, deberamos intentar facilitar el acceso a los usuarios que hagan mayor uso de los datos para, de esta manera, minimizar el impacto total del rendimiento del sistema.21


Grafo de yuntos entre fragmentos.

El primer criterio, sin embargo, no es tan sencillo. Veamos la parte fcil de este criterio. Considere, por ejemplo, el grafo de yunto (los enlaces) entre los fragmentos de CLIENTES y la derivada PROVINC. Hay nicamente un enlace entrando o saliendo de un fragmento. De ah, que se denomine a este grafo, grafo simple. La ventaja de este diseo donde la relacin de yunto entre los fragmentos es simple, radica en la asignacin a un sitio tanto de la propietaria como de la miembro y los yuntos entre pares diferentes de fragmentos pueden realizarse independientemente y en paralelo. Desgraciadamente, la obtencin de grafos de yunto simples no siempre es posible. En tal caso, la mejor alternativa sera realizar un diseo que provoque un grafo de yuntos fragmentados. Un grafo fragmentado consiste en dos o ms subgrafos que no estn enlazados entre ellos. Por tanto, los fragmentos que se obtengan no se distribuirn para ejecuciones paralelas de un modo tan fcil como aquellos obtenidos a travs de grafos simples, pero su asignacin an ser posible. Procederemos ahora a probar la correccin de los algoritmos presentados con respecto a los tres criterios enunciados anteriormente.1.

Complecin. La complecin de una fragmentacin horizontal primaria se basa en la seleccin de los predicados a usar. En la medida que los predicados seleccionados sean completos, se garantizar que el resultado de la fragmentacin tambin lo ser. Partiendo de la base que el algoritmo de fragmentacin es un conjunto de predicados completos y mnimos Pr', se garantiza la complecin siempre que no aparezcan errores al realizar la definicin de Pr'. La complecin de una fragmentacin horizontal derivada es algo ms difcil de definir. La dificultad viene dada por el hecho de que los predicados que intervienen en la fragmentacin forman parte de dos relaciones. Definamos la regla de complecin formalmente. Sea R la relacin miembro de un enlace cuya propietaria es la relacin S, la cual est fragmentada como FS = {S1, S2, ..., Sw}. Adems, sea A el atributo de yunto entre R y S. Entonces para cada tupla t de R, existir una tupla t' de S tal que t[A] = t' [A]. Reconstruccin. La reconstruccin de una relacin global a partir de sus fragmentos se desarrolla con el operador de unin tanto para la fragmentacin horizontal primaria como para la derivada. Disyuncin. Resulta sencillo establecer la disyuncin de la fragmentacin tanto para la primaria como para la derivada. En el primer caso, la disyuncin se garantiza en la medida en que los predicados minitrmino que determinan la fragmentacin son mutuamente exclusivos. En la fragmentacin derivada, sin embargo, implica un semi-yunto que aade complejidad al asunto. La disyuncin puede garantizarse si el grafo de yunto es simple. Si no es simple, ser necesario investigar los valores de las tuplas. En general, no se desea juntar una tupla de una relacin miembro con dos o ms tuplas de una relacin propietaria cuando estas tuplas se encuentran en fragmentos diferentes a los de la propietaria. Esto no es fcil de establecer e ilustrar por qu los esquemas de la fragmentacin derivada que generan un grafo de yunto simple son siempre ms atractivos.22

2.

3.


Fragmentacin Vertical: Recordemos que la fragmentacin vertical de una relacin R produce una serie de fragmentos R1, R2, ..., Rr, cada uno de los cuales contiene un subconjunto de los atributos de R as como la clave primaria de R. El objetivo de la fragmentacin vertical consiste en dividir la relacin en un conjunto de relaciones ms pequeas tal que algunas de las aplicaciones de usuario slo hagan uso de un fragmento. Sobre este marco, una fragmentacin ptima es aquella que produce un esquema de divisin que minimiza el tiempo de ejecucin de las aplicaciones que emplean esos fragmentos. Existen dos enfoques heursticos para la fragmentacin vertical de relaciones:1.

Agrupacin. Comienza asignando cada atributo a un fragmento, y en cada paso, junta algunos de los fragmentos hasta que satisface un determinado criterio. La agrupacin sugiri en principio para bases de datos centralizadas y se us posteriormente para las bases de datos distribuidas. Escisin. A partir de la relacin se deciden que fragmentos resultan mejores, basndose en las caractersticas de acceso de las aplicaciones a los atributos. Esta tcnica se present, tambin, para bases de datos centralizadas. Posteriormente, se extendi al entorno distribuido.

2.

Trataremos nicamente la tcnica de escisin, ya que es ms apropiada para la estrategia descendente y porque resulta ms probable encontrar la solucin para la relacin entera que a partir de un conjunto de fragmentos con un nico atributo. Adems, la escisin genera fragmentos no solapados mientras que la agrupacin normalmente produce fragmentos solapados. Dentro del contexto de los sistemas de bases de datos distribuidos, son preferibles los fragmentos no solapados por razones obvias. Evidentemente, los fragmentos no solapados se refieren nicamente a atributos clave no primarios. Antes de profundizar ms, vamos a aclarar un problema: la rplica de las claves de la relacin en los fragmentos. Esta es una caracterstica de la fragmentacin vertical que permite la reconstruccin de la relacin global. Por tanto, la escisin considera nicamente aquellos atributos que no son parte de la clave primaria. La rplica de los atributos clave supone una gran ventaja, a pesar de los problemas que pueda causar. La ventaja est relacionada con el esfuerzo para mantener la integridad semntica. Tengamos en cuenta que cada dependencia (funcional, multivaluada, ...) es, de hecho, una restriccin que influye sobre el valor de los atributos de las respectivas relaciones en todo momento. Tambin muchas de estas dependencias implican a los atributos clave de una relacin. Si queremos disear una base de datos tal que los atributos clave sean parte de una fragmento que est ubicado en un sitio, y los atributos relacionados sean parte de otro fragmento asignado a un segundo sitio, cada peticin de actualizacin provocar la verificacin de integridad que necesitar de una comunicacin entre esos sitios. La rplica de los atributos clave de cada fragmento reduce esta problemtica, pero no elimina toda su complejidad, ya que la comunicacin puede ser necesaria para las restricciones de integridad que implican a las claves primarias, as como para el control de concurrencia. Una posible alternativa a la rplica de los atributos clave es el empleo de identificadores de tuplas, que son valores nicos asignados por el sistema a las tuplas de una relacin. Mientras el sistema mantenga los identificadores, los fragmentos permanecern disjuntos.

23


Informacin sobre las aplicaciones

Por tanto, este punto tratar de especificar la informacin que de una aplicacin que funciona sobre la base de datos podamos extraer. Teniendo en cuenta que la fragmentacin vertical coloca en un fragmento aquellos atributos a los que se accede de manera simultnea, necesitaremos alguna medida que defina con ms precisin el concepto de simultaneidad. Esta medida es la afinidad de los atributos, que indica la relacin estrecha existente entre los atributos. Desgraciadamente, no es muy realista esperar que el diseador o los usuarios puedan especificar estos valores. Por ello, presentaremos una forma por la cual obtengamos esos valores partiendo de datos ms bsicos. El principal dato necesario relativo a las aplicaciones es la frecuencia de acceso. Sea Q = {q1, q2, ..., qn} el conjunto de consultas de usuario (aplicaciones) que funcionan sobre una relacin R(A1, A2, ..., An). Los vectores uso(qi,) pueden definirse muy fcilmente para cada aplicacin siempre que el diseador conozca las aplicaciones existentes en el sistema. La regla 80/20 expuesta pginas atrs podra resultar til para el desarrollo de esta tarea. Los valores del uso de los atributos en general no son suficientes para desarrollar la base de la escisin y la fragmentacin de los atributos, ya que estos valores no representan el peso de las frecuencias de la aplicacin. La dimensin de esta frecuencia puede incluirse en la definicin de la medida de los atributos afines afd(Ai, Aj), la cual mide el lmite entre dos atributos de una relacin de acuerdo a cmo las aplicaciones acceden a ellos. Fragmentacin mixta o hbrida: En muchos casos la fragmentacin vertical u horizontal del esquema de la base de datos no ser suficiente para satisfacer los requisitos de las aplicaciones. Como ya se cit al comienzo de este documento podemos combinar ambas, utilizando por ello la denominada fragmentacin mixta. Cuando al proceso de fragmentacin vertical le sigue una horizontal, es decir, se fragmentan horizontalmente los fragmentos verticales resultantes, se habla de la fragmentacin mixta HV. En el caso contrario, estaremos ante una fragmentacin VH. Una caracterstica comn a ambas es la generacin de rboles que representan la estructura de fragmentacin. No se desea entrar en excesivos detalles sobre las reglas y condiciones para efectuar la fragmentacin mixta. Entre otras razones porque, tanto a la fragmentacin HV como la fragmentacin VH, se le pueden aplicar los mismos criterios y reglas que a la fragmentacin horizontal y vertical. Debe tenerse en cuenta el nmero de niveles arbreos que se generen al realizar este tipo de particin, es decir, nadie impide que tras realizar una fragmentacin VH, podamos aplicar a los fragmentos resultantes una nueva fragmentacin vertical, y a estas ltimas una nueva fragmentacin horizontal, etc. Dicho nmero puede ser grande, pero tambin ser ciertamente finito. En el caso horizontal, el nivel mximo de profundidad se alcanzar cuando cada fragmento albergue una nica tupla, mientras que en el caso vertical el final llegar cuando cada fragmento contenga un nico atributo. Sin embargo, aunque no deba tomarse como dogma, el nmero de niveles no debera superar el par (VH y HV). El porqu de esta afirmacin es bien sencillo, piense, por ejemplo, en el coste que supondra realizar la unin o el yunto de una relacin con fragmentacin nivel 7. Evidentemente, el coste sera muy elevado y ese aumento de rendimiento que se persigue al aplicar estas tcnicas, quizs, no se produzca. Antes de pasar a estudiar el problema de la asignacin se desea comentar la tcnica de fragmentacin mixta basada en celdas. Esta tcnica se basa en la generacin de celdas de rejilla. Una celda de rejilla podramos definirla como un fragmento horizontal y vertical simultneo. La tcnica24


aplica un algoritmo de fragmentacin vertical y otro horizontal de manera concurrente sobre la relacin. Los algoritmos realizan una fragmentacin mxima, es decir, se persigue que en cada celda nicamente haya un atributo y una tupla. Quizs alguien pueda encontrar el mtodo contradictorio con lo citado anteriormente respecto a la eficiencia, dada la gran cantidad de fragmentos generados, el nmero es, efectivamente, el mximo. Sin embargo, este slo es el primer paso del proceso. Una vez generadas las celdas se aplica un mtodo para optimizar la rejilla mediante fusin o desfragmentacin, de acuerdo, fundamentalmente, a las aplicaciones que acten sobre esos fragmentos. El mtodo, por tanto, persigue una fragmentacin lo ms especfica posible acorde con las aplicaciones y los sitios existentes en la red. En esta etapa de la asignacin, necesitaremos datos cuantitativos sobre la base de datos, las aplicaciones que funcionan sobre ella, la red de comunicaciones, las caractersticas de proceso, y el lmite de almacenamiento de cada sitio de la red. Procederemos a discutirlos en detalle. Informacin sobre la base de datos

Para desarrollar la fragmentacin horizontal, definimos la selectividad de los minitrminos. Ahora, necesitamos extender esta definicin a los fragmentos y definir la selectividad de un fragmento Fj con respecto a una consulta qi. Es el nmero de tuplas de Fj a las que se necesita acceder para procesar qi. Este valor lo notaremos como seli(Fj). Otro elemento informativo de los fragmentos de la base de datos es su tamao. El tamao de un fragmento Fj viene dado por tamao(Fj) = card(Fj)*long(Fj), donde long(Fj) es la longitud (en octetos) de una tupla del fragmento Fj. Informacin de los sitios.

Sobre cada ordenador necesitamos conocer sus capacidades de procesamiento y almacenamiento. Obviamente, estos valores pueden calcularse a travs de funciones elaboradas o por simples estimaciones. La unidad de coste de almacenar datos en el sitio Sk ser denotada como UCAk. As mismo, especificaremos como medida de coste UPTk al coste de procesar una unidad de trabajo en el sitio Sk. Informacin sobre la red.

En este modelo se asume la existencia de una red simple donde el coste de comunicaciones se define respecto a una trama de datos. Entonces gij nota el coste de comunicacin por trama entre los sitios Si y Sj. Para permitir el clculo del nmero de mensajes, usaremos ftamao como el tamao (en octetos) de una trama. Es evidente que existen modelos de red mucho ms elaborados que toman en cuenta las capacidades del canal, las distancias entre sitios, las caractersticas del protocolo, etc. Sin embargo no tocaremos esos temas. Otro enfoque distinto y relativamente nuevo, consiste en aplicar sobre una relacin, de forma simultnea y no secuencial, la fragmentacin horizontal y la fragmentacin vertical; en este caso, se generara una rejilla y los fragmentos formaran las celdas de esa rejilla, cada celda ser exactamente un fragmento vertical y un fragmento horizontal (ntese que en este caso el grado de fragmentacin alcanzado es mximo, y no por ello la descomposicin resultar ms eficiente). En el esquema presentado anteriormente (Enfoques para realizar el diseo distributivo) puede observarse como los casos C y D se basan en la mencionada generacin de la rejilla, con la diferencia que en el primero de ellos se produce una fusin, una desfragmentacin de las celdas, agrupndolas de la manera ms adecuada para obtener mayor rendimiento, ya que los fragmentos generados son muy pequeos. En el segundo caso se asignan las celdas a los sitios y luego se realiza una rigurosa optimizacin de cada sitio. El caso E sera aquel en el que se utiliza la fragmentacin VH o la fragmentacin HV.25


Grado de Fragmentacin Cuando se va a fragmentar una base de datos deberamos sopesar qu grado de fragmentacin va a alcanzar, ya que ste ser un factor que influir notablemente en el desarrollo de la ejecucin de las consultas. El grado de fragmentacin puede variar desde una ausencia de la divisin, considerando a las relaciones unidades de fragmentacin; o bien, fragmentar a un grado en el cada tupla o atributo forme un fragmento. Ante estos dos casos extremos, evidentemente se ha de buscar un compromiso intermedio, el cual debera establecerse sobre las caractersticas de las aplicaciones que hacen uso de la base de datos. Dichas caractersticas se podrn formalizar en una serie de parmetros. De acuerdo con sus valores, se podr establecer el grado de fragmentacin del banco de datos. Alternativas de asignacin Partiendo del supuesto que el banco de datos se haya fragmentado correctamente, habr que decidir sobre la manera de asignar los fragmentos a los distintos sitios de la red. Cuando una serie de datos se asignan, stos pueden replicarse para mantener una copia o varias idnticas. Cada copia se almacena en una localidad diferente, lo que resulta en una repeticin de la informacin. La rplica tiene varias ventajas y desventajas: Disponibilidad: Si falla una de las localidades que contienen la relacin r, puede disponerse de sta en otra localidad. As, el sistema puede continuar procesando consultas que impliquen a r a pesar de haber fallado una localidad. Por lo tanto, todo esto gira en torno a la seguridad y a la eficiencia de las consultas de lectura. Mayor paralelismo: en el caso en que la mayor parte de los accesos a la relacin r resulten slo en la lectura de la relacin, varias localidades podrn procesar consultas que involucren a r en paralelo. Mientras ms copias de r existan, mayor ser la probabilidad de que los datos requeridos se encuentren en la localidad donde se est ejecutando la transaccin. Por tanto, la replica de los datos reduce al mnimo el movimiento de informacin entre localidades. As, un buen parmetro para afrontar el grado de rplica consistira en sopesar la cantidad de consultas de lectura que se efectuarn, as como el nmero de consultas de escritura que se llevarn a cabo. En una red donde las consultas que se procesen sean mayoritariamente de lectura, se podra alcanzar un alto grado de rplica, no as en el caso contrario Mayor tiempo extra de actualizaciones: El sistema debe asegurarse de que todas las copias de la relacin r sean consistentes, pues de otra manera pueden hacerse clculos errneos. Esto implica que cada vez que se actualice r, la actualizacin debe propagarse a todas las localidades que contengan copias, lo que resulta en un mayor tiempo extra. Por ejemplo, en un sistema bancario, donde se repite la informacin de cuentas en varias localidades, es necesario que las transacciones garanticen que el saldo de una cuenta determinada sea el mismo en todas las localidades.

26


Transparencia y Autonoma

27


Sabemos que una relacin puede almacenarse de varias formas en un sistema de base de datos distribuida. Es esencial que el sistema reduzca al mximo la necesidad de que el usuario se de cuenta de cmo est almacenada una relacin. Como veremos, un sistema puede ocultar los detalles de la distribucin de la informacin de la red. Esto se denomina transparencia e la red. La Transparencia de la red se relaciona, en algn modo, a la autonoma local. La transparencia de la red es el grado hasta el cual los usuarios del sistema pueden ignorar los detalles del diseo distribuido. La autonoma local es el grado hasta el cual el diseador o administrador de una localidad pueden ser independientes del resto del sistema distribuido. Los temas de transparencia y autonoma sern considerados desde los siguientes puntos de vista: Nombre de los datos Repeticin de los datos Fragmentacin de los datos Localizacin de los fragmentos y copias Asignacin de nombres y autonoma local Todo elemento de informacin de una base de datos debe tener un nombre nico. Esta propiedad se asegura fcilmente en una base de datos que no est distribuida. Sin embargo, en una base de datos distribuida, las distintas localidades deben asegurarse no utilizar el mismo nombre para dos datos diferentes. Una solucin para este problema es requerir que se registren todos los nombres en un asignador central de nombres. Sin embargo, este enfoque tiene varias desventajas: Es posible que el asignador de nombres se convierta en un cuello de botella. Si el asignador de nombres se cae, es posible que ninguna de las localidades del sistema distribuido pueda seguir trabajando. Se reduce la autonoma local, y que la asignacin de nombres se controla de forma centralizada. Un enfoque diferente que origina una mayor autonoma local es exigir que cada localidad ponga como prefijo un identificador de localidad a cualquier nombre que genere. Esto garantiza que dos localidades nunca generarn el mismo nombre (ya que cada localidad tiene un identificador nico). Adems, no se requiere un control central. Esta solucin al problema de asignacin de nombres logra autonoma local, pero no transparencia de la red, ya que se agregan identificadores de localidad a los nombres. As, la relacin depsito podra llamarse localidadX.depsito en vez de depsito simplemente. Cada copia y fragmento de un elemento de informacin deben tener un nombre nico. Es importante que el sistema pueda determinar que copias son copias del mismo elemento de informacin y que fragmentos son fragmentos del mismo elemento de informacin.

28


Transparencia de la repeticin y la fragmentacin No es conveniente requerir que los usuarios hagan referencia a una copia especifica de un elemento de informacin. El sistema debe ser el que determine a que copia debe acceder cuando se solicite la lectura, y debe modificar todas las copias cuando se produzca la peticin de escritura. Cuando se solicita un dato, no es necesario especificar la copia. El sistema utiliza una tabla-catlogo para determinar cules son todas las copias de ese dato. De manera similar, no debe exigirse a los usuarios que sepan cmo est el fragmentado de un elemento de informacin. Adems, es posible que los fragmentos verticales contengan id-tuplas, que representan direcciones por predicados complejos. Por tanto, un sistema de base de datos distribuido debe permitir las consultas que se hagan en trminos de elementos de informacin sin fragmentar. Esto no presenta problemas graves, ya que siempre es posible reconstruir el elemento de informacin original a partir de sus fragmentos. Sin embargo, este proceso puede ser ineficiente. Transparencia de localizacin Si el sistema es transparente en cuanto a repeticin y fragmentacin, se ocultar al usuario gran parte del esquema de la base de datos distribuida. Sin embargo, el componente de los nombres que identifican a la localidad obliga al usuario a darse cuenta del hecho de que el sistema est distribuido. La transparencia de localizacin se logra creando un conjunto de seudnimos o alias para cada usuario. As, el usuario puede referirse a los datos usando nombres sencillos que el sistema traduce a nombres completos. Con el uso de seudnimos, no ser necesario que el usuario conozca la localizacin fsica de un dato. Adems, el administrador de la base de datos puede cambiar un dato de una localidad a otra sin afectar a los usuarios. Esquema completo de asignacin de nombres Ya vimos que un nombre proporcionado por el usuario debe pasar por varios pasos de traduccin antes de que pueda servir como referencia a una copia especfica de un fragmento determinado en una localidad especfica. Para ilustrar cmo funciona el esquema, consideramos un usuario que se encuentra en la sucursal 1 (L1). Este usuario emplea el seudnimo depsito-local para el fragmento local depsito-F1 de la relacin deposito. Cuando este usuario hace referencia a depsito-local, el subsistema de procesamiento de consultas busca depsito-local en la tabla de seudnimos y la sustituye por Ll.depsito.F1. Es posible que L1.depsito.Fl est repetido. Si es as, debe consultarse la tabla de copias para elegir una copia. Esta copia podra tambin estar fragmentada, lo que hara necesario consultar la tabla de fragmentacin. En la mayor parte de los casos, slo es preciso consultar una o dos tablas.

29


Transparencia y actualizaciones De alguna forma es ms difcil hacer transparente la base de datos para usuarios que la actualizan que para aquellos que slo leen datos. El problema principal es asegurarse de que se actualizan todas las copias de un dato y tambin los fragmentos afectados. En el caso ms general, el problema de actualizacin de informacin repetida y fragmentada est relacionado con el problema de actualizacin de vistas

30


Procesamiento distribuido de consultas

31


El xito creciente de la tecnologa de bases de datos relacionales en el procesamiento de datos se debe, en parte, a la disponibilidad de lenguajes no procedurales los cuales pueden mejorar significativamente el desarrollo de aplicaciones y la productividad del usuario final. Ocultando los detalles de bajo nivel acerca de la localizacin fsica de datos, los lenguajes de bases de datos relacionales permiten la expresin de consultas complejas en una forma concisa y simple. Particularmente, para construir la respuesta a una consulta, el usuario no tiene que especificar de manera precisa el procedimiento que se debe seguir. Este procedimiento es llevado a cabo por un mdulo del DBMS llamado el procesador de consultas (query processor). Dado que la ejecucin de consultas es un aspecto crtica en el rendimiento de un DBMS, el procesamiento de consultas ha recibido una gran atencin tanto para bases de datos centralizadas como distribuidas. Sin embargo, el procesamiento de consultas es mucho ms difcil en ambientes distribuidos que en centralizados, ya que existe un gran nmero de parmetros que afectan el rendimiento de las consultas distribuidas. La funcin principal de un procesador de consultas relacionales es transformar una consulta en una especificacin de alto nivel, tpicamente en clculo relacional, a una consulta equivalente en una especificacin de bajo nivel, tpicamente alguna variacin del lgebra relacional. La consulta de bajo nivel implementa de hecho la estrategia de ejecucin para la consulta. La transformacin debe ser correcta y eficiente. Es correcta si la consulta de bajo nivel tiene la misma semntica que la consulta original, esto es, si ambas consultas producen el mismo resultado. El mapeo bien definido que se conoce entre el clculo relacional y el lgebra relacional hace que la correctitud de la transformacin sea fcil de verificar. Sin embargo, producir una estrategia de ejecucin eficiente es mucho ms complicado. Una consulta en el clculo relacional puede tener muchas transformaciones correctas y equivalentes en el lgebra relacional. Ya que cada estrategia de ejecucin equivalente puede conducir a consumos de recursos de cmputo muy diferentes, la dificultad ms importante es seleccionar la estrategia de ejecucin que minimiza el consumo de recursos.

32


Optimizacin de Consultas Distribuidas Como se estableci antes, el objetivo del procesamiento de consultas en un ambiente distribuido es transformar una consulta sobre una base de datos distribuida en una especificacin de alto nivel a una estrategia de ejecucin eficiente expresada en un lenguaje de bajo nivel sobre bases de datos locales. As, el problema de optimizacin de consultas es minimizar una funcin de costo tal que funcin de costo total = costo de I/O + costo de CPU + costo de comunicacin

Los diferentes factores pueden tener pesos diferentes dependiendo del ambiente distribuido en el que se trabaje. Por ejemplo, en las redes de rea amplia (WAN), normalmente el costo de comunicacin domina dado que hay una velocidad de comunicacin relativamente baja, los canales estn saturados y el trabajo adicional requerido por los protocolos de comunicacin es considerable. As, los algoritmos diseados para trabajar en una WAN, por lo general, ignoran los costos de CPU y de I/O. En redes de rea local (LAN) el costo de comunicacin no es tan dominante, as que se consideran los tres factores con pesos variables. Arquitectura del procesamiento de consultas El problema de procesamiento de consultas se puede descomponer en varios sub-problemas que corresponden a diferentes niveles. En la Figura 3, se presenta un esquema por niveles genrico para el procesamiento de consultas. Para simplificar la discusin, suponga que se tiene un procesador de consultas esttico semicentralizado en donde no se tienen fragmentos replicados. Cuatro capas principales estn involucradas en mapear una consulta a una base de datos distribuida en una secuencia optimizada de operaciones locales, cada una de ellas actuando en una base de datos local. Descomposicin de consultas La primera capa descompone una consulta en el clculo relacional en una consulta en el lgebra relacional que opera sobre relaciones globales. Consiste de cuatro partes: 1.-Normalizacin. Involucra la manipulacin de los cuantificadores de la consulta y de los calificadores de la misma mediante la aplicacin de la prioridad de los operadores lgicos. 2.-Anlisis. Se detecta y rechazan consultas semnticamente incorrectas. 3.-Simplificacin. Elimina predicados redundantes. 4.-Reestructuracin. Mediante reglas de transformacin una consulta en el clculo relacional se transforma a una en el lgebra relacional. Se sabe que puede existir ms de una transformacin. Por tanto, el enfoque seguido usualmente es empezar con una consulta algebraica y aplicar transformaciones para mejorarla. Localizacin de Datos La entrada a esta capa es una consulta algebraica definida sobre relaciones distribuidas. El objetivo de esta capa es localizar los datos de la consulta usando la informacin sobre la distribucin de datos. Esta capa determina cuales fragmentos estn involucrados en la consulta y transforma la consulta distribuida en una consulta sobre fragmentos.

33


Optimizacin Global de Consultas Dada una consulta algebraica sobre fragmentos, el objetivo de esta capa es hallar una estrategia de ejecucin para la consulta cercana a la ptima. La estrategia de ejecucin para una consulta distribuida puede ser descrita con los operadores del lgebra relacional y con primitivas de comunicacin para transferir datos entre nodos. Para encontrar una buena transformacin se consideran las caractersticas de los fragmentos, tales como, sus cardinalidades. Un aspecto importante de la optimizacin de consultas es el ordenamiento de juntas, dado que algunas permutaciones de juntas dentro de la consulta pueden conducir a un mejoramiento de varios rdenes de magnitud. La salida de la capa de optimizacin global es una consulta algebraica optimizada con operacin de comunicacin incluidas sobre los fragmentos. Optimizacin Local de Consultas El trabajo de la ltima capa se efecta en todos los nodos con fragmentos involucrados en la consulta. Cada subconsulta que se ejecuta en un nodo, llamada consulta local, es optimizada usando el esquema local del nodo. Hasta este momento, se pueden eligen los algoritmos para realizar las operaciones relacionales. La optimizacin local utiliza los algoritmos de sistemas centralizados.

34


Recuperacin en Sistemas Distribuidos

35


Hasta ahora las primitivas bsicas de acceso que se han considerado son las consultas(queries) que pueden ser de actualizacin o lectura a la base de datos. Sin embargo, no se ha discutido qu pasa cuando dos consultas tratan de actualizar el mismo elemento de datos o si el sistema falla durante la ejecucin de una consulta. En algunos casos no se puede simplemente proseguir con la ejecucin de la consulta dado que algunos datos pueden haber sido modificados antes de la falla y por lo tanto conducir a que la informacin en la base de datos contenga datos incorrectos. Luego intuitivamente podemos pensar que el concepto principal que debe manejar la base de datos es la de ejecucin consistente de consultas. Por eso es que se introduce a continuacin el concepto de una transaccin que es usado dentro del dominio de la base de datos como una unidad bsica de cmputo consistente y confiable. As se define una transaccin como una coleccin de acciones que hacen transformaciones consistentes de los estados de un sistema preservando la consistencia del mismo. Una base de datos est en un estado consistente si obedece a todas las restricciones de integridad definidas sobre ella. Los cambios de estado ocurren debido a actualizaciones, inserciones, y supresiones de informacin. Y lo que se quiere asegurar es que la base de datos nunca entre en un estado de inconsistencia. Sin embargo, durante la ejecucin de una transaccin, la base de datos puede estar temporalmente en un estado inconsistente, lo importante es asegurar que la base de datos regrese a un estado consistente al fin de la ejecucin de una transaccin. Lo que se persigue con el manejo de transacciones es por un lado tener una transparencia adecuada de las acciones concurrentes a una base de datos y por otro lado tener una transparencia adecuada en el manejo de las fallas que se pueden presentar en una base de datos. Las propiedades de una transaccin son las siguientes: 1.-Atomicidad. Se refiere al hecho de que una transaccin se trata como una unidad de operacin. Por lo tanto, o todas las acciones de la transaccin se realizan o ninguna de ellas se lleva a cabo. La atomicidad requiere que si una transaccin se interrumpe por una falla, sus resultados parciales deben ser deshechos. La actividad referente a preservar la atomicidad de transacciones en presencia de abortos debido a errores de entrada, sobrecarga del sistema o interbloqueos se le llama recuperacin de transacciones. La actividad de asegurar la atomicidad en presencia de cadas del sistema se le llama recuperacin de cadas. 2.-Consistencia. La consistencia de una transaccin es simplemente su correctitud. En otras palabras, una transaccin es un programa correcto que lleva la base de datos de un estado consistente a otro con la misma caracterstica. Debido a esto, las transacciones no violan las restricciones de integridad de una base de datos. 3.-Aislamiento. Una transaccin en ejecucin no puede revelar sus resultados a otras transacciones concurrentes antes de su commit. Ms an, si varias transacciones se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado de manera secuencial (seriabilidad). 4.-Durabilidad. Es la propiedad de las transacciones que asegura que una vez que una transaccin hace su commit, sus resultados son permanentes y no pueden ser borrados de la base de datos. Por lo tanto, los DBMS aseguran que los resultados de una transaccin sobrevivirn a fallas del sistema. Esta propiedad motiva el aspecto de recuperacin de bases de datos, el cual trata sobre como recuperar la base de datos a un estado consistente en donde todas las acciones que han hecho un commit queden reflejadas.

36


En resumen, las transacciones proporcionan una ejecucin atmica y confiable en presencia de fallas, una ejecucin correcta en presencia de accesos de usuario mltiples y un manejo correcto de rplicas (en el caso de que se soporten). Tipos de Transacciones Las transacciones pueden pertenecer a varias clases. Aun cuando los problemas fundamentales son los mismos para las diferentes clases, los algoritmos y tcnicas que se usan para tratarlas pueden ser considerablemente diferentes. Las transacciones pueden ser clasificadas con respecto a: reas de aplicacin. En primer lugar, las transacciones se pueden ejecutar en aplicaciones no distribuidas. Las transacciones que operan sobre datos distribuidos se les conoce como transacciones distribuidas. Por otro lado, dado que los resultados de una transaccin que realiza un commit(confirmacin de ejecucin de una transaccin) son durables, la nica forma de deshacer los efectos de una transaccin con commit es mediante otra transaccin. A este tipo de transacciones se les conoce como transacciones compensatorias. Finalmente, en ambientes heterogneos se presentan transacciones heterogneas sobre los datos. Tiempo de duracin. Tomando en cuenta el tiempo que transcurre desde que se inicia una transaccin hasta que se realiza un commit o se aborta, las transacciones pueden ser de tipo batch o en lnea. Estas se pueden diferencias tambin como transacciones de corta y larga vida. Las transacciones en lnea se caracterizan por tiempos de respuesta muy cortos y por acceder una porcin relativamente pequea de la base de datos. Por otro lado, las transacciones de tipo batch toman tiempos relativamente largos y accesan grandes porciones de la base de datos. Estructura. Considerando la estructura que puede tener una transaccin se distinguen dos tipos: transaccin que contiene a su vez subtransacciones y transaccin plana que consiste en una secuencia de operaciones primitivas encerradas entre las palabras begin y end.

Se ha definido anteriormente una transaccin como una unidad de programa cuya ejecucin conserva la consistencia de una base de datos. La ejecucin de sta debe ser atmica(propiedad de atomicidad). En un SBDD puede que participen varias localidades en la ejecucin de una transaccin por lo que es ms difcil garantizar la propiedad de atomicidad. El fallo de una de estas localidades o el fallo de la lnea de comunicacin entre ellas pueden llevar a un resultado errneo. Es por esto que existe el gestor de transacciones cuya funcin es asegurar la ejecucin atmica de las transacciones gestionando la ejecucin de aquellas transacciones(locales o globales) que acceden a datos almacenados en su localidad y el coordinador de transacciones que es el encargado de coordinar la ejecucin de varias transacciones(locales o globales) iniciadas en su localidad. Ms especficamente un gestor de transacciones se encarga de: Mantener una bitcora para la recuperacin Participar en un esquema de control de concurrencia apropiado para coordinar la ejecucin en paralelo de las transacciones que se ejecuten en esa localidad.

37


Mientras que para cada transaccin iniciada en su localidad el coordinador de transacciones debe: Robustez Un SBDD puede sufrir las mismas fallas que un SBDC, por ejemplo fallo de memoria, fallo de disco, etc., pero a estas fallas se le deben agregar: el fallo total de una localidad, la interrupcin de una lnea de comunicacin, prdida de mensajes, fragmentacin de la red. Protocolos de compromiso Para garantizar la atomicidad, es preciso que todas los sitios dnde se haya ejecutado una transaccin Y coincidan en el resultado final de la operacin (ejecutada o abortada en todos los sitios). Esto lo consigue el coordinador de transacciones utilizando los llamados protocolos de compromiso. Protocolos de compromiso de dos fases: Fase 1: En la primera fase el coordinador enva un mensaje a todas las localidades. Los gestores de cada sitio responden si estn dispuestos o no. Fase 2: En la segunda fase, una vez recibidas o no las respuestas el coordinador determina si se ejecuta o no la transaccin. Protocolos de compromiso de tres fases: Fase 1: Igual que para dos fases. Fase 2: Si el coordinador recibe una respuesta de abortar o no recibe respuesta dentro del intervalo de tiempo de un sitio, entonces aborta. Si recibe confirmacin de todas decide preejecutar (an puede ser eventualmente abortado) y enva un mensaje a los sitios. Los gestores envan mensajes de reconocimiento. Fase 3: Se ejecuta slo si la decisin tomada en la fase 2 fue la de preejecutar. Cuando el coordinador recibe los mensajes de confirmacin de los sitios, enva mensaje de ejecucin a los sitios. El protocolo de pasada dos fases realiza esta coordinacin. Un lugar coordinador pide a todos los participantes la ejecucin de las subTi. Cuando cada participante termina, genera un estado de preparado-para-pasar donde es posible pasar la subTio abortarla. Enva un mensaje de preparadopara-pasar al coordinador, que al recibirlo desde todos los participantes, coloca una entrada de pasar en su diario y enva el mensaje de pasar a todos los participantes. Cuando un participante lo recibe, l completa la subTi. Si hay alguno que no puede o no quiere completar las subTi, lo comunica al coordinador, quien escribe una entrada de abortar en su diario y enva el mensaje de abortar a todos los participantes. Para reducir la redundancia de bloqueos y los problemas de disponibilidad, se tiene como meta la de garantizar una copia semntica, esto es como si existiera una sola copia. Algunos protocolos38

Iniciar la ejecucin de la transaccin. Dividir la transaccin en varias subtransacciones, las cuales ha de distribuir en las localidades apropiadas para su ejecucin. Coordinar la terminacin de la transaccin, ya sea que quede ejecutada o abortada en todas las localidades.


permiten solo bloquear la copia primaria, otros bloquear solo las copias disponibles, otros que no todos los participantes con copia pasen, etc. Actualmente no todos los manejadores proveen las facilidades de optimizacin de consultas distribuidas o de manejo de rplicas.

39


Control de Concurrencia

40


Un mtodo de control de concurrencia es correcto si es serializable, es decir existe una secuencia equivalente en que las operaciones de cada transaccin aparecen antes o despus de otra transaccin pero no entremezcladas. Una ejecucin serial de transacciones es siempre correcta. Se debe sincronizar las transacciones concurrentes de los usuarios, extendiendo los argumentos para la serializabilidad y los algoritmos de control de concurrencia para la ejecucin en ambientes distribuidos. La finalidad del control de concurrencia es asegurar la consistencia de los datos al ejecutar transacciones, y que cada accin atmica sea completada en un tiempo finito. Problemas de concurrencia especficos de las bases de datos distribuidas: Consistencia de copia mltiple (se produce cuando un mismo dato esta en varias localizaciones). Adems se siguen dando los mismos problemas para bases de datos centralizadas (prdida de actualizaciones, dependencia neutral (uncommitted dependency) y anlisis inconsistentes).

Serializacin distribuida: Si cada planificador de ejecucin local es serializable y las rdenes locales serializadas son idnticas (es decir, respetan el orden de secuencia), entonces el planificador global es serializable.

Hay dos soluciones para el control de concurrencia en un ambiente distribuido: El bloqueo (lock) garantiza que la ejecucin concurrente. En este caso hay que tener cuidado de que no se produzcan interbloqueos (ni a nivel local ni a nivel global). Las marcas de tiempo garantizan la ejecucin concurrente segn el orden fijado en las marcas de tiempo. Este asegura la serializacin global. Si solo hay una copia de cada dato entre todos los nodos, se pueden usar mecanismos de control de concurrencia para sistemas centralizados, aunque con modificaciones.

Protocolos de bloqueo (locking protocols). Estos son todos de dos fases: 2PL centralizado

Este tipo de bloqueo de caracteriza por que consta de un nico planificador, o gestor de bloqueos (lock manager), para la totalidad del SGBD Distribuido que pueden garantizar (grant) y liberar (release) bloqueos. Funcionamiento: 1. El coordinador de transacciones local divide la transaccin en subtransacciones, usando el catlogo global del sistema. Si la transaccin implica actualizar un dato que est replicado, el coordinador solicita un bloqueo de escritura de todas las copias antes de actualizar cada copia y liberar los bloqueos. El coordinador puede elegir cualquiera de las copias de un dato replicado para lectura.41


2.

El gestor de transacciones local, implicado en la transaccin global, solicita y libera los bloqueos que mantiene el gestor centralizado de bloqueos usando las reglas usuales para el bloqueo en dos fases. El gestor centralizado de bloqueos comprueba que las peticiones de bloqueo sobre un dato sean compatibles, de manera que el gestor de bloqueos enva un mensaje de vuelta al nodo que origin la peticin reconociendo que el bloqueo ha sido concedido. En caso contrario, coloca la peticin en una cola hasta que el bloqueo pueda ser realizado.

3.

2PL con copia primaria

Se caracteriza por: Cada gestor de bloqueos local es responsable de un conjunto de datos, de manera que se elige una copia como copia primaria; el resto de copia se llaman copias esclavas. La eleccin del nodo primario es flexible, y el nodo elegido no contiene necesariamente la copia primaria de ese dato. 2PL distribuido

Se caracteriza por: Se distribuye un gestor de bloqueo en cada nodo. Cada uno es responsable de la gestin de bloqueos de los datos que contiene en ese nodo. El 2PL distribuido implementa una protocolo de control de replicas Read-One-Write-All. Cualquier copia de un dato replicado puede ser usada para operaciones de lectura, pero todas las copias deben ser bloqueadas para escritura antes que se puedan modificar. Bloque mayoritario.

Se caracteriza por: Se mantiene un gestor de bloqueos en cada nodo para gestionar los bloqueos de ese nodo. Cuando se ejecuta una transaccin que trabaja con un dato que esta replicado, debe enviar una peticin de bloqueo a ms de la mitad de los nodos donde esta el dato Protocolos de marcas de tiempo (timestamp protocols) Su objetivo es ordenar las transacciones globalmente de manera que transacciones con una marca de tiempo menor, obtengan la prioridad en el caso de conflicto. El problema es que los relojes de nodos diferentes podran no estar sincronizados.

42


Manejo de Bloqueos

43


Si se les hace algunas modificaciones, los algoritmos de prevencin y deteccin de bloqueos pueden aplicarse en un sistema distribuido. Por ejemplo, el enfoque de ordenamiento por horas de entrada puede aplicarse directamente a una configuracin distribuida. La prevencin de bloqueos puede hacer que algunas transacciones esperen y otras retrocedan sin que sea realmente necesario. Adems es posible que algunas de las tcnicas de prevencin de bloqueos obliguen a participar en la ejecucin de una transaccin a ms localidades de las estrictamente necesarias. Si se permite que ocurran bloqueos, para depender despus de la detencin de los mismos, el principal problema en un sistema distribuido ser decidir como se va a mantener el grafo de espera. En todos estos esquemas se requiere que cada localidad mantenga un grafo de espera local. Los nodos del grafo corresponden a todas las transacciones (locales o no) que en un momento dado utilizan o solicitan algunos de los datos que pertenecen a esa localidad. Observemos que las transacciones T2 y T3 aparecen en ambos grafos, lo que indica que estas transacciones han solicitado datos de ambas localidades. Estos grafos de espera local estn construidos de la misma forma para transacciones locales y datos.T4 Cuando una T2 transaccin Ti en la localidad L1 necesite algn recurso que est siendo ocupado por la transaccin Tj en la T5 T3 localidad L2, enviar un mensaje a L2 T3 solicitndolo. La arista Ti Tj se insertar en ese momento en el grafo local de espera de la localidad L1. Naturalmente, si cualquier grafo de espera local contiene un ciclo, se habr presentado un bloqueo. Grafos de espera local Localidadembargo, el hecho de que ninguno de los grafos locales 2 espera contenga un ciclo no significa Localidad L de Sin L1 que no existan bloqueos. Para ilustrar este problema, consideramos los grafos de espera locales de la figura anterior. Ambos grafos son acclicos; no obstante, existe un bloqueo en el sistema. El bloqueo existe porque la unin de los grafos locales de espera contiene un ciclo. Este grafo se muestra en la figura siguiente. T1 T2

44


T1

T2

T4

T5

T3

Grafo de espera global para la figura anterior

Algunos esquemas de uso comn para organizar el grafo de espera en un sistema distribuido son el enfoque centralizado y el enfoque de distribucin total, existen otros, pero nos abocaremos a describir stos. Enfoque centralizado En el enfoque centralizado se construye y mantiene un grafo de espera global (unin de todos los grafos) en una sola localidad, que ser el coordinador de deteccin de paralizaciones. Dado que existe un retraso de comunicaciones en el sistema, es menester distinguir entre dos tipos de grafos de espera. El grafo real describe el estado real, pero desconocido del sistema en cualquier instante en el tiempo, tal y como lo vera un observador omnisciente. El grafo construido es una aproximacin que el controlador genera durante la ejecucin de su algoritmo. Es obvio que el grafo construido debe generarse de tal manera que, cada vez que se invoque el algoritmo de deteccin, los resultados sean correctos, en el sentido de que, si ocurre un bloqueo, ste se reportar rpidamente, y, si se reporta un bloqueo, es porque de hecho el sistema ser en un estado de bloqueo. El grafo de espera global puede construirse: Cada vez que se inserta o elimina una arista en alguno de los grafos de espera locales. Peridicamente, una vez que se haya efectuado cierto nmero de cambios en un grafo de espera local. Siempre que el coordinador tenga que invocar el algoritmo de deteccin de ciclos.

Cuando se invoca el algoritmo para deteccin de ciclos, el coordinador examina su grafo global. Si encuentra un ciclo, se elige la vctima que debe retroceder. el coordinador debe informar a todas las localidades de que una transaccin determinada sido elegida como vctima. Las localidades, a su vez, hacen retroceder a dicha transaccin. Cabe hacer notar que en este esquema es posible que se efecten retrocesos innecesarios como resultado de dos situaciones:

Es posible que existan dos ciclos falsos en el grafo de espera global. Para ver esto, consideremos una instantnea del sistema representado por los dos grafos de espera de la45


figura que se muestra a continuacin. Suponemos que T2 libera el recurso que estaba ocupando en la localidad L1, haciendo que se elimine la arista T1 T2 en L1. A continuacin, la transaccin T2 solicita un recurso que T3 est ocupando en la localidad L2, el resultado es la insercin de la arista T2 T3 en L2. Si el mensaje insertar T2 T3 enviado por L2 llega antes que el mensaje eliminar T1 T2 de L1, es posible que el coordinador encuentre el ciclo falso T1 T2 T3 despus de la insercin (pero antes de la eliminacin). En tal caso se iniciar la recuperacin de bloqueos, pese a que no existe bloqueo.

T1

T1

T3 T2 L1 T1 L2

T2 CoordinadorCiclos falsos en el grafo de espera global

T3

Tambin es posible que se efecten retrocesos innecesarios en el caso en que si se haya presentado un bloqueo y se haya elegido una vctima, pero al mismo tiempo una de las transacciones se aborte por razones que anda tiene que ver con el bloqueo. Por ejemplo, suponemos que la localidad L1 de la figura anterior decide abortar a T2. Al mismo tiempo que el coordinador acaba de descubrir un ciclo y ha elegido a T3 como vctima. Tambin T2 como T3 retrocedern, aunque bastaba con que retrocediera T2.

46


Enfoque de Distribucin totalEn el algoritmo de deteccin de bloqueos totalmente distribuido, todos los controladores comparten equitativamente la responsabilidad de detectar los bloqueos. En este esquema, cada una de las localidades construye un grafo de espera local que representa una parte del grafo total, dependiendo del comportamiento dinmico del sistema. La idea es que, si existe un bloqueo, aparezca un ciclo en (por lo menos) uno de los grafos parciales. A continuacin se presenta un algoritmo de este tipo, en el cual requiere de la construccin de grafos parciales en todas las localidades. Cada una de las localidades mantiene su grafo de espera local. Estos grafos locales difieren de los antes mencionados en que se agrega un nodo adicional, Tex al grafo. Existir un arco Ti Tex en el grafo si Ti est esperando un dato de otra localidad que est siendo ocupado por cualquier otra transaccin. De manera similar, existir un arco Tex Ti en el grafo si existe una transaccin en otra localidad que est esperando un recurso que Ti est esperando en sta. En el caso en que un grafo de espera local contiene un ciclo en el que no participa el nodo T ex , entonces el sistema se encontrar en un estado de bloqueo. Sin embargo, la existencia de un ciclo que incluya a Tex , implica la posibilidad de que se haya presentado un bloqueo. Para verificar si es as, es necesario invocar un algoritmo distribuido de deteccin de bloqueos. Suponemos que el grafo de espera de la localidad Li contiene un ciclo en el que participa el nodo Tex .Este ciclo debe tener la forma: Tex Tk1 Tk2 Tm Tex lo que indica que la transaccin Tk de Li est en espera para poder ocupar un dato de alguna otra localidad, por ejemplo Lj . Al descubrir este ciclo, la localidad Li mandar un mensaje de deteccin de bloqueos a la localidad Lj, el cual contendr informacin referente al ciclo.

T1

T2

Tex

T2

T4

T5

T3

Tex T3

Localidad L1

Localidad L2

Grafos de espera local

Cuando una localidad Lj recibe un mensaje de ese tipo, actualiza su grafo de espera local con la informacin que acaba de obtener. Una vez hecho eso, determina si en el grafo de espera nuevo existe un ciclo en el que no participe Tex. En caso afirmativo, se habr detectado un bloqueo y se invocar un esquema de recuperacin apropiado. Si se descubre un ciclo en el que participe T ex, Lj transmitir un mensaje de deteccin de paralizaciones a la localidad correspondiente, por ejemplo Lk. La localidad Lk, a su vez, repetir el procedimiento. As, despus de un nmero finito de repeticiones, bien se habr detectado un boqueo, o se suspender el algoritmo de deteccin.47


Para ilustrar lo anterior, examinamos los grafos de espera locales de la figura anterior. Suponemos que la localidad L1 descubre el ciclo: Tex T2 T3 Tex Puesto que T3 est esperando un dato de la localidad L2, la localidad L1 transmitir un mensaje de deteccin de paralizaciones que describa este ciclo a la localidad L2. En el momento en que L2 reciba este mensaje, actualizar su grafo de espera local para producir el grafo de espera de la figura siguiente. Este grafo contiene el ciclo: T2 T3 T4 T2 que no incluye al nodo Tex. Por tanto, el sistema est en estado de bloqueo y es conveniente invocar un esquema de recuperacin apropiado.Tex T2 T4

T3

Localidad L2

Grafo de espera local

Es conveniente apuntar que el resultado habra sido el mismo si la localidad L 2y hubiera descubierto primero el ciclo en su grafo de espera local y hubiera enviado el mensaje de

Date post:	12-Jul-2015
Category:	Documents
Upload:	reyna-olga-reyes-cruz
View:	1,806 times
Download:	1 times

Base de Datos Distribuidas

Documents