UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMTICA

MODELOS AVANZADOS DE BASES DE DATOS

BASE DE DATOS DISTRIBUIDAS

Grupo: Distribucin 1

Francisco Corbera Navas Alejandro Delgado Gallego

Fecha : 01/04/2008

Base de Datos Distribuidas

ndice
Introduccin ... 3 Sistemas gestores de Bases de Datos Distribuidas (SGBDD) ... 5 Tipos de SGBDD ... 5 Los objetivos de un SGBDD ..... 6 Arquitectura cliente-servidor . 8 Diseo de Bases de Datos Distribuidas ..9 Estrategias de Diseo 10 Fragmentacin ...12 Asignacin .13 Transacciones en base de datos distribuidas .14 Control de concurrencia ....15 Serializacin distribuida ....16 Protocolo de bloqueo (locking protocol) ...17 Protocolo de marcas de tiempo (timestamp protocol) ...17 Procesamiento de Consultas Distribuidas . ....17 Objetivos de la optimizacin de consultas .19 Caractersticas de los procesadores de consultas ...20 Arquitectura del procesamiento de consultas .20 Ventajas y desventajas de las Bases de datos Distribuidas 21 Conclusiones ..22 Bibliografa ....22

Base de Datos Distribuidas

Introduccin
Inicialmente podemos decir que las SBDD surgen como respuesta a la distribucin que las empresas ya tienen, al menos de manera lgica (divisiones, departamentos, etc) y que en ocasiones tambin tiene de manera fsica (plantas, fbricas, etc). Todo esto nos lleva a que posiblemente los datos tambin estn distribuidos, ya que cada unidad organizacional mantendr los datos con los que normalmente opere.

A cada uno de estas subdivisiones se les llama islas de informacin (sitios), y lo que hace un sistema distribuido es establecer los puentes necesarios para conectar a esas islas entre si.

En definitiva lo que pretende es que la estructura de la base de datos refleje la estructura de la empresa (principal beneficio de los sistemas distribuidos). Es en realidad una BD virtual compuesta de varias BDs reales distintas que se encuentran en varios sitios distintos.

Otra de las principales motivaciones para el desarrollo de sistemas de bases de datos es el deseo de integrar los datos operacionales de una organizacin y proporcionar un acceso controlado a esos datos. Aunque la integracin y el acceso controlado pueden implicar la necesidad de utilizar mecanismos de centralizacin, el objetivo en realidad no es ese. De hecho, el desarrollo de redes informticas promueve el modo descentralizado de trabajo.

Los SGBD distribuidos deberan ayudarnos a resolver el problema de las islas de informacin. Esto puede ser resultado de la separacin geogrfica, de la incompatibilidad de las arquitecturas informticas, de los protocolos de comunicaciones, etc. Si se consigue integrar las bases de datos en un todo lgico coherente, podemos resolver el problema.

Con todo esto podemos dar una definicin ms formal de base de datos distribuida (BDD) como una coleccin de mltiples bases de datos interrelacionadas lgicamente y distribuidas por una red de computadores.

Base de Datos Distribuidas

Es importante tener clara la diferencia que existe con el procesamiento distribuido, en el cual existe una BD centralizada a la que se puede acceder a travs de una red informtica. En las siguientes figuras podemos ver claramente la diferencia entre ambos:

Base de Datos Distribuida

Procesamiento Distribuido

El Sistema Gestor de Bases de Datos Distribuido (SGBDD) es el sistema software que permite gestionar la BDD y hace que dicha distribucin sea transparente para los usuarios.

Un SGBDD est compuesto por una nica base de datos lgica dividida en una serie de fragmentos que pueden estar replicados en diferentes instalaciones. Cada fragmento se almacena en uno o ms ordenadores bajo el control de un SGBD independiente. Todos estos ordenadores (instalacin o nodo) del sistema estn conectados entre s mediante una red de comunicaciones.

Clasificaremos las BDD segn dos criterios: Homogneas o heterogneas dependiendo de si todos los servidores utilizan el mismo SGBD o no . De rea local o de rea ancha segn sea la red de comunicaciones que conecta los servidores.

Por otra parte y con lo que respecta a las implementaciones comerciales, la mayora de los productos SQL actuales proporcionan algn tipo de soporte de base de datos distribuida, con diversos grados de funcionalidad. Ingres/Star. La opcin de base de datos distribuida de Oracle. La propiedad de datos distribuidos de DB2. Informix y SQL Server.

Base de Datos Distribuidas

Vale la pena resear que todos estos sistemas son relacionales, adems hay varias razones que iremos descubriendo a lo largo de este tema, que aconsejan que para que un sistema distribuido sea exitoso, debe ser relacional.

Sistemas gestores de Bases de Datos Distribuidas (SGBDD)

Software que hace transparente al usuario la gestin de una base de datos distribuida. En adelante lo llamaremos SGBDD.

Entre sus funciones particulares destacan: Poder acceder a sitios remotos. Transmitir consultas y datos a travs de redes de telecomunicaciones. Rastrear la pista de distribucin y replicacin de los datos. Capacidad de elaborar estrategias de ejecucin. Control de concurrencia. Mantener la consistencia de las copias de un elemento de informacin. Capacidad de decidir qu versin de la copia de un elemento de informacin es la que tiene que ser accedida en un momento determinado. Recuperacin ante cadas. Control de la seguridad para mantener privilegios de acceso a los datos distribuidos.

Para ofrecer todas las funcionalidades vistas un SGBDD debe contar (al menos) con los siguientes componentes: Componente de manejo de la base de datos. Componente de comunicacin de datos. Diccionario de datos Componente de base de datos distribuida.

Tipos de SGBDD
Hay diferentes tipos de SGBDD. El factor para categorizarlos es su grado de homogeneidad. Partiendo de l, tenemos dos tipos de SGBDD.

Homogneos: todos los nodos utilizan el mismo SGBD Heterogneos: los nodos pueden utilizar distintos SGBD.

Base de Datos Distribuidas

Los sistemas homogneos son mucho ms fciles de disear y mantener. Esta tcnica permite el crecimiento incremental, haciendo que la adicin de un nuevo nodo al SGBDD sea sencilla, y tambin permite conseguir unas mayores prestaciones, al aprovechar las capacidades de procesamiento paralelo de los mltiples nodos.

Los objetivos de un SGBDD

Una vez que nos hemos introducido en el mundo de las SBDD, estamos preparados para establecer el principio fundamental de los sistemas distribuidos: Los usuarios deben actuar de la misma forma tanto si estn ante un sistema distribuido como si estn ante uno centralizado.

En 1987, uno de los ms importantes y conocidos tericos de las bases de datos relacionales, C. J. Date, propuso 12 objetivos que deban alcanzar los diseadores en sus BDD junto con sus SGBDD basndose en este principio fundamental. Las 12 reglas son las siguientes:

1. Autonoma local: Los sitios de un sistema distribuido deben ser autnomos en el mayor grado posible, lo que permite una mayor seguridad, control de concurrencia y copias de seguridad. Esto quiere decir que los datos deben ser gestionados localmente, las operaciones son locales y todas las operaciones en un puesto son controladas por ese puesto.

2. Independencia de un sitio central: El anterior objetivo implica que todos los sitios deben ser tratados como iguales, por lo tanto no debe existir ningn sitio maestro central del cual dependan el resto. Esto es as por das razones fundamentales: Puede ser un cuello de botella. Puede ser vulnerable, si ste falla tambin fallar todo el sistema. 3. El sistema debe estar en continua operacin: Un fallo en uno de los nodos no debe afectar al sistema. Tampoco si se aaden nuevos nodos. As, un SD deber proporcionar las siguientes caractersticas. Fiabilidad (o confiabilidad): probabilidad de que el sistema est listo y funcionando en cualquier momento dado. Disponibilidad: probabilidad de que el sistema est listo y funcionando continuamente a lo largo de un perodo especificado. Podemos decir que nunca

Base de Datos Distribuidas

debera ser necesario apagar el sistema para realizar tareas como: aadir un sitio, creacin dinmica de fragmentos, actualizacin de versiones, etc.

4. Transparencia de ubicacin: Para el usuario la localizacin fsica de los datos debe ser transparente. No necesita saber dnde est el dato para utilizarlo.

5. Transparencia de fragmentacin: Los usuarios deben comportarse, como si los datos en realidad no tuvieran fragmentacin alguna, la cual es necesaria por razones de rendimiento. Este objetivo es deseable, como el anterior, porque simplifica los programas de los usuarios y sus actividades en el sitio.

6. Transparencia en la replicacin: Consiste en que el usuario no debe tener conciencia de la replicacin de los datos, as como de su destruccin La replicacin es necesaria por las siguientes razones: Un mayor rendimiento, puesto que disponemos de copias locales. Una mayor disponibilidad, puesto que los datos son accesibles siempre al tenerse varias copias. La principal desventaja, es que hay que mantener actualizadas todas las copias de ese objeto o dato replicado. Esto nos lleva al problema de la propagacin de las actualizaciones.

7. Procesamiento de consultas distribuidas: El sistema debe ser capaz de procesar consultas que afecten a datos de ms de un sitio y hacerlo de forma optimizada. Este hecho puede ser considerado como otra razn por la que los sistemas distribuidos siempre son relacionales (las peticiones relacionales son optimizables, mientras que las no relacionales no lo son).

8. Administracin de transacciones distribuidas: El sistema distribuido debe disponer de mecanismos (protocolos) adecuados para el control de concurrencia y la recuperacin de transacciones distribuidas. Una transaccin puede acceder y modificar datos en diferentes nodos sin que el usuario se entere de que mltiples sitios se estn viendo afectados por la transaccin.

9. Independencia del hardware: Es necesario tener la posibilidad de ejecutar el mismo SGBDD en diferentes plataformas de hardware (IBM, ICL, HP, PC, SUN) y, adems, hacer que esas mquinas diferentes participen de igual forma en un sistema distribuido.

Base de Datos Distribuidas

10. Independencia del sistema operativo: Un vez ms, es necesario tener la posibilidad de ejecutar el mismo SGBDD, en diferentes plataformas de sistema operativo (UNIX, Windows XP ) bajo un mismo sistema distribuido.

11. Independencia de la red: El sistema debe tener la posibilidad de soportar tambin, una variedad de redes de comunicacin distintas.

12. Independencia del SGBD: Lo que en realidad se pretende es que todos los ejemplares del SGBDD locales en sitios diferentes soporten la misma interfase, que en este caso sera el estndar SQL oficial. Con esto conseguiremos que el sistema distribuido fuera heterogneo, al menos en cierta medida ya que en realidad los fabricantes solo cumplen determinadas caractersticas de este estndar, que suelen ser distintas de unos a otros.

Debido a que estos cuatro ltimos objetivos son ideales y no existen estndares al respecto, solo cabe esperar un cumplimiento parcial de los mismos.

Arquitectura cliente-servidor
Las aplicaciones de bases de datos distribuidas se desarrollan en el contexto de la arquitectura cliente-servidor.

Base de Datos Distribuidas

La arquitectura cliente-servidor se cre para manejar los nuevos entornos de cmputo en los que un gran nmero de PC, estaciones de trabajos, servidores de ficheros, impresoras, servidores de bases de datos, servidores Web y otros equipos estn interconectados a travs de una red.

En un sistema cliente-servidor tenemos dos partes fundamentales:

Cliente. Se podra corresponder con una mquina usuario que proporciona capacidad de interfaz al usuario y procesamiento local. Servidor. Es una mquina que puede proporcionar a las mquinas cliente servicios, tales como impresin, acceso a ficheros, o acceso a la base de datos. An no se ha establecido de forma exacta cmo dividir la funcionalidad del SGBD entre el cliente y el servidor aunque existen varios enfoques.

En cuanto al software, en un sistema de gestin de bases de datos es normal dividir los diferentes mdulos software en tres niveles:

El software de servidor que gestiona los datos locales en un sitio, al igual que el software del SGBD centralizado. El software del cliente que soporta casi todas las tareas de distribucin y maneja las interfaces de usuario El software de comunicaciones (algunas veces junto con el sistema operativo distribuido) proporciona las primitivas de comunicacin que utiliza el cliente para transmitir instrucciones y datos entre los sitios necesarios.

Diseo de Bases de Datos Distribuidas

El diseo de base de datos distribuidas se ocupa de tomar decisiones en la ubicacin de programas que accedern a la base de datos y sobre los propios datos que la constituyen, a lo largo de los diferentes nodos que constituyen la red. Tenemos que distribuir pequeos elementos entre diferentes computadores, es decir, distribuir la informacin.

La organizacin de los sistemas de bases de datos distribuidas se puede analizar desde tres dimensiones:

Base de Datos Distribuidas

El nivel de comparticin. Esta caracterstica posee tres alternativas dependiendo del nivel de comparticin: o Inexistente. Cada aplicacin y sus datos se ejecutan en una maquina sin comunicacin con otros programas o datos. o Comparticin de datos. Cada mquina posee sus propias aplicaciones locales pero se comparte los datos. o Comparticin de datos y programas. Las aplicaciones locales en una mquina pueden invocar servicios en otras y adems comparten los datos. Caractersticas de acceso a los datos. Estas caractersticas pueden ser dos: o o Esttico. El modelo de acceso a los datos no vara con el tiempo. Dinmico. El modelo de acceso a los datos vara con el tiempo.

El nivel de conocimiento de la caractersticas de acceso: o Sin informacin. Los diseadores no tienen informacin de cmo acceden los usuarios a los datos. o Con informacin parcial. Los diseadores no poseen toda la informacin de cmo acceden los usuarios a los datos. o Con informacin total. Los diseadores poseen la informacin completa de cmo los usuarios acceden a los datos.

Estrategias de Diseo
Estas estrategias son las utilizadas al disear una base de datos relacional, pero aadiendo un paso de diseo de la distribucin. A la hora de abordar el diseo de una base de datos distribuida podremos optar principalmente por dos tipos de estrategias: la estrategia ascendente y la estrategia descendente:

La estrategia ascendente (botton-up): En este caso se partira de los esquemas conceptuales locales y se trabajara para llegar a conseguir el esquema conceptual global. Despus se pasara al diseo de distribucin. Esta estrategia suele ser utilizada para integrar varias bases de datos centralizadas existentes.

En la estrategia descendente (top-down) se parte de cero y se avanza en el desarrollo del trabajo. Los pasos a realizar mediante esta estrategia son los siguientes:

10

Base de Datos Distribuidas

1. Anlisis de requisitos: En esta etapa se determinan los requisitos para obtener tanto los datos como las necesidades de procesamientos de los usuarios. Igualmente se debern fijar los requisitos del sistema, los objetivos que debe cumplir en cuanto a rendimiento, seguridad, disponibilidad y flexibilidad teniendo en cuenta aspectos econmicos. Al finalizar esta etapa debemos poseer unos objetivos que servirn como entrada para dos actividades: Diseo conceptual y diseo de vistas.

2. Diseo de vistas: En esta etapa se definirn las interfaces del usuario con el sistema. Se determinan las aplicaciones que usaran la base de datos as como datos estadsticos o estimaciones de las mismas sobre frecuencia de acceso de cada aplicacin a cada tabla, que nos permitir poseer informacin que nos ayudar a optimizar ciertas partes y crear un diseo conceptual mas eficiente. Al finalizar esta etapa se debera poseer toda la informacin de acceso y la definicin de los esquemas externos.

3. Diseo conceptual: En esta etapa se suele realizar la integracin de las vistas del usuario. Como resultado de la ejecucin de estas dos ltimas etapas debemos tener un esquema conceptual global, informacin de acceso y los esquemas externos que servirn de entrada para la prxima etapa.

4. Diseo de la distribucin. Esta etapa es representativa en el diseo de BBDD distribuidas ya que es la etapa que la diferencia del diseo de bases de datos centralizadas. Consiste obtener diferentes esquemas conceptuales locales a partir del esquema conceptual global y la informacin de acceso. En este punto debemos considerar dos actividades importantes: Fragmentacin: consiste en decidir como dividimos la base de datos y en que partes. Asignacin: consiste en ubicar los fragmentos que hemos obtenido en los distintos nodos.

5. Diseo fsico. A partir de los esquemas conceptuales locales y la informacin de acceso obtenidos en las etapas anteriores se debe obtener el esquema fsico.

6. Monitorizacin y ajustes. Este paso se realiza para llevar un control del proceso y e intentar reparar lo errores o desviaciones que se produzcan en el proceso.

11

Base de Datos Distribuidas Fragmentacin

La fragmentacin es el proceso encargado de dividir una relacin en otras subrelaciones de menor tamao, y su objetivo es encontrar la unidad apropiada de distribucin. Existe una serie de razones por las que llevar a cabo la fragmentacin: Utilizacin: En general, las aplicaciones funcionan con vistas que normalmente son subconjuntos de relaciones. Por tanto, es lgico considerar como unidad de distribucin a esos subconjuntos de relaciones. Eficiencia: Los datos se almacenan cerca del lugar en el que son utilizados con mayor frecuencia. Adems, los datos que las aplicaciones locales no necesitan no se almacenan en ese nodo. Paralelismo: La descomposicin de una relacin en fragmentos permite que una transaccin pueda ser dividida en subconsultas. Cada subconsulta operar sobre el fragmento adecuado. En definitiva, se aumenta el grado de concurrencia. Seguridad: Los datos no requeridos por las aplicaciones locales no se almacenan en ese nodo, por lo que no estn disponibles para los usuarios no autorizados.

Qu unidad de fragmentacin tomar?

El principal problema de la fragmentacin consiste en encontrar una unidad de fragmentacin. Se podra considerar como unidad de fragmentacin una relacin completa pero esto no es ptimo debido a cuestiones de eficiencia. Las siguientes afirmaciones nos dan razones por las que la relacin no es la unidad de fragmentacin ideal: Las vistas son subconjuntos de varias relaciones, es decir, se forman a partir de trozos de varias tablas. Ya que cada aplicacin posee sus propias vistas lo mas adecuado ser conseguir que la mayora de las vistas estn definidas sobre subtablas locales a cada aplicacin y as logramos un incremento del rendimiento. Luego la mejor unidad de fragmentacin seria subconjuntos de relaciones. Al descomponer una relacin en fragmentos, se permite el procesamiento concurrente de transacciones ya que no se bloquean tablas enteras sino subtablas, por lo que dos consultas pueden acceder a la misma tabla en fragmentos distintos. Al descomponer una relacin en fragmentos, se permite la paralelizacin de consultas al poder descomponerlas en subconsultas, cada una de las cuales trabajar con un fragmento distinto producindose un incremento del rendimiento.

12

Base de Datos Distribuidas

Inconvenientes de la fragmentacin:

Si las aplicaciones tienen requisitos que necesiten la descomposicin de la relacin en fragmentos mutuamente exclusivos, estas aplicaciones cuyas vistas estn definidas sobre ms de un fragmento pueden poseer menor rendimiento.

Si una vista de usuario no se puede definir sobre un solo fragmento necesitarn un control semntico que dificulta y degrada el rendimiento debido a que la verificacin de las restricciones de integridad implican buscar fragmentos en mltiples localizaciones.

Tipos de fragmentacin:

Fragmentacin horizontal. Consiste en el particionamiento en tuplas de una relacin global en subconjuntos, donde cada subconjunto puede contener datos que cumplen una condicin y se puede definir expresando cada fragmento como una operacin de seleccin sobre la relacin global. Fragmentacin vertical. En este tipo de fragmentacin se dividen el conjunto de atributos en grupos. Los fragmentos se obtienen proyectando la relacin global sobre cada grupo. La fragmentacin es correcta si cada atributo se mapea en al menos un atributo del fragmento. Fragmentacin mixta. Este tipo de fragmentacin consiste en la aplicacin de fragmentacin vertical y despus fragmentacin horizontal o viceversa.

Asignacin
Supongamos que tenemos un conjunto de fragmentos F={F1, F2, , Fn} y una red que consiste en este conjunto de sitios S={S1, S2, , Sm}. El problema de asignacin determina la distribucin ptima de F en S. La optimalidad puede ser definida de acuerdo a dos medidas:

1. Coste mnimo. Consiste en el coste de la comunicacin de datos, coste del almacenamiento y el coste de procesamiento. Nuestro objetivo es encontrar una funcin que minimiza el coste.

2. Rendimiento. La estrategia de asignacin se disea para mantener una mtrica de rendimiento. Las dos mtricas ms utilizadas son el tiempo de respuesta y el throughput (productividad).

13

Base de Datos Distribuidas

Cuando una serie de datos se asignan, estos pueden replicarse para mantener una copia o varias idnticas. Por tanto, respecto a la replicacin, en la asignacin de fragmentos existen tres estrategias:

No soportar replicacin. Cada fragmento reside en un solo sitio. Soportar replicacin completa. Cada fragmento reside en cada uno de los sitios. Soportar replicacin parcial. Cada fragmento reside en alguno de los sitios.

Se considera de gran utilidad la replicacin cuando el nmero de consultas de solo lectura es bastante mayor que el nmero de consultas de actualizaciones.

Transacciones en base de datos distribuidas

La pregunta es qu pasa cuando dos consultas tratan de actualizar el mismo elemento de datos o si el sistema falla durante la ejecucin de una consulta. Intuitivamente se puede 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 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.

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

14

Base de Datos Distribuidas

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.

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

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.

A ms bajo nivel nos encontramos con la necesidad de transferir los datos entre el almacenamiento en disco y la memoria principal. De esto se encarga el gestor de bferes. En un SGBDD, todos estos mdulos se encuentran tanto a nivel local en cada equipo como a nivel de nodo. Estos ltimos son los denominados gestores globales de transacciones. El procedimiento a seguir cuando se ejecuta una transaccin global en un nodo N1 es la siguiente: o El gestor global de transacciones del nodo N1, divide la transaccin en una secuencia de subtransacciones, siguiendo la informacin guardada en el catlogo global del sistema. o El encargado de la comunicacin de datos del nodo N1 enva dichas subtransacciones a los nodos adecuados, por ejemplo N2 y N3. o Los gestores globales de transacciones del los nodos que reciben los datos, se encargan de gestionarlos y los resultados de las secuencias de instrucciones SQL se devuelven a travs del encargado de la comunicacin de datos al primer nodo N1.

15

Base de Datos Distribuidas

Control de concurrencia
Todos los mecanismos de control de concurrencia deben asegurar la consistencia de los objetos y cada transaccin atmica ser completada en un tiempo finito. 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.

Uno de los problemas de concurrencia especficos de las bases de datos distribuidas es la 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 la ejecucin concurrente. En este caso hay que tener cuidado de que no se produzcan interbloqueos. 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.

16

Base de Datos Distribuidas Protocolo de bloqueo (locking protocol)

Nos fijaremos en el Protocolo de Bloqueo de Dos Fases distribuido (2PLP) Se caracteriza por distribuir 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 2PLP 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.

Protocolo de marcas de tiempo (timestamp protocol)

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.

Procesamiento de Consultas Distribuidas

El procesamiento de consultas ha recibido una gran atencin en las bases de datos distribuidas, ya que es un aspecto crtico en el rendimiento de las mismas.

Sin embargo el procesamiento de consultas es mucho ms difcil en ambientes distribuidos que en centralizados, ya que en ambientes distribuidos existe un gran nmero de parmetro que afectan el rendimiento de las consultas distribuidas, mientras que en sistemas centralizados los lenguajes de base de datos relacionales permiten la expresin de consultas complejas en una forma concisa y simple.

La funcin principal de un procesador de consultas relacionales es transformar una consulta en una especificacin de alto nivel, normalmente en clculo relacional, a una consulta equivalente en una especificacin de bajo nivel, normalmente alguna variacin del lgebra relacional.

17

Base de Datos Distribuidas

La transformacin es correcta si la consulta de bajo nivel tiene la misma semntica que la consulta original, es decir, si ambas consultas producen el mismo resultado. Para verificar si es correcta la transformacin se hace un mapeo bien definido entre el clculo relacional y el lgebra relacional.

Otro aspecto importante es el consumo de recursos. Hay que elegir una buena estrategia de ejecucin que sea eficiente para que as minimicemos el consumo de recursos de nuestro sistema.

18

Base de Datos Distribuidas

Ejemplo: Consideramos esta Base de Datos:

EMPRESA(ID_EMPRESA,NOMBRE_EMPRESA) PROYECTO(ID_EMPRESA,NOMBRE_PROYECTO,FUNCION)

La consulta trata de encontrar todos las empresas a las que les subvencionan un proyecto.

Expresin SQL: SELECT NOMBRE_EMPRESA FROM EMPRESA E, PROYECTO P WHERE E.ID_EMPRESA=P.ID_EMPRESA AND FUNCION = BENEFICIARIO

Dos consultas equivalentes el lgebra relacional seran:

1) EMPRESA (FUNCION-BENEFICIARIO E.ID-P.ID (E x P)) 2) ENOMBRE (E>< ID (FUNCION=BENEFICIARIO (P))

La segunda estrategia es mejor, ya que evitamos calcular el producto cartesiano de E x P, por lo que la eficiencia mejora (al disminuir el coste computacional).

Sin embargo, en los sistemas distribuidos (a diferencia de los sistemas centralizados) el lgebra relacional no es suficiente para expresar la ejecucin de estrategias, que debe ser complementada con operaciones para el intercambio de informacin entre nodos. Entre estas operaciones destacan las que hacen el procesador de consultas distribuidas para elegir el orden de las operaciones del lgebra relacional, el mejor sitio para procesar datos y la forma en que los mismos deben ser transformados.

Objetivos de la optimizacin de consultas

El objetivo PRINCIPAL de la optimizacin de consultas distribuidas es mejorar la eficiencia de las mismas. Ms detalladamente, podramos decir que se trata de transformar una consulta sobre una base de datos distribuidas en una especificacin de alto nivel a una estrategia de ejecucin eficiente en un lenguaje de bajo nivel.

Tenemos que minimizar la siguiente funcin de coste:

En funcin el ambiente en que se trabaje cada uno de los factores de la expresin anterior pueden llegar a tener pesos diferentes. Por ejemplo, en la redes WAN el coste de comunicacin

19

Base de Datos Distribuidas

domina dado que hay una velocidad de comunicacin relativamente baja. Es por esto que los algoritmos diseados para trabajar en entornos WAN suelen despreciar el coste de CPU y de entrada/salida. En redes LAN el peso las comunicaciones no es tan dominante y los tres factores se equiparan.

Otro factor importante a tener en cuenta a la hora de optimizar consultas en bases de datos distribuidas es saber la complejidad computacional de los diferentes tipos de operaciones que se pueden hacer. Antes hemos visto que ganbamos eficiencia al eliminar un producto cartesiano, que como veremos ahora, es la operacin ms compleja.

Veamos un listado de las principales operaciones del lgebra relacional junto con su complejidad: Seleccin y proyeccin sin eliminar duplicados: O(n) Proyeccin (con eliminacin de duplicados) y agrupacin: O(n*log n). Junta, semijunta, divisin, operaciones con conjuntos: O(n*log n). Producto cartesiano: O(n^2).

Caractersticas de los procesadores de consultas

Comparar un sistema centralizado con uno distribuido es una tarea complicada ya que ambos difieren en una gran cantidad de aspectos, desde su arquitectura hasta la forma de tratar una consulta. Vamos a enumerar las principales caractersticas de los procesadores de consultas distribuidas y que los diferencias de los procesadores de los sistemas centralizados: Tipo de optimizacin. Granularidad de la optimizacin. Tiempo de optimizacin Estadsticas Nodos de decisin. Topologa de la red.

Arquitectura del procesamiento de consultas

El procesamiento de consultas distribuidas podemos separarlo en cuatro fases o niveles, desde que la consulta llega hasta que se optimiza al mximo posible: Descomposicin de consultas. Localizacin de datos.

20

Base de Datos Distribuidas

Optimizacin global de consultas. Optimizacin local de consultas.

Ventajas y desventajas de las Bases de datos Distribuidas

Ventajas: Favorecer la naturaleza distribuidora de muchas aplicaciones, no solamente a nivel local sino incluso en diferentes lugares. Se consigue una comparticin de los datos, sin perder un determinado control local. Crecimiento modular. El rendimiento se mejora. Cuando se distribuye una gran base de datos por mltiples sitios, las consultas locales y las transacciones tienen mejor rendimiento porque las bases de datos locales son ms pequeas. A parte de esta distribucin, se puede conseguir lo siguiente en estos sistemas: o o Reducir el nmero de transacciones ejecutndose por sitio. Un paralelismo entre las consultas ejecutando varias en sitios diferentes, descomponiendo una de ellas en subconsultas que puedan ejecutarse en paralelo. Aumento de la fiabilidad y la disponibilidad. Economa: es ms barato construir un sistema con pequeas computadoras que uno grande si ambos dan el mismo rendimiento. Por ltimo, la autonoma de estos sistemas es grande.

Desventajas: Hay una menor seguridad en cuanto al control de acceso a los datos: control de replicas y errores que puedan producirse en la red. Mayor complejidad en el diseo e implementacin del sistema. Adems si la replicacin de datos no se hace de forma adecuada, las ventajas se pueden transformar en desventajas. Excesivos costes en el intento de conseguir la transparencia mencionada anteriormente. Falta de estndares y de experiencia, una vez ms en estos modelos avanzados de BD. No se puede garantizar al 100 % el rendimiento y la fiabilidad.

21

Base de Datos Distribuidas

Conclusiones
Las bases de datos distribuidas son cada vez ms usadas por las empresas y suponen una ventaja competitiva frente a los sistemas centralizados, siempre y cuando la empresa en cuestin tenga necesidad de usar una base de datos de este tipo. Lo ms habitual es disponer de varias sedes y tener que manejar informacin comn, para lo cual las bases de datos distribuidas son especialmente tiles.

Es una tecnologa que ya lleva aos en rodaje por lo que tiene la madurez suficiente como para ser usada con garantas, no obstante, debido a la gran dependencia que estas bases de datos tienen de las telecomunicaciones, en Espaa nos encontramos muchos problemas para conseguir el rendimiento oportuno de las mismas.

Bibliografa
Distributed Databases, School of Science & Technology, Bell College (Hamilton) Silberschatz, Korth, y Sudarshan, Fundamentos de Bases de Datos, 4 ed. Mc Graw Hill CONNOLLY, Thomas M. y BEGG, Carolyn E., Sistemas de bases de datos: diseo, implementacin y gestin. Pearson - Addison Wesley, 4 edicin. Armes A. Elmasri y Shamkant B. Navathe, Fundamentos de Sistemas de Bases de Datos. 3 ed. Addison Wesley. http://www.fing.edu.uy/inco/cursos/interop/interPresencial/transparencias/queries.pdf http://www.mitecnologico.com/Main/OptimizacionDeConsultasDistribuidas http://sistemas-distribuidos-unerg.blogspot.com/2007/12/bases-de-datosdistribuidas.html http://catarina.udlap.mx/u_dl_a/tales/documentos/msp/alvarez_c_g/capitulo1.pdf

22